Plan or Pain?

The 2014 Digital PM Summit is here! I'm greatly looking forward to presenting on organizational growth from a PM perspective. I've arrived at the final post in this mega-series supporting the presentation, which focuses on planning (or not planning) for growth. It takes a look at examples where planning is called for, while in other cases making decisions based on growing pains is the most efficient route to success.

Other Posts in This Series:

1. A Formula for Healthy Project Size Compared to Organization Size
2. Scaling Projects and Scaling the Organization
3. Unit Change During Project & Organizational Growth
4. Family-Sized Business Units & the Agency Holding Company Model
5. Beware the Matrix Model?
6. Communication Styles and Team Dynamics
7. Agile Versus Waterfall, Once and For All
8. Process Frameworks That Weather Growth
9. "Why" Not "What" Documentation
10. Project Manage The Organization
11. Plan or Pain?

Planning is a Double-Edged Sword

Project managers love to plan. Operations managers love to plan. Who doesn't love a good plan? Yet basic tenets of Agile versus waterfall explain clearly why planning too much too far in advance can be a futile or even counterproductive effort. My Agile versus waterfall post is all about the cone of uncertainty, and future growth of an organization is an incredibly uncertain thing. Don't make the mistake of trying to plan structure for future scenarios that are so uncertain they can barely be defined. Some companies anticipate one or more possible futures, build plans that will seemingly facilitate those scenarios, and then are frustrated when the future doesn't arrive exactly as planned. Also common are organizations that spend a huge amount of time to plan multi-year direction and goals and then get bored or never complete the plan because it was too big and hairy. Most planning time is wasted unless there's a strong commitment to follow-through, the ability to execute quickly, and alignment around a central goal.

Don't get the wrong idea; not all planning is bad. In fact, most planning is good! The very act of daydreaming and thinking of what could be is key to launching a business, and is in itself planning. Business plans are still pretty much a requirement to get funding and start a new company. However, a common danger with planning is attachment. We get deeply attached to our plans and desparately want them to be the right plans. We see one ideal way forward, and pour our energy into making that plan a reality while missing important course corrections needed to respond to unknowns along the way. Instead, do plan for the long-term when it comes to the few time-tested knowable principles of growing an organization, plan a bit more last-minute when it comes to low uncertainty objectives in the short-term, and let pain determine your course corrections and adjustments along the way. Most importantly, be confident in your plans, but be completely willing to ditch them and be aware of when doing so might make sense.

Defining Pain

Let's go back to the very definition of pain. Pain is an unpleasant reaction by your body to various forms of stimuli. Pain is a good and necessary thing; it helps you understand and react to illness and injury. In much the same fashion, if your organization is a single body, pains are the natural problems, tensions, stresses, and frustrations that arise from within. Organizational pains can come from any number of things, but often problem employees, broken processes, and poor communication are triggers. Organizational growing pains specifically are almost always amplified by increasing complexity as the organization grows.

The physical pain and organizational pain comparison breaks down in one key way. In the human body, the central nervous system does an amazing job of communicating pain to your brain almost without fail. With an organization, the ability to identify pain is only as good as a) the intuition and proactive awareness of those who can solve problems to reduce pain, and b) communication channels between those feeling pain and those who can fix the causes of the pain. Much like someone with congenital insensitivity to pain placing their hand on a hot stove, organizations that don't have strong, open communication channels can fail to identify and correct painful problems quickly. 

When problems fester without speedy recognition and swift corrective action, the classic "fighting fires" analogy appears. Fire fighting isn't sustainable; I've seen many a project manager or business manager who was a great fire fighter, but they never got past putting out fires to be proactive so that fire doesn't spread and doesn't start in the first place (because when that happens, soon everyone is a firefighter). I coach our team that it's a must to be proactive on projects in order to rarely need to go into fire fighting mode, but I also distinguish between being proactive (which is often a function of improving communication and strong expectation-setting) and going into process and structure planning mode.

MVP (Minimum Viable Process)

