Ever since I made the transition from being a developer to being a manager I no longer spend my days in front of an IDE coding away. These days my tools of choice are calendars, spreadsheets, documents and presentations. Another significant change is that the people that I interact with on a daily basis have a more diverse set of skills and backgrounds that not always includes technology.
In this world is common to see a strong focus on processes definition. Whenever a new process is to be put in place, endless meetings take place to make sure that every department is aligned and that their needs are taken into consideration. After that, long documents are created to make sure that every scenario is captured and that there’s no room for misunderstanding. Presentations are created to communicate back the final product and to kick start the process.
After a significant amount of time invested up front we might find ourselves with a process that no one is following because it’s too stiff and complicated. Out of frustration people slowly stop following it before going back to their old ways until the whole thing becomes a distant memory. Because the underlying problem was never fix, eventually someone will have the idea of creating a new process and the hamster wheel will spin again.
As a developer these problems are just too familiar. It’s been a long time since we abandoned the idea of heavy up front planning in favour of experimentation, small batches and fast feedback loops. We also gave up on extensive documentation because we know how fast they become outdated. We focus instead on tooling that helps us move in the right direction. We have embraced ideas from lean manufacturing, the agile manifesto, lean startup and DevOps practices.
If you are ever in this situation avoid the long preparation meetings, create instead something small and simple that can be tested as soon as possible. Gather feedback from the people and go back to the drawing board to make improvements. Avoid long documentations by creating tools to automate tasks. Create two or three different versions of the process and try it out with different teams. Which one was more effective? Don’t assume that you know what works and what doesn’t. Everything is a hypothesis that’s waiting for an experiment to be validated or disproved.
Not everyone will be happy with this approach as it’s not common outside of manufacturing or software development but we know it works. It’s my believe that a high performance company is closer to “chaos” than to “order” as the former embraces innovation while the latter stagnation.