13

Enhancing Management Using Your Technical Toolset

In this chapter, I’ll cover how the various tools in your technical toolset enhance your ability to manage projects and programs. I’ve discussed each of the key management areas in the first two parts of this book through various lenses and have touched on challenges you face in the technical space. Next, I talked about the technical toolset, which consists of code expectations, system design, and architecture landscape design. Now, we’ll cover each of these intersections of the technical toolset and the key management areas and, lastly, explore how the toolset will also help you be a better leader in your organization.

We’ll explore how to enhance management with the technical toolset by doing the following:

• Driving toward clarity
• Resolving conflicts
• Delivering through leadership

Let’s dive in!

Driving toward clarity

A TPM is an extension of a program manager and, as such, it shares the trait of driving toward clarity. However, our technical toolset allows us to use specialized tools to tackle technical problems that would leave a non-technical PM struggling to process them. We speak the same language – quite literally – as the people who are delivering the project and can bridge the gap between technical jargon and the business. I’ve talked about driving clarity in various stages of a project and have discussed the technical tools TPMs use. Now, let’s see how these two concepts help each other. I’ll go through each key management area, from planning through risk management and stakeholders and communications.

Planning

During the planning stage, all three technical skills I’ve discussed are used. We’ll go through each of the technical skills across three steps in the planning process: requirements analysis, project plan creation, and feature design. Figure 13.1 shows the overlap between the planning process and the technical toolset and will aid in the discussion.

Figure 13.1 – Technical toolset during planning

Requirements analysis

The first pass through the requirements has you exercising your code knowledge to start to piece together the functional specification based on the requirements. You use the known system designs and architecture landscape to determine viable solutions and identify upfront risks, which we’ll cover more in the next section.

Project plan

The more you know of the code base that your developers use and have an understanding of the programming language, the more you can begin to intuit the effort it would take to implement your solutions and start to lay out your project plan. For instance, in many applications, there are tasks that are performed often and follow a particular pattern. A good example is adding a new data type based on an existing abstract class and plumbing that data through multiple services. Knowing where the abstract class is located and where the data model is defined can help you piece together the various tasks for implementation, and then knowing the deployment timelines for the packages where the class and model are will give you an idea of the launch plan.

Strategic planning

In this example, I mention that creating a new class instance from an abstract class is a common scenario. If you notice, tasks are often repeated from project to project; this is a good area to dive deeper into and see if there is a way to automate or reduce overall time-to-production. Your next project might be a good place to add time to build out an automated solution. Watching for patterns is a key part of a TPM’s long-term strategy planning.

Design

Once you have a plan drafted, you consult with your developers and SDMs to dive a bit deeper. At this stage, you are relying on your ability to bridge the gap from the business requirements to the technical requirements to help your team understand the scope and bring context to your proposals.

Risk management

Good risk management starts with good risk analysis and in order to analyze, you first need to understand what you are analyzing well enough to do so. That is to say, to properly analyze risk in the technology sector, you need to understand technology.

Figure 13.2 illustrates how the technical toolset allows for more effective risk management.

Figure 13.2 – Technical toolset in risk management

In the preceding figure, we are concentrating on the first two stages of risk management: Risk Identification and Risk Analysis. The last three in the cycle are mainly administrative and acting upon the work completed in the first two stages. As you can see, both of these stages include all three technical skills that we’ve discussed as represented by the triangles surrounding the stages. Let’s discuss both stages in a little more detail.

Risk identification

Similar to how knowing the code base can help you create a plan, it can also help you identify risks. For instance, you might notice that a particular requirement will require a code refactor in a package that is currently being modified in another project, potentially causing a cross-project dependency and risking delivery timelines.

Knowing your code base and service dependencies can also help you identify risks in system designs. Introducing a new architectural pattern to an existing system or in a system that is new to the team is a risk to timelines as there are a lot of unknown unknowns when doing greenfield development.

