This little phrase has been popping up all over lately, attributed to multiple sources. Here’s why it has such a powerful effect on how we approach IT work.
The most intuitive way to avoid mistakes is to plan carefully. Thinking about the big picture, ideally, means that every step you take moves you one step closer to the goal. And having a shared, common vision means that everyone can work independently and produce results that move the team forward. Result: less rework and less communication overhead. If complete, accurate, detailed plans don’t get you where you want to go, then, presumably, they aren’t complete, accurate or detailed enough.
Thinking about the big picture is pretty important, as far as it goes. The problem is that perfect plans are rare. The future is often surprising and we end up learning as the project progresses. That’s less of a defect than just a matter of how things work. So, the best approach here, ironically, is to plan for it. Plan for the fact that you don’t know everything at the outset, that you’re going to get smarter as time goes by. Plan to get smarter as fast as you can. Starting small and optimizing for speed of execution are great ways to do this.
So, easier said than done, right? What if we have big dependencies, like architectural foundations to put in place before we can do anything that delivers business value? Won’t we just end up with hacks that won’t scale or adapt to new demands?
Well, it’s unlikely. The benefits of seeing how well your design works in real life reduces the risks and speeds the teams learning curve. If you make a mistake early on, you will still have time to correct it, as long as you did it as quickly and easily as possible. All you have to do is avoid doing something big that turns out to be the wrong thing and you will have recovered all the effort you might waste on doing small things twice.
The point is, understanding the big goals and how the team will measure success, the big picture, is essential. There is also real value in doing things quickly on a small scale. You’ll learn a lot quicker, reduce the risk of the project and save a lot of time by doing it. Don’t pick. Do both.