Moving Too Quickly

There is a point in everyone's career when they are moving faster than they should be. Antiquated management techniques pride the program on pushing contributors to the edge increasing the efficiency of a process. After all efficient usage of time is the only metric that matters, right?

WRONG!

The why behind this answer is another blog post on its own. So for now, let's keep it short and leave it at. A single contributor's efficiency is a local maximum. To make my team's time-efficient, we could delegate the majority of work to other teams. Those teams could either precede or be a customer of my team, it does not matter either way. My team is efficiently using their time to complete a single task in the flow of work, which does not make the system any better at creating value.

When working under these antiquated management styles, there is an expectation that after every cycle the contributor becomes faster and faster. Reasonable expectation, given we are doing the same operations all the time. Again, wrong! Crafting software is not the same thing over and over. Similar? Yes at times, but rarely the same thing, we have abstractions for those that are the same thing.

So is it reasonable for us to move any faster as a development team?

ABSOLUTELY!

As the contributors on the team are working together, understanding what the best working arrangement is for them, they will indeed increase the velocity at which the output. Win for everyone, right? Not really... There becomes a time where a team begins to move too fast. Typically, this is seen at an individual level first. But unless the issues are corrected, it has the potential to grow into a full team problem.

So what is with moving too quickly?

So much! How about the time when you locked yourself out of the car because you were too busy thinking about the next issue and not focusing on the current task. Maybe it was the time the team released a huge bug into a testing environment that required a ton of re-work to fix. How about the time someone was setting up data to test something and accidentally used a production connection string, adding garbage to the environment. Or even worse, removing real live data for a customer to set up the perfect testing scenario. Maybe it was the time when no questions were asked about why the team was building a feature. They just built it. Then no one used it. What a waste of time for a team. The opportunity cost of delivering something that no one was asking for.

I think you are catching on here. There are an infinite amount of ways that moving too fast could be impactful. Some of them are easy to write off, as just an accident. Others are offenses that could cause real problems to the product or the brand. A handful of innocent mistakes due to everyone moving too quickly can cause real harm to the projected revenue. Go out there and make mistakes, that is how we learn what not to do. But, do not rush through work just to call it done, leaving a wake of other cleanup items to execute on later. Or burning down the bridges that everyone relies on to sustain a living.