Emergency brakes in software and technology projects can be annoying when seemingly one person can bring everything to a halt, acting on limited information.
On Braking
If you care about driving, you've probably gotten surfaced the video of a driving experiment where 10 cars are driving in a continuous circle. Like an ever revolving wheel, the cars begin by maintaining a constant distance and a constant speed, about 2 car lengths in front of and behind the next car. After about 30 seconds, things seem to get out of whack, and you notice several cars are bunched up on one side, and the other side 2 or 3 cars are speeding up slightly to maintain pace with the car in front of them. We've got a traffic jam simulator on our hands.
My Philosophy When Driving
On the highway, I always try to find myself behind a car that I can see around, over, or through. These new huge SUVs, or even something like a Nissan Rogue which has tiny slits for windows or is heavily tinted by default, doesn't allow me to see what's going on in front of the car in front of me. Everything in front of that person, is what's important to me even if it's not easily at hand (that's why I like driving behind normal sedans, or even a sports car). I find it a lot more work to make adjustments to only the driver in front of me, ignorant of what they have going on in front of them. If I can see what they see (or even just the one car in front of them), I can have a lot more empathy and information about what's changing on our shared path. It makes driving a lot more pleasant and predictable.
How this applies to software projects is fairly similar. Let's first imagine the nightmare scenario. You and your team have labored for several sprints to get a huge feature out the door. Most everyone was bought into the scope, timeline, etc. It felt good doing the work and you're glad to see it in a nearly finished state. However, just before planning the rollout to your users, someone who hadn't been involved with how the sausage is made decides to throw up a red flag, slam on the brakes (for everyone). They might have a very valid reason, but the memories of this that are most memorable, I find the importance of their reason is inversely proportional to the importance of their title. "It needs to be blue", "Should we A/B test", etc.
There's very little road rage in software projects fortunately. My theory is that road rage comes from not being able to pinpoint exactly who is to blame for the conditions on the road. Is it one maniac/idiot driver? The governor of the state? Dwight David Eisenhower himself? In the office, we can see who is slowing down things, or stopping them entirely, and usually they have a half decent reason for it.
Either way, it's frustrating and the point of this all is that on the highway, you can pick and choose your environment (as I choose to do by driving behind a car that allows me to have a little bit more empathy of the road conditions/traffic patterns). On software projects, there are some things you can do as well.
Mitigating Road Rage in Software Projects
- Create a Project Management RACI chart
RACI stands for "Responsible, Accountable, Consulted, Informed". Iron these things out well beforehand and define who is even within the project scope at all. Within these different groups, only a few can pull the emergency brake (R,A).
- Do a Weekly Status Review
I personally prefer performing ceremonies weekly. It helps to keep them short and sweet. And if something can be short and sweet, it can usually be done in writing (highly preferred). You can even do retrospectives asynchronously! Hour long status meetings every 2 weeks or more give too many opportunities for important people to fall out of touch with the pulse of the project, or not pay attention until the voices get louder and agitated around that time in the project when people, far too late, start asking "so are we in agreement about go-live?". In a few immature organizations, that's usually the language used to START the conversation about go-live! Don't do this of course. But also don't weaponize a written status update in the way large corporations might with terms of service agreements that are too long or complicated to realistically digest.
- Gantt Charts
Sometimes the person pulling the emergency brake too late (for your taste) in a project usually is operating in a different medium than your team. Business stakeholders, directors, might not be in the weeds in Jira, or whatever issue tracking tool you use. To augment weekly status reviews (written or meeting-wise), the formal "signoff" action usually is not trackable as a Jira Story or something like that. However, Jira Stories, Epics, Initiative, etc do fit very nicely together into a Gantt chart. For your team, spend a few minutes putting a formal signoff event within the Gantt chart, as well as a comfortable timeline to do that, obviously much earlier in the project than just before the decision for Go-Live. At the very least, have a meeting on the calendar for this for anything as big as an Epic.
- (BONUS TIP) Efficient Meeting Culture
Sometimes traffic jams just result because of something other than one person's decision or indecision. Another experiment shows that traffic jams can be mitigated by just a few drivers by intentionally driving much slower, to allow the waves of cars collapsing together before and behind, a little leeway to get back to an optimal (albeit slower than the speed-limit speed).
For software projects, keeping everyone on time with meetings makes everything else run smoothly. Start meetings on time with an agenda, don't punish the teammates who are on time by waiting for those that are late. A meeting isn't a hermetically sealed time and place, it takes time to get ready for it by stopping whatever meeting you had beforehand, so finish your meetings early, to allow your attendees time to decompress and digest what just happened, as well as to potentially do the very short action items before they might be forgotten or become vague when transferred into long-term memory.
Overall, be that person that smooths out traffic, even if it means compensating for the people who overcommitted and went too fast, causing a jam, or overreacting and slowing down too aggressively because of lack of context about what else was happening on the highway.
Hate traffic as much as me? Get in touch