The Engineering Manager’s job includes helping their team become more effective at solving problems, and collaborating with other teams and departments to achieve results that their own team cannot achieve alone. EMs work to improve software development processes, encourage collaboration within the team and with the team’s stakeholders. They help the team to structure their work.
A complex software system is made from many components, and most development requires changes across several components.
Which teams get to work on which components? The answer to this question has a large and often unacknowledged impact on how Engineering Managers spend their time. The more components a team can work on, the less time an EM spends on negotiating with other EMs. But, the tighter a team’s focus, the more inter-team coordination is necessary.
John Cutler calls this invisible work
A huge source of "invisible work" in companies is managers having to essentially manage sideways to sort out dependencies, etc. It is basically asking managers to be the human load balancers of the org instead of focusing on their teams, and connecting with customers.
Marcus, a good friend of mine, is an Engineering Manager at a Big Tech company in the US. During our regular video chat, I introduced him to Org Topologies™, and learned something about the work of EMs in Big Tech.
Org Topologies is a diagnostic showing what kind of organisational dynamics your team structure is generating. Also, how changing team structures in specific ways can bring about changed dynamics.
Hi Steve!
Hey Marcus! So one of my consulting clients has a complicated development process, with lots of meetings and tickets. Their managers and architects are super busy just keeping things connected up. The company’s senior management feels that product progress is slow, and they’re right.
We’ve both seen that before. The first step is acknowledging you have a problem.
Right. I’m showing them how to use the Org Topologies chart as a navigation aid:
First figuring out what kind of team structure they have, and what kind of problems and benefits come with that.
Then, where on the chart they’d like to end up.
Finally, what it’s going to look like getting there.
Sounds too easy…
There’s a lot of nuance to the tool, and a bunch of work to actually make the changes. That’s one of the reasons we’re charting it out — so that we can work one step at a time, and take everyone on the journey together.
Okay, I’m interested… tell me how it works.
The map shows an organisation through the lens of what kinds of results an individual team can achieve on their own. Within a team, while there are norms and conventions, there doesn’t need to be so much formal process. The longer a team has worked together, the less formality is needed. But between teams, we need coordinating roles or project management systems.
Scope of work
The vertical axis is called Scope of Work. What kind of a goal can a team take on?
The rows are labeled Y A B C. Let’s start on the cherry blossom row “Feature focus”.
Cherry blossom? How poetic! Oh wait… you mean the red row
Row A. Teams are asked to make product features, where a feature is some new or changed functionality that the system should provide. Work on a feature is usually focused on a single system component, maybe with dependencies on other components. It’s common to see several A teams, each owning a system component. Work is assigned to teams based on what component is involved in the work, and there are project management systems to track dependencies.
The one component to one team model is popular, maybe because when a team is solely responsible for something it’s easy to hold them accountable[1] for that thing. But it means that a team can only change their own component; for anything else, they need to make arrangements with another team.
That sounds like my team
There’s also task-focused work (row Y), where individuals or teams are given narrowly-focused and often technical work to do. You see this sometimes when a team seems to work together, but each team member is working on a different near-term goal. In this case, it’s wrong to call them a team, as there is no shared objective they’re working on together. It’s like a football team, but where each team member is playing a different match. So, we call these units instead.
No, we don’t do that. We actually have shared goals every two weeks and everyone on the team contributes
Row B product part focus is where a team is asked to provide a customer outcome or business need. They can work across many components as necessary to create the desired outcome, even while other teams are doing the same for other customer needs. Teams collaborate with other teams as needed, without needing to assign work to dependent teams, and without external project management.
The top row C, whole product focus, is the same. Each team can work across any part of the system that is needed to get something done.
The difference between B and C is in how much of the system, and how much of the business domain of the system, teams are responsible for. At B, a team works on parts of the business domain and parts of the system. At C, a team can be effective across everything, because they are supported and equipped to learn as they go.
If a component is owned by several teams, how does that work? Shared ownership could lead to chaos
Sure, if there’s an “anything goes” approach, it’ll be chaotic. Code quality, tech debt, and all that stuff. Fortunately, there are several ways to share ownership in more structured ways. A team can have a stewardship or guardianship responsibility for a particular component, and when another team wants to make changes, the guardian team helps them with the change design, and reviews the changes. So, there can be lighter-touch involvement between teams than “add it to their backlog and wait”.
That’s how it works here. You “file tickets against other teams” when you need something changed in a component owned by another team
File tickets against sounds like getting parking fines
It does. Actually, it often feels like a kind of punishment, because the team receiving the tickets now has more work to do that they hadn’t planned for. That’s how we normally work. But sometimes, if you know the other manager well, and there is trust, there’s an opportunity to work in a more shared way.
There are other teams that you share components with sometimes?
Not usually — we have this B-ish collaboration sometimes, but it requires Engineering Managers to put time and energy into enabling it. After the feature is done, things fall back into the usual pattern on the A row.
Getting work done despite the organisational structure.
That’s a good way to put it. A lot of an EM’s job is helping things to work well despite the organisational structure
So, that can happen, but it takes extra efforts to make it work, and it’s not sustainable without continuing to apply the effort. Wouldn’t it be nice if the organisational structure supported the requisite work, instead?
(Marcus offers a knowing smile) Changing structure is difficult; it affects career ladders and how people are seen within the organisation, and lots of other things.
Is there anyone who has a broader remit than one or two components?
Sure, some senior managers have a broader B-row kind of scope. But they’re also rather disconnected from what the teams are actually doing. There’s also SVP and VP level executives whose actions make it harder or easier to “work despite the structure”. Often because their actions impact how much trust there is between team-level engineering managers.
Okay, high levels of trust is needed for work despite the structure ?
It’s the most important thing. I get the rows now; tell me about the columns.
Completeness of skills
The columns are about completeness of skills. They’re labeled 0 1 2 3.
My guess is your team is a multi-skill unit
Do we have to be a “unit” ? I’d prefer to be called a Team
You were in the Feature Focus row A, so it’s quite likely you are a team. We still call the column “unit” because when there’s a narrow task-focus (row Y) there’s usually not a shared goal, limited amounts of interdependency. So while there’s people doing work, there’s not a lot of team work.
Ad hoc collaboration is possible within a unit. But the structure of the organisation determines how coordination between units happens. So, people in the same unit can work together with little overhead; but when multiple units are involved, we typically see some level of bureaucracy.
Got it. We do have multiple skills: development, test, design, deployment.
There are two things[2] that regulate whether a team can do some work without needing to be blocked by others outside the team.
Can they work on the component areas of the product as required?
Does the team have the requisite skills?
This second point is about all the skills needed to take a feature from the point where we recognise that it’s something we want to do, all the way through to shipping the feature to users. That probably includes design, test, coding, integration, deployment, release.
Are the requisite skills known on the team? And if they are, are they allowed to use them; or do they need to hand off to another department for some kind of security test, or deployment?
No, we’re good. In most cases we can release all the way.
A single-skill individual, column 0, would be like a Database Administrator who deals with the Oracle database. I worked in a company once where there was one DBA (Microsoft SQL Server this time), and he was the only one allowed to edit stored procedures and do certain deeper database stuff. To get him to do something, you would send him an email, and a bit later he’d do it and mail you the results. He was in the same office most of the time.
Okay, let me guess… Y0 for the task-oriented DBA
Exactly, Y0 single skill individual.
Now imagine there’s a whole department of DBAs, managed by a senior DBA. Across the whole department they know different databases. A few can do deep performance tuning; others specialise in 5th and 6th Normal Form.
Y1, functional unit
Almost right. Column 1 for “functional unit”. But we don’t know about the Y — if they’re task-focused. From the description it sounds likely, if the database is one of several system components.
But if the product is in fact a database, and their customers / users interact with it directly (maybe using a B.I. tool like Looker or Tableau), they might be at A1, B1 or C1.
So it depends on what the product is: what are customers paying for, and users expecting to use?
Multi-learning teams
Got it. So right-hand column: what’s a Multi-Learning Unit?
A team that has support to learn new skills of different kinds (domain knowledge, technical knowledge), and learning perhaps being more like figuring out proofs-of-concept together, rather than being sent by a manager on a 3 day training course then being expected to have a new skill.
Teams that learn by doing and collaborating; rather than having to add people to the team to bring in new skills.
Going further, groups of teams that choose when to take the most direct line to delivering a feature, and when to take the “scenic route”, slowing down in order to acquire new skills and knowledge. Optimising capability and learning across the entire group. Developing ways of predicting what skills and knowledge will be needed in the mid-term future, so by the time they’re needed the teams are prepared.
If our tech stack is stable, and our business isn’t changing, is there much benefit to being multi-learning?
Maybe not! But over the course of months and years, technology changes whether we want it to or not. Whether it’s software versions, new internet protocols (e.g. HTTP/3), consumer hardware (new iPhone models)…
And a business that doesn’t change either has a captive market, a monopoly, or owners with a lot of disposable income.
If there’s a lot of employee turnover, people won’t stick around for long enough to learn and then apply those learnings. But that’s a sign of more serious problems.
Okay, I think I understand how the Org Topologies chart works Teams at my company are more or less at A2, multi-skill teams with feature focus. Sometimes Engineering Managers make special efforts to get teams together and soften the unit boundaries, so we’re at a B2-ish place, working across several components. But this lasts only as long as needed to get some specific feature delivered. The organisation’s structure and politics naturally returns to A2.
Is there anything EMs can do to shift the organisation out of A2, perhaps into B2? Would there be a benefit to this?
We’ve shown we can work in a B2-ish way when there’s trust between the EMs and teams, and when the need is there. But to do so long-term would mean changing a lot of things — progression / incentive structures, technical practices around component ownership, company-wide project management… Engineering Managers can support such a change, but it needs to be driven by more senior roles.
Starting a journey with intention, you need to know where you are.
If you’re planning to go somewhere, it helps to know where you’re starting from.
And even if you’re happy where you are, maybe it’s reassuring to understand more about why this is the place to stay.
Learn more about Org Topologies.
[1]: In many companies, hold accountable is business jargon for blame. The company’s leadership want to be able to blame specific people if something bad happens. They are reluctant to give this up, even if it means having less effective teams. Part of the reason for this is that they don’t understand what blame is, and what might be used instead.
Blame is an organisational development tool, and a particularly blunt and clumsy one. Wielding it always causes unintended consequences, chronic wounds that resist healing. Giving up blame, and switching to more subtle and precise organisational development tools is an important enabler that allows companies to shift into the top-right area of Org Topologies.
[2]: A third thing that enables teams to have dependencies without blocking: whether the other team is available to them without the need for a backlog. Both teams work on dependent features at the same time, and are fully available to each other to mutually adjust the features as they are developed. But this is for another conversation.