Knowing your architectural landscape can help identify cross-organizational or even cross-team dependencies arising from a system design. These dependencies carry risks as you are reliant upon changes from another project, your changes are needed by another team, or it simply requires working closely with another project to ensure that no duplicative effort is done on either project. During design reviews, always ensure you are looking upstream and downstream of your system to ensure proper alignment in data flows, as well as at other projects that may be working in the same code packages concurrent with your project.

Risk analysis

During the analysis stage, you are determining which strategies can be planned for every risk that was identified. Each of the strategies involves varying degrees of technical acumen. Let’s look at each one:

• The avoidance strategy may depend on code understanding and system design to know whether or not a risk can be avoided. As an example, if you know using a specific technology framework would add risk due to stability issues, you need to know whether alternatives to the framework offer more stability. It may be helpful to know whether other frameworks are used elsewhere in the company (architecture landscape) where using a known system may offer some synergy.
• The mitigation strategy would require similar knowledge as avoidance in that you would need to know whether specific mitigation is feasible. For instance, using additional resources to crash a task would only work if you knew the task could support additional resourcing. If the task involves a single code package, it may be hard to parallelize enough work for more than one person.
• The transference and acceptance strategies do not lean heavily on technical acumen as they are mainly project management trade-offs between time and scope. For transference, there may be some level of understanding of the technical requirement of the task and to be able to evaluate whether the party you need to transfer the task to is technically capable, though standard vendor evaluation procedures can help in these cases.

We’ve looked at how the technical toolset enhances both the planning and risk management areas, now let’s explore stakeholder management.

Stakeholder management and communications

Our technical toolset naturally enhances our ability to work with stakeholders simply by the nature that many of our stakeholders are also technically minded. For those that are not, we act as a bridge between the technical details and clear understanding. Since we interact with stakeholders all throughout the project, we’ll look at this from the perspective of the technical toolset and see how each skill offers ways to enhance our engagement.

Code basics

By understanding the code base that your teams work with, you can have open and unrestricted conversations with your developers. Your developers do not need to worry about translating the problem when talking with you and can just explain the issue in a way that is natural to them. This reduces the chances of misunderstanding and can speed up conversations by being able to speak on the same terms.

This isn’t to say you won’t have questions, but that the questions will be technical clarifications and deeper in nature. In fact, I encourage asking clarifying questions as this is key to driving toward clarity. Without knowledge of basic programming philosophies, the depth of the questions would be insufficient to clarify the problem to a point at which you can help.

System design

As a TPM, you contribute to project designs, from feature designs to full system designs that cover the project from end to end. Your technical background will help you navigate design reviews effectively. In these reviews, you tie the design back to the functional specification as well as the business requirements. I have often found discrepancies in designs where the business requirement wasn’t fully understood, and it becomes clear that what seemed to be a clear understanding in a meeting translated to a misinterpretation. Your ability to read the system design and catch this early on during the design is a safeguard against late-breaking discoveries that take more time to fix and often lead to a project delay.

I recently had a discussion in a design review where two of the three design choices didn’t meet the business requirements and I realized that the team didn’t fully understand the background of why the project was being done. All the developers were new to the project and the months-long context building that happened before they came on board was lost to them. They saw the requirements text but didn’t know why the requirements existed. So, I set aside time to go through the history of the project and what system limitations led to the need for the project. This context helped the developers understand why we were doing the project, which in turn helped them better understand their design choices and led to a better design that offered greater room for future scalability.

Architecture design

During a design discussion, the TPM is also responsible for ensuring the right people are in the room to make the most appropriate choice. To do so properly, you need to be able to speak about the design authoritatively and understand what the various stakeholders may need to get out of the proposal. In some cases, this may require looking beyond the system design you are reviewing and up to the architectural landscape. I have found that in large distributed systems, solving a data flow problem within a few local systems may not always scale to the entire ecosystem. This could lead to an ineffective design where the new data flow cannot be utilized upstream and downstream due to the client’s – or even a client of the client – data handling. Looking at the larger picture, you may know of architecture evolutions that are in-flight and not present in the current architecture that should be examined to save future throw-away work. While this is true at the system design level as well, the SDEs and SDMs are more likely to be aware of these initiatives than of cross-organizational initiatives.

