Move fast and fix things
When the Product Manager left the business I work in to move overseas, they left a product-shaped hole in our processes. Rather than rush to hire into this position, the role was shared between myself (as the Head of Engineering), and the CEO. Aside from me now spending much more time talking with customers, this also changed how we operate internally.
There’s a classic ‘Both Sides of the Table’ article where Mark Suster defines his view on the difference between VP Engineering and CTO. Broadly, along the axes of Process and Technical Capability, the CTO and Program Manager sit mostly in the Process and Technical quadrants whereas the VP Engineering saddles both.
I firmly believe there’s a third dimension that many startups need to consider when defining technical leadership roles —understanding of the product and your customers. Product Management is definitely its own role — but there’s significant wisdom in technical leaders knowing Product; and knowing is half the battle. Know your product, know your customers, know your business.
As technical leaders, we prioritise development to maximise impact and leverage but, as seemingly intangible attributes, how do you assign relative value to them? Understanding your customers and their problems can help provide a customer-focused framing that everyone in the business can understand and get behind.
We can frame impact as a function of both customer success and engineering success. If you know your team and your customers, you can open the discussion with your team and your business colleagues to estimate a value. Pick a scale. 1–10 is fine. For your project, epic or story, assign values to both attributes. Sum them. Stack rank them. Bam! — you have a list which attempts to balance the needs of both your business and your technical team, but some of these items will be much harder to create than others. How do we factor that in?
Leverage is the concept of maximising output versus input, so we will want to add in a value that represents complexity vs impact. Simple work with high impact is often the best way to get a product moving. This value is a multiplier, however, there’s a double edge here — an incorrect scale might mean that complex work is avoided indefinitely. It’s worth understanding how your team views time spent and complexity and adjusting the scale using their own terms and perception.
There will be many other forces at play here —and these will likely be specific to your business. You will also want to consider the negative impact — what happens if we ignore this and do nothing. Asking these questions will inform your decisions.
Operating along in only the customer or technical realm can result in technical debt or busywork — neither of which are desirable long-term. If you must tread one of these paths, make sure it’s a conscious choice, and that the reasoning is documented . Future you (and future technical leaders in your business) will thank you and be perhaps be less likely to throw you under the bus!
This simple approach has helped me to balance business and technical work. What frameworks do you use to help define technical priorities? I’d love to know.