Chapter 17: 150 Desks  –  On Managing Workflow Groups

11 min read

Sometimes you really can grow too fast.

Victor was at his desk when he received the RFP from McBride Auto Group, the largest dealer group in the country, a 130-store behemoth listed on the NYSE. He jumped up and ran into your office, grinning from ear to ear. McBride wanted to upgrade its ancient home-grown CRM system, and SparkLight Digital was one of the companies under consideration. It was an exciting moment.

Shortly after submitting the initial proposal, it was clear that SparkLight Digital was in a two-horse race. McBride narrowed the field to you and your competitor, DealerGasket. In the last 18 months, stung by a host of customers lost to SparkAction CRM, DealerGasket’s CEO mobilized to win back market share. DealerGasket’s product team closely evaluated every feature of SparkAction and conducted a ground-up redesign. Release by release, your product advantage narrowed as you found more of your best features replicated inside DealerGasket’s CRM.

But DealerGasket’s price quote feature was designed poorly. It didn’t automatically adjust the price to account for manufacturer promotions (such as zero percent down on the Toyota Rav4, or $2000 cash back on the Ford F150). Instead, the dealer had to enter that data manually. SparkAction CRM automated this step. You suspected that this feature gap would prove to be a big sticking point for McBride.

The negotiations were tortuous. Every week for three consecutive weeks, Victor shuttled back and forth between San Francisco and Miami. Joe and Vijaya joined him the first week. For two days, McBride’s CTO grilled them relentlessly while conducting an exhaustive technical due diligence. He was particularly concerned about security and pestered them about their infamous security breach two years ago. McBride hired two professional hackers, who spent a week trying to hack into SparkAction CRM’s back-end to no avail. Then McBride stress-tested the platform for scalability. Once again it passed muster.

The subsequent week, Victor spent all day Tuesday and Wednesday sitting in a small room at McBride headquarters. In the adjacent room was the VP Sales for DealerGasket. For two full days, McBride’s VP Purchasing, Guido Scaramucci, shuttled back and forth between the rooms. He chiseled away at every deal term, thick eyebrows raising up with the implication that “the other guy” caved, so you should, too.

You and Victor were in constant contact each step of the way. Finally, it was clear that the deal was turning in your favor. Victor received an email from McBride’s SVP Operations Jack Acton, demanding him to build the store launch schedule into the Service Level Agreement (SLA). Victor then received a meeting invite to go through the rollout plan. When Victor informed you of this new development, you leaned forward with anticipation. You were now on the glide path to a deal.

In the third week of negotiations, it was time to close the deal. You joined Victor on the 6:00 AM flight out of San Francisco to Miami. You sat in economy, squeezed between two XXLs, while Victor used air mile points to ride in first class. As you taxied toward the gate in Miami on a stiflingly hot June afternoon, you checked your iPhone. There was an email from Bill.

It was a warning. He’d just lost two of his top launch team managers to another hot startup; that made five open positions on the launch team.

“Be careful what you promise with the McBride store launches,” he said. “We can barely handle the backlog as it is. Even if I could hire a dozen launch managers tomorrow, I don’t think I’d be able to launch more than fifteen stores a month for McBride, at least for the next four to five months.”

As you and Victor walked towards baggage claim, Victor informed you that he also received an email — from Acton. Acton wanted Victor to know that he expected all 130 stores to be fully launched and operational within three months.

“So, come to tomorrow’s meeting ready to tell me how you plan to get it done,” the email said.

.      .      .

All of the things that matter most in a company — the health of the culture, the happiness of customers, and the financial imperatives of revenue growth, profit, ROI, and cash flow — depend on efficient and effective workflows.

Broken workflows damage the product experience. Dissatisfied customers are a direct result. Their complaints cause inefficiencies and motivational issues as employees have to redirect time away from regular workflow to manage customer problems. Unhappy customers demand credits, refuse to pay their bills, and cancel. Poor customer reviews make it difficult to sign up new customers. Culture, reputation, and financial health suffer.

On the other hand, healthy workflows keep customers happy. Work progresses in a planned and predictable way. Employees can do the job as intended, without being forced to stop everything and address the “crisis de jour.” Customers pay their bills, renew and purchase more products or services, and tell others about their high satisfaction. Culture, reputation, and financial health thrive.

