Being asked to work faster? Some quick math could diagnose the problem

When you look at modern growth companies – and I’m not talking about just digital organizations – you find common patterns in how they organize to innovate, maintain quality and to scale. When you look at the MOST successful, fast-growth businesses an even more consistent pattern emerges: they’re hyper-designed to optimize software engineering velocity. Why?

Well, software engineers tend to be some of the most expensive and hard-to-find people in all IT, so anything your organization can do to improve their velocity generates a large ROI. Unfortunately, too many organizations try to address this by adding lower-rate support people to “help.”

It’s not uncommon to find IT organizations with 2-1 or even 3-1 non-engineer staff for every engineer who actively codes. These same companies cite how hard it is to recruit and retain engineers.

A client I work with has about 500 employees, two-thirds of whom are software engineers, actively working on their software-as-a-service products. Their entire “IT department” is six people. Six. Another client we surveyed learned that their engineers spend only twenty percent of their time actually delivering value to their business customers, and the rest is wrestling with their corporate bureaucracy. Take a moment and think about your IT organization. How many software engineers to IT staff do you have? How much of their time is spent delivering value vs. bureaucratic tasks?

My clients’ ability to innovate and scale is driving profits and organic growth. They’re off-the-charts efficient because engineering teams are able to do most of the infrastructure work they need by themselves, using automation. But modern technology is just one strategy legacy organizations need to embrace if they’re going to remain competitive. Avoiding bogging down your teams with time intensive processes is as important as any other modern tech process you could invest in.

With all of this support, why then are engineers jumping ship?

One of the most commonly-cited reasons I’ve heard from peers is, “it just took too long to get anything done.” Another: “I couldn’t take all the hoops I had to jump through to get to a decision or to try something.”

The cost to replace a single software engineer, including lost velocity, recruiting costs, interviewing costs, compensation, and lost value to the business can easily exceed $250,000. Not to mention the impact of lost knowledge of your business, products, existing code and legacy systems. Churn is expensive almost anywhere, but at the heart of your innovation or performance engine, it can make or break your timing in the market.

But what about all of those IT managers and technical support people? Aren’t they doing important things?

In my experience, when IT organizations are primarily staffed with non-engineers, they often shift organizational focus to preventing bad things from happening. To prevent isolated projects from taking root in core systems, they create governance and approvals boards at the start of projects. To prevent a bad code deployment, they design a gauntlet of testing and release process and governance. To prevent the possibility of a security flaw, they require manual security reviews to be blessed by a security auditor. Which teams have to do this? Why, all of them, of course! Are these important goals, yes. But are they the MOST important thing? Less often than you think.

Successful organizations know that while its important to prevent some bad things from happening, too much energy on “perfect” isn’t just the enemy of “good,” this culture carries a lot of collateral damage. Metrics on all the “quality” controls leave unreported the good things they delayed or prevented from happening!

Best in class companies trade process solutions for communication and decision-making solutions that are better equipped to balance speed, cost and quality with market oriented risk management. They focus efforts to ensure that software engineers are allowed to make decisions AND are well-equipped to do so. They also make sure their engineer leaders know how to assess critical situations and make good judgement calls. The entire organization is set up so that the consequences of decision-making, both good and bad, fall appropriately on the people with the skills to do, undo and fix. Responsiveness and speed more than compensate for the minor mistakes velocity creates.

Slow organizations aren’t stupid. There are good reasons why less successful organizations wound up structured the way that they are. But technology is busy eliminating whole categories of IT jobs, and replacing many core IT functions with automation and organizations just aren’t keeping pace.

Careers like database analyst, build master, network administrator are sun-setting as cloud computing and utility compute become common. As the need for people in these jobs goes away, a larger and larger percentage of IT workers can be those highly-paid software engineers. Sadly, too many organizations don’t adjust to put their engineers in a position to succeed.