Dear Gemba Coach,
What do you mean by developing people?
Good point! Let’s look at your question from the gemba. Say, for instance, that you’re the boss of a construction company and you’d like to develop every project manager in charge of building apartment blocks. From the CEO’s perspective, you know that some of your guys are very reliable and somehow always do well (even in tough spots, contractually and technically) while others are weaker. What does developing them mean in practice?
Making a building from scratch is no mean job. First, you’ve got to understand the engineering of it and make smart choices. Secondly, you’ve got to manage the building teams. Then you bring in trade professions to do all the internal fitting and finishing, which means managing a bevy of subcontractors, each with their own agendas and skill sets. You also have to be clever in finding substitution options to seek to increase the value of the building in terms of usage, and decrease its building cost. You also have to deal with clients – promoters, architects, etc. and other stakeholders such as various control agencies. Exciting work, but not easy.
The first level of developing people is helping them to face their professional challenges confidently and autonomously. Professional stress is essentially the gap between the perceived demands of the situation, and one’s felt inner resources to get on top of it. Take basic building engineering, no two constructions will happen in the same exact conditions – location, ground type, building specificities. Developing project managers first means growing their ability to make the right engineering choices autonomously (i.e. without help and/or correction) and progressively doing so confidently – but not overconfidently, which means being open minded to ask for help when something seems off.
We do this through problem-based learning to leverage the experience the project manager progressively acquires. Case by case, the project manager is asked to:
- Explain a problem in terms of what is the standard way of doing this or that, and then why this is problematic in this case.
- Go through what she intends to do about it.
- Is taught by her mentor the specific elements on which the situation hinges (Have you noticed the ground is particularly wet? In this case …)
- Explain the theory of the situation in greater detail.
- Try something in a small way and see what it happens.
Sometimes, there is genuinely no way to “try and see,” and then the mentor will take back control until the person feels ready. But essentially, the role of the mentor is to help the project manager develop her personal library of “unusual situations” and give her specific reference points for dealing with each in terms of “if you see this … worry about that …”
Your “Autonomy Shelf”
From the CEO’s perspective, people can be assessed in terms of the topics at which they are autonomous – they can deal successfully with this list of situations on their own; those where they can deal with the situation but need help – which requires careful monitoring when they’re in that case; and those where they need teaching from scratch – which means someone will have to supervise them as they discover the problem. People can be developed by adding typical problems to their mental “autonomy shelf.” This is never easy because the comfort zone is to learn more about something we already know a lot about, not to learn to tackle a whole new different problem (such as relationships with stakeholders).
The second dimension essential to developing someone is teamwork: the ability to solve problems across boundaries. In the project manager’s job, teamwork is critical to her success or failure. We’ve noticed that project managers with a natural flair for teamwork thrive and others, who can be quite competent technically, struggle, as any large project can be seen as a sum of relationships.
To help project managers develop a better grasp of teamwork, they’re asked to focus on one specific technical problem in any work relationship. With an architect, for instance, they’ll be asked to identify which specific aspect the architect is most sensitive to and commit to making a special effort to get that right. Conversely, with a subcontractor, the project manager has to identify one “above and beyond” aspect of the job and try to get the subcontractor to make a special effort on this. The aim of this approach is to teach project managers how to establish a grounding for a working relationship not on generalities, but on concrete joint efforts – in order to build trust.
Not all players play nice, of course, and many younger project managers are frustrated (and often destabilized) by partners who behave irrationally or are seen as constantly seeking their own advantage to everyone else’s detriment. This does happen frequently, and to help project managers with this, this company has picked up Willian Ury’s “getting past NO” method:
- Don’t react: go to the balcony – learning to take a step back from contentious moments (very hard) and avoid getting caught up in a cycle of mindless striking back to perceived attacks, grudges and hurt feelings.
- Don’t argue: step to their side – make the best effort to listen to what the other side has to say, beyond the bluster, acknowledge their point and their feelings, and understand their perspective – even if it’s simply not okay from your point of view. Understanding doesn’t mean agreeing, and young project managers have to learn that understanding is not the first step to agreeing. They can both understand and stand firm.
- Don’t reject: reframe – many stakeholders will take an inflexible position, which is hard to deal with for project managers. The trick here is to move from arguing about set positions to thinking flexibly about satisfying interests. The difficulty, of course, is that in high emotion/low trust situations, everyone is wary of stepping away from a position they understand for fear of being had. Project managers have to be taught to negotiate the negotiation process itself before fighting over positions.
- Don’t push: build them a golden bridge – this means learning to mediate your own agreement. Rather than pushing to get them to sign on the dotted line, this is about making it easy for the other side to change their mind, change their position without loss of face, and so on. It is particularly difficult for younger project managers who feel the other person’s issues are “not my problem.” It is also the most powerful part of their training to learn to see beyond their immediate situation and realize that other stakeholder’s problems are precisely part of their problem if they want to succeed.
- Don’t escalate: use power to educate – an instinctive reaction to a blocked situation is to find a bigger gun: to threaten, coerce or intimidate the other side into giving in. However, the harder you make it for them to say no, the harder you also make it for them to say yes. It’s a fine line between warning and threatening (especially for the other side), but this is exactly the line project managers need to learn to tread. They have to learn to discuss with the difficult person what the play of consequences will be whilst leaving out the threatening or bullying tone. Never easy.
Learning System
Whether this method or another, the main point is to teach project managers to build trust relationships across functional or trade barriers. The main way to do this is to pick a specific item in the work and build mutual interest on this as an anchoring point to the work relationship (here’s what we’re trying to do here – can you help?) and that is usually enough to change the game. But we also need to realize that project managers need help in dealing with difficult people and, again, we need to develop their autonomy in facing harder and harder negotiation situations. In any project, giving in costs you money, but having to change partners is very costly as well. Learning to turn people around is a key success skill.
Beyond developing basic competence, the deeper aim of developing people is to develop better judgment. More output seldom translates into better outcomes. In largely complex and fluid situations with never enough information, the key asset for the company is the individual good sense of its project managers and directors. The third level of developing someone is, therefore, to learn to develop others. As experienced project managers are asked to develop others they progressively realize the difference between getting the job done and succeeding at the job.
Developing others starts with a clear diagnostic of their area of autonomy – the list of problems they know how to solve correctly without help in a wide range of conditions – and figuring out which next area they need to learn in order to become more successful both for themselves and for the company. This is not an easy exercise, and to create repeated learning opportunities, the CEO organizes quarterly “people review” sessions where experienced project managers and directors discuss the more junior managers in terms of: what are they comfortable with; what are they competent in but still need supervision; what is the next skill we should like them to master; and, very importantly, what would they like to do next? Not surprisingly, these four questions rarely align – which is precisely the point of the exercise.
We’re discussing developing people, which begs the question: is someone ever fully developed? The environment moves faster than we ever will, so there is no dearth of new challenges, of course, but yes, on some issues the best managers can demonstrate their mastery by developing a robust learning structure. For instance, in lean’s foundation story, Taiichi Ohno developed kanban as a way to “reduce the water in the lake to make problems appear.” In a rare interview (republished in Birth of Lean), Eiji Toyoda talks of Toyota in terms of who brought which learning system to the company.
A learning system is a method that allows others to climb up the learning curve without having to only rely on experience – much like there are several methods to learn piano, languages, sports and so on. The above-mentioned company uses several learning systems (mostly developed by the CEO) to support autonomy in technical problem solving, project management and so on.
William Ury’s method to deal with difficult people can be seen as one such learning system. In the construction case, some project managers have developed systems to learn to better achieve technical excellence, such as carbon-footprint reduction in building a site, better handoff amongst trades, and so on. The greatest contribution one person can make to the company is not just inventing a new technique, but setting up the process for everyone to master this new technique.
Developing people, in this sense, means:
- Growing one’s technical expertise topic by topic by understanding more deeply both the practice and theory of what we do.
- Growing one’s teamwork expertise by learning to work better with others across boundaries, particularly in difficult situations
- Growing one’s better judgment by learning to develop others in turn.
- Contributing learning systems to the company in terms of both new techniques and the processes to master these new techniques.
More profoundly, development is not just about cold technical competence. It’s about the energy of managers, vitality of teams, solidity of relationships that create value; and satisfying customers whilst reducing waste generation and related costs. A company is not a clockwork mechanistic assembly of departments. It’s a living, breathing, evolving organic team of people.