High-functioning workflows are crucial to scaling. Workflows consist of a set of steps required to fulfill a task. They may be entirely automated: most software is simply a digital workflow. In fact, wherever a workflow can be fully automated, it should be. But often, workflow completion requires people. People use tools and take human steps to accomplish a task.

In many cases, workflows cross departmental boundaries. For example, marketing and sales must collaborate at the lead handoff juncture. Sales and customer success must be in sync at the point of the closed won sale, and then later in pursuit of upsells and expansion opportunities. Sales and finance must work together to ensure accurate pricing and billing. HR and departmental managers must collaborate on hiring, promoting, and firing processes. Product and engineering must work side-by-side in product development. Marketing and product must cooperate to enable the flow of market knowledge into product feature prioritization decisions.

All of these cross-functional hand-offs are potential points of failure. Smart companies invest significant resources to guarantee they are well-executed.

It starts at the top. As CEO, it’s on you to ensure that where there is a cross-functional dependency, a “power partnership” between each top executive exists. The heads of sales and marketing need to be in a power partnership. So too with sales and customer success, product and engineering, sales and finance, and marketing and product. And the head of HR needs to build a power partnership with every executive. As you scale, the same idea applies at the next level in the hierarchy. Director-level and manager-level partnerships must emerge to continuously improve cross-functional workflows. In best practice companies, groups of individual contributors from each function work directly with each other — often in weekly meetings — to review cross-functional workflow performance and design improvements.

Carnegie Mellon’s Capability Maturity Model posits that there are five stages of workflow maturity:¹

  1. Initial — the workflow is chaotic and ad hoc, requiring individual heroics
  2. Repeatable — the workflow is documented sufficiently such that repeating the same steps may be attempted
  3. Defined — the workflow is defined as a standard business process and linked to adjacent workflows
  4. Capable — the workflow is quantitatively managed by agreed-upon metrics
  5. Efficient — teams involved in the workflow use metrics to continuously improve it

As top executives, mid-level managers, and individual contributors work across functions on shared workflows, it is critical to identify workflow maturity. Are you at the chaotic first stage? Or are you beginning to measure workflow steps and proactively engage in continuous improvement? By clarifying your current stage of maturity, you will instantly define the next right work.

With cross-functional collaboration occurring from top to bottom, and with a clear understanding of how to gauge workflow maturity at a high level, you are ready to prepare workers with a best practice understanding of workflow optimization principles.

To manage workflow groups effectively, it helps to know what a good workflow looks like. In 1984, Eli Goldratt turned his “theory of constraints” into perhaps the best book ever written on workflow optimization: The Goal: A Process of Ongoing Improvement.² The 30th-anniversary edition published in 2014 remains a best seller. It is one of just three books Jeff Bezos required his executives and managers to read during a summer book club he launched to help him communicate the future of his company.³

The essential workflow optimization principles are all captured in Goldratt’s book. These principles have direct applicability to leading-edge technical and digital workflows. For instance, in 2013, Gene Kim, et al. leveraged Goldratt’s principles in their book, The Phoenix Project, recently updated in a 5th-anniversary edition.⁴ With full credit to Goldratt, they applied his work to the IT world of DevOps. I recommend you become a student of both books.

In workflow optimization, we must start with the goals. Any business survives and thrives by optimizing net profit, ROI, and cash flow. These are the essential goals. Workflows exist to advance them. Yes, for high-flying, VC-backed tech companies profit may be less critical in the short term as investor cash pours into a hot company to supercharge revenue growth. But in the long run, companies must optimize all three.

Workflows support these three goals by increasing throughput while reducing inventory and operational expense. Throughput is the rate at which the system generates money through sales. Inventory is all the money the system has invested in purchasing things it needs to sell. For a tech company, this could be the cost of an externally-sourced data set or an externally-sourced software component incorporated into your product offering. And operational expense is all the money the system spends to turn inventory into throughput.

In workflow optimization, the first objective is to increase throughput. Next important is to reduce the cost of inventory. The third and final priority is to reduce operational expense.

Every step in a workflow is either a bottleneck or a non-bottleneck. A bottleneck is any step where the capacity is less than or equal to the demand placed on it. The capacity of a system is equal to the capacity of its bottlenecks. That’s because an hour lost at a bottleneck is equal to an hour lost throughout the system.

Best practice in workflow optimization is to move bottlenecks to the front of the workflow when possible. Always put your best people at the bottlenecks. It is better to accomplish quality control before or at a bottleneck, not after it. These practices reduce bottlenecks.

Prioritize work so that items necessary to get through a bottleneck are addressed first — including completion of any non-bottleneck steps that are ahead of the bottleneck. The bottleneck steps define the pace of the non-bottleneck steps: in other words, the level of utilization of a non-bottleneck step should not be determined by its potential, but by the requirement to serve or keep pace with the bottleneck.

If you can establish a schedule for releasing materials required by the bottleneck and a schedule for materials required by non-bottleneck steps that matches the production pace of the bottleneck, you can determine the final assembly schedule. Once you know when the bottleneck parts will reach final assembly, you can calculate backward and determine the release of non-bottleneck materials along each of the routes. In this way, the bottlenecks will determine the release of all materials within the “factory.”

For every workflow step, there are four sub-steps: set-up time, process time, queue time, and wait time. Set-up time is the time spent waiting for a resource that is required for you to work on a part. Process time is the time spent on the step itself. Queue time is the time that a part spends waiting in line for a resource while that resource is busy working on something else. And wait time is the time that a part is waiting for another part.

Queue time and wait time consume the most time. If you can eliminate latency in these two areas, you will make a significant impact on workflow efficiency. For parts that are going through bottlenecks, queues are the dominant issue; for parts that are going through non-bottlenecks, waits are the dominant issue. The best way to solve for queues is to cut batch sizes that flow into bottlenecks. This reduces the investment in work-in-process inventory.

A non-bottleneck can still be a problem. If work is handled at a non-bottleneck step in such a way that a hole is created in the work-in-process buffers in front of bottlenecks, then this step will constrain capacity and create or exacerbate a bottleneck. If workers work according to the sequence in which parts arrive — first come, first done — the parts will be done in the right sequence, fewer holes will be created in the buffers in front of bottlenecks, and people won’t have to track the stuck materials.

So how, then, does a workflow group use this workflow optimization best practice to improve the workflow for which it’s responsible? Goldratt insists it comes down to five simple steps:

  1. Identify the system’s bottlenecks
  2. Decide how to exploit the bottlenecks
  3. Subordinate everything else to the above decision
  4. Elevate the system’s bottlenecks
  5. If in a previous step a bottleneck has been broken, go back to Step 1

Here is a list of practical questions that cross-functional power partners and workflow groups should ask themselves. If they answer them with rigor, the yield is continuous workflow improvement:

  • What is your throughput?
  • What are the components of your inventory?
  • What are the components of your operational expense?
  • What are all the steps in your workflow, for all conceivable use cases?
  • Have you mapped out these workflow steps graphically?
  • What steps in your workflow are bottlenecks? How do you know?
  • What steps are non-bottlenecks?
  • What bottlenecks, if any, can be moved to the start of the workflow?
  • Do you have your best people working on your bottleneck steps?
  • Have you built quality control into the bottleneck step vs. having it come after the bottleneck?
  • Have you arranged your work so that you’re always working first on the items necessary to get through a bottleneck, before items that need to get through non-bottlenecks? Does your information reporting support this?
  • Where do you have queues in front of bottlenecks? What is the size of each queue?
  • What can you do to reduce these queues?
  • What are the information reporting requirements necessary to support a precise tracking of your end-to-end workflow so that bottlenecks are quickly identified and attacked?
  • Does your workflow group prioritize time to identify and crack bottlenecks?

Workflows operate within systems. Systems incorporate all the tools, data flows, and human steps necessary to complete a body of work. An optimized system comprises optimized workflows — when you measure every step in the workflow, data feedback loops function well, and leaders use data continuously to learn, optimize, and experiment.

Functional leaders can manage workflow groups (and the systems they support) ad hoc. If the workflow crosses functions, multiple functional leaders can collaborate informally as required. Or workflow groups can be organized formally as standing teams. A workflow group is called a team when there is a designated leader, a charter with an aggressive mission, and SMART goals in place to drive performance. Teams are best, if and only if there is substantial executive commitment to maintain them and keep them accountable. For more on high-performance teams, please go to Chapter 6: Eight Desks — On Teams.

Effective workflow group management starts at the top. As CEO, you must make it a priority.

.      .      .

As you and Victor flew back from Miami early Friday morning, a signed contract in hand, Jack Acton placed a call to Bill.

“You’re the SparkLight Digital head of Customer Success right?”

“Ah — yes that’s me.”

“So I just had one of our drivers drop your CEO and Victor off at Miami Dade. Your guys are probably in the air right now.”

At that moment Bill noticed on his iPhone a missed call from you that had come in thirty minutes ago.

“You probably heard we just signed the contract — SparkAction will be our new CRM system. I’m not one to waste any time, so I just wanted you to know I need you on a call Monday morning at 7 AM your time.”

“What for?”

“It’s our weekly General Managers call. We’ll have all 130 of them on, and we’re going to announce our decision. Believe you me; they’ll be happy — they hate the piece of junk we now have. Here’s what I need you to do. You will need to present your plan. Give them an overview of the launch process. Tell them which forty stores will be launched this month. You OK with that?”

“Uh — well I think I should wait until I can meet with our team before I commit to anything.”

“Oh bull crap. I need you at 7 AM ready to roll out the plan. Get on it.” With that, he hung up.

Bill drove out to SFO to await the arrival of the 2:10 PM flight from Miami. When you and Victor landed, Bill’s text led you to his waiting car outside baggage claim. The drive back into the city was painful — and loud. Bill and Victor got into a shouting match. At one point you feared for your life as Bill lurched the car from lane to lane in complete distraction.

A launch manager requires both training and experience before he can execute launches effectively. At SparkLight Digital, one launch manager can handle about three simultaneous launches. If all goes as planned, the launch of a store takes three weeks.There are a series of intricate workflow steps to follow with precision. With multiple points of integration, the technical launch is challenging. And it is also necessary to successfully train and onboard the manager and sales staff at the store. It’s a labor-intensive effort.

And that was the problem — not enough labor. The customer success group consisted of only four trained launch managers. There were five open, unfilled positions. The McBride deal completely overwhelmed the group. Even after deciding to push all other dealer launches out of the way, McBride launches slipped and slipped until they fell hopelessly behind. In thirty days, SparkLight Digital launched just twelve McBride stores, less than a third of the committed number.

Jack Acton didn’t care that your launch team was short-handed. In a blistering phone call, he informed you that SparkLight Digital had failed big time.

“Twelve launched stores? Are you kidding me? At this pace, it will take over a year to launch all our stores. I advocated for you. I sold our exec team on SparkAction CRM. And now you’ve personally humiliated me. I will never forget this. Consider this your formal communication. SparkLight Digital is in full breach of the SLA. Our contract is hereby canceled.”

You were sick. Defeat snatched from the arms of victory. Understaffing and a suboptimal launch workflow just killed the biggest deal in company history.

Just one month later, DealerGasket launched forty McBride stores on its CRM platform, the first tranche in a three-month rollout schedule. No issues were reported.

.      .      .

You may also enjoy previous chapters of People Design here.

And if these insights matter to you, please visit us at to see how we help tech founders and CEOs of startups and growth-stage companies achieve $10m+ exit valuation.

.      .      .


  1. Carnegie Mellon Univ. Software Engineering Institute, The Capability Maturity Model: Guidelines for Improving the Software Process (SEI), (Boston: Addison-Wesley Professional, 1994).
  2. Eliyahu M. Goldratt and Jeff Cox, The Goal: A Process of Ongoing Improvement, 30th-anniversary ed. (Great Barrington, MA: North River Press, 2014).
  3. Max Nisen, “The 3 Books Amazon’s Jeff Bezos Asks His Senior Managers to Read,” business, September 25, 2013,
  4. Gene Kim, Kevin Behr, and George Spafford, The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win, 5th-anniversary ed. (IT Revolution Press, 2018).
Tom Mohr

Leave a Reply

Your email address will not be published. Required fields are marked *