Late last year, I volunteered to play Technical Project Manager (TPM) on a project. This was a new role for me. I expected it to align with my skill set and one that I would enjoy doing, and after 4 months, I feel like I was right. I was both a TPM and an engineer on this project and as it turns out, playing both sides worked well for me. It didn't start out that way, but my responsibilities / contributions as TPM became more clearly defined. I

• scheduled and "ran" weekly sync meetings,
• posted weekly updates for stakeholders and observers,
• set scope (or, in most cases, settled scope when there was ambiguity)
• organized work into milestones and justified it qualitatively and quantitatively,
• tracked open questions and whether or not we needed to answer them,
• initiated and concluded conversations with representatives from other teams
• and attended wider TPM meetings and participated in larger "How to TPM" work at the company

My general view is that groups of people don't organically work towards the same goals, at the same pace, or stay focused on the same thing at the same time. Software projects often take longer or never fully execute because of this. A project manager's role is to make sense of the organic nature of people, and to direct energy into the right places. This is harder (and more important) with distributed teams. I visualize it like the sport of curling — TPMs brush and sweep the ice around an already-traveling-stone such that it arrives at its destination as planned. I don't know if this is the perfect metaphor because I know nothing about the sport of curling, but the idea that a TPM nurtures a protective space in which a product and engineering team can do their best work seems right.

In any case, I was fortunate to play this bridge role, and would probably do it again.