Training versus development

Mike Myatt, Chief Strategy Officer N2growth, recently posted a very savvy article regarding the difference between training (a typically rote, stale process) and development (more dynamic, needs-based, and effective) in the context of leadership. What I really liked is his point-by-point comparison of the strengths and weakness of training versus development:

  1. Training focuses on the present — Development focuses on the future.
  2. Training focuses on technique — Development focuses on talent.
  3. Training adheres to standards — Development focuses on maximizing potential.
  4. Training focuses on maintenance — Development focuses on growth.
  5. Training focuses on the role — Development focuses on the person.
  6. Training indoctrinates — Development educates.
  7. Training maintains status quo — Development catalyzes innovation.
  8. Training stifles culture — Development enriches culture.
  9. Training encourages compliance — Development emphasizes performance.
  10. Training focuses on efficiency — Development focuses on effectiveness.
  11. Training focuses on problems — Development focuses on solutions.
  12. Training focuses on reporting lines — Development expands influence.
  13. Training is mechanical — Development is intellectual.
  14. Training focuses on the knowns — Development explores the unknowns.
  15. Training is finite — Development is infinite.

I couldn’t agree more. When it comes to leadership development, you can’t “train the leader.” Training on technical, procedural topics is of course highly effective, but leadership requires too much contextual differentiation, too much innovation, and frankly relies much more on innate skills that can only be developed over time, not absorbed from a short training course.

Trying to change the world can be dangerous

Trying to change the world (or at least the professional one)? It can be dangerous, as Julia Kirby writes in Harvard Business Review: It’s one thing to be the agent of change in an organization that realizes it needs it; it’s quite another when you’re the only one in the room convinced of that. Be sure people perceive any change as being done for them, not to them, or risk their wrath.

Dealing with negativity in the team

You are leading a star project team working on a challenging project when you noticed a particular team member spreading negativity, rumors among peers. You are afraid this negative behavior will bring whole team’s morale down. What would you do in this situation?

Every individual is different, and every situation is going to require a different response. Temper tantrums, sexist remarks, chronic lateness, information hoarding, playing favourites … people don’t always behave themselves at work. An adept manager needs to understand the individual nuances of the situation and act accordingly. You need finesse, insight into your team, an understanding of psychology, and often, incredible patience. Here are a few strategies that I always like to try.

1. Engage the malcontent

Quite often, the negative attitude comes from feelings of being disengaged from the team or the project. Perhaps the individual thinks he could do the job better; perhaps he isn’t working on what he wants to work on; or, just feels the project is heading in the wrong direction. Most often negativity stemming from these problems will surface in a team setting, such as passive aggressive behavior, grumbling, openly showing dislike for decisions. I like to engage this individual in finding a solution. Hand accountability to that individual and, in essence, give full reign to fix the problem. With accountability often comes responsibility — and the need to realize that decisions are not always quite as simple as they appear on the surface. Of course, sometimes the individual makes a mistake — but in this case, the lesson is still learned. They “get their way,” but also find out that “their way” wasn’t, afterall, the right way. Of course you’ve got to strive for a better outcome — assign responsibility, and then back them up. Make sure they’ve got resources and help in the decision making process. Hopefully it becomes a learning experience for everyone.

2. Reach consensus

Sometimes it’s not practical to let an individual run with their own ideas. Yet, still you have someone that feels “things” are heading in the wrong direction. I like to try to reach consensus or, failing that, at least agreement that we’ve made the right choices given what we know. One approach is to schedule a round table with the malcontent and his peers, perhaps 3-4 people. Discuss the problem, and try to reach agreement on direction. In the best case, his peers will sway his opinion. More often, the complexities, choices and decisions that have led to the current situation will be discussed — and the “black and white” situation fades in favor of many choices, and trying to make “the best one.” With a little luck, the malcontent employee walks out of the round table with two things: 1) a sense of having been engaged in the decision making process and 2) a new appreciation for the complexity at hand, and the decisions that have been made.

3. Make it clear that it’s a team effort

