When I was at University I remember studying lean management techniques in car manufacturing based on the sole premise that it’s faster to put 10 letters in an envelope, write the address and stamp them one by one than it is to split that job up into three sections, and complete each task before moving onto the next one (i.e. fold ten letters at once).
Now it seems counter intuitive that splitting a task up into sections would be less efficient than just doing the whole task in one go, after all the model T made production lines where each task was split up into small sections made the American dream possible, but it’s actually a well-tested fact.
The story on lean management begins post world war two, with the USA ploughing ahead with huge production lines, Japan needed to catch up but they couldn’t afford or sustain such high volumes as production techniques like the Model T required.
So they pioneered lean production instead by reinventing the production process from the ground up. What they realised was that by working in small batches they could recreate these economies of scale while also being much more adaptable to customer needs.
Once it was started the Model T production line couldn’t stop, but using the lean model meant that after each run a tweak or improvement could be made while the number of options available e.g. colour increased massively which meant the sales team could tailor products to clients needs. “You can have any colour as long as it’s black” was a quote by Henry Ford that summed up mass production; who knew it also summed up the downsides?
Moving on then, there I was sat in a lecture hearing about how lean methods could be translated into management too. You see the theory is that rather than have different departments, where projects get split up and sent to which ever department it needs to be in until handing off to the next one, lean management promotes the use of teams and transcends departmental barriers.
In essence you still have departments like “IT”, but that department is more about sharing knowledge and skills than performing a function. When a problem comes up a team leader is appointed to solve that problem and they then recruit team members from multiple departments, forming one coherent team and solving a problem amongst themselves in real time utilising all the skills they need to go from a to b as fast as possible, tweaking along the way (see ready, fire, aim for more info).
What you get is an individual letter type approach to a big problem, but with all the skills necessary to solve it. In practice this type of team work promotes quick responses. For example it’s well known that in prototyping, machinists, designers and engineers can come together to make a prototype in days not weeks for small businesses, yet go to a huge factory and you’ll wait weeks to get something due to the barriers put in place by organisational processes.
Now as an eighteen year old being fed this kind of information I was pretty skeptical, it all sounded like hocus pocus to me, particularly when the text books present “lean management” in a twee way where each team gets a few bean bags and a trolley to store their work! It makes you dismiss the idea as an ideal but actually with hindsight and experience it’s exactly the type of set up a great business needs to keep themselves efficient; it seems perhaps the idealistic way of explaining it might need some tweaking itself.
I fully understand why 99% of businesses have fallen into the trap of departmental barriers to problem solving. As you expand, there’s a huge temptation to build departments, break tasks down into chunks and bottleneck power. Sadly I know all to well the problems of this type of assumed way to handle growth.
I’ve spent a few years in different organisations that are all afflicted by this ailment, caused it’s sad to say by the people at the very top (see the bozo explosion) who set up the culture and ethos of the business the wrong way in order to control the “how” instead of liberating it. This bottle necks decisions so nothing gets done and departments in turn act to slows down progress rather than speeds it up.
I’ve talked before about management being a misleading term, instead preferring to use the conductor theory to explain how management should operate. This pairs quite nicely then with lean management, where as a company grows you build departments with their own sub-culture variants of the main culture (e.g. it’s ok to be geeky in the software department but you might want to be a bit more hard core sales culture in sales), ideas are swapped and competencies are increased, but when it comes to applying those skills, everyone breaks away into their own teams with cross departmental members to solve the job at hand, the team leader being the person who picks which team members to include. In this instance the team leader is the conductor.
As businesses grow, growth itself serves to stifle communication and entrench an “us and them” culture between departments or buildings so lean management is a great tool to help keep communication lines open.
Yet even I have to admit that lean management isn’t always the answer, sometimes you really do have to spoon feed. To me lean management is something that is better suited to “uncertain” jobs types, for example, projects or sales. It is not suited to fixed events, for example “register me an email address”. There’s simply no point in setting up a team to do something we already know about, as such for me then you need to split your business into fixed processes and those subject to change. Fixed processes are often simple ones that have been done time and time again (and often kept in departments) where as those subject to change are perfect for team creation.
If you’re packing the same box over and over again, with a process that had been defined and cannot improve, then why need a team? If you’re defining that process for the first time, or the box is liable to change often then perhaps a team is the way forward.
It’s also important to define what I mean by a team. There will invariable be formal and informal projects. Some require teams to be formed around a table, whereas others are more informal with the person responsible for solving the problem getting people to help ad hoc. Whether formal or informal there will however always be a team leader (manager or any other term) that is responsible for the outcome of the project. The workplace isn’t a democracy and as such their decision and choice of team members should be final. It important that they are accountable for the outcome of their teams efforts and therefore responsible for making sure a conclusion is reached while also recruiting/motivating the team members involved.
As a side note I’ve always found basecamp to be a great tool to help promote the use of teams across and organisation, with the mobile app being particularly useful, in fact 90% of my projects are conducted through basecamp with differing degrees of formality.
Once a team is formed in my experience, the best way to solve a problem is to start testing straight away by building a minimum viable product or solution (MVP), putting it out there and learning from what happens. Team collaborations across departments give organisation the opportunity to test ideas and tweak things to improve the product that’s eventually set in stone. It’s all part of promoting creativity in your organisation rather than providing ridged structure as you grow. The lessons learnt from each MVP and tweak should be well documented such that it can be shared and the information built on so that the next time a team is assembled it doesn’t start from scratch, enabling an organisations core competency to grow.
The problem with ridged structures vs lean ones is that ridged structures don’t want to go to market till every box is ticked, but this ready, aim, fire mentality delays solving the problem. Think of it this way, split your problem into %’s; when you have a problem you have 100% of one. If you wait a few weeks to create a solution, passing it around departments to get decisions made and agreement, then you still have 100% of a problem for the duration of that period.
If instead you create a small team and get a solution out there straight away, while aware it might not be the final solution then you can immediately reduce the impact of a problem to say 20%, reducing the impact significantly over the period it takes to get it solved completely. The same premise holds for production or new products. Why go straight to full production after a long wait when you don’t know if the product you’re selling is right for the market? Test & tweak first to get it right.
Read our next blog post “Growth kills growth“.
