When scaling a team of engineers, the scope increases with it, and it becomes hard to maintain everyone’s focus. When it’s a group of five engineers, one leading engineer can make sure everything is on track by providing the projects and the needed support in execution for everyone. But when it’s a group of fifteen engineers — it’s harder to keep depending on one leading engineer to define the work and help with execution of everyone else. And the obvious answer — delegation — is not as easy as it sounds in these cases.
Often, most of the context and the big picture are held inside that one engineer’s head, and passed to the people around as a set of projects and tasks. Usually it disables independence of the engineers working on these projects. This can happen in cases where the scope becomes so complex that explaining the entire picture becomes ineffective. This behavior creates a dependency on this one engineer. It happened in my team in the last couple of months.
Lately my team grew, and our responsibility grew with it. Explaining the responsibility and the scope to other people has become non-trivial, and even though I keep trying, it’s been hardly working. I’ve been providing the projects and the tasks, helping wherever I can with execution, and taking accountability for both the plan and the execution. As the team continues to grow, I can no longer handle the scope in such a way, and I have to delegate in order to be able to handle everything. But, as mentioned above, it’s harder than it looks in a setup where the bigger picture is held inside my head only.
It’s all about phrasing the right context
While the experience described, I understood that a key factor in taking a step back is to be able to pass the full context in some way to the people around me. At the end — context is what enables people to be independent. I realized that trying to transfer the entire picture is not going to be possible in order to get other people fully independent — I had to simplify that big picture, and narrow the boundaries in some way.
In the book No Rules Rules Reed Hastings provides an interesting approach with regards to leadership that helped me here. He talks about the importance of “Leading with context, not control”. In short — in order to create a real bottom-up impactful work, a leader must provide the right context for the people around them. This will set them up to be effective and make the right decisions themselves. A leader should not provide any solutions/tasks. This method opens the organization up for innovation, and allows one to be independent in their work.
Providing context is narrowing the boundaries — from a high level view to something that is more specific and more actionable for people around. Each level in the hierarchy makes it more concrete. Sometimes, during this narrowing process, a bet must be taken by a leader. It happens when the narrowing process isn’t trivial (which is very common when innovative ideas are formed). That bet will result in a whole different set of contexts below them. The leader that made the leap is accountable for the success of the bet, and their people are accountable for execution (and for more bets along the way).
In the context of my day-to-day life — we are working on a migration of some pieces in our messaging infrastructure. The context I’ve been given from the organization was — “we need to ship this new architecture to the entire population soon in order to unlock several product enhancements”. In other words, I’ve been given the task of mitigating the engagement regressions we observed while conducting an A/B test (mainly drop in messages sent). Part of the complexity of this task is the fact no one really knows where these issues are coming from.
We conducted some experiments, making sure it isn’t one big bug that causes this. We analyzed some user behaviors. Eventually, in order to move forward and start fixing things — we had to take a leap, and make a bet on what are the things that will affect user engagement most, to try and bring it to neutrality.
The context I gave to the people in the team was “we need to make this tech stack performant at least like the previous one. Specifically, this exact interaction probably matters most”. The bet I was taking when saying that was — app performance will affect the most on user engagement, more than anything else. I am accountable for this leap, as the team of six engineers is now focused only on that specific interaction performance. I am now trying to take a step back, letting the talented folks in the team plan, innovate, and execute within this narrower context. While I’m still not entirely out of the picture — the path towards it is clearer now. Taking a step back will allow me to deal with other important issues, and will let other people around me grow, which is a very big benefit from this process as well.
The amount of context to provide depends heavily on the kind of engineers around. Ideally, the little context possible is better for everyone, because it enables a leading engineer to deal with other things, and lets the team be independent and to innovate. Engineers tend to grow whenever the context defined to them is getting wider (see my other post about it). We should always pursue providing as little context as we can, and probably to push our people with a bit less context than they are used to, in order to help them grow. For the leading engineers — the less context they provide, the more time is freed for them to handle other big challenges the organization is dealing with. They should be doing the leaps in their level, up to the point where people around them can be independent. When that happens, and they are no longer needed, it means they are doing their job well.