A one-on-one discussion goes a long way. Spend some time with the individual and really try to listen, and understand what the problem is. Come up with some mutual objectives — some things for the individual to work on (these might be soft skills, such as being less negative) as well as some things for you to work on (these will be things to help ameliorate the bad attitude, such as making sure his opinion is part of the decision process). Make sure it’s mutual, and show some real effort here — there’s tremendous value in demonstrating how much you value each individual’s contribution. Work with the individual to address the problems and find solutions.

4. If all else fails…

If you still have a problem employee on your hand after making a sincere effort to fix the problem, you’ve got to make it clear that continued negative behavior will not be tolerated. You also need to be prepared, so document the problems. Keep a record. After some time, it will become a matter of reprimanding and giving specific, required objectives. This is the worst case scenario and more often that not, the first step toward losing an employee. Sometimes it’s a “wake up call” to the individual, but often this kind of heavy-handed approach just feeds the negativity. Be prepared for either outcome.

Wayne McHale was a senior manufacturing executive when he heard reports that one of his branch offices was getting fed up with the arrogant, condescending attitude of a new manager. He decided to pay a personal visit to the office and put an end to the situation right away. “I made it absolutely clear that while we were delighted to have him on the team, certain behaviours could not be tolerated in a team environment,” says Mr. McHale. “He was taken aback, initially, because I think the behaviours were somewhat ingrained. He was a star and had been told for too long that he was wonderful.”

Whatever the case, make sure you have a good documented history. You can use it when talking about the problem with the employee, making sure you have concrete references to poor behavior. In the worst case situation, you can also use it to back up termination papers.

Above all else, don’t be an enabler

Some organizations actually nurture bad behaviour, according to Lew Bayer, president and CEO of Civility Experts Worldwide. For example, an all-star employee with a primadonna attitude may be tolerated because a manager decides it’s too costly or too much hassle to seek a replacement. Or perhaps certain rules may not apply to someone who has formed a friendship with a senior manager. In situations like this, it’s often the boss that’s the problem.

You can’t avoid dealing with workplace performance issues — it will come back to haunt you in the long term. Perhaps other employees will get fed up and quit. The problem employee might have a temper tantrum in front of a client. It’s hard to predict but one thing is almost certain: It’s going to happen at the worst time, when stress is high and a lot is on the line. Ignoring the issue won’t make it go away; it will just get worse.

Don’t wait until the problem becomes a problem for everyone. Be proactive, and recognize that the workplace is above all a place for professionalism. If your star performer is worth keeping, coaching can help. If your disaffected team member needs to feel involved, a few changes can make that happen. But, only if he’s open to the idea. If not, it may be time to take more direct action in order to preserve the integrity of your team.

When there’s a freeloader on your team

According to extensive research The Gallup Organization (Washington D.C.) and Harvard Business Review have conducted over the past decade, few factors are as corrosive to employee engagement as a colleague who skates through the workweek taking advantage of the much harder work of others. What’s the cost of disengagement? Much more than any manager wants to pay. Thanks to Clarity Technical Communications we can read all about it in the Harvard Management Update, When There’s A Freeloader On Your Team.

Hiring for the culture

Hiring the right people means more than identifying good technical skills. A person’s resume can be outstanding, but it won’t matter one whit if personalities clash or new hires just don’t mesh with your culture. As Dan McCarthy writes in How to Hire for Cultural Fit, “It’s not what you know, but how you fit in the culture that results in accelerated performance.” He points out that first and foremost, you need to assess your own internal culture, decide whether your goals include changing that culture, and proceed accordingly. Everyone that joins the team changes the team dynamic: Are you hiring to sustain your culture, or looking to alter the team dynamic?

Fix your boss (or, reduce risk to quality using a matrix approach)

How do you ensure that one person doesn’t derail your entire project? Most of us have been there before, unfortunately. Maybe it’s a co-worker who doesn’t work well with the team. Maybe it’s your boss, who has to oversee every single decision even though he’s an overtasked bottleneck. Either problem poses a critical risk to your project: Delays, mistakes and rework because one person isn’t part of a streamlined process.

