Imagine you’re part of a software development team that’s working on an important new project. Everyone is excited about the work, but you’re running into trouble.
The work wasn’t clearly divided up, so some of the engineers unintentionally did overlapping work. Meanwhile, neither the PM nor the engineers realized that they would eventually need sign-off from an external stakeholder, who doesn’t agree with all of the project requirements. By this time, the company’s security team has reviewed the engineers’ plans and has some of their own requirements. To cap it all off, the engineers realize that their original approach will take much longer than expected, because a key dependency needs to be updated first.
So, to review: the project requirements need to change, the approach needs to change, the scope or timeline needs to change, and the engineering work needs to be divided up more clearly. Whose responsibility is it to make all of these changes? On this team, the best solution might be a series of conversations between the PM, the stakeholder, the security team, and the engineers. This solution might work in the end, but it will likely involve some frustrating miscommunications and a lot of wasted time.
However, if this team had included a technical project manager (TPM), many of these rough spots might have quickly disappeared.
What is a TPM?
To clarify, a TPM is a technical project manager, not a product manager. Once a product manager (PM) has defined what’s to be built and its scope, the TPM is in charge of executing that vision. This involves understanding the engineering approach in order to track the team’s progress and flag technical risks. It also involves keeping track of everyone who’s working on a piece of the project, and clearly communicating with them all about timelines, budget, and requirements. The TPM also communicates with stakeholders outside of the team, so that these stakeholders understand the project’s status and vision.
All of this work is valuable for a project’s success. When a TPM communicates clearly and effectively, developers’ work flows easily. They’ll be able to focus on what’s important for the project without spending time communicating with external stakeholders or figuring out how to divide up their work within the team.
But the real value of a good TPM is in shaping the project itself. A successful TPM has a uniquely detailed-yet-global view of the project. This allows them to help shape the project’s approach so that the work is both feasible and aligned with the team’s ultimate goals. This alone can be a full-time job, as project timelines and requirements inevitably shift in response to new information. For example, a new blocker or risk may become obvious once the implementation work begins. When this happens, a good TPM can track the developments, understand how they will affect the project’s success, and help the PM modify the project’s scope accordingly.
TPMs and large organizations
While TPMs’ skills can improve the health of any engineering organization, they’re particularly crucial for larger organizations. This is because larger organizations are more likely to take on projects that span several teams. Managing the execution of such projects is far more complex than managing single-team projects, and a good TPM can have a powerful effect by making these multi-team efforts more successful, efficient, and healthy.
At large organizations, it’s also more difficult to establish standard practices and nimbly respond to changes in the code stack. This is another area where TPMs can help. For example, when a new vulnerability—such as the Log4Shell vulnerability in Log4j—threatens a whole organization, TPMs can coordinate a response across disparate teams to ensure that everyone’s code is patched and healthy.
What makes technical project management hard?
At this point, you can likely appreciate that the TPM role is hard. It involves tracking a lot of parallel work streams and coordinating among a lot of collaborators. Often, this job is difficult because TPMs are solving legitimately tricky challenges that can’t be simplified; for example, finding the most efficient way to build a product that meets all stakeholders’ requirements. But frequently, this job is hard for the wrong reasons.
Being a TPM typically involves a lot of manual tracking, ticket-writing, and assigning. TPMs have to constantly check in with the project’s collaborators to monitor their progress and catch blockers. As a result, TPMs are often seen merely as naggers and time-keepers, and don’t get the respect that they deserve. This makes their work increasingly difficult—they have to continue checking in on people who associate TPMs with the stress of project deadlines.
How can Cortex help?
Cortex builds software that can lighten this unnecessarily hard grunt work for TPMs and free them up to do the truly important work.
For example, TPMs can gather a project’s requirements into a Cortex scorecard. They can also identify all the collaborators involved in the project, and share the project’s requirements and status in a common forum that all of those collaborators can access. This means that everyone is on the same page, because everyone gets the same information. Scorecards can also be used to manage a production readiness checklist, which will help the team anticipate and debug errors upon release. For cross-organization initiatives (e.g., handling package vulnerabilities or version control), Cortex can help TPMs identify which teams or services are affected by the initiative, and then compile and share scorecards across those teams.
With these tools, Cortex essentially automates the grunt work involved in coordinating projects across team members and tracking their progress. As a result, TPMs can focus on the legitimately hard work of shaping the project itself, rather than spending time and social capital checking in with collaborators. With their powers leveled up, TPMs can help their teams level up as well.
To learn more about how Cortex can help your organization, sign up for a demo here!
