Software executives and managers not knowing enough about technical implementation, means procrastination, smoke + mirrors, and potentially catastrophic wasting of time and money.

Software executives should change their own motor oil

A friend of mine is the only software dev for a small startup that’s running out of cash. Pretty soon they need to either secure another investment round, or paychecks will start to bounce. Killer business idea, and my buddy is really stoked about the long-term prospects, but short-term it’s getting pretty tense.

A few weeks ago, they get word that their only firmware engineer – this company has a physical product as well – is headed to other pastures. Damn, right? Things are getting tight, need all hands on board, and people start jumping off? Hell.

Well, my friend’s the last dev standing, so to speak, and they’ve got features waiting on firmware enhancements. So with a get ‘er done mentality he dives into the unfamiliar firmware code. What does he find?

A whole nasty, corroded, aluminum tin-full of Blinker Fluid.

What your CEO doesn’t know about software development may be killing you

Turns out the physical controller they’re working with is pretty simple and the code is straightforward. But hold on, the guy has been saying new features will take weeks! He’s been behind on functionality!

My friend is not management, not a lead – he had no authority over this other dev’s work. The person who was supposed to hold the now-departed firmware dev accountable was, yes, the CTO of the startup. A CTO who apparently had either no time, or no inclination, or no skill, or none of the above, to review the firmware code to see if the reasons for delay were valid.

With an afternoon of research – within the first half hour, I would guess – a developer with a reasonable amount of skill and a critical mind was able to uncover months of wasted time and salary.

Clearly this startup cannot afford the lost money. And even if they secure another round, those development hours are gone forever!

The banana in the tailpipe

As firmware features dragged on, I expect the CTO was able to complain about the slow pace of progress. Complaining and applying pressure in a generic way are easy-to-learn management skills. But what happens when a technical team has their list of reasons? How does management determine whether those reasons are valid? The only way to know, is to get technical.

Now clearly this can go too far – you’ve hired specialists who are experts at what they do, and they need to be supported and not second-guessed. But you are well-served to take the time to get familiar with the nuts and bolts, so that you can at least participate in the conversation. Read some books. Go to technical seminars. Use your knowledge talk to the dev leads at a deeper – it may be a bit llembarassing at first, but your leads should be understanding and ready to support management more broadly.

When your executive in charge of managing software teams, has little idea about how software actually gets made, what the process of executing from prototype to code to test and production actually looks like at the code management level, then you are setting your organization up to make common, preventable mistakes. And when those mistakes are made, developers can use every tool in the box to squirm out of being accountable.

In comparison, a regular investment of discipline and time – say, 3-5% of one’s work week? – to get comfortable with technical details, insulates the executive team from deception or misdirection. Plus, it shows your technical team that you care about the work they do. Showing that you care inspires loyalty and raises morale, which increases speed, cooperation, proactive problem-solving and retention.

Software executives: setting aside some regular time to study the technical details of process and the technology you’re using, can revolutionize your organization.

It’s money on the table – somebody ought to pick it up.