10
The Technical Toolset
In this chapter, I’ll make the case for the technical toolset. Introduced in Chapter 2, Pillars of a Technical Program Manager, the technical toolset is a foundational pillar for a TPM. It is the connecting glue between the other pillars, program and project management, and is the foundational pillar that sets a TPM apart from a generalist PM.
We’ll continue by discussing the various tools in the technical toolset and how they help you not only excel at your job but also work across job families as the need arises.
We’ll explore the technical toolset through the following topics:
- Examining the need for a technical background
- Defining the technical toolset
Let’s get started!
Examining the need for a technical background
In discussing the origins of the TPM role, we looked at the role of the PM and how gaps in knowledge could hinder the execution of a project or program. This book has focused largely on the tech industry and the common usage of the word technical to refer to information technology. However, if you look at the word as a synonym for specialized, then the need for a specialized background might be a bit clearer.
Looking back at the pillars of the TPM from Chapter 2, program and project management are two-thirds of the foundation of a TPM. This is because these skills transcend each individual project and program management position that you may hold. They are the most fundamental needs to succeed. However, to truly thrive as a TPM, your specialty focus as a technically minded practitioner requires a fundamental understanding of technology. This is what sets you apart and allows you to be more successful than a generalist PM in this role.
TPM specializations
The tech industry as a whole is still getting used to the concept of a TPM as a needed role. However, some companies are going a step further and making it more specialized within the technical spectrum. This makes sense given that the reason for the TPM role is to provide specialized knowledge of information technology to the PM role. As the market for TPMs becomes saturated, a more nuanced delineation is needed when a simple technical background will not suffice. When you need a TPM specializing in Application Security (AppSec), then the title becomes TPM – AppSec. If you need a TPM that can help you move entire ecosystems to the cloud, you may need a Solutions Architect – TPM.
Becoming a TPM
The career path of a TPM was covered in Chapter 9, Career Paths, but it’s worth noting here that while the discussion on needing a technical background sounds like the path to a TPM is as a PM that expands their technical knowledge, the path is most often a person with a technical background (for example, a software developer, systems developer, or another similar role) that expands their PM skill set.
This is why this book provides a lot of chapters on PM skills that are relevant to a TPM as this is the area of growth for most people coming into the TPM field.
This trend of specialization is similar outside of the tech industry where TPMs are needed. A medical company may need a TPM with specific medical knowledge or a specific software package or device. One such job where this is needed is Program Manager (Medical Device). Though listed as a PM, the role requires an engineering background with knowledge of working with feature launches of medical devices. If the need is large enough, a new title may be created. Figure 10.1 illustrates a few different TPM specializations found on the Amazon job board and how they are related:
Figure 10.1 – Specialized PM overlaps
All of these TPM positions have a basic requirement of project and program management, as well as some technical background. The type of technical background needed is a large differentiator that denotes the nuances between some of these specialties. AppSec and Security TPMs share similar security-related skills. The solutions architect needs to understand the full stack – or the services used from the frontend to the backend of a cloud system.
Some of the specializations are not geared toward the technical background but instead toward specialized tools used in that role. The Global Process Owner (GPO) role focuses on change management, acceleration, and process improvement skills such as Lean and Kaizen. The Security TPM focuses on the Risk Management Framework, which is a specific type of risk analysis life cycle based on the life cycle described in Chapter 6.
This categorization is not exhaustive of what is out there, nor are the differences between them the same as every company has slightly different needs. However, this illustrates the varying degrees to which a technical background is required to perform the TPM role.
Technical proficiencies used daily
In each of these roles, a generalist TPM can ramp up and perform the job as they have the pillars needed to be a successful TPM. This ramp-up is often costly in terms of both time and resources and isn’t always a fit for the needs of the organization. So, just as a PM could learn the technical foundation needed for a specific purpose or role, a TPM could do the same.
As we’ll explore more in the next three chapters, your technical skills are widely used at every stage of a project or program. We’ve discussed some of the roles and responsibilities that a TPM has in various aspects of project management. Table 10.1 provides a list of standard roles and responsibilities that a TPM may have where some level of technical acumen is needed:
|
Key Management Area |
Step |
Role |
|
Planning |
Refine requirements |
Accountable |
|
Create functional specification |
Accountable/Responsible | |
|
Sprint planning |
Responsible/Consult | |
|
Review designs |
Consult | |
|
Stakeholder Management |
Draft communication plan |
Accountable/Responsible |
|
Daily stand-ups |
Consult | |
|
Status report/meeting |
Accountable | |
|
Monthly business review |
Responsible | |
|
Risk Management |
Risk analysis |
Accountable |
|
Risk monitoring |
Accountable/Responsible | |
|
Issue resolution |
Accountable |
Table 10.1 – Roles and responsibilities of a TPM
Throughout the life of the project or program, the TPM is constantly drawing on their technical toolset to deliver key artifacts, resolve issues, drive clarity, and ultimately deliver on the goal.
During planning, the TPM relies on their technical background to clarify ambiguity in requirements and to ensure they can transform them into a functional specification (functional spec), which is a document mapping business requirements to functionality (APIs, user actions, and features). In turn, the functional spec relies on the TPM’s technical background and system knowledge to trace the system functionality back to the requirements. TPMs provide input during sprint planning as to which items to pick up. This draws on the project plan and technical dependencies between tasks that the TPM has identified. Lastly, design reviews are where the TPM uses their understanding of system design as well as the surrounding architectural landscape to influence the right design choices based on the needs of the project, team, and company.
Stakeholder management is focused on your ability to bridge the gap between business and technical concepts. As the communication bridge between the technical and business worlds, you draft the communications plan and ensure you have the right type of communications in place to bridge the technical gaps in understanding. As such, status reports, meetings, and business reviews all require you to tailor your status and narrative to the technical proficiency of your audience.
Let’s look at a single scenario and see how it would need to be handled differently, depending on your audience. Let’s say you have a design that has been delayed because the service interface contract between two services cannot be agreed upon. The sending team wants to treat missing or empty data as null, whereas the receiving team has a technical limitation where their service cannot handle a null value. The receiving team wants the values to be sent as empty strings, or to create default values for every parameter, and the sending team is challenging why the receiving service cannot handle a fundamental concept like null values.
If this scenario came up in a project that was building out a platform feature that was not externally facing, your stakeholders are likely all technically minded, and your status reports can stay technical. You would list out exactly what the issue was: a service contract disagreement, and the options being explored – setting default values or updating the receiving service to understand a null value. The audience would understand what was going on, as well as what the next steps are.
However, if your project is to deliver a customer-facing feature or product, you likely have non-technical stakeholders, so the MBR and status report need to be written in a way that they will understand this issue. In this case, it may be best to state that a design sign-off has been delayed due to a mismatching of requirements and what the newly expected ETA for the sign-off will be. A link to a more detailed rendition of the problem can be added but the details are left at a level non-technical teams would likely understand: the requirements or implementation steps are not clear, and the team is seeking clarity to close it out.
On the opposite end of translating a technical issue to a business stakeholder, you will be translating business needs into technical requirements or clarifications for your developers during daily stand-ups or sprint planning meetings. A common occurrence for this could be in the interpretation of the business requirements as the business teams may have their own jargon that can cause confusion on the developer side. As an example, I work with tax compliance legislation, where requirements take multiple steps to get to the development team as they are essentially translated from legislation into system requirements and then into functional specifications. On the extreme end, you have the business as the tax legislation that is written. Legislation is often very heavy in legal terminology, which can be hard to translate into system requirements. For instance, one law may refer to the tax owed on a customer’s purchase. This may seem straightforward for a brick-and-mortar system but can be complicated when talking about e-commerce systems, where a purchase may result in multiple boxes being shipped out. Understanding the difference between what the law says a purchase is versus what that means for the e-commerce ecosystem is something I would work out as the TPM when writing the functional specification. Helping the development team understand that a purchase has a different meaning in the business than it does in the technical workflows helps remove built-in assumptions from the developers as to what work is being done.
In risk management, the analysis will draw on your deep understanding of the technical systems you are working with to identify and classify risks. The more you know and understand about the frameworks, network protocols, latency constraints, and availability needs of your system, the more problems you will be able to foresee.
Now that we know why the technical toolset is needed, let’s explore how the toolset can help you help your team by helping others in their role.
Using your technical toolset to wear many hats
Wearing many hats means leaning into one technical skill over another to fill in gaps in roles based on need. As such, your technical toolset should be well-rounded in preparation for that need.
In Chapter 1, we discussed the need for a TPM to wear many hats, or to take on part of a role that is normally adjacent to you but that is missing. If your organization has a product but doesn’t have a product manager, you might find yourself prioritizing a product roadmap. Similarly, some TPMs take on the role of a scrum master when one isn’t present.
Each of these roles leans on different technical skills and will require some level of proficiency to wear the hat effectively. Figure 10.2 illustrates the interconnection your technical toolset provides to allow you to step into varying roles:
Figure 10.2 – Technical overlap across job families
This Venn diagram highlights that, across the adjacent job families of PM-T and SDM, all three positions rely on a technical background to succeed. As seen in Chapter 1, Figure 1.5, each of these has some overlap outside of the technical background that also helps you wear the hat of a PM-T or SDM. However, without this technical background, the other skills would not be enough for you to step into these other roles to take on service-level projects for the SDM or roadmap prioritization efforts of a PM-T.
Now that we’ve made the case for needing a technical background and how the technical toolset will help you in your role, let’s look into what the skills are in the toolset.
Defining the technical toolset
As we discovered in the previous section, the technical foundation that you have can vary widely, depending on what your role requires.
Each of these tools is an accelerator to your role when your proficiency matches the need of your team. In cases where it doesn’t match, you will need to lean on a specialist that does have that proficiency, such as a specific programming language. This will add time to the project as additional communication is needed to get the same results you would get if you were proficient in the right technical skill.
In this section, we’ll discuss three areas that are most widely used across the general and specialist TPM roles. We’ll touch on the level of code proficiency that may be needed, system design, and architectural landscape.
Code proficiency
As a TPM, you will rarely be asked to write code. However, this doesn’t mean you shouldn’t be proficient. As a TPM, you will be working alongside software developers in most roles as they are the main resources working on technical projects. This means that your work breakdown structure will largely be high-level tasks, or stories, aimed toward your development team to implement. Your estimates, daily stand-ups, and a large portion of issues and risks will be related to code or the software development life cycle.
To determine accurate estimates, vet timelines for tasks, and even help with designs, you’ll need to have a basic understanding of reading and writing code. As with most tech jobs that require you to write code, the language you know isn’t as important as knowing one. This is because understanding a programming language is more about the capabilities, shortcomings, and problem-solving related to that language. Learning the syntax of another language and ramping up on its weaknesses and strengths is much easier once you know at least one language. This is why many tech companies allow their developers to interview in any mainstream language. This applies to the TPM role as well.
There is one caveat to this, however. There are different types of programming languages and knowing a language of one type doesn’t immediately translate to a language of a different type. The most common types in modern systems are object-oriented languages such as Java, C#, and Objective-C, and functional languages such as Scala and Haskell. Python can be used to write in both styles and is popular in technical classes. Knowing an object-oriented language does not guarantee an immediate understanding of a functional language because how they behave is fundamentally different. The same is true for the reverse as well. However, knowing one language is still easier than learning from scratch!
Chapter 11 will go into more specifics about the level of code proficiency expected, along with some examples.
System design
System design involves mapping the components and data flow within a system or service. It is also the most commonly exercised technical proficiency for a TPM. This is because most TPMs are associated with a service team or group of service teams, so knowing how the service components connect, what their APIs do, and which other services it interfaces with is required to perform your job. You cannot effectively write a functional spec without understanding the system that the functional spec is referencing.
In most cases, your day-to-day experience with system design will be concerned with writing functional specs and participating in design reviews. This means you will mainly be learning existing systems, so understanding how to dive deep into a system is an important skill to hone. You need to learn what APIs are available to clients of the system, what arguments they take, and what information they vend. I find that to truly understand an API, it’s best to also understand why it exists in the first place. This goes deeper than the answer that it exists to vend certain data. You need to ask why the API was created in the first place instead of extending an existing API and what service boundaries that the API is working within.
As the bridge between the business team and the technical team, it is important to understand the why and how of your systems as much as the why and how of your business. The reason why an API exists – which is often business-related – can help drive clarity to software designs when the developer proposes multiple options based on technical optimizations or needs. You can rule out proposals based on the business context of the requirements of the API or the needs of the business. Acting as the bridge is where our most valuable contributions come from.
Chapter 11 will also cover system design in more detail and will provide an example of system design, as well as some expectations in interviews.
Architecture landscape
An architecture landscape is a map of application and service interconnectivity at an organization or enterprise level. It’s similar to a system design but has a wider scope. Whether or not you will need this depends on your organizational structure and how closely you work with systems outside of your team. This also correlates with your TPM level: the higher your level, the wider your scope and impact become, which will necessitate understanding periphery systems in your team. Just as a junior developer would only focus on creating classes and methods for an existing system, an entry-level TPM would focus more on the immediate systems they interact with and may not think much about the overall architectural landscape.
Given the broader scope of architecture landscapes compared to a system design, the level of depth you’ll be expected to understand is much less. After all, these systems are not your immediate concern, so knowing their internal data flows is not nearly as important as understanding the input and output of the systems.
When mapping out an architecture landscape, you may focus on different aspects of system relationships, such as system dependencies or data flow. Each of these aspects brings a different perspective of the landscape to light and may aid in answering different questions. For instance, if you need to get access to a piece of data, knowing where that data originates and which systems it currently flows through can help you define and design a solution that gets the data to where you need it. However, knowing the system dependencies can help you determine the impact an API change may have on downstream services so that you can start a campaign to work with potentially impacted clients to navigate the change.
Understanding your architecture landscape is another area where the TPM acting as the bridge between the technical team and business teams is important. Similar to knowing the ins and outs of a system, knowing how your system connects to other systems in the company ecosystem can help you notice patterns or places of concern that others closer to the project cannot see. Understanding how downstream systems might react to a new piece of data or even a new value for an existing field can speed up the design process and prevent undue issues from coming up during integration and testing. Aside from knowing how systems will behave with new data, you also understand which systems are impacted by your requirements and can include them in your initial project plan.
Summary
In this chapter, we looked into the need for a technical background to be successful as a TPM. As a specialized PM, the TPM brings their technical toolset to the table to manage a technical project more effectively. We saw how the trend of a specialized PM is going deeper as the TPM position itself is being refined into hyper-focused areas of expertise, such as AppSec – TPM.
Then, we examined the common technical background across adjacent job families and how this allows the TPM to fill in gaps in personnel on their project or team more effectively than PM skills alone.
Lastly, we looked into the tools in the toolset that are most used across the industry to get a sense of how those tools are used.
In Chapter 11, we’ll dive deeper into some of the technical skills introduced in this chapter. We’ll discuss code use and proficiency for the TPM role and look at some of the high-level concepts you should understand.
We’ll also discuss system design. As this is a highly used skill and it is often brought up in interviews, we’ll focus on good and bad design practices while using the Mercury project as a basis for the examples.