Probably the most difficult situation is the latter — a boss that’s too hands-on, or perhaps an external resource that is too busy, yet absolutely must approve every decision. The story usually goes something like this: He’s a great guy, pretty easy to get along with when it comes right down to it — but he’s also insufferably “hands-on.” He’s just got to review every critical decision, contributing, fine-tuning and tweaking until it’s just right. This micro-managing mentality is causing all kinds of bottlenecks: Decisions are held until the last moment, changes are made late in the game, and your entire department suffers — staying late to “catch up” after your boss delivers his final word on any given issue. But here’s the real kicker: He’s good at what he does, and even though it creates internal chaos the finished product is that much better for his input.

QS1Consider the image to the right: A critical “quality spike” representing the single project resource that is overloaded. This resource does raise project quality, but the spike also represents a huge bottleneck to the project.

Your department has tried everything: Getting him involved earlier in the game (it doesn’t work, his schedule is booked and it always presses to the last moment); Involving other review sources so your boss’ input is minimized (that helped a bit, but the other sources don’t like it when your boss overrides their contribution); You tried publishing the “departmental cost” figures that show all this inefficiency (but the powers-that-be seem to feel this is “just the cost of doing business”).

This is not a simple problem. It gets right to the root of the dynamics created in working teams. How can the situation be improved, realizing positive gains in a habitually entrenched process that some recognize as painful, but overall is regarded as good enough?

There are really two issues that need to be dealt with here. One is obvious, one perhaps a little bit less so. Most strategies up until now have focused chiefly on the primary goal:

“How can we minimize the negative impact of a critical resource (our ‘hands-on boss,’ for example) that doesn’t work efficiently with your team?”

The problem with this approach is that it attacks an entrenched problem head-on, and often does so using a single head-on approach to solve the problem. When an attempt fails, that approach is discarded and another tried. The principle flaw here is that each attempt to solve the problem is, in and of itself, not effective enough to get the job done. A secondary flaw is that each separate attempt tends to get lost in the chaff of day-to-day operations. We all know there’s a problem, but nobody is really tasked with studying it, compiling the entire scope of the problem and its impact, and somehow bringing about a solution.

For example, when your department produced some figures on costs to the organization, those figures clearly showed that, through inefficiency, rework, and last-minute changes, your team suffered. You even went so far as to tie it to actuals, a dollar figure that represented all that overtime and rework — but, it was accepted as “the cost of doing business.” Since it didn’t work, it was discarded — but the fact is, it’s only part of the overall puzzle.

So the head-on solution won’t work. Let’s consider a more subtle approach to the problem:

“How can we make the critical resource less critical?”

This would achieve the same result, but it’s really an entirely different problem — one that can be attacked somewhat obliquely. Rather than focusing on how to change the way your boss works (aka “the critical resource”), try focusing on changing what your boss needs to work on.

The first step toward a solution is realizing that solving this problem is a project, just like any other. It needs a project lead and sponsor. It needs to be handled as an iterative project, and the team needs to recognize that incremental improvement toward an ideal is acceptable. You aren’t going to discover a single silver bullet that solves the whole problem — that’s just not the nature of human team dynamics.

Make it a project initiative

Once your “quality improvement project” is up and running it will snowball. Here are a few steps that will get the ball rolling:

  1. Initiate the project. Don’t think of this as a “workplace problem” that needs to be fixed in the short term. Instead, create a project initiative around it and get some mindshare going. Someone is going to need to lead the project, even if it’s unofficial — that person will keep the forward momentum.
  2. Focus on making many small improvements across the board. For example, in the case I described above, consider how involving other review sources did in fact help, but not always. That’s an incremental improvement, and it raised the quality of the project a little bit.

QS2Now, consider the impact of this approach over time. If numerous improvements can be implemented, and each one raises project quality just a little bit, it has an inevitable outcome: Your boss is going to have less to worry about, and less to be involved in. This is shown visually in the second image — as the overall quality matrix delivers improvement across the project, the “critical spike” that represents your boss’ workload begins to shrink. This is a quality matrix at work.

The goal is simply this: Dilute the need for your boss to be involved in every decision, by raising the bar in as many places as possible. You will gain a “double whammy” by not only reducing the amount of work he needs to contribute to, but also by increasing his own efficiency since he’ll have less to worry about. The bottleneck will begin to dissipate.

Assemble your team

