Every company is a software company, or so the saying goes. The technology industry is extremely fond of stylising every ‘modern’ organisation as an essentially cloud-native data-centric operation where the physical assets and machinery are secondary to information intelligence.
So dear CEO, you thought you were an offshore petrochemicals specialist? No sorry, your topographical ocean floor surveys all run on applications, databases and data, so essentially we can forget about the pipes and gantries and call you a software company.
What’s that, other CEO? You think you’re a cake baking specialist? Actually no, your fabrication plant and product preparation line ranks somewhat second place to the importance of your digital supply chain system and your Internet of Things (IoT) bakery sensors. Leaving aside the fondant icing and the chocolate sponge mix, you’re essentially a software company.
Inside the operational fabric of business
If this reality doesn’t wholly play out in the real world, then perhaps enough of it does to allow us to talk about what role an organisation’s software developers should be having inside the operational fabric of business itself.
Bemoaning the lack of business-to-developer integration that exists in many companies today, CTO at open source database platform company MongoDB Mark Porter suggests that this gap creates what amounts to an almost self-imposed ‘innovation tax’ that businesses are burdening themselves with.
The MongoDB technology lead says that, in his experience and despite the industry’s relentless emphasis on speed and innovation, software and data engineering teams and their sub-discipline colleagues continue to be misunderstood, mismanaged and marginalised inside both large and small companies.
Business context for techies
Porter calls for a new attitude where we afford software engineers and data scientists with a tangible degree of business context.
“Business needs to wake up and stop insulting the intelligence and maturity of the technology function and developers in particular. Organisations can – and must – understand the business rationale for their work. Defining and detailing strategic targets for developers will result in a better working business product as they align their key decisions in the architecture and design experience of your software. Once they understand the business context, they’ll find better ways of achieving it bottom-up than any top-down leader ever possibly can,” said Porter.
In his experience, Porter suggests that the single biggest source of low morale among developers is the combination of too much technical debt (where code is quickly assembled and shoved into production with poor levels of integration) and management’s dismissal of it.
Porter and the MongoDB team are realistic though i.e. they accept that taking on some debt to get a release out is fine - if you do it knowingly and pay down the ‘principal’ later. But what happens when leaders who don’t pay attention to mounting debt is demonstrated in a very visceral way to developers. These are C-suite managers that have become project-blind Gantt-chart leaders that have lost touch with the true ethos of the engineering going on beneath their feet.
Don’t build on a steaming dumpster
“Developers don’t do well with cognitive dissonance (i.e. telling anyone to go ahead and take a positive move, but within the context of what they perceive or know to be a bad idea), so when you tell them to build the next great software application on top of a smelly dumpster that’s on fire, you lose credibility, they lose patience and your company loses money as the pace of innovation slows to a crawl,” said Porter.
The bottom line being suggested here is that if C-suite leaders don’t understand how developers spend their time, they have no business leading the teams. It’s easy for any organisation to just focus on new IT services and features, but leaders must acknowledge and address the fact that adjacent work like maintaining databases or a legacy staging environment is pure drudgery that provides no innovation value, costs a fortune in developer time and saps morale.
Porter warns how important it is to listen to the developers when they say that they need to revamp an adjacent or dependent system to understand why it’s important.
He also wants to see an end to what he calls ‘vanity metrics’ i.e. the sort of goals that managers set in order for them to look like they are functional (look out for Objectives & Key Results - OKR as a usual suspect here) when really they’re just reading from the standard management crib sheet.
Killing off vanity metrics
“Top-down innovation is an oxymoron. Leaders have to trust that developers want nothing more than to see their work come to life. The more management tells them how to do their job – through objectives and key results or any other key performance indicators – the more they limit the scope of innovation. Paint the target, then get out of the way,” said Porter.
This whole argument comes back to providing business context for all stakeholders inside an organisation. Leaders and developers need to believe they are working together toward the same goal.
An oppositional relationship takes developers out of flow and leaders can lose a whole day of productivity from a single negative interaction. This is not an excuse for mollycoddling; developers have their part to play in the complex recipe that builds a successful company, just like everybody else. But for that to work, leaders must align business, technical and organisational goals and build honest and transparent relationships.
You thought you were a [insert random business discipline or specialism here] company? No, you’re mostly a software-centric company when it comes down to what’s happening in the engine room. So please, show some love to - or at least elbow-bump with - your developers sometime soon.