This is the beginning of a five-part blog series about what holds organizations (not just single teams) back in creating value faster.
Being fast is a good thing since:
- It lessens the time our end-users have to wait for new stuff that can help make their life better
- It accelerates return on investment (ROI) for us since we can start charging our customers sooner (or collecting other types of value).
- This increases feedback so we know better if we are doing the right thing or need to change course.
After 15 years of helping organizations improve, my clients’ number one question is: “Can we get more out of the people and organization we already have?” The answer is almost always: “Yes, you can.”
It’s not about cracking the whip and making people work harder under pressure and longer hours. That’s not sustainable and, in my opinion, inhumane. On the contrary, it’s about making it easy to be fast without extra effort, and I know a little about that, hence this blog series.
Being fast is not the only important thing. Even more important is creating products that serve people and your business well. Choosing what to build and what not to build in a product discovery process is a topic for a future blog series. Today, we start with speed.
Part 1, “Don’t start at the wrong end,” discusses where to start to increase your organization’s speed. Bottlenecks and dependencies might stand in the way, but if people don’t care, you won’t get far despite your best efforts.
In Part 2, “Dependencies kill flow,” we explore perhaps the main reason for an organization’s slowness. Dependencies between teams and units mean synchronization in time (one delivers and one receives), and synchronization almost always leads to one party waiting for the other, which adds to lead time.
Part 3, “Create organizational focus,” looks at the most common solution to the dependency problem: having teams work on different things and releasing them independently. It sounds excellent, but the consequence is that you spread your organization thin, reduce collaboration, and have competing priorities.
In Part 4, “Don’t scale with underperforming teams,” we look at the building blocks of your organization. I introduce some key points for high-performing agile teams, but this subject really requires a whole blog series on its own that may come in the future.
Finally, in part 5, “Continuous improvement on an organizational level,” we look at how to make the state of being a fast organization permanent. This means that the leadership has to build an environment where people can perform and have a system for identifying things that suck and fixing them when they can’t be addressed on the team level.
I hope you’ll join me on this little journey.