Scott Berkun

The start-up inflection point

An upside of being a consultant is exposure to dozens of working environments: While clients benefit from everything I’ve learned to date, I leave a little wiser after each gig, with a few more observations and experiences under my cap.

There is one pattern in the tech sector that is so common, and so under-explored[1], that I’m compelled to talk about it here. I call it the start-up inflection point.

The basic premise:

1. Small engineering start-up is born, does well, hires like mad.
2. Heavy hiring bias for self-driven solo programmer prodigies.
3. Company grows; scores of engineers running around.
4. Soon primary challenge isn’t quality programmers: it’s organizing them.

No matter how self-directed programmers are, eventually their utility declines as ambiguities in direction, roles, goals and ownership become increasingly distracting and frustrating. The company is changing because of scale effects – but scale effects are hard to recognize, predict or compensate for. Hiring more brilliant engineers won’t solve this problem.

The trap:

1. The organization has history of success without management talent.
2. The staff have historic biases against management (that’s why they joined a start-up).
3. Organizational leaders are engineers first, managers second. This may include the founders and CEO, who’s only sanity check on management philosophy is themselves.
4. Even if leaders want better management, it’s not a stength. Worse, they’re trying to improve management in an environment resistant, by-design, to the very elements that need to be added.

Dozens of tech-sector companies are stuck in this trap and have been for years. They have manager to programmer ratios of 15 to 1, undiagramable networks of overlaping virtual teams, and decision making models so consensus driven that the brillance of many programmers is averaged away.

For awhile the fast pace of direction changes hides these problems, but these folks are smart: they soon realize effectiveness, real effectiveness of individuals, is nothing like what it used to be, and that there might be ways to fix it.

So what’s the solution?

The answers come fast if everyone has shared goals. Someone has to call out this new kind of problem, the meta problem of scaling up #s of people, and make managing it a top goal.

What are the symptoms? The pain points? How is this preventing us from kicking-ass? What has changed in the challenges to optimal work flow, now that we’re not 8 people in a basement, but 40, 80, or (gasp) 250?

With those questions fresh in everyones mind, a leader can then remind everyone of the underlying goals.

Goals start-ups need at the inflection point:

• We (still) want to kick ass – and now we have the resources to do it
• We want everyone to be as productive/happy as possible
• We want programmers to be as independent and agile as possible

With pain points + goals, the magic happens. People can see why surgical addition of management structure, or smarter ways to work when you have teams of teams, are logically necessary. There’s no fear of management now, since it’s not a 500lb anvil of random, suit wearing, MBA degree gloating, overhead. It’s the same smart, no-frills behavior that’s gotten the company to where it is, just applied to a different dimension.

Tactics start-ups need at the inflection point:

The pain points of any growing start-up vary. But here’s a starter list of common tactics that should be considered.

• Create a lead role, for people talented at leading, communicating and organizing. This is a different skill from writing great code: recognize your best leads won’t necessarily be your best coders. Invest in rewarding, hiring and training for this role. Don’t default to making your best programmers leads, as that is classic Peter Principle behavior. If you create the role, don’t create rules or procedures. The leads will self-create these as needed.
• Clarify who has tie-breaking authority to end consensus-madness, break political deadlocks, and over-ride virtual team Catch-22s. This is not Napoleon generation, it’s giving people a stupidity extinguisher to handle flare-ups in communication bottlenecks. Reward folks who use their authority appropriately.
• Make every VP or senior manager say the word Delegate, 5 times a day, and at least once before every meeting. As start-ups scale, founder types often become bottlenecks: they have to learn to get out of the way.
• Have every VP or senior manager wear a t-shirt that says “Hit me if I Micromanage you” every Wednesday: call it Micromanagement recovery day. Serve beer, pizza and smash magnifying glasses with hammers.
• Use a simple process for planning work. XP, lightweight specs, something – it’s unavoidable, but it doesn’t have to suck and you do need to have one. More people means more dependencies, and eventually retroactively handling dependencies costs you more than catching them before you write code.

Whatever you do, clarify the reasons/goals before you do it. Then check in with all the impacted parties in a week or two, after the change, and see if the pain is gone. If it’s not, stop or change what you did, and try again.

[1] – Most start-up literature I’ve read focuses heavily on getting off the ground. I’ve found next to nothing about the difficult transition from start-up to small company, especially from a management perspective. If I’ve missed some great resources, leave a comment.

• Posted Monday, August 7th, 2006 at 11:55 am


• in Innovation, Management | 12 Comments » |