Now that we’ve discussed all three key management areas, let’s see how your technical toolset helps you resolve conflicts in these same areas.

Resolving conflicts

Conflict resolution is one of the key methods by which we find a path forward as many issues are rooted in disagreement or misunderstanding between multiple parties. As such, any place where a TPM can run into an issue, conflict resolution can make an appearance.

Planning

Conflicts during the planning phase usually occur while analyzing requirements but can also occur while creating the project plan. We’ll go through a few examples and see how your technical background can help resolve these conflicts.

During requirement analysis, disagreement on a requirement or an ambiguous requirement is common. As you work with your stakeholders, any clarification may introduce new complexities or insights and can steer the conversation organically. I have found that knowing my system behaviors and complexities helps during these conversations.

For instance, a recent project had a requirement to take a regional functionality and make it available globally for business expansion. I understood how the functionality was implemented and could use that to elaborate on specific inputs needed from the business team and was able to clarify ownership of data elements and expectations across multiple teams. Without knowing how the feature was implemented, this discussion would have come up much later during the design or implementation and could have led to delays by not having proper expectations about when and where data would be made available for the expansion.

Sniffing out implementation requirements

Depending on where your requirements are coming from, they will include some technical details and push for a specific implementation. Being able to recognize these scenarios will give you the chance to challenge the requirements and dig deeper to find what the underlying ask actually is. This is important because systems change over time and relying on a specific way to solve a problem can slow down the natural evolution of a system. Knowing what the actual need is allows the development team, along with the TPM, to find the best long-term way to meet the requirements.

Risk management

Risk management can involve conflicts in the identification and callout of risks as well as the risk strategies that are planned.

We discussed how your technical background helps identify risks in the planning section. Conflicts during identification are almost solely office politics in nature. As such, the skills needed here are mainly soft skills as people don’t like a light shined on their team or service if it is called out as a risk either due to a cross-project dependency or code deployment difficulties. Leaning on transparency and ensuring language is as neutral as possible is the best course of action.

For risk strategies, there can be disagreement on whether avoidance, transference, mitigation, or acceptance should be planned for. In these instances, your technical background can be of help in resolving conflict. As an example, a project I was working on identified a risk where a new data field was being passed between services from different organizations. The risk was planning for the use case where the new field wasn’t ready in time for system integration. The proposed mitigation was to pass a null value downstream so that the data field could at least be picked up and some work downstream could be unblocked. I knew that the downstream system could not handle null values in this context and that this mitigation would not work and so I challenged it. Instead, we mocked non-null data to unblock integration testing downstream. Though a straightforward example, my technical understanding of downstream systems allowed for a quick re-direction of the risk strategy to ensure we identified the right strategies that would actually achieve what was needed.

As an arbiter in many conflicts, a TPM’s technical understanding of the problem at hand will aid in quicker arbitration. It also allows us to catch instances where the technical problem is not being conveyed properly across all parties – again acting as the technical bridge. This bridge can be between two technical teams and may rely on your domain and technical knowledge combined to successfully arbitrate between teams.

During a systems integration between two services, there was an error that was identified during testing. The error seemed to point toward one of the two services as the root cause though that team denied that the error was their problem. Upon investigation of the error code returned, I realized that there was a misinterpretation of a field as required by one of the teams. Essentially, one team assumed the other team had made a field required, so they did the same, but it wasn’t actually required. Knowing the two systems involved, and the requirements, I was able to catch the mistake and worked with the team to update their model to reflect that the field was not required in both services.

Stakeholder management and communication

Most conflict happens in stakeholder management as this encompasses most communication with the people involved in the project, from the developers to the team leaders. As it involves communication, it too is often focused on soft skills and tailoring your responses to the audience for clarity of thought and relevance. However, there are cases where your technical background plays a pivotal role in resolving conflicts with stakeholders. Let’s take a look at a few examples.

