Finding Clarity in the Technical Landscape

Leveraging depth and breadth in a technical role

As a TPM, we are often aware of many programs and projects that impact our team or organization. We work with leaders, other TPMs, and other teams to deliver our goals. This gives us both a deep knowledge of our projects and a breadth of knowledge in the technical landscape surrounding us.

In a technical setting, we use this depth and breadth to our advantage, because we can look at each problem from different vantage points—to use our analogy, from the street level to the full cityscape. These varying vantage points allow us to connect the dots across projects and programs. Let’s look at a few examples of seeking clarity and connecting the dots in a technical setting.

Let’s explore a technical breadth example. As is often the case, team members working on the implementation of a project are highly focused on the project goals. While this is desirable, because it ensures a solid solution to the problem at hand, they might miss how these changes may impact other initiatives.

As a TPM, you might be in a position to help drive the technical direction of your team. This involves knowing where your team and technology are headed, as well as the tenets that drive them.

This knowledge will help drive your day-to-day direction and your design decisions, by helping you connect problems and solutions across project and program boundaries.

Author’s experience

In a recent example, my organization received a request from a client team to look into the behavior of a field we return in our service response. It was behaving incorrectly for an edge case, and they wanted us to fix it because they relied on that field. Our on-call developer was looking into this issue when I came across the ticket. Though it is always a good idea to fix edge case issues in your API responses, for this particular field, the team had decided that, in the long term, they wanted to remove this field from our response. I engaged with the client who submitted the ticket and talked with them about what they were trying to solve. I took this back to our team to help ensure that our long-term vision was not missing a use case, while also providing a different way for the client to achieve their desired behavior without relying on that field. Our on-call developer didn’t know or wasn’t thinking about the long term—they were in triage and trying to solve issues, so this connection was initially missed.