More money, more problems

 In Staying small, I exposed how big teams are inherently slow and thus less productive, responsive, and competitive. However, I only scratched the enormous surface of large teams and large budgets. You’d think that having lots of money and lots of people would always be an advantage. You’d think wrong.

Throwing money and people at problems leads to duplication, inefficiency, complacency, sloth, waste, inertia, and eventually the business equivalent of cardiac arrest. Why? Being fat and filthy rich changes how you approach problems. If you’re poor with little help, each problem you face requires study and ingenuity. You can’t afford to let it fester. If you’re rich with legions of help, you can spend money to mask maladies or throw plenty of peons at patching the problem.

As I discussed in Being big, having extra money and people can be a good thing, but it’s often a disaster. The moment you get lazy. The moment you delegate your team’s problems to another team, or pay to make the problem temporarily abate, you’ve gone down a path toward bigger problems and greater expense. That moment of expediency costs you more than money, people, and trouble. It costs you innovation, improvement, and competitive edge. That moment is the point at which you failed.

Please, sir, I want some more

I can hear nearsighted, unimaginative, large-organization middle managers saying, “Are you kidding? I have half the staffing and funding needed to accomplish what’s expected of my team.” Actually, you probably have more than triple what you need (given discipline and feature silos), but you’re blinded by an environment of excess that has you staffing inefficiently and promising irresponsibly.

Large organizations tend to silo disciplines and feature areas, which leads to multiple people from different silos working on the same problems. If they combined forces, they’d have too many people, but in silos they have too few.

Filthy rich organizations can afford to work on all kinds of things at once, rather than focus on just a few things that make the biggest difference. If they focused and prioritized, they’d have excess capacity, but trying to do it all at once results in shortages.

Silos, overcommitting, and feeling poor when you’re actually rich leads to all kinds of trouble.

• You do work prematurely that adds to your technical debt or gets thrown away.
• You do frivolous work that gets lost or tossed, while it drains resources from what matters.
• You mask symptoms with money and manpower, rather than fixing the underlying problems, allowing those problems to fester until they can’t be contained.

Let’s take a closer look.

It’s not ready yet

People need to occupy their time at work. They want to be recognized for their achievements. When you’ve got a big staff, you need lots of work to do. That work can be disjointed, which means everyone makes tons of progress, but the results are incoherent to customers and often conflict with one another (ah yes, Microsoft in the 1990s and early 2000s). Instead, work can be coordinated, but a huge staff requires enormous effort to manage and align.

If you organize your huge staff by scenario, then multiple different teams are changing the same components at the same time, which leads to severe quality issues. If you organize by component, then teams are overwhelmed with scenario requirements, and everyone complains that they lack staff. (Conway’s Law describes the serious impact organizational structure can have on design.)

However, an even bigger problem than poor quality or overwhelmed staff is the amount of work happening at once, before components or scenarios are really understood. Even novice software developers know that writing software is an exploration. You don’t know in advance if the interfaces are right, if the architecture scales, if the user interface flows and excites, if security measures are sufficient, if the data model meets all the demands, and if the system performs within limits. By doing an enormous amount of work at once, before you learn what works, much of your code will be wrong. That code will become technical debt or thrown away entirely and redone. Great options.

The solution is doing less at once. Organize the huge project into independent pieces. Draft a multistep plan that gets each piece from concept to full realization, ensuring quality along the way. Then for each step: complete, learn, and advance. Since there are a limited number of independent pieces for any project, you only need a limited staff. More people than that and you’ve got incoherence, quality issues, insatiable demand for staff, runaway technical debt, and thrown-away work. You know—what we often deal with today.

Eric Aside

I discuss focusing on a few things at a time in You can’t have it all. I describe what small teams can do for big companies in Staying small.

You’ve done nothing

I left out another way people occupy their time—doing pet projects and busy work. Idle hands can cause all kinds of trouble. If team members aren’t making a strategic contribution to the main project, leaders will often supply pet projects to keep their staff busy, or team members come up with their own small projects. Maybe it’s rewriting a stable, yet convoluted portion of the code, or fixing postponed bugs. (In a separate column, I discuss the evils of Idle hands.)

While these pet projects may seem nice, if they alter product code, tests, or tools, they can distract or even block strategic project work that matters. After all, any kind of product work impacts other team members. Rewritten code and postponed bug fixes must be carefully tested, and new tools must be debugged and documented. Sometimes pet projects generate more work than they save and produce more cost than benefit.

The best solution is to not have idle staff. Everyone should be focused all the time on adding strategic customer value (including technical debt reduction). The next best solution is to choose work that doesn’t impact product code, tests, or tools and can be dropped quickly. You can analyze customer and bug data to determine the root cause of issues and find helpful patterns, learn new technologies and skills, and enhance existing shared tools so that everyone benefits.

Reducing technical debt and coming up with innovative ideas is great. However, those activities should be part of the strategic plan, not pet projects that get thrown away or disrupt critical work.

He can run, but he can’t hide

Perhaps the worst thing you can do when you’re a fat and filthy rich organization is to avoid dealing with your problems. If a dependency is late, instead of reprioritizing work, mitigating the impact, or falling back to old stable code, you just add staff to the team (as if that helps). If your deployments require hundreds of manual steps, instead of improving your automation, you just hire vendors to run the manual steps. If your servers constantly fail, instead of root causing the issues and resolving them, you just increase the server count and operational support. All of these approaches will temporarily alleviate the symptoms, but none will fix the underlying problems.

Throwing money and staff at a problem, instead of fixing it, allows the problem to fester. It keeps getting worse until the cost is so high that our business fails. Hiding problems is worse than irresponsible—it’s insidious.

The solution is to fix problems as soon as they are discovered. Patch if you must, then quickly address the root cause. You should ensure problems directly impact the lives of those who can fix them, and make fixing those problems a lifestyle improvement. This approach is the cornerstone of DevOps. When developers help operate the services they write, problems are immediately apparent to the folks who can fix them, and the lives of those developers get better with the more problems they fix.

Eric Aside

I cover DevOps in more detail in Bogeyman buddy—DevOps.

Enough is enough

It’s wonderful to be successful, have lots of money, and have a large staff to tackle big problems. However, you can have too much of a good thing.

When you hire so many people that you end up reducing quality, throwing away work, and getting in your own way, life is worse, not better. When you have so much money that you can afford to hide problems instead of confronting them, life is worse, not better.

Keep your teams small, with only enough people to tackle your critical independent projects one at a time, one step at a time. Keep those people close to your customers and your problems. Face failures fast so that issues are fully foiled, not forestalled or forgotten.

The better we use the talented people we have, and the more we make of the success we’ve achieved, the broader our reach can be and the greater the prosperity we can bring to everyone we touch.

Eric Aside

Back in December, I mentioned that I was taking off the holidays to work on a fun project that I’d share when it was finished. Well, Agile Project Management with Kanban is now available for preorder. I actually started the book back in June, but the last 10% is always the hardest.

The book is short, straightforward, and pragmatic. It has a quick start guide, with illustrations and online spreadsheets to get you productive fast. Other chapters help you estimate work, meet deadlines, deploy results, evolve from Scrum or traditional Waterfall, and integrate Kanban into large projects. There are extra chapters that expand Kanban to other areas. I hope it helps you and your team achieve more every day.