Get involvement from everyone that’s affected by the problem — your team, your peers, other departments that might be affected. Of course, part of the finesse in this kind of project is to make it clear exactly what problem you are solving without making the project sound subversive or offending the wrong people. Your boss may be a terrible bottleneck, but also remember how valuable he or she is — this isn’t about cutting him out of the picture, going around him, or changing policies you don’t like. It’s much better to focus on things like qualitative improvement, streamlining projects to avoid inefficiency, or developing lean principles. Make it positive, in other words.

Identify key risks

Your probably already know what the main pain points are. Your team experiences them all the time: Loss of productivity, overtime, last minute changes, introducing new errors, reworking something that could already be finished. These are the lesser symptoms of an endemic problem: What are the potential risks if the problem goes unaddressed? Certainly continued loss of efficiency, higher expenses to the company and lower employee satisfaction come to mind. Perhaps there’s even a trend of some team members transferring out of the department to find a better working environment. More dramatic effects can include missed product deadlines, problems with released products or lowered perception of the department’s attention to quality. All of these can have a real financial impact on the company.

Identify those risks that are most significant. Those should become the focal point for initial improvement. This is a “risk driven” model, where high risk is identified — in other words, the most painful or potentially painful result of the problem gets the most attention as early as possible. Generally it’s best to tackle a few things at a time. While the list of risks could be very long, if you try to solve every problem at once it’s going to be overwhelming.

Mitigate

Once you’ve identified the top few risks, pull together your project team and identify candidate solutions. You’re designing something new here, so it’s going to seem like brainstorming — which is exactly what it is:

  1. Can more attention from outside experts improve the overall product, lowering your boss’ need to be involved?
  2. Would the quality assurance organization be a helpful partner in achieving this?
  3. Could changes in the project timeline better accommodate your boss’ hectic schedule? Perhaps driving for earlier involvement (or longer project schedules) would help.
  4. Can the team multitask, effectively putting several critical paths into play so that if one gets stalled waiting for your boss, the others move forward?
  5. Would better tracking systems and information management help solve the problem? Perhaps your boss would benefit from a system that brings more organization and immediate answers directly to him.
  6. Perhaps greater visibility into the project timeline and reasonable deadlines would both improve responsiveness and provide some firm schedule guidance.
  7. Information radiators (such as task boards, timelines and assignment lists) might help keep people up to speed on overall project status (and what has moved from “medium” to “high” priority).
  8. A widely accessible system that assigns tasks and prioritizes those tasks would increase visibility of current goals as well as get everyone united about what needs attention first.

Every organization is going to discover different solutions that help its specific situation. It will likely take time to hit on the first few steps that move in a positive direction — but those are the ones you want to hang on to.

Include a quality improvement element

Organizations that have the benefit of a formal quality assurance and improvement group should try to leverage the group’s knowledge. Quality assurance is about auditing and measuring progress toward improvement. Most quality assurance groups tend to be very good at measuring improvement over time, and putting that knowledge to use will help in gathering metrics and identifying what’s working, and what isn’t.

Track your progress

Measure, act, measure again, and adjust. This is the heart of most agile development methodologies — and most scientific methods.

The most important thing to do is realize when improvement has taken place. That means tracking information — metrics — about your organization’s efficiency. This can seem pretty amorphous when dealing with a problem such as this. Remember that it comes down to improved efficiency of individuals. Some teams will have simple metrics that are easy enough to track, such as number of projects completed on a monthly or quarterly basis, or number of cases filed. When all else fails, the number of hours committed to rework is a great metric, because it tracks directly to risk identification and mitigation up front. That is, if you properly identify a risk and mitigate it early in the project, the amount of time spent in rework related to that risk goes down.

This is one reason it’s important to have everyone affected by the problem involved: It’s going to require everyone to look for these signs of improvement. It might even require tracking hours spent in rework. Fortunately, with the goal in sight (less time spent reworking and fewer overtime hours) it shouldn’t be too hard to commit people to some moderate tracking.

Gather metrics on what works and what doesn’t work. Emphasize incremental improvement as a desired outcome: Track the results of each effort, and keep the best practices. The important thing here is to demonstrate improvement over time, so that everyone sees each action as contributing to the solution, not as a failure in delivering the end result.

