One of the most important dimensions on which teams differ is the degree to which they’re proactive vs. reactive.
Proactive teams operate primarily by strategizing, and then methodically executing on their plans. Think of teams such as User Research which conduct research and synthesize it into results, ideally building repeatable frameworks and reusable outputs along the way.
Reactive teams operate by rapidly assessing, deciding, and executing on new needs, typically due to external factors. They often follow playbooks for efficiency purposes, and are skilled at responding rapidly to changing information. They favor quick-thinking and the ability to juggle multiple competing priorities.
At a technology company, Design is the team that I usually think of as the most proactive. There are never really “Design Emergencies,” and even typing that phrase feels weird. Content Marketing is another example – it’s very rare that the business urgently requires a thought leadership piece. On the most reactive end of the spectrum are teams such as Support or Customer Success which need to respond to customers situations. These teams live in reaction-land, and need to quickly think on their feet and contend with unpredictable workloads.
Most teams fall somewhere in the middle. For example, much of the work that a PR team does is proactive, such as placing stories and building industry relationships. But there are also PR emergencies that demand immediate reaction – if your CEO gets indicted, your PR team doesn’t just get to go home at 5pm. Many enterprise SaaS teams such as Revenue Operations also fall in the middle. The day-to-day of a RevOps team consists of many reactive steps to advance ongoing deal cycles, but these teams also do the proactive work of mapping sales territories, setting up Salesforce processes, and more.
The most important factors to consider on the proactive <> reactive spectrum are:
- Reactive work tends to happen right where you make money: making customers happy, selling new deals, or doing damage control (eg, to keep the servers running or combat a PR issue). If you aren’t sufficiently reactive, you will let the business down.
- Your ability to scale as a department will largely be driven by proactive steps that you take to add efficiency. If you aren’t sufficiently proactive, you won’t be able to level up and scale.
Should Your Team Be Proactive or Reactive?
Given that businesses demand varying levels of reactivity from teams, and that proactively improving processes is how you scale, it’s imperative to know how you should balance your time.
If you’re a Support team and try to dedicate 70% of your Support reps’ time to scaling, you’ll quickly let down your customers. Indexing too hard on proactive work and allowing reactive work to languish leads to the type of leaders who self-brand as “visionaries” with lots of good ideas, but who ultimately fail because they can’t keep the lights on.
On the other hand, if your Product Management team spends 70% of its time reacting to the latest customer request, you’ll build a terrible product. This leads to the opposite case – great tactical leaders who get lots of small incremental wins, but who ultimately can’t scale their organizations to the next level of growth because they never identify step-function improvements to their organization.
As a result, the first thing to keep in mind about the proactive <> reactive dimension is that you need to figure out where on the spectrum your team should ideally fall. I’ve made a horrifically ugly graphic below to help illustrate this:
Establishing Your Spot on the Spectrum
Once you know where on the spectrum your team should fall, you need to take practical steps to gain and maintain that position in a scalable way.
For example, product, engineering, and design teams are ideally joined at the hip and operate more like a single function than a set of disparate departments. My favorite example: I view it as one of the key roles of a successful product management function to enable engineering to operate with the right level of proactivity. There are a few ways that this works:
- By laying out a well-prioritized and explainable roadmap, you buffer engineering and design teams from switching projects all the time when a new customer need or executive opinion arises.
- By working with design to set up a solid product development lifecycle, you prevent engineers from needing to react to changing requirements as features are being built.
- By hiring people with strong communication skills, you can help engineering with communications and more quickly resolve their most painful reactive needs: for example, responding to production incidents or customer questions.
Below are a number of different techniques to maintain your desired zone on the proactive <> reactive spectrum:
- Highly reactive teams can add a more proactive muscle by carving out explicit, defensible time for leveling up their operations. For example, establish a single goal per month/quarter (“revamp the performance management and compensation process”) and make sure that you defend this one beachhead vigorously. This proactive time should remain inviolate for everything but the largest emergencies.
- Conversely, proactive teams can use techniques such as on-call rotations to serve as a reactive buffer for an otherwise proactive organization. This prevents ad hoc needs from creating inefficiencies when a team focused on long-term projects constantly has bits and pieces of attention chipped away without a triage process.
- Setting clear expectations can go a long way as well. For example, you should tell a Customer Success Manager, Account Executive, or Site Reliability Engineer that they’ll be expected to work late if an urgent customer issue arises (and of course these teams should be compensated appropriately). By contrast, you should set the expectation with your Product Managers that they can’t react and change course with every new piece of customer feedback.
The Spectrum Determines How Teams Collaborate
And finally, once you’ve gotten your own house in order, you should consider the proactive/reactive spectrum in how you work with other teams. Team interactions work best when you understand how other teams operate, and design collaboration accordingly.
The degree to which a team is proactive or reactive will dominate its operating rhythm. For example, if you’re working with a Design team, you should expect them to be highly proactive and have detailed long-term plans. It’s best to get alignment and long-term ownership for what you need done so that they can work it into their multi-quarter or even multi-year vision for the future evolution of your product. Conversely, if you need to work with a Support team, they can probably help you with anything that you need on short notice but will likely not have the ability to commit to multi-year plans the way that a Product or Design team might.
Understanding the dynamics of how teams naturally operate can help big cross-team projects get done more efficiently, which is one of the hardest challenges at a startup. By considering where you need to fall on this spectrum, and defending your place there, you can help your team operate more effectively with minimal drama.
Takeaways
- All teams naturally fall on a spectrum of reactive to proactive – you need to understand your position.
- If you’re too reactive, you’ll never level up and scale. If you’re too proactive, you won’t respond sufficiently well to business-critical needs.
- Use techniques like explicit time carve outs (to be more proactive), on-call rotations (to be more reactive), and good expectation setting to defend your spot on the proactive <> reactive continuum.
- For best results, consider other teams’ place on the spectrum when collaborating.