Breaking News: The “do more with less” mandate won't be achieved by doing nothing

Practically daily we hear from engineering leaders that are scrutinizing their investments to find ways to “do more with less.” This statement affectionately translates to “If you can’t help my team operate more efficiently, I am not interested at the moment.” Ironically, there might be no better place to look for leverage than the existing tools, time, and process required to effectively run their teams.

Up till now, organizations have accepted the institutionalized visibility/coordination/alignment/status overhead that builds up over time as a cost of doing business. The abundance of available resources to throw the problem, coupled with the absence of an obviously better solution, have historically made doing nothing the default choice. But with the current business climate, combined with the rapidly evolving nature of how and where teams work, it is becoming abundantly clear that the “do more with less” mandate can’t be achieved by doing nothing.

While it’s easy to go straight into debating which tools can solve the problem, they are just a means to an end. It’s more constructive to first step back and identify the end state engineering leaders are trying to achieve and then determine which tools are best suited to help them get there. So let's do that.

An engineering manager's main goal is to maximize business value by shipping high quality software as quickly and efficiently as possible in support of organizational objectives. In meeting this objective their time is spent surfacing and resolving points of friction that get in the way. Their days are spent keeping the team focused, advancing decisions, fixing communication issues, clearing blockers, and mitigating risks, while continually driving software platform optimizations, reducing QA & release times, working down technical debt, and improving team productivity. Said another way, keeping teams running requires constantly optimizing their ability to get things done faster and more efficiently. This debugging of execution is not dissimilar to a software engineer debugging code.

When debugging code, you have a set of known inputs and you're trying to arrive at a set of known outputs. During execution, side effects arise that change the outputs in unexpected ways. This is where debugging comes in - allowing you to trace through every line of code, see what's happening in real time, and identify the fix. Applying this concept to execution in engineering, you have known inputs of a number of engineers, and time. The outputs are the things that need to be built. The side effects are operational issues, technical debt, unanticipated dependencies, poor planning, etc. Debugging in this world means being able to get into the weeds at any point and clearly see what's going on in order to react to it.

Historically, in order to get the visibility needed to properly debug execution and take action to alleviate it, leaders have resorted to some costly combination of people, ceremonies, meetings, spreadsheets, and project management tools. The tools were relied upon to capture the outputs generated from the other four resources. But the tools outputs were only as good as the inputs and tracking down all the activity and progress indicators requires a lot of heavy lifting and constant nagging that no one enjoys. And more often than engineers fail to consistently report what they’re doing so the information and metrics that end up in these tools are either inaccurate or the guesswork of PMs and EMs.

For years Engineering Managers have brute forced their way around shortcomings of this approach with a few different tactics. One path is they choose to effectively operate as a full-time project manager, spending way too much time in spreadsheets, sending status pings, attending check-in meetings, and rummaging through tools in order to provide an indication of how things are going. Alternatively, they delegate the responsibility to their most process oriented senior manager, or they hire some combination of Product Operations, TPMs, Release Managers and/or Delivery Managers to do it for them.

Regardless of the method, the goal of the engineering manager is to get the intel needed to debug the progress of their teams and the project they're working on. But the current cost and impact on the team is WAY too high and the information gathered quickly becomes stale. As projects, and the teams working on them, get further dispersed across locations, time zones, and tools, the situation only gets worse. Yet the solutions have remained unchanged.

In order to actually “do more with less”, leaders can no longer no longer afford to waste money and time trying to bandaid over the shortcomings of products that were designed for a different era.

Interested to experience what it’s like to actually “do more with less"?

Explore KATA: https://www.getkata.com/product-tour