Skip to content

March 15, 2022

Doing it All is Not a Good Strategy

By Dominica Degrandis

Product teams in the midst of change at one of the biggest US insurance companies came up with an experiment they called “Doing it All.” The sarcastic title was intentional, as it magnificently described the nature of a theme that I observe across multiple industries. From finance to insurance to transportation, carving out capacity for you and your teams to implement a new way of working requires herculean efforts.

Change takes time. It’s not enough to just give teams approval to do something. They also need time allocated to do so during regular business hours. Some people at the insurance company I mentioned above were working sixteen-hour days to meet expectations. Leadership may agree to change and approve the budget for a transformation, but if teams are not given the capacity to learn new tools and processes on top of their existing load, then “doing it all” burdens the teams with too much cognitive overload, creating resistance and resignation.

Those struggling with conflicting priorities and caught up in “doing it all” can improve their situation by helping others understand the impacts to their business bottom line using metrics. Measuring the value you’re delivering for the business is a useful way to address common objections to develop a healthier, more resilient partnership.

When people complain that things take too long, technology leaders should be positioned to demonstrate just how long things actually take to do in a way that others can see, helping to show that “doing it all” is not a good strategy.

When the VP of Sales (or anyone else) claims that things take too long, it makes sense to measure and show how long things actually take. This measure of speed (flow time) is helpful to start a data-driven conversation on objections and offer a thoughtful response.

This and other objections that you might encounter are listed in the table below, along with suggested responses and useful metrics to use when building your argument.


Response Key Metric

“Things take too long.”

“Here’s how long features actually take to do.” Flow time: measures speed. Clock starts when work begins and ends when the customer can consume the value.
“Not enough features get delivered.” “The capacity of the teams is often less than the demand. Teams are constrained by conflicting priorities.” Flow velocity: measures throughput—the number of items completed over a period of time; this is useful for gauging capacity.
“We should just outsource this to vendors.” “Outsourcing this work will likely insert more dependencies into the workflow, which impacts efficiency due to back-and-forth communication delays.” Flow efficiency: the ratio of wait time vs. active time. Prompts the reasonable question, “Do we need more wait states in our toolset to accurately reflect all the wait time in the value stream?”
“We need features to be delivered, but you just want to refactor architecture.” “We need to change the oil in the car every now and then. Otherwise, we won’t have a car to drive.” Flow distribution: the distribution of different work item types, e.g., 30% features, 60% defects, 10% debt.
“We are at risk of not completing all the initiatives on this year’s roadmap.” “Attempting to do too many things at once results in lower quality and slower delivery. It’s why Steve Jobs killed many great ideas at Apple, so they could do fewer things really well.” Flow load: the amount of work started but not yet finished. Lots of partially completed work-in-progress (WIP) is expensive.

It may seem as though conversations like these are adversarial. However, they are essential for partnership building discussions. Every good objection has a worthwhile objective to consider.

As objections come up from business leaders, be prepared to address these and see other people’s perspectives. Two people may bring their opinions to the table. The outcome is that they both walk away with a third option that is better than either of the original two. Consider different perspectives as feedback to move toward a shared path forward.

This post was excerpted from the second edition of Making Work Visible: Exposing Time Theft to Optimize Work & Flow by Dominica DeGrandis.


- About The Authors
Avatar photo

Dominica Degrandis

Author of Making Work Visible

Follow Dominica on Social Media

No comments found

Leave a Comment

Your email address will not be published.

Jump to Section

    More Like This

    The Role of the Software Architect in Agile Medical Device Development
    By Summary by IT Revolution

    In a recent presentation at the 2024 Enterprise Technology Leadership Summit Virtual Europe, Tom…

    Calculating the ROI of Flow Engineering
    By Steve Pereira , Andrew Davis

    This post is adapted from the book Flow Engineering: From Value Stream Mapping to Effective…

    What to Expect at Enterprise Technology Leadership Summit Las Vegas 2024

    Holy cow, Enterprise Technology Leadership Summit Las Vegas is happening in August, which is…

    Transforming Telenet’s Operating Model: Insights from a Multi-Year Journey
    By Summary by IT Revolution

    In a recent presentation at the 2024 Enterprise Technology Leadership Summit Virtual Europe, Barbara…