Technical Product Management

Like many software engineers I’ve gradually worked my way up to leader ship roles and have also started a few companies where I typically take ownership of the technology platform. As a startup CTO, any job that has some technical aspect to it, it’s of course my problem to fix or delegate. However, I’ve over the years realized that, that is not the whole story. There’s a reason why we do the technical things we do. There’s a reason we things in a particular order, and there’s a reason we do certain things and don’t do certain other things.

Those decisions are informed by the business context and are typically taken by somebody that might style themselves as a business owner, a product manager, etc. Somebody that is not the CTO basically.

Over the years, I’ve worn that hat as well. Sometimes out of necessity (there was nobody else to do it) but also frequently because I had specific ideas about what needed doing and why. For better or worse, I’m currently both the CTO and CPO of FORMATION. I’m learning on the job and I have great people around me including some that would wear that hat if it weren’t for the fact they are busy wearing other hats. And I’m not half-bad at it too.