One of the most important goals in creating a project mentality is the positive group effect. Seeing each practice as part of a solution keeps it alive — as opposed to trying something and perceiving failure. As the team, department or company works together to deliver a solution it becomes a self-reinforcing effect. Even your boss might notice, and actively start to take part.

Why heroes are bad

Most project leaders have been there before: The hero saves the day, yet again. Everyone is grateful because, obviously, if not for the hero the project would have crashed and burned. It seems so lucky that the team can benefit from this all-star who pulls the project out of the fire time and again. What would we do without him (or her)?

Indeed, a good question: What would we do without the hero?

Let’s flash forward a little ways. The hero has grown tired of the project and leaves. Fears abound that the project is doomed; there’s no way the team will survive without him. Concerns run deep, until the hero tells us he’ll stay on-board as a part-time consultant. Of course, he’s pretty busy these days — but, well, he’ll give us a “preferred” rate and show up at least a few days each week. He’ll keep the project afloat, no worries… in between getting his new company off the ground, of course. The one we’re funding with expensive consulting dollars. Either that, or the hero feels the project isn’t challenging enough, and leaves to greener pastures and more exciting projects, still promising to provide part-time support to keep the project afloat.

Either situation is dismal. Both demonstrate a project and a team that’s being held hostage to the whims of the “hero.”

The truth of the matter is simply this: Heroes are bad for the team, bad for the project and bad for the company.

Heroes are motivated by making themselves indispensable to the project by becoming irreplaceable. Most often this takes the form of information hoarding. The hero understands quite well that the established culture supports his role only while he and he alone can solve the project’s problems. One of the most effective ways to make sure this happens is to keep critical information away from the team. He’s the only expert in a few critical areas, and refuses to share his knowledge because it would be inefficient or too difficult to convey to someone else.

This leads to situations where the hero is subtly motivated to make sure there are instances in which only he can save the project. By ensuring the hero is the only one with the answers, the only one who can solve the problem at hand, he becomes indispensable — and, also, a tremendous project risk. Not only is everyone on the team constantly put in second-place to the hero, they also suffer as a whole when the hero is at his best. In times when the hero “shines,” the team is struggling to overcome roadblocks they haven’t been prepared to deal with. The project falls into jeopardy because the team cannot focus on a solution as a whole. Instead, the team churns in vain trying to contribute to the solution that only the indispensable hero can tackle.

Consequently, team morale is often a casualty of the hero culture. The continued failure of the team to exceed project goals, instead running into roadblock after roadblock, is tiring. Compound this with the fact that only one person, the hero, is enough of an over-achiever to solve the problems of a seemingly over-ambitious project and the team begins to become demoralized. Nobody likes to come face to face with failure repeatedly. Doing so in an environment that doesn’t provide the tools to better oneself is futile, and the hero team leader is certainly not motivated to fix the situation. In point of fact, most heroes tend to be pretty lousy team mentors, as being a hero implies putting oneself above everyone else. This means that while the hero has holed up inventing the next great solution, the team is left to its own devices. This vacuum of leadership provides a poor environment for anyone interested in advancing their skills and career, let alone seeking out a workplace that provides opportunity to learn.

Environments that support the hero become detrimental to the team. With the team leader focused on fulfilling the role of hero, collaboration suffers. Without a truly open, collaborative, information-sharing environment projects function at low efficiency (or, in some cases, fail to function completely as information is silo’d and isolated). In contrast, a healthy team elevates everyone, sharing information and skills, making the hero obsolete and making the entire team indispensable. A collaborative team rapidly turns into a formidable force when its collective attention turns to any problem — such teams turn out productive results faster and more efficiently. Each individual’s growth becomes a focal point, and the positive experience and knowledge gained from such a working environment becomes a lesson that each team member can share. In an open, collaborative, delegating environment the team lead will mentor the team; constantly challenging each person to take on more responsibility and grow into new opportunities. The best team leads are not information hoarders but information sharers, almost trying to engineer themselves out of the equation by teaching everything they know. In fact, this kind of leadership becomes truly indispensable because so few people are able to teach, motivate, mentor and unify a group of people toward a single purpose effectively. It’s not the information hoarded in the team lead’s head that makes him invaluable, it’s his ability to create a hyper-productive team and get things done.

