Sabotage Pattern #8: Build on Functional Expertise and Discourage Generalization
Insist on having experts for everything. And on that only the experts can do their stuff and no-one else. And if you are not an expert in some area, try to hand over the work to someone else, who is an expert, because clearly he will be able to finish the work in much less time — an argument that is most usable when dealing with anyone who sees only numbers and money behind everything.
Having experts for everything and discouraging generalization has two effects:
- Firstly, you will probably slow everything down because some of the experts will get overloaded with work. Also, during the numerous handoffs some information surely will not be passed along and delay and confusion will happen.
- Secondly, disallowing generalization will mean that people will less and less communicate with each other, they will tend to “mind their own business” and when problems will arise, they will try to blame someone else instead of trying to solve them as a team.
Functional expertise in general is something that worked in the industrial age and what works in the complicated domain but it fails brutally in complexity. Moreover, these “experts” very often behave like primadonnas: they insist everything to be done their way, without discussion, without room for others to add value. And this created demotivation, resignation and general lack of ownership. In other words: anyone except the expert will not care about what is happening and many people will secretly wish what the expert says fails — some will of course even use sabotage to make sure a huge failure happens.
Bring me the one expert!
I remember that once I was suggesting some organizational changes — transformation from silo-based functional domains to cross-functional team — in one company. While I was presenting these thoughts to the CIO, he asked me to “show him the one person responsible for JAVA code” and “the one responsible for the architecture”.
I tried to explain there is no such “one person” and that the knowledge and decision power go together and they are distributed amongst the teams. He did not believe me and insisted on having that one “super-expert”.
This wish, which (because he was the CIO, remember) eventually became reality led to disengagement of people and wrong decisions made by the “super-experts” due to them lacking some key information. However, at least there was someone to blame — from the CIO’s perspective.
Recognition
- Is anyone at the company asking for experts?
- Does the work get handed over several times, so that the experts do their part?
- Is the decision making process centralized in the hands of few chosen experts?
- Are people allowed to learn new things outside of their primary domain of expertise, or do they stick in their one domain forever?
- Do you have cross-functional teams aiming for a business goal, or do you have silos where the overall goal is not known and every silo only does its part of the work?
Removal
- When you have the opportunity to learn something new, do it. If you do not have such opportunity, try asking for it.
- Try to form teams around the work that needs to be done with everybody contributing instead of passing the work from one group of experts to another.
- Try to push decision making power down the hierarchy. There are several tools that may help you both explain and ease this process such as Delegation Boards and Ladder of Leadership.
