“When will Stu stop playing with code?” The question was about Stu Fieldhouse, a Technical Project Manager working on my programme. My answer was “Never”. I had brought Stu in exactly because he plays with code. Or, more constructively, he fixes problems and lets us move on. Fast.

Stu was puzzled why I’d brought him in as a project manager (PM). That isn’t his thing.

I have worked with Stu before – he is one of the rapid development specialists I mentioned in the 35 person-years worth of prototype is a fantastic spec. At that time he was a coder. Loved it. Still loves it. In the intervening time he picked up some project management responsibilities within my old team. It was that combination that opened the door to the role on my new team.

And, as it happens, I didn’t really need a PM or a Delivery Manager. At least not a hard core version of a PM.

When Stu asked “what do you want me to do?” I explained that the product we were working on was a new area for the business and for the industry in general. A lot of the technology was raw and rapidly evolving. I didn’t know what problems we’d have to face but I knew there would be problems. Technical problems that could kill the initiative dead. I also knew I was unlikely to build up an internal team to deal with these challenges – I was going to spend the development budget elsewhere. The majority of technical work would be done by vendors. I was confident that Stu would help me spot the problems before they were harmful and that he would cobble together a solution.

Stu now calls himself a Technical Project Manager (TPM). Generally people on my team can call themselves anything they like and, although TPM is a role I normally avoid, in this case I agreed. Stu is a TPM. A proper one. More technical than PM.

A conventional PM could not have contributed what Stu has on this project – would not have cracked the technical challenges Stu did. Or would have needed a technical team to do it. Stu was more like a one man band. Liaising with 3rd parties and imposing high quality standards on them. Knocking up proof of concepts. Turning some of them into production systems. Keeping the ball rolling in a challenging and evolving area.

My point isn’t really about Stu or the TPM role, my point is about shaping the team. I believe in bringing in good people – like Stu – and putting them in the right role – in this case a TPM. Then let them loose.

Sometimes you might even surprise people with the role you see them playing. Stu was quite surprised.

Every programme and project is different. You need to shape the team accordingly. And on this gig I needed a Stu.