As a project leader it’s important to confront the hero mentality head-on, making it clear that a hero is known for what it is: A detriment and risk to the project. Heroes are a liability. They are a bottleneck to progress, introduce the risk of “hostage projects,” generally make poor mentors and leaders, and always create specific situations that are harmful or dangerous to the project.

Unfortunately, putting an end to hero culture is often not an easy task. Many workplaces that embody hero culture don’t understand the problem — they think everything is “just fine,” and look to the hero as a critical resource, someone that has saved the project or the company time and again. Especially in young or inexperienced organizations, the difference between a supportive environment and a destructive one is unclear. The hero continues to operate above and apart from the team, often disregarding what little authority or direction he disagrees with. Inexperienced team members don’t know they should have a team lead that is mentor, guide and teacher. Organizations can be set up in such a way that the hero figure is empowered beyond reasonable boundaries, as often happens when clear structure and accountability is not in place. Combined, these problems can create the environment where a hero-mentality, embodied in someone who is ill-suited to create unity, lead, and mentor, ends up holding the project hostage. Most often, the evidence will point to the root problem: The team will constantly run into problems only one person can solve; team members will disagree with the hero and often not achieve consensus; much of the team will be “out of the loop,” particularly where the hero is involved; overall, the team will operate either apart from the hero or as individuals, not a cohesive group. Perhaps most indicative: The hero has sole authority over the project, yet little accountability. This is common in so-called “flat” organizations. I tend to avoid organizations that strive to be “flat,” as it’s really just a way of saying “we don’t want to deal with the fact that someone has to be in charge.” The simple truth is that leaders and managers need to have the authority to implement policy. Good leaders and managers will find ways to do it without using their authority unless necessary.

The easiest way to fight hero culture is from a position of authority, such as the project sponsor or project manager role. Given the advantage of authority, the hero can be given a choice: Either become a collaborative leader, or face what amounts to demotion as a new leader steps in. Some heroes won’t be able to make the right decision and will end up leaving the project — but others will embrace the idea of transforming themselves into a positive influence. I’ve seen this happen in a few cases and can honestly say the results were extraordinary. It could be that your hero’s spirit is willing but he doesn’t recognize there’s a problem. Likewise, it could be that your hero is struggling to move into a management role and needs guidance himself. Sometimes you’ll find out the hero was thrust into a leadership role without wanting it, and will happily step aside.

Whether tackling the problem from a position of authority, or from the inside, there are a few strategies that will help to ease the process. Developing a collaborative environment is a first step at ending the hero culture. This means putting in place tools and processes to share information, including an open information environment. Get information out of everyone’s head and into a tool that facilitates group review and commentary, such as a wiki or document repository. This can begin by emphasizing brainstorming sessions, collaborative documentation and group exercises to design and implement solutions. Often group development can be a productive tool, as well (some environments, such as Extreme Programming, push pair programming as one example — I don’t believe pair programming should always be put in practice, but this is a good example of when it makes sense). Project deliverables should also be managed in an open, collaborative environment. Use a project or task tracking system that lets everyone see what’s going on, what’s being delivered and how it’s being done, and most important: Focus on shared responsibility and avoid having unique specialties in favor of collaboration.

The team should also push for opportunities to advance skills and individual knowledge. Avoid “information silos,” or individuals who hold all the answers to a specific problem. It’s healthy for teams to have more than one expert in an area. Not only does it reduce risk, it also affords a more collaborative environment where two or more people can openly discuss a solution and work together on implementation. Any time you hear “only one of us knows how to do that,” immediately think in terms of how you can turn one into two or three people.

Demand a leader that is a good mentor. If the team hero isn’t up to the job, find someone who is — and be vocal about wanting an environment that supports growth. A healthy work environment includes ample opportunity to take on more responsibility. Any project manager that hears you want the responsibility will start casting about for a means to give it to you — and that usually means making sure the team leader can advance his team.

Ultimately, your work environment is in your hands. If you’re aware of the problem, identify it and and surface it — but do so in a constructive way. Have ideas and solutions ready to solve the problem, and emphasize the value it will bring to the team or organization. Focus on the facts as much as possible, like productivity gains the team will experience when it has greater bandwidth, and how getting to market more rapidly (and probably with a better, more robust product) will boost return on investment.