During the execution of the project, you will be working with your developers on a daily basis in most cases and will attend stand-ups to help your team along and get an update on tasks. During stand-ups, blockers are often identified and talked about. It often falls on the TPM to act as a scrum master or at least help developers to unblock. Having a solid technical foundation will help you understand the risk quicker and allow you to act on it faster. As a TPM, there are times when the developers may look to you for technical guidance. Your insight into system behavior, client behavior, and code structure makes you a natural resource for trying to find the right solution to a problem. The TPM is also often the source of the functional specification that the developers reference during design and implementation, so quick consults with you can go a long way to quickly resolving roadblocks.

In the same way that your technical background helps you during stand-ups, it also helps when reviewing system designs. Part of your job is to challenge the system design when it doesn’t fit the needs of the project and the needs of the organization. The other part is being an arbiter of conflict during system design reviews. As the TPM, you own the functional spec, you understand the requirements, and you know the architectural landscape, which gives you a unique perspective on the problem that the design is trying to solve.

A program is a good analogy of your role in a system design. In a program, multiple projects share a common set of goals, but each has its own set of goals that may seem unrelated if looking at the project on its own. As program managers, we ensure that the common goals are understood across all projects in the program and that every decision made in a project is done with full awareness of the implications at the program level. The same is true for a system design discussion where you bring knowledge and understanding of systems that are related and have an impact on the system design being reviewed and you ensure that the decisions being made on the design take the other systems, projects, and initiatives into account.

We’ve discussed many different ways in which your technical toolset enhances your ability to manage a project and resolve conflicts. Now we’ll discuss how your technical foundation helps you deliver through leadership.

Delivering through leadership

As a TPM, you are a leader in your organization. You effect change through your programs and projects, but also as a contributor to the technical direction and strategies of your team. You identify problems but you also resolve them. Here are the ways in which your technical toolset helps you deliver through leadership.

As a leader, you will be expected to define the direction of your team. This expectation grows the higher up you go as a TPM. To do this, you are expected to find issues and define and drive solutions to fix them. This can be a difficult move for some who prefer to work within the bounds of a specific problem. However, defining a problem and solution within the confines of a project is similar to the confines of a team or organization. Just as a project has a goal, a team or organization has a charter. The most reliable way to find a problem worth fixing is to look at repeatable efforts across projects and recurring pain points during development. If the problem occurs often, the ROI is likely worth the effort to solve it. Use your knowledge of your system designs, architecture landscape, and even coding practices along with your backlog of project issues and risks, to help understand where problems may exist. The only difference between these is the scope in which you are looking to solve problems.

It isn’t always your job to come up with the direction to go in but sometimes it is up to you to ensure that the chosen direction is being pursued. During project planning and design, you can reinforce the team or organizational direction by ensuring system designs and design patterns match the intended direction of the organization.

As an example, many companies have a technology directive that persuades the use of specific technologies or announces a shift from one technology to another. These are often forward-looking and gradual shifts, allowing teams time to make the switch. Knowing the expected technologies, if any, of your company allows you to be an arbiter of change. This can come up during project planning where you add additional time to allow for the migration from one technology to another for a single project, or even create a project to track a team-wide migration effort.

Summary

In this chapter, we discussed how your technical toolset can help enhance your project management by examining the key management areas of planning, risk management, and stakeholder management and communication. We looked at each of these in terms of driving clarity, resolving conflicts, and delivering through leadership.

Across all aspects of project management, a TPM’s technical toolset allows for quicker, more efficient execution by providing foundational context and knowledge in the problem space. The toolset also enhances the TPM’s leadership by effecting change in the technical direction of their organization.

A TPM is both a PM and a technical expert, and they are greater than the sum of their parts, as the old saying goes. It is the joining of the project and program management skills with technical acumen that acts as a force multiplier and allows the TPM to do their job better than a subject matter expert or a PM alone.