How to Run Horizontal Teams At Scale

Problem

Some time ago, I took over a horizontal front-end team. This horizontal front-end team owned products which served as the first point of interaction to the customers. It also worked internally with a lot of vertical back-end teams. Those back-end teams would offload their requests at any given time and without much concern for our priorities and deadlines.

When I joined the team, everything was pretty much ad hoc. There was no sprint planning, and people would drop by asking the team to fix their bugs with the highest urgency. Without streamlining team processes, we would be able to serve neither our customers nor other teams.

Actions taken

I came up with a process that guardrailed how those vertical teams should approach us with their dependencies. The next step was the hard part, of working with all the EM's in bringing about the right set of alignment and agreement on the new process. The hardest part was to be able to run the show on the ground consistently sprint on sprint.

To address the customer side of things, we came up with a bug triaging process. These were self-serving guidelines that anyone could use to categorize bugs. We published and socialized our SLA, which made people aware of the new triaging procedures we established. Then we initiated an on-call process, which turned one person from the team into a gatekeeper who would deal with everything coming from the outside. That would allow the rest of the team to focus on actual work being shielded from numerous requests being dropped on them.

The other dimension to the team's success was to look at all the open source repositories on Github and how those repo's could be made self-serve thus reducing the number of tickets. By taking a more active approach, if a ticket was raised on GitHub detailing a request, we could push back by referring to the document that outlined what we would support and what not. Being one step ahead reduced a significant overhead for the team.

In the end, we started to conduct training for Sales and Solutions that would enable them to address many of the issues that in the past were handed over to us. There were many things they could take care of with minimal knowledge investment. That reduced the volume of things that would end on our plate so that we could focus on more specific tasks.

Lessons learned

• First and foremost, you should build trust with a new team. Without mutual trust, your efforts to introduce any change will be futile.
• Ensuring the alignment of all stakeholders is critical. Provide stakeholders with clarity on what the team is doing and make the process of regularly informing them automated.
• Identify pain points -- bug triaging, poor metrics, and training for Sales and Solutions -- and make a plan to address each of them. Solving one by one will help you reduce duplicated work and will allow you to focus on more specific work.
• Identify avenues where you can be more proactive. For example, create a FAQ and Wikis on GitHub to reduce the overall load or find another way to communicate in advance what you (don’t) support. Be always one step ahead to be able to push back unreasonable requests from other teams timely.