T-POP
A mental model for technical leadership positions
Starting a new technical leadership position can be challenging:
You may have a hard time making sense of technology and solution landscape
Once you do make sense of it, you may have a hard time driving change
Once you do manage to change it, you may have a hard time operating it
Once you do succeed to operate it, it may not align with the evolving product problem definition
Over the past few years, I have changed jobs multiple times and faced one or more of those challenges. Reflecting on those experiences I created a mental model to systematically approach self-onboarding to technical positions. This model surprisingly works well after the onboarding as well to decide how to balance spreading energy and time. I call it T-POP!
In this post we’ll go through:
Why do we need a mental model like T-POP?
What is T-POP?
How to use T-POP?
What will happen when this model is broken?
Why do we need a model?
Technical leadership roles (i.e., Staff Engineer, Principal Engineer, Enterprise Architect) on the IC (individual contributor) track are unique in multiple ways:
Lack of mandate: unlike EM and PM who have a mandate over engineers and product, technical leaders are supposed to “lead tech”. But tech doesn’t talk or listen. To do their job effectively, tech leads must go through people and products.
Wider scope: covering a wider tech landscape, product area, and organizational surface calls for a different toolset than preceding IC roles (e.g., junior/senior engineer) that are usually attached to one team, product, or technology (e.g., frontend, Android, etc.). You must accept that you can’t master some technologies and instead you need to prioritize other aspects to deliver value.
Longer horizon: Technical leaders need to think about the longer-term impact and technical strategy while simultaneously connecting it to the tactical.
Without a systematic model, the following are the top risks that threatens technical leaders:
Ivory tower: going back to the origin of the term “staff”, your primary masters are the engineers at the leaf nodes of the organizational tree. Those are the people you’re supposed to empower, and you can’t do that without understanding their struggles and living their lives. Ivory tower is a state of privileged seclusion or separation from the facts and practicalities of the real world which is a real risk if you spend most of your time in the leadership room and neglect the engineers you’re supposed to serve.
Snacking and preening: The leadership roles usually have a lot of autonomy. If not managed properly, the autonomy can quickly lead to wasting time on the wrong thing (snacking). Even worse, it can lead to working on things that have high visibility but no value for the business (preening). Will Larson did a great job explaining this phenomenon here.
Premature solutions: due to higher visibility and scope, many decisions may come your way. Sometimes organizational or product problems disguise themselves as technical problems. Without a solid understanding of the tech landscape and your role, it is tempting to respond with premature solution. A good example is premature standardization where the tech lead demands tech defragmentation without understanding the root cause of fragmentation in the first place or offerring a hand in doing the actual migration. I have a dedicated post for premature standardization in the future.
What is T-POP?
Broadly speaking, there are four categories that define an environment:
Tech: the actual technical solution in place and its maturity in terms of applications, DevOps, security, reliability, architecture, 3rd party tooling, etc.
People: the org structure and the type of talent making up the organizational DNA: the behaviors the company tolerates, the style of leadership and engineering, the talent pool, the talent intake & recruitment filters, mentorship, etc.
Operation: the way of working (WoW), processes, history, facts, incentive models, vision & mission, culture (how people act when they’re not watched), assumptions, and beliefs (or FAB as John Cutler puts it). We’re not only talking about DevOps, SecOps, MLOps, ProductOps, OpsOps (!) and what not, but any way of working that is unique to the company. Processes often are light on WHY and heavy on WHAT. They naively assume that you can “program” people to follow “best practices” (which is a generalized term for something that appeared to work at a given circumstance and point in time). Path dependence theory states that the history of the organization puts constraints in its future trajectory.
Product: the context of the problem the business set out to solve and its business model and customers. The tech you’ll be leading tightly couples to the problem it’s trying to solve. That problem is defined by the product and business model.
Put together, you get T-POP: 🤤
You can see those four dimensions clearer when starting a new technical leadership position, but even if you’re promoted internally, these areas become more visible with the elevated level.
As a technical leader, tech is your primary focus but make no mistake: it is far from being the only one. Tech doesn’t exist in a vacuum. It is heavily influenced by people, operations, and product.
How to use T-POP?
Self-onboarding
When you’re new, you often know one of the 4 dimensions. Usually, it’s familiarity with the tech that got you through the interviews.
People: Sometimes you know the people or have good domain knowledge.
Operation: Sometimes you’re hired for your skills to help improve how the business operates.
Product: Some other times, you may be hired for your prior experience with the product (e.g., you’re joining a competitor).
Regardless, use your initial edge to expand into the other dimensions. For example, if you know the tech very well, try to meet people who use that tech, have meaningful conversations about tech, and expand your network (People dimension). Learn how that tech is used, deployed, monitored, and operated. While doing that, try to understand the problem as defined by product because tech is only valuable when it’s the solution to the product problem.
Distributing time and energy
It is easy to hide in the tech cubicle and geek out but that’s not the best use of the tech lead bandwidth, nor does it cover the entire possibilities and expectations.
People: In Senior to Staff+ we established that soft skills are key to your success. From networking to dotted reporting lines to internal training, you need to spend the time to build a solid people foundation to deliver technical impact. The networking aspect alone lubricates everything else because it makes it easier to navigate the org chart.
Operation: How the organization operates plays a key role in the health of the technology. Understanding how things operate prevents unnecessary friction (some fights can wait for another day).
Product: The evolution of the technical solution is tightly coupled to the product. Like all things in life, it’s about balance. Balance is hard when those dimensions are not clear.
Maintain Focus
At a given time, you’re probably working on 1-2 specific initiatives. You can use T-POP to focus on relevant tech, people, operations, and products.
Tech: No need to spend time trying the latest ECMAScript state 1 proposals if you’re working on a C# code base.
People: No need to keep a monthly 1:1 with a dotted reporting line that doesn’t have anything to do with your current project.
Operations: No need to focus on optimizing CI/CD pipelines or picking up a discussion on data governance if you’re optimizing the incident handling process.
Product: No need to spend time improving the user flows in the app if you’re focusing on improving the backend payment API.
The point is: although T-POP calls for attention in multiple dimensions but the focal point for all your investments at a given time should is to execute and deliver your current initiative.
Measuring impact
As a leader, your impact will be measured by the outcome of the initiatives you drove or contributed to across your organization and company.
It’s too simplistic and naïve to think that it’ll boil down to technical initiatives just because your title has “tech” in it.
Your brag document (a log of your impact over time) should contain all aspects of the POP, not just the T:
People: You help your organization resolve a people-issue (politics) disguised as a technical issue (e.g., data ownership).
Operations: You help your organization to adopt and use ADR to push decisions closer to where they are executed
Product: You build a POC (proof of concept) to demonstrate how a new feature in the mobile operating system can open a new revenue stream for your company.
Recruitment
I have interviewed many Staff Engineering candidates and can confidently say the number 1 reason for rejection was lack of a well-rounded skill in leadership.
The Staff+ interviews are focused on hiring a well-rounded technical leader, not just someone who codes better and faster. As I argued in a previous article, a Staff Engineer is not necessarily more technical than a Senior Engineer.
A good interview process is mindful of all these aspects and assesses them adequately:
Tech: The candidate can demonstrate depth of understanding technical landscape and navigate complexity at scale.
People: The candidate can identify and work with key stakeholders and other engineers to deliver impact.
Operation: The candidate is literate with how modern software is operated and how to scale a piece of software when needed. Moreover, the candidate has a track history of improving operational efficiency and effectiveness.
Product: The candidate can see the big picture and connect the result of their efforts to the impact on the business model and vice versa: use business data and product insight to calibrate the technical solution.
Promotion
I have mentored a few Senior Engineers and those few who made it to the Staff Engineering level were well-rounded technical leaders, not just hard-core tech savvy programmers.
If you want to grow in your career, whether you're a Senior Engineer or Staff, make sure that you gain experience in all those dimensions not just tech.
People: network internally and build a personal brand so when it’s time for a promotion, there are enough data points to build a positive history for you. It can be as simple as technical demos, blogging, organizing hackathons, or lunch & learn to inspire others.
Operation: try to leave a mark on how your organization operates day-to-day. It can be as simple as rolling out async work culture (e.g. RFC, ADR, TDD, etc.), implementing an A/B testing tool to promote testing live, or internal developer portal (IPD) to improve efficiency. Look at the operational problems, develop a hypothesis, validate it with key people, and deliver incrementally in a measurable manner.
Product: understand how product measures success.
has listed tons of metrics here. Once you identify the key metrics, see how you can use your technical edge to deliver a measurable impact.
I’m a big fan of brag docs (a record of your accomplishment) not only for promotion and job interviews but also to feel good about what you have achieved. It also gives a trajectory to your growth.
Broken T-POP
It wouldn’t be a good model if we couldn’t remove something from it, without breaking it!
Let’s see what happens if one element is removed from T-POP:
Tech: I haven’t seen a technical leader who abandons the tech altogether, but a common pitfall is to prioritize other dimensions and have a shallow understanding of tech which in turn hurts your impact. Let’s be clear: as a technical leader, tech is your home and that’s the primary area you should influence (hence the dash in T-POP).
People: Computers are logical, predictable, and fast creatures compared to people. It is easy to abandon the people dimensions as an IC (individual contributor). As we argued before the people factor is single handedly the most key factor that blocks the promotion of great Senior Engineers to the Staff level. Leadership by definition is about delivering an impact that is larger than one person can deliver. Metcalfe's Law, states that the influence of a network is related to the square root of the network's total nodes. Any tech lead who abandons networking, avoids dotted reporting lines, skip levels, mentorship, sponsorship, and other means to scale their leadership severely limits their impact.
Operation: Ignoring how the company operates and the shared stories and rituals that shape the interactions and connection between people and systems is a huge mistake. Too often I’ve seen great initiatives being blocked because “people don’t get it”, “this company sucks”, “upper management is stupid”, “we’re not mature”, etc. That’s usually the sign of something trying to improve the tech without understanding how the company operates. “Best practice” from one company may not work in another. You have to understand the system before trying to change it and even then, you should do it gradually and systematically. You’ve probably heard “culture eats strategy for breakfast”. It certainly applies to tech strategy too. The ways of working at a company can create a tremendous friction that fights anything you’re trying to change. Seek to understand before trying to change and even then, do it in iterations.
Product: Many software engineers see their job as builders. But builders of what exactly? Tech is a solution to a problem and without understanding the problem, the solution will be inefficient if not flat out inappropriate. You cannot blame them though. When learning software, many of us only had to deal with well-defined abstract problems. We’re even tested for it when applying for jobs. In the real world, problems are hairy, obscure, and act like a moving target. It is easy to dismiss product as “not my job”, but sadly this is the most important aspect (after the tech) to do your job as a tech lead. That’s because leadership needs vision and you cannot have a vision that’s fake and disconnected from product (i.e. how money is made).
Conclusion
I developed this mental model a few years ago when I changed jobs, but it matured over the last 2 years when I worked as a senior staff engineer. Regardless of how much I’ve thought about it, it’s still limited by one person’s limited experience and professional life trajectory.
I’d love to hear your thoughts and reflections. With your feedback I can enrich it even further and make it useful to a wider range of technical leaders. 🙌
Thanks Mikael Vesavouri, Joakim, and Mattias for reviewing the early draft of this article and giving feedback.
My monetization strategy is to give away most content for free. However, these posts take anywhere from a few hours to days to draft, edit, rethink, illustrate, and publish. I pull these hours from my private time, vacation days and weekends. You can support me by sparing a few bucks for a paid subscription. As a bonus you get access to my WIP book Reliability Engineering Mindset. Right now, you can get 20% off via this link.
If you can’t spare the money for whatever reason, sharing this article within your circles would also help. Thanks in advance.
Great article Alex. While I haven’t been in such a role myself, I’ve seen few from the side, and the ‘broken’ T-POP section resonated.
When I first join a company, I usually grasp the technical stuff pretty easily. But figuring out the company's culture and how they motivate employees is tough. It's like there are these unwritten rules about what's good and what's not.
For instance, knowing what actions get praised and which ones might get you in trouble can be tricky. And then there's trying to make sense of why certain decisions were made in the past. Sometimes I've tried to solve a problem only to find out later that there were factors I didn't know about holding me back. It can be frustrating.
My main question is whether your understanding of T-POP's "P" includes things like incentives, culture, and context. If it does, can you explain how T-POP helps us delve into these aspects?