Over the years, swinging back and forth between positions, I found myself often thinking of Charity Major’s The Engineer/Manager Pendulum blog post.
The best frontline eng managers in the world are the ones that are never more than 2-3 years removed from hands-on work, full time down in the trenches. The best individual contributors are the ones who have done time in management. And the best technical leaders in the world are often the ones who do both. Back and forth. Like a pendulum.
Charity Majors
In my case, the swinging is between working in Stream-Aligned and Enabling teams as defined by Skelton and Pais in Team Topologies.
Stream-aligned team: aligned to a flow of work from (usually) a segment of the business domain
Enabling team: helps a Stream-aligned team to overcome obstacles. Also detects missing capabilities.
Mathew Skelton & Manuel Pais
When working in each type of team, there are certain skills you practice more while you let others stay dormant. Here are some of the things I observed over the years on working on both sides.
Working in an Enablement team you come across a variety of problems and challenges. It’s part of your job to invest the time to find their patterns and look for the possible solutions that could apply to them. As a member of a Stream-aligned team you usually don’t have that broad knowledge. Often enough, you don’t even have the time to step back and see the big picture of the problem you face. That’s about the time you ask for outside help from Enabling teams.
Coming in to help as a member of an Enabling team you usually have people’s attention. There is time reserved to talk or work together with the Stream-aligned team to improve their work. Management negotiations are rarely required to achieve that. Nevertheless, if you were to ask for the same amount of time as a Stream-aligned team member to run some deep-dive sessions with your team, you might have to face a very different reality.
As a member of an Enabling team you rarely work alongside a Stream-aligned team long enough, before suggesting changes and improvements. But sometimes your suggestions, even though they make total sense, just fall to deaf ears. As member of the Stream-aligned team you know more about the nuances in your environment, for example that Joe won’t start working on a new issue on a Tuesday. So your suggestions, even if they are not ideal, might be easier adopted or at least have a chance.
Working in a Stream-aligned team you get to see the results of your work in the users’ hands and can measure the impact your software provided. Delivering something and seeing it used is something very tangible. In an Enabling team, your success is always indirect through the success of the Stream-aligned team. If it’s hard to tell how users will use your software it’s even harder to tell how development teams will adopt tools and processes developing the software. Apologies for the complicated sentence, but couldn’t find a way to express it better.
Last but not least, as a member of an Enabling team you rarely stay around to see how your suggestions have actually helped. You might come back for a review where you can observe what worked and what didn’t. But as member of a Stream-aligned team you get to live with the consequences of your decisions day by day. You experience, sometimes in painful detail, how things that make perfect sense in theory fail, making you more open to adopting solutions that even if they are not “right”, they are right for you.
Having the experience of working in a Stream-aligned team makes you better at helping out others when you join an Enabling team. And having been part of an Enabling team you have a broader knowledge to help out your Stream-aligned team. Given the chance, shifting between the two every so often can be a really beneficial thing for you, the people you work with and your business.
More Questions Than Answers 
2 thoughts on “Balancing Between Stream-Aligned and Enabling Teams”