Engineering Attribution

Attribution may be a funny way to describe it but how exactly can you describe to a non-technical person what good engineering is? How do you take outcomes/initiatives such as;

• lines of quality code written
• lines of code removed
• scalable, maintainable code
• re-factoring components/features
• prototyping/evaluating new tooling/technologies
• pair-programming

and stick a dollar figure on it? Things like uptime or speed to market sure, but the more subtle parts of engineering that can have the biggest impact are a factor of times harder to convey. I wrote about how being the fastest, not the first is what the aim needs to be for a business to scale but to do that requires a heavy upfront investment with little or no showing for a period of time — and that’s where it becomes very difficult to attribute progress to engineering. Because there can be no visible progress.

Business, especially non-technical business folk love to understand the Return On Investment — what’s the ROI on this goal/initiative/feature/new hire they ask. They then go deeper, and try to understand what percentage of time engineers spend building vs maintaining so that they can capitalise the cost of the team and make their EBITDA figure look better, which is what investors usually look at. It’s worth noting that Operating Free Cashflow (OFCF) might be the better figure given it doesn’t discriminate between what you’re building vs what you’re maintaining, it just tells you in plain text what you’re investing and for what return in a given time period. But I digress.

Image: Technocrazed

The reality is good engineering can have compound effects. Bad engineering can actually provide a significant negative return on investment and a heavy sunk cost. Imagine that happening in another profession? It would be akin to hiring a team to build you a house and instead they dig you a hole, fill it with rubbish and then leave after getting paid. Not likely right? It’s a pretty realistic outcome if you’ve ever seen bad engineering, which can be caused by things ranging from bad business strategy to just poor decision making by those closest to the code.

If we’re going to be successful in proving to non-technical business folk on why software is eating the world then we better start being able to articulate it and quickly else our roles in companies run by these folks will forever be limited and bounded by the business folks view on technology, or even worse “I.T”. I’ve had decent success with the Engineering Effectiveness framework which is quantitative and importantly, repeatable but I’d love to hear your thoughts on how you attribute value to engineering and some of the tactics employed that have helped.

For more insights check out the Carsguide/Autotrader engineering blog.