Reactionary isn’t a bad word
You just don’t adapt well enough to change
The word reactionary gets a bad rap. In tech, reactionary is a requirement to being successful in a startup. It’s the best muscle to use as a startup against incumbents.
Your organization has to be built to handle the adaptability required in a reactive org however. If the org isn’t setup from top to bottom this way you will give your team whiplash.
Prior to the 1950s cars were built like a rock. This protected the car but, quite literally, killed people inside due to the instant change in momentum. In 1937 Béla Barényi invented what is called the “crumple zone”. It increased the time of the change in momentum from the time of impact to the time the people inside stop moving. The incumbents are the ones built like a rock and startups need to have that crumple zone.
So, what is a crumple zone in an org look like? Well, let me pick on scrum a bit. I come at this from someone who implemented it, was successful (in scrum terms), and was a CSM (Certified Scrum Master). Let’s take a task that only one engineer needs to make like changing the icon sizes.
In scrum the entire team is supposed to “point”, or estimate the size of, tasks. You pull in the team which, at the smallest, is you product manager, scrum master, and individual contributors (ICs). At the smallest recommended size of scrum that brings the total impact to 5 people. But, oh no, this actually touches another team who manages the icon library so now you have to do a scrum of scrums! Now you have to pull in two full teams. Slowly but surely you’ve got everyone and their dog involved in updating these icons and they don’t even care and won’t be doing the work.
This is why you get the “we have to stop being so reactionary!” because it kills the productivity of all these people involved for every little change. You need to have one damn good reason to change the plan because if not you’re throwing a wrench into the cogs of this massive process machine. I didn’t even get into the trade off discussions you’re supposed to have before adding points mid-sprint. Oof, good luck with that.
Why is it like this? Most commonly it occurs counterintuitively when process is slowing everything down. Going back to the crumple zone, if you’re naive and you design your process, or car, to not withstand impact you might think “we need to build a stronger car!” but really you want a car that adapts to the sudden change in environment instead.
To do this I like to consider the crumple zones in the process. At Quin we’re still a small team but we still have a process. For example, for our MVP’s sign up flow we wrote a Product Requirements Document (PRD), we diagrammed our infrastructure out and reviewed it, we reviewed the tech stack and weighed pros and cons, we spiked out integrations with third parties, and had a kick off and planning meeting. The important piece is what happens when a change has to happen which it inevitably does.
Recently, an engineer noticed that the flow of sign up as designed was overly complex within the code and they didn’t believe was the best UX either. In scrum if we were to change onboarding up we’d need to have a trade off discussion, new tickets, and we’d need the team to point. Instead, the engineer raised this in Slack. Some people chimed in with opinions, and the product manager made the call to change it in favor of the engineers suggestion.
This might feel like a lack of process but that is intentional at this point in the project’s lifecycle. This is the crumple zone. The process broke down here, but that’s OK and expected and in a reactive organization it’s a requirement. We planned that things would change and allowed that to be acceptable. In a scrum world, or in a previous org of mine, something like this would literally have had required leadership to approve and the scrum team.
Instead we made the important parts “built like a rock”: our mission, the project’s product goals, overall quality, and user experience. Those can’t crumble. In this case the product goals are: a streamlined, easy to use, sign up flow that integrates with some third parties that can be built in a few weeks. Our director of product, the engineers and designer can determine what that means and rearrange and alter sign up as needed until our target completion date and doesn’t require me or anyone else on leadership to “sign off” if they want to move a screen around or change styles.
All this is to say that when you get the comment “we need to stop being so reactionary!” it’s probably a smell that your process can’t adapt to changes well enough. It’s probably layers and layers of process that make it impossible to do a quick change. The way around that is to setup your process with parts that can’t change such as your mission and the overall goal of your project and everything inside that remove the process, give them trust, and let your figure the rest out.
