Codus Interruptus: Stop Wasting Time

Never waste your time; it is too precious. There are never any guarantees we will have tomorrow.

—Catherine Pulsifer, Author

“I don’t have enough (fill in the blank)” is a common refrain in the face of new demands. It’s normally followed by that much-loved phrase “We need to prioritise.” I’ve observed that the challenge is perhaps less a lack of resources and more a misuse of how we valuable humans spend time.

One slightly tongue-in-cheek metric to quantify this problem is the Bureaucratic Mass Index (BMI). My interpretation of this was inspired by a management metric long-established in companies like McDonald’s—unit-producing hours. Unit-producing hours measure time spent on activities that directly contribute to a customer outcome, such as preparing food or developing value-adding features in e-commerce applications. Non-unit producing hours don’t directly contribute to a customer outcome, although the activities might be necessary, such as counting inventory or undertaking compliance obligations in a bank. Organisations theoretically look to maximise unit-producing hours by minimising the time spent on non-unit producing activities.

BMI captures the non-value-adding time in a simple equation expressed as a percentage:

In this equation, NVA represents the non-value-adding time an employee spends on activities like attending status meetings or negotiating access to data needed to make a decision. W is the time spent before value-added activities can be resumed (e.g., waiting for decisions to be made or for the infrastructure team to action a ticket to provision a new compute instance on a project’s critical path). Total is the total time the employee has available in a period.

BMI is an intuitive measure for understanding organisational waste but is rarely quantified. There’s no single reason for this. Understanding your BMI can be seen as not “leadership-y.” It requires perseverance and attention to detail, which feels more tedious than “big” gestures like announcing yet another organisational reshuffle. Leaders may lack understanding about what outcomes are valuable to an organisation. Employees may lack a sense of psychological safety to share how their time is really spent—unfortunate, considering these employees often offer the best insight into how time is wasted by bureaucracy and inefficiencies. Harvard Business Review highlights another issue: the belief that being busy, a pseudomeasure of productivity and importance, is a good thing. Ask ten people how they are; invariably, eight people answer, “Busy.” [1]

While these issues apply to any role, let’s focus on one I have previous experience with: the developer. While research indicates a general shortage of technical skills, there is more to the problem. While there is quite a disparity in public domain reports on developer productivity, most agree that less than a third of a developer’s time is spent developing. One report suggests the real number is less than five hours a week!

So what can be done?

Coding Companions

The natural inclination is to look for a whizzo technology that magically resolves productivity issues. Luckily there are solutions that can help. If you were once a developer, you might recall the hours spent researching how to code a particular function and the days spent debugging code only to find a simple missing semicolon or an undeclared variable. AWS recently released Amazon Code Whisperer, a generative AI coding assistant that helps developers spend more time developing securely and less time searching for often suspect answers in the public domain. It’s encouraged me to get hands-on again, helping to develop simple applications in 25% of the time it has previously taken—even when using cloud services that I’ve never used. Early reports on productivity improvements for experienced developers range from 30% to 57%.

Hidden Waste

While coding companions are an obvious win, it’s just the tip of the developer productivity iceberg. As history reminds us, new technology comes into its own only when ways of working change. While technology can accelerate what developers are doing in the time they have to code, how can the time available be expanded?

Eliminating what lean practitioners call waste starts with curiosity about how work really gets done and mapping it in a highly visible way. We did this exercise at McDonald’s for one product and found over 160 handoffs between ideation and production. The development team might have been working in two-week sprints, but the end-to-end process consisted of months of work invisible to us leaders! Everyone was involved and busy, but no one was accountable for accelerating the overall process—a common problem only surfaced when the complete picture was painted.

Eliminating Waste

Three of my favourite ways to eliminate waste are (a) accelerating decision-making, (b) allowing healthy duplication, and (c) eliminating bottlenecks. Similar to building loosely coupled architectures, improving in these areas enables teams to operate more autonomously, something we strive for at AWS as we embrace the phrase “Dependencies are defects.”

Accelerating decision-making combines creating a shared understanding of how decisions should get made using tenets and determining how to drive more decisions deeper into the organisation using the mental model of one- and two-way door decisions. Decisions are optimised for speed and reversibility—not the pretend pursuit of the perfect decision.

Healthy duplication is traditionally seen as the archnemesis of pursuing efficiency in organisations. At AWS we use a two-part formula to break with this tradition. “2 > 0” asserts that it is better for two teams to do the same thing than for no one to do it because of slow decision-making or a lack of ownership. Speed matters. An addendum to the equation, “1 > 2,” asserts that over time, a natural desire to engage in more interesting work will see teams who created similar solutions agree on one of them, freeing up time.

Eliminating bottlenecks requires persistence and a willingness to experiment with new approaches. While we commonly advocate for cross-functional two-pizza teams, as Tom Godden’s blog post describes, there are other complementary solutions. Many start with a mindset shift. If you are an infrastructure leader, do you enable self-service provisioning of compute instances or storage, such as Amazon EC2 or Amazon S3, as the cloud was intended to be used rather than insisting on old-school ticket raising? If you are a compliance leader, how do you automate validation in CI/CD pipelines? If you are a security leader, why doesn’t your authentication solution use a simple API integration for a team that wants to use it? In every case, it is a question of how your team can do their jobs better and less transactionally while removing themselves as potential barriers.

Focus

Two-pizza (or two-product) teams aren’t the solution to every issue, but from a productivity perspective, they allow teams to focus on the job at hand—a meaningful outcome—rather than a list of tasks. It is incredibly powerful to charter a team to deliver an outcome rather than use the classic model of lots of people in lots of silos focusing on their role descriptions and activities. Equally important, this construct recognises what we can be in denial about: our poor ability to multitask. For example, it is really hard for a developer to solve a complex issue if they are continually context switching.

In my previous blog post, I alluded to the waste inherent in waiting for others. Yes, developers can start new work during this time, but this typically adds to the pile of work in progress. It’s also not the right solution to unneeded waiting time for completing a presumably important initiative aimed at delivering value. In the context of development, this waste can take many forms: waiting for a decision before coding can continue, waiting for a new compute instance to be created, or waiting for another team to complete their security assessment or quality assurance.

Each time a human switches focus, there is ramp-up time and a loss of creative continuity. Undertaking two unrelated activities in a day instead of one doesn’t halve your time on each. Instead, it can lead to a 20% drop in productivity—worse if more activities are added. Conversely, when a developer (or any human doing any task) is in a flow state, they are clear on the outcome they are going after, are fully immersed in the problem without distractions, and make considerably more progress.

Reduce Undifferentiated Work

There’s an obvious answer to a lack of developers: do less coding where it does not add a clear advantage. It’s the reason many customers adopt the cloud, enabling more focus on delivering valuable outcomes. We increasingly see services such as Amazon QuickSight Q enabling dashboards to be created with little coding and Amazon SageMaker Canvas providing intuitive ways of creating outcomes that don’t involve coding. Generative AI and machine learning can help build test cases and create synthetic data for testing. I hope it goes without saying that technology isn’t even needed if the focus is truly on the business problem and not a preordained assumption about the solution.

So back to the original challenge. Do you understand your organisation’s BMI? Your people know when they are put in the impossible situation of following burgeoning bureaucratic mandates while being exhorted to be more productive. Create an environment where they will share their insights, and you’ll be pleasantly surprised about the positive impact changes can have on them and your ability to deliver value faster.

References

[1] Waytz, Adam. “Beware a Culture of Busyness.” Harvard Business Review, February 14, 2023. https://hbr.org/2023/03/beware-a-culture-of-busyness.

[2] Weinberg, Gerald M. Quality Software Management. New York, NY: Dorset House Pub., 1992.

[3] Hamel, G., Zanini, M. Humanocracy: Creating Organizations as Amazing as the People Inside. Harvard Business Review Press, 2020.

[4] “Global Code Time Report,” 2021, https://www.software.com/reports/code-time-report.