Attribution may be a funny way to describe it but how exactly can you describe to a non-technical person what good is? How do you take outcomes/initiatives such as; engineering lines of code written quality 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 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 no visible progress. being the fastest, not the first be 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 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 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. why software is eating the world Engineering Effectiveness For more insights check out the . Carsguide/Autotrader engineering blog
