In Computer Science there is the idea of a Design Pattern. A Design Pattern is a general solution to (or template to solve) a commonly occurring problem. As the Design Pattern is general, and because it solves a generally occurring problem, they come in handy again and again when writing code. Design Patterns became widely known in 1984 when the so called “Gang of Four” published the book Design Patterns: Elements of Reusable Object-Oriented Software.
If you’re not familiar with design patterns then here’s an example. Imagine a large, distributed computer system serving millions of requests every second. For the system to function it needs to run on some assumptions. We might need to change these assumptions from time to time, but for the most part they stay the same for each of the millions and millions of requests. Now imagine how difficult it would be to update or change just one assumption if that assumption was distributed and replicated around the world within numerous parts of the system. I can easily envisage it being so complex you need to setup a project to handle all the intricacies and ensure everything goes smoothly. Rather than get into this mess however, when building the system we could have decided to use a Singleton pattern. A Singleton pattern ensures a class (our assumptions) only exists in one place, and that there is access to it globally. So, because we’ve use a Singleton pattern, if we need to update one of our assumptions, it’s a very simple job which can be done quickly and confidently. Pretty cool, eh?
Design Patterns are described or written down in a standard manner which makes them easy to reuse. To learn more about design patterns have a look at their definition on Wikipedia, and to see how they are written, here is the link to the Singleton pattern. The information contained within a written design pattern includes the following items:
Often when I read modern Business books there is only one big idea contained within the book. The idea is usually out in the open by the fourth or fifth chapter, and then the rest of the book is spent examining problems through the lens of this new solution. Maybe it’s because I’m from an engineering background, but when I read these books I can’t help think it would be better to use something similar to a Design Pattern to describe their idea. Perhaps we could call them Management Patterns or Leadership Patterns. This way the idea would be captured succinctly, and I wouldn’t need to read the whole book again if I wanted to make use of the idea long after I’d originally finished the book. If we had all management tools and ideas captured in a single body of work then perhaps we could move management more towards science than art.
If you look at the article describing Design Patterns on Wikipedia, you can see that the patterns are broken down into four categories: Creational Patterns, Structural Patterns, Behavioural Patterns, and Concurrency Patterns. A similar approach could be taken with Management Patterns, we could even use the categories above, as follows:
Creational Patterns: could relate to patterns around the execution of projects and programs and the creation of outcomes
Structural Patterns: could relate to patterns around organizational or team structure
Behavioural Patterns: could relate to patterns concerning how to interact with people and communicate
Concurrency Patterns: could relate to patterns associated with teamwork
Having done a brief search for Management Patterns, the only person I can find who has attempted to create some is Alistair Cockburn. Although, the patterns are focussed on managing very small software projects and the page hasn’t been updated since 2004.
Above are just my current suggestions, I’d like to do some more thinking on this topic, but if you have some thoughts then write in and let me know. I’d be delighted to receive some feedback on the idea of Management Patterns.