The message so far is that some planning is good, while other planning is bad. That's ambiguous! The answer lies in finding the right balance of planning and process-building, or what I'm going to call minimum viable process. Just as creating a minimum viable product entails building just enough product to go to market, minimum viable process is all about erring on the side of building just enough structure around growth. Ben Horowitz captures this concept perfectly with his notion of giving ground grudgingly, which I can particularly relate to when it comes to organizational design. Horowitz writes "The first rule of organizational design is that all organizational designs are bad. With any design, you will optimize communication among some parts of the organization at the expense of other parts... Still, at some point, the monolithic design of one huge organization runs out of gas and you will need to split things into smaller sub-groups." Implied in this is that each individual employee has a limited capacity and can only scale their communication quantity to a certain point. Beyond that point, structure needs to be created to facilitate ever more complex communication.

Horowitz's thoughts on process are similar: "The purpose of process is communication. If there are five people in your company, you don’t need process, because you can just talk to each other. You can hand off tasks with a perfect understanding of what’s expected, you pass important information from one person to another, and you can maintain high quality transactions with no bureaucratic overhead. With 4,000 people, communication becomes more difficult. Ad hoc, point-to-point communication no longer works. You need something more robust—a communication bus or, the conventional term for human communication buses, a process" and further, "When should you start implementing processes? While that varies depending on your situation, keep in mind that it’s much easier to add new people to old processes than new processes to old people. Formalize what you are doing to make it easy to onboard new people."

Let's look at a few specific examples to illustrate the entire spectrum from planning (and structure) to pain (and fire fighting) and how the right choice often varies based upon the stage of growth an organization finds itself in:

• Headcount - Headcount as a whole is something that can be generally predicted based on growth goals and projections, and is therefore inherently somewhat plannable. Hiring priorities and headcount is one where I can see an arguement for either planning or pain depending on what phase of growth your organization is in. On the pain side, you'll ensure your hiring priorities at any given time are the abosolute most critical to fill the gaps causing the most pain. The big downside to pain is that as you grow, more people will want a say in hiring priorities, and they'll each bring their own pain to the table, resulting in ever-changing and increasingly confusing priorities. Planning becomes more and more advantageous as that occurs, and we created some structure around our hiring at roughly 25 people. By getting ahead of hiring with 3, 6, and 12 month rough organizational charts, we were able to clearly identify our future gaps and plan a priority order that makes sure hires happen before the pain of any single gap becomes severe.
• Space - Similar to the predictability of headcount based on growth, office space is something that early on may be best determined by pain. Until a clear growth track with increasing revenue and headcount is established, planning to increase square footage doesn't make sense. If an office space suddenly gets tight, leases on smaller spaces are easier to negotiate, remote options are possible, and opening additional office locations may even make sense. However once growth is on a more predictable path, it'd be somewhat foolish to not plan for future accomodations and instead wait until space becomes cramped to figure out what might come next. Space planning has been a year in the making for Metal Toad as we've grown, and luckily we're just now starting to feel significant pain as we're six weeks out from new office readiness.
• Team Structure - As the quotes above suggest, with organizational growth comes the need for structure around communication channels as transaction quality in communication decreases. Our plans to refactor our one large production team into small, cross-functional two pizza teams attempts to get the team unit size back to the point at which "just talking to each other" is perfectly manageable. Up until 30-35 people it made sense for us to adapt to team communication needs based on pain. Around that point, it became increasingly clear that we needed to plan and have structure in place by the time we reached 50 or risk facing severly diminished communication and efficiency on projects.
• Onboarding - We waited perhaps a bit too long to really plan for onboarding with developers, and then had to play catch-up a bit as we entered a rapid hiring phase. The burden created on our team by the lack of a system in place didn't entirely set us back, but there was a noticable impact on our overall capacity to produce work for a time. That said, in other roles with smaller numbers of employees, planning a robust onboarding system would be overkill given the likely quantity of future hires.

As a whole, there's no perfect rule for when to plan versus when to react to pain, but I'll leave you with two general criteria for when to plan that have served us well. First, identify areas where maintaining high quality communication is already complex and burdensome, as the complexity increase when scaling will be exponential. Second, identify areas of the company where alignment may be low or competing interests are likely to exist, regardless of communication strength in those areas. Planning and minimum viable process here will help keep communication channels open during times of debate and will de-escalate conflicts and potential fires before they occur.

I'd love to hear your examples of plan versus pain thinking. Leave a comment!