Speed vs. bureaucracy: management issues confronted by companies in transition

I was at a relatively young company once where a senior executive suddenly sent out a message to the entire employee base, asking for general input on the cause and treatment of the following concerns:

• “There is a feeling that the company is not able to move fast enough or nimbly enough — we’re not delivering products fast enough or turning projects around fast enough
• “People feel that it’s very difficult to get things done
• “There is a feeling that we’re getting too bureaucratic in everything
• “People aren’t working collaboratively; there appears to be a ‘contract’ mentality in dealing with people”

Aside from the unfortunately vague, passive-voice constructions in this message (“there is a feeling”: meaning one person? everyone? just senior management?), this message didn’t surprise me much.  In fact, it wasn’t (at all) the first time I’d seen this kind of sentiment arise in a young company.

Here’s what I know: when a company is first formed and starts to get traction, everyone does everything. There’s a high sense of frenzy and focus and commitment, corners get cut but everything really important still gets done, and so on.  It’s a heady and exhilarating time.  Then, as the company matures, perhaps broadens its product line, expands its customer base, ramps up on employees, and tightens down some previous loosey-goosey processes, a degree of wistfulness and concern settles in, particularly among the old guard.  “We’re not customer-responsive enough anymore!” goes out the cry.

But in truth, it’s now a much more complex world than it used to be, with necessarily more constraints and rules, and well, some people chafe at constraints and rules quite a bit.  Hence this post, since many of the concerns about speed and potential bureaucracy tend to be directed at things that relate to information technology.

The chafing at new rules and increased structure comes from a range of people across the enterprise, people such as the following:

• developers, who are irritated that they have to check code in and out as they work, instead of managing it themselves the way they used to (when everything went just fine, thank you very much);
• sales/marketing people, who cut deals for customers that it turns out can no longer be implemented within the promised time frame, because the company’s world of interrelated systems has grown more complex with much more to juggle than there was “in the old days”;
• IT infrastructure people, who are being required to actually write down an implementation plan before beginning to execute it;
• customer support people, who discover that it’s no longer an acceptable process to just “call up Bob in IT” and put him to work on the perceived crisis of the moment;
• product managers, who can’t fathom why it’s now no longer acceptable to insist that a developer code and release a patch into production in the middle of the night to assuage an angry customer;
• users, who are being told they can’t use their own laptops on the company network or bring in their own printer from home if they feel like it;
• employees, who are suddenly being required to carry and display a badge at work.

And on and on and on.

Implementing new processes such as the ones cited above is of course a quite normal and expected (indeed, arguably unavoidable) rite of passage for a growing company.  Yet, the change management associated with them looms large, and the need for change management simply must be recognized and championed at the most senior levels of the company.  In young companies, though, it’s unfortunately the senior management themselves (particularly the ones who were around in the early days) who often appear most consternated by these shifts.  And that doesn’t help the rest of the employees grow or adapt.  As an analogy, it’d be like a parent not understanding it as expected and normal when their son’s voice changes, or when their daughter begins to menstruate. Think of the impact on the poor teenager in that situation, watching his or her parent freak out on them.

Distressed calls for input about how to stop the encroaching bureaucracy, even though well-meant, deliver a very mixed message.  Almost always at these juncture points, there are actually a lot of middle management forces within a company that are correctly pushing for what’s really needed now: focus, prioritization, measurement, scalability, and long-term benefit, rather than merely short-term “success”. Then along comes a message like this, indicating that oh, we’re not being responsive enough as a company.  Employees’ heads start to spin around in confusion, and morale can suffer.

Consider the following:

• These juncture points at young companies typically revolve around the need for greater scalability: more customers, more volume, etc.  Competitive pressures now aren’t just about getting new products rolled out in an agile and fast-paced way; they’re also (or more) about successfully delivering more of the existing products, and to a broader base. The company usually started its existence by focusing on product definition and delivery; scalability concerns come late to the party and are less understood and usually underprioritized.

• Structure is not bureaucracy. Early-stage companies often equate cowboyhood with success and reward.  Individual, bold initiative carries the day early on, and rightly so.  But, people who are used to being cowboys will tend to complain about fences, any fences.  Cowboys usually don’t want to hear about why good fences make good neighbors.

• It’s speed, not lack of speed, that’s actually the problem. Usually, it’s not that a company at this juncture is moving too slowly, but really the opposite: as projects proliferate and accelerate against the landscape of a broadening business, a greater degree of “haste makes waste” often sets in: poor planning (or non-existent planning) contributes to scrambling, rework, failure to focus, and failure to execute because of the emergency du jour.

• As for a “contract mentality”: actually, clear agreements are a benefit of a greater emphasis on process, not a symptom of bureaucracy. Of course there’s a strong need to work collaboratively, but it actually helps collaboration and throughput if scope and dates and responsibility/accountability are firmly identified for tasks and projects, rather than just assumed. Reaching agreements on those basics doesn’t have to even represent a huge amount of overhead, frankly, particularly considering what typically happens when the agreements aren’t clear: chaos and rework before success is ultimately snatched from the jaws of repeated failure.  As the old saw goes, people seem to have the time to do a given task over (and over and over), but not the time to do it right.

So don’t let the discussion be about the supposed but specious tradeoff of speed vs. bureaucracy.  Instead, it’s all about change management and all about leadership. Recognize that using the same approaches that worked earlier to shoot your company into space will now serve to drag you down to crash and burn. Don’t throw collaboration and need-for-speed out the window, but instead find ways to make them work within the new world of the broadening company.  The old world isn’t coming back, and frankly, no one really wants it to.