TPMs: The “ATC” of Software Development Teams
People often ask me “What’s your role like as a TPM in Capillary?” For a very long time, I didn’t have a short answer to it or a role that I could relate to. In this blog, I’ll try to explain more about the role in general and how this has evolved in Capillary.
Firstly, thanks to Gergely Orosz for a great article on TPM’s role which inspired me to write something similar for Capillary.
We started this role in Capillary back in 2018 when I joined as the first TPM for one of the products. In the beginning, I and the Director of Engineering started laying the foundations for this role. We had a single-point agenda to streamline processes around prioritisation, planning, development, and release communications. Today, we’re a seven-member org that collaborates with different functions within the company and outside too.
TPM Organisation in Capillary
In the early days, Capillary had just the Product Managers(PM), Engineering Directors, and the TPM function for almost every team. TPMs had to work with engineering directors in the initial stratification phase and then execute the plan with the team lead. This kept the structure lean and the process lightweight. As we started expanding, now, all the teams have Engineering Management(EM) functions with well-defined responsibilities and charters. And like any mid-sized company, this trio(PM, EM & TPM) takes care of everything that touches the core development activity of these teams. Below are the two paramount job responsibilities of a TPM in Capillary.
Roadmap Delivery
Like every company, the role and involvement of a TPM in Capillary varies from product to product. But certain responsibilities are common across. At a high level, TPM org has the responsibility to identify the “When” part of any request. And the ambiguities across the organisation to identify the “When” part are ubiquitous.
We follow a quarterly planning cycle for the teams. Every quarter, the team(PM, EM, Leads, TPM) sits down for 3 weeks and finalizes their plan for the next 12 weeks. The product owns the “Why” & “What” part of the consideration set which is derived from roadmap, customer feedback, company vision, etc. TPMs orchestrate the overall process to arrive at the “When” part while leaving “How” and “Who” to the Engineering Manager.
Once the plan is finalised the group owns the execution throughout the quarter along with the engineering manager. Any deviation or reprioritisation in the plan is discussed and closed with relevant stakeholders.
When I look at this cycle, I see TPMs operating as “ATC”( Air Traffic Controllers) for an individual task/project which goes through different stages. Each stage has its challenges, known and unknown. The TPM has to lead from behind and implicitly motivate the decision-makers in every stage to move to the next. Like how ATC does it for an airline pilot. Helping them in various stages of the flight path and making them aware of any hurdles (external delays, weather risks, change in route, etc).
Process and Tooling
The TPM org in Capillary also owns the responsibility of implementing necessary processes and tools to achieve the project goals or enhance the overall customer experience. The emphasis is on bringing processes that are an absolute must and automating as much as we can from the beginning. We track a few important metrics and objectives with the help of certain tools.
Roadmap Delivery
This is one of the most important metrics and data points for engineering org. We track it at a central place for all the teams via Data Studio reports. The report and integration are built with the help of Jira, stitch data, PostgreSQL and Google sheet.
Documentation
The information architecture of any company plays a crucial role in growth and velocity. Knowledge documented is time saved. Technical detailing, Product Specifications, Business Requirements, and recorded Product Demos are all effective information to ensure minimal ramp-up time for onboarding a new member. We bank on Confluence heavily for this.
Business KPIs
Capillary has multi-tenant architecture. It is paramount for engineering teams to have some visibility into important business metrics at the tenant level. Metrics like uptime, throughput, response time, etc. play an important role in defining the health of a tenant. We use tools like Site24x7, Hevo, and New Relic to build a robust integration and enhance our observability.
What has worked for us?
While many smaller things contribute to the success of any role, there are a few that stood out for us in scaling the TPM org. The biggest one was inculcating a data-informed culture and investing in automation; process and data both. We invested heavily in Excel and BI tool platforms to open up data across the company and also standardise it wherever it made sense. And almost everything was automated. Automation ensured that we stay away from mundane activities while being aware of what’s happening around us. Making governance easier! Some of our reports around Jira data, Uptime, SLA, and Delivery stats are covered in another blog here.
Challenges
While we evolved well in the last few couple of years, it came with its challenges. Challenges that are intrinsic to this role purely because of org structure. And is true for most of the companies which have a TPM function.
- This is a role with high accountability and low authority. It demands influential skills in aligning incentives of multiple stakeholders and subscribing them to the leadership vision. The org structure of the TPMs function makes it furthermore complicated. Since the function rollup to engineering org, the obvious bias stems in and it makes it furthermore difficult to work with their dotted line function like Product, CX, Implementation, etc. in arbitrating any cross-functional issue.
- Lack of process gathers maximum steam in any failed project post-mortem reports. A good TPM has to strike the right balance while defining processes within and outside the team. They need to ensure that the process is just enough for everyone to operate efficiently and not too bureaucratic. At Capillary, we ensure to have processes that are just right! In the end, processes are for people not vice-versa!
When we look back, the TPM org has evolved remarkably in the last five years. The function works as a glue within the organization and helps achieve long-term goals and visions. As TPMs, we embrace ambiguity and use it as an opportunity to step up and drive clarity of execution across the board. The ambiguity in the role demands and tests your core leadership skills like communication, conflict resolution, decision-making, etc. You’re strategically placed to understand the business asks while helping engineering teams with their complexities and challenges in meeting them. The “ATC” of software projects!
So, if you’re starting the TPM org for a 50–100 sized engineering org then follow some of the basics that we followed at Capillary. This will help you scale gradually.
- Understand what is really broken for your internal customers; CXs, Products, Implementation, etc. It could be as small as the availability of sprint timelines.
- Don’t invest too early in complex tools and automation; try processing manually initially and automate if needed
- Propagate data-oriented culture; expose more data to your team and let them introspect
