Update: an older version of this post used to use the terms “centralized” and “decentralized” instead of functional and integrated, respectively. It was updated to these new terms to avoid confusion.
Now that 
I have laid out my thoughts enough about TPM to “open to floodgates” so to speak, I want to discuss a topic that immediately comes up: what’s your recommended organizational (org) structure? I have lived both the integrated team structure at Amazon, where TPMs, Software Development Engineers (SDEs), and Software Development Engineers in Test (SDETs) all report to Engineering Managers (EMs/SDMs).1 But I have also lived the functional team structure at the company formerly known as Facebook,2 where TPMs report to TPM managers (Group TPMs), SDEs report separately to EMs, and Production Engineers report to a dedicated manager as well. The org overlaps at the Chief Technology Officer (CTO) level, but not before; from the TPM perspective, I sometimes call this model a Technical Program Management Office (TPMO).
So, which is better? Or is there a hybrid in between the two models you recommend? Let’s dig in!
The Functional Model, or TPMO
My experience shows that this is the more common model, so I want to start with this one. This model is based on the hypothesis that by breaking up the org such that various functional leaders lead others of that function, they can provide the best support for Individual Contributors (ICs) of that function. And initially on paper, this makes intuitive sense!
For example, who better to hire, evaluate, grow, and promote TPMs than a Group TPM? They live and breathe TPM daily and are guaranteed to compare TPMs to other TPMs, not to other functions (such as SDE). However, that is a long list of things – hire, evaluate, grow, and promote – let’s dig into these.
First, we have hiring. Yes, functional leaders should always be involved in interviews and hiring decisions for others of that function, unless you are hiring the first for a role and such a requirement isn’t possible. Ignoring that one-off case though (which may lead to a separate post in the future), imagine hiring an SDE without other SDEs doing the evaluation – you’d never do this, right? Right. However, this has nothing to do with org structure – functional leaders can be involved in hiring decisions regardless of who their manager is. In fact, it’s valuable to have at least one interview occur from outside the team you’re hiring for to avoid bias and ensure candidates meet the bar for the company, not just the specific role. So hiring is not a valid reason to have an org structure.
I argue the other benefits can all be picked apart in a similar way. Mentorship has nothing to do with managerial boundaries and is something all ICs should be doing, regardless of function. While you also need managerial support for growth, growth comes by achieving benefits for the team. Thus, you do not need a disconnected leader from the team(s) you are supporting to coach you on your growth. Rather, the team leaders themselves are in the best position to do this. Because of this disconnect, I argue growth is actually harder when on a functional team given the added organizational friction.
Imagine you are a new TPM joining a TPMO. There are some basic questions to answer, like where do you sit? With your engineering team or your TPM team? Your engineering team, right? But then you realize everyone is gone for a team meeting, and you’re not invited. So you figure this out, and get added. But this keeps happening – email Distribution Lists (DLs) that are automatic based on the org chart don’t include you, and you’re accidentally excluded from a team onsite involving travel as your team isn’t all in the same location. You talk to your manager about it, but the reality is they only support three ICs, and they’re more of a “player-coach.” In other words, they’re too busy with their own work to address this at the company level.
OK, now imagine a month goes by, and you have the first new idea for the program that you are managing. You tell your manager and they help you write a document to share the idea with your engineering team. But when you share it, you quickly get dismissed with “we don’t have time for that.” This makes you question what your job even is – who is in charge of prioritization? Usually, it’s the TPM for a team (working backwards from the TPM model outlined in this previous post). So you push back saying that you disagree, but it’s clear the EM isn’t going to budge – what do you do? Escalate all the way up to the CTO?
I argue you were setup to fail from the start – a simple conversation with the EM from the get-go could have avoided this entire situation. While yes, this is feasible regardless of them being your manager or not, it is an extra hop to have to chat with both managers every time you have an idea rather than just one. And even if you did share the idea in advance, your disagreement still has no real way of being resolved.
Now cease your imagination – this is what actually happens. And yes, I had a positive experience at Facebook and would recommend my managers – that’s not my point. My point is, I wasn’t part of the team(s) I was supporting. As soon as the functional org alignment starts having “player-coaches” as managers, the proposed benefits cease to make sense. The reality is you get less support with double the overhead. This likely looks like:
- Weekly 1:1s with both your direct manager and your EM – this is an extra 30m/week.
- Weekly team meetings, one with your EM’s team and another with your Group TPM’s team – this is an extra 60m/week.
- Monthly 1:1s with both your skip-level TPM manager and your EM’s manager – this is an extra 30m/month.
Factor in the delays of needing to communicate everything twice, and I argue that it is unavoidable for this model to slow down and stifle innovation. And don’t forget about the added cost to the company! Yup, that too. Multiply the wasted time above for every TPM at the company – that’s a lot of lost time! On top of this, you have twice as many managers (who aren’t cheaply paid). Now scale this out to the testing function, or system engineer/production engineer function as well, so there are four separate managers. Now imagine you need an SDE, an SDET, and a systems engineer for a project, perhaps to change the default configuration of some networking settings that are leading to retry storms.3 Who is the Single Threaded Leader (STL) / Directly Responsible Individual (DRI)? Cross-functional decision making is now challenging, if not impossible; this does not scale.
In summary, increasing the managerial overhead for every function reduces the incentive to add functions, even when appropriate. Instead, you have the incentive to increase the size of your existing function. As you now have four managers all asking for more headcount instead of just one, as managers’ scope is reduced to their function only (rather than the product or projects they own). In summary, the functional team model undermines the ownership that an EM should have.
Insert: The Integrated Model
The integrated team avoids the concerns laid out above, but like all decisions, it has its set of trade-offs which we’ll get into below. However, what it does beautifully is empower EMs to be Single-Threaded Owners (STOs) – and yes, this is the same link as the STL reference above, as it explains the difference between the two. To summarize here, in this integrated model, where SDE, SDET, TPM, and other engineering functions all report to the same manager, then that manager is effectively the STO of their tech stack. If they recognize an issue and decide they need to invest more in the SDET function, they can do that. This avoids the contention between all functions, as naturally all managers of the separate functions are all vying for the same pool of headcount.
This model also makes horizontal mobility much easier – and I say this with a huge bias, as this is how I transitioned to TPM seamlessly from SDE. I stayed on the same team, so I could focus on the new role with all of the team context I already had. And from my manager’s perspective, there was no headcount handoff or sticky process – it was the same team. Heck, I didn’t even have this idea, but my manager at the time did! He came to me, told me he thought I’d be a great fit, and if I didn’t like it, I could transition back to SDE. That is an amazing deal – risk-free, try out a new role? I said yes, and after just 6 weeks, we made the transition permanent. This seamless experience enabled the single best move I ever made for my career, and it pains me to see how hard it is for other engineers that want to transition that are in centralized environments by function. Rather than be supportive, their managers try to convince them not to change, as they would lose a great team member this way. While the functional team model is sold as being more supportive of ICs, the integrated team model is more supportive in this case.
Lastly, there is an elephant in the industry – not everyone with the TPM title is technical, despite the T. As I discussed in my last post, there are plenty of other titles for these folk. But by keeping TPMs directly integrated with engineering, you minimize the likelihood of this happening. They will be interviewed and evaluated as part of the engineering team, because they are part of the team by design, Extreme Programming (XP) style. You don’t need to worry about accidental exclusion occurring, or the TPM accidentally being disconnected from the EM, as the EM is the TPM’s manager! The team acts as one because they are one – all with a reduction in cost to save the company money.
OK, I have waxed poetic about the integrated model; but surely there are flaws, right? Of course! The one area that holds well in the functional model is that it reduces the cognitive load for the managers. By only needing to support one function instead of multiple, they are able to focus on that one function. In the integrated model, EMs need to be able to calibrate SDEs, TPMs, SDETs, and other engineering functions. I argue this is simply the job of management, as when you only manage one function you end up becoming a player-coach anyway (so clearly the bandwidth exists to handle more than one). However, with this added work, the company needs to clearly set the expectation of managers with this workload and set them up for success. For example, if you are introducing TPM to the company for the first time, you need to both coach the manager who will support that TPM and prioritize that TPM’s time to scale out the support for the company (via things like a ladder guide to handle evaluation and promotions, etc).
The other reality is that I am only talking about the engineering organization having a flat management structure in this integrated model. Marketing, design, and other non-technical organizations are still separate. Which is where a hybrid approach gets interesting…
A Hybrid Approach
I have a life motto: in all things, balance is the key. However, I admit, I’m not fully convinced of this solution yet, as to my knowledge, it’s never been tested. However, I think it is worth mentioning and considering to try and thread the needle between the pros and cons of the two approaches.
Effectively, what is meant by hybrid here, is taking Single-Threaded Ownership to the extreme. Have a leader of something, likely a VP, and then have directors of functions report to that leader. You could have a director of engineering, a director of TPM, a director of design, etc all report to that leader. This makes for a clear escalation path for decisions while trying to balance the workload put on managers. Additionally, it can make a lot of sense when adding a new role – instead of needing to train all existing managers how to handle a new role consistently, you can install managers of the function as needed in new locations. Cost-wise, this can be cheaper than said training – it depends on the situation at hand.
You could scope this approach to engineering functions only, which minimizes some pain of the functional organizational model where the first alignment is at the CTO level. While this improves clarity in decision making and ownership, I argue it still keeps all of the other flaws of the functional ownership model along with the high cost. It also severely limits the managerial growth track, as non-SDE managers will rarely become managers of managers. In other words, these functional managers only need one level – there is no career ladder for them – and I don’t believe in having such roles, as you will struggle with retention.
Conclusion
The reality is that there is rarely a “one size fits all” answer here. For example, I would be surprised if the hybrid approach made sense to companies that were under 1,000 people. When you’re small and growing, cost savings are incredibly important, and the integrated structure is by far the cheapest solution. However, for mid to large sized companies, the hybrid approach could be a significant improvement over the functional team model.
Appendix: Good External Resources
- Two-Pizza Teams Are Just the Start: Accountability and Empowerment Are Key to High-Performing Agile Organizations (Part 1, Part 2)
- 6 Principles for Building a World Class TPM Team – this is an interesting read vs the opinion shared here. While it advocates for a TPMO, it also advocates to keep TPMs “highly leveraged,” meaning the philosophy is similar as those shared here.
Footnotes
- Sorry Valley folk, but Seattle has the acronym right here. It’s not SoftWare, so calling engineers SWEs is just wrong 😝. However, you do get EM right (vs SDM, which Seattle companies use), especially if the EM manages more than just SDEs, but SDETs, TPMs, and others as well.
- The rebrand of Facebook to “Meta” happened after I left, and lets just say I’m not a fan 😅.
- Hah, sorry, this is a real example of something I led years ago.
6 Comments
Leave your reply.