What Is a Technical Project Manager?

What is a Technical Project Manager (TPM)? The answer depends on whom you ask, says Andi Blackwell, a veteran IT consultant and business operations expert. As Toptal’s Lead Director of Project and Product Management, Blackwell heads up the team responsible for matching highly skilled project managers in Toptal’s freelance network with organizations seeking top talent for specific initiatives. In recent years, she has seen a surge in demand for TPMs.

“There is definitely some debate across the technology industry about what that term actually means,” Blackwell says. “There are many people who call themselves Technical Project Managers because they have worked very closely with an engineering team or have led a technical team from a project management perspective, but that’s not what we’re looking for.”

Toptal’s definition is more specific. All project managers in Toptal’s network are experts in traditional project management skills such as scoping, budgeting, and managing timelines, as well as Agile software development practices related to iterative delivery and continuous improvement. They have invariably worked closely with engineers and could, if called upon, coach and guide a Scrum team.

In order to qualify as TPMs, however, they must have an additional layer of experience beyond managing Agile processes and collaborating with developers: They need to have been developers themselves.

A Prized Combination

Organizations big and small are increasingly interested in this particular combination of skills. “Most startups can’t hire a person that can only do one thing,” says Blackwell, and larger enterprises want to see “developer” or “architect” in a candidate’s profile if they are hiring for an engineering project.

Even in cases in which a client does not specifically require a project manager with a technical background, having the “developer” box checked is a major selling point. Someone who can plan and execute a software project, implement and optimize Agile processes, and code? That’s a huge boon.

In reality, however, TPMs are not expected to code—many haven’t coded in years. Why, then, the need for programming experience?

TPMs are required to make technical decisions, says Blackwell: “If you don’t have at least some relatively recent hands-on experience with a modern tech stack, SDK (software development kit), architecture, or test automation platform, then you’re potentially not going to make the right decisions. You’re not going to have credibility with the client because you haven’t used those things before.”

Working With Teams

Demonstrating credibility to a prospective client is a significant factor in securing engagements, but it’s only the first hurdle. Once assigned to a project, a TPM must quickly earn the trust and respect of a technical team.

Michael Poythress took up programming as a teenager. At 16, he built a commercial website for a real estate advertising business he started with his dad. He has been the CEO and founder of multiple startups since. In 2018, he joined the Toptal network as a TPM and now works closely with engineering teams. “If I had no experience with coding, the programmers would pick up on that,” he says. “They would not shoot straight with me. But if I’m challenging them and speaking to them as a peer, there’s respect and a rapport.”

And it’s the technology experience that counts more than the title, says Allen Takatsuka, a Toptal TPM based in Orange County, California: “From what I’ve seen, the ‘T’ in TPM doesn’t really carry any weight for engineers. They think it’s just another project manager who’s going to set up their meetings and ask them to fill in spreadsheets.”

Once common ground is established, however, “the flavor of the interaction is very different. It’s more of a partnership with engineering,” he says.

Takatsuka spent decades leading engineering teams earlier in his professional life. He credits that experience for having leveled up his soft skills. “It’s a bit of a different empathy skill,” he says. “You have to show that you can speak the language. You’re able to say, ‘I see why you have these challenges based on the technical things that are going on.’”

Dan Allen, a technology consultant from Vienna, Virginia, describes his career progression as “guy-in-the-cubicle programmer to technical lead to architect, director, VP, CTO, CIO.” Since joining the Toptal network as a TPM in 2019 he’s been busy, having worked on 14 client engagements.

“I rarely read code. I almost never write code,” he says. “But there have been situations where a developer gets stuck. They can walk me through the architecture and I can see exactly what they’re trying to do and the logic.”

He finds the dynamic useful not just in edge cases but more broadly. “Your team knows that they can come to you and talk, and you’re really understanding what they’re saying,” he says. “You can help them consider all of the complexities in case they missed something. You can be a sounding board and provide feedback.”

The Multiplier Effect

That kind of feedback and insight is important for more than relationship building. TPMs offer a different value proposition to an organization. They serve less as conduits for information and more as sources of knowledge. Yes, they plan, coordinate, and communicate, but they also help clients and teams work through complex technology decisions.

“You have the ability to be technically opinionated,” says Takatsuka. “And that adds value to the organization because now you’re having more of a multiplier effect, as opposed to just organizing and collaborating.”

Takatsuka notes that TPMs have to jump through fewer hoops to solve problems. At larger organizations especially, a non-technical program or project manager might approach a technical challenge by identifying the relevant players and stakeholders, offering context, aggregating information, and then sifting through the results to make a decision. TPMs can bring their own knowledge to bear.

“You can address risks so much more efficiently,” says Oana Ciherean, a TPM based in Tokyo. “And those risks can come from so many places. They can come from wrong estimates from the team. So you’re able to say, ‘Okay, I’m sure that this piece of code is not going to take a week to be written’ because it’s really two days. So you can actually unblock people. Because you’ve figured out that they’re stuck and that’s why it’s taking them five days. You know that because you’ve been there and you’ve been stuck yourself.”

Finding the Balance

Ciherean began her career as a developer but soon moved into project management out of a desire to be involved with the bigger picture. In those roles, however, she found she missed coding. She says Technical Project Management offers the best of both worlds: “It allows me to be really hands-on in technology but also high-level with understanding the business and the customers and what they want in features.”

Poythress, too, feels he’s found his sweet spot. “I am a translator or a liaison between the visionaries who have an idea and the technical talent that knows how to build it and make it happen,” he says. “I speak both languages fluently. I speak ‘normal person’ and I speak ‘technical-ese.’”

The Mini CTO

TPMs working for startups and small businesses occupy an especially prime seat at the intersection of business and tech. On these engagements, a TPM is often the first hire to come on board at the outset of a project. He or she is then responsible for assessing product viability, defining the technical scope and requirements, and helping the client (sometimes a single founder with a seedling of an idea) select a tech stack, evaluate vendors for service delivery, implement DevOps best practices, and assemble the right team.

Takatsuka thinks of these engagements as “mini CTO” roles, in which the TPM bridges the business and technical realms to get things off the ground. Some clients know next to nothing about developing software, he says: “How do I set up shop? I’ve read about Agile. How do I do that?”

Poythress sees the two roles as overlapping, even indistinguishable from one another in certain cases. “There’s a lot of cross-pollination,” he says. “A CTO for a smaller organization could very easily move into a senior technical PM role in a larger organization and feel right at home.”

Enabling Agility

While the mechanics of Agile are in the wheelhouse of virtually any project manager with software development experience, someone with technical aptitude can bring a more nuanced perspective to managing processes.

Ciherean finds that Agile methodologies are never implemented strictly by the book; they must be customized, blended, and adapted for the specific needs of a team and project.

“You have to make sure that what you are designing as a process doesn’t interfere with the developers’ work and actually makes it more efficient or productive,” she says. “Sometimes that means going deep into the GitHub workflow, for example, to see how they do their commits, seeing how they create branches for their code, and seeing if your process fits in their workflow. And then you either correct your process or correct their workflow.”

A TPM’s expertise can also inform specific Agile artifacts and practices, like the product backlog and relative size estimations.

“If you understand the technical, you know the rough complexity of things in a backlog,” says Takatsuka. “Otherwise, all you have is this list and it would be hard for you to know whether number one is a T-shirt size Large compared to number two. You might have an idea that one is harder, but you don’t really know what’s behind the scenes. An “extreme” TPM, he says, “could size things himself, with the caveat that when the team comes on board, they’re going to have their own velocity.”

Poythress uses his understanding of size estimation as a gauge to evaluate the tech leads and engineers he considers for a project. If he expects something to be a small task but someone else considers it giant, that’s a red flag: “I’ll hear them out to see if there are complexities I don’t know about, but if that doesn’t hold water, I’m like, ‘Okay, well, that’s not a good fit.’ We need somebody who understands this really well and isn’t intimidated by what should be a simple feature.”

TPMs also help educate clients about non-functional requirements. How do you deal with high availability? How do you deal with disaster recovery? “Without the technical understanding, I don’t know how you have that discussion,” says Takatsuka. “You’re going to probably stop at the Scrum-requirements level and call it a day until the technical people come on. Well, then you’ve got this huge chasm.”

Keeping Current

Although their time at a keyboard plays a fundamental role in what they do today, TPMs can’t rely on past experience to stay relevant. Given the rate at which technology changes and develops, it’s easy to fall behind.

Poythress learned this the hard way, during a five-year window prior to joining Toptal, when he was exclusively focused on running his own company. “I definitely got stagnant,” he says. “Lots of different languages came along and solved problems in that period of time that I knew nothing about because we had our tech stack and that was all we needed.”

Today he spends up to 10 percent of his time reading documentation, watching YouTube, and sandboxing “to learn about the latest and greatest things.”

“I’m almost always dabbling on the side with a new language or technology, just so I stay sharp,” he says. “Because if I don’t, the industry will move on. I’ve had that happen before. And it’s a lot harder to cram than it is to stay up to date.”

Takatsuka is also proactive about filling in his knowledge gaps: “Google is great these days. YouTube is awesome. You have to do your homework. But that work builds on itself.”

He also relies on a wide network of fellow consultants for support and knowledge sharing. “I have been in situations where the client wants to use Google, but I happen to know the AWS platform better,” he says. “I can call friends and say, ‘Hey, we’re going to use Firebase. Have you had any clients that do this? What about scalability?’”

Even after more than 30 years in the business and multiple executive-level roles, Dan Allen isn’t afraid to get his hands dirty. In the last three years, he’s taught himself to single-handedly deploy on Amazon and Google Cloud. “I did it so that I could understand it and help a Toptal client,” he says. “They didn’t have a technology team. All they had was me. So I went to YouTube University and I got it done.”

So much has changed since Allen started out as a developer in 1985. But he relishes the challenges that come with each new opportunity. “That’s part of what I love about the job,” he says. “There’s always something you haven’t done, something new. And you always walk away with an additional feather in your cap that you can leverage on the next engagement.”