The Counterintuitive Secret To Fixing Broken Teams
If you manage a team that is struggling to perform, you know how frustrating it can be when nothing you try seems to work. Watching them flounder, at times you may feel powerless to help them. You’re reading tons of blog articles, watching videos online, and asking your friends and colleagues for advice. You’ve tried using incentives both positive and negative, friendly competitions and contests, and one hack-a-thon after another.
Nothing seems to stick. You can get their creative juices flowing under special circumstances, but it never seems to translate back to their regularly scheduled work.
If you’re like most managers , you were promoted into management because you were a good individual contributor with some seniority, and you more or less figured out how to manage on the job. Unfortunately, you’re probably hindering their progress more than you’re helping. Don’t believe me? Let’s take a closer look at the problem.
What is considered effective management has changed significantly in the last few decades. The way of the legendary corporate executive throughout the 1980s and 1990s was characterized by ruthless downsizing and cutthroat competitiveness. At some point after the turn of the 21st century, newer and more subtle methods of motivation were developed by leading firms. These methods, while counter-intuitive for a culture that traditionally praises hierarchy and the strong fearless leader, are nevertheless far more effective in leading groups that produce creative knowledge work like engineering and design.
In management guru Peter Drucker’s 1993 book, “Post Capitalist Society” he underscores the absurdity of modern managers who believe their job is to give orders. “In the traditional organization,” he warns, “most people called managers do not actually manage; they relay orders downward and information upward. When information becomes available [to everyone], they [managers] become redundant.”
This sentiment is resonant in a number of more recent reflections of modern management and its need to change radically, including “Turn the Ship Around” by David Marquet, “Team of Teams” by now retired general Stanley McChrystal, who headed up the task forces in Iraq and Afghanistan from 2003 to 2006, and “Drive” by Daniel Pink.
Marquet’s story illustrates Drucker’s point brilliantly. Marquet was trained to captain a nuclear submarine according to all the US Navy’s traditional methods and measures. This training was all thrown into the blender when, after studying the engineering details of his assigned ship for about a year, Marquet was abruptly reassigned at the last minute to a different submarine with which he was completely unfamiliar, staffed by a crew that was reported to be the worst-performing crew in the Navy’s nuclear fleet.
Faced with the daunting obstacle of getting the crew ready to pass an inspection in six months time and then be deployed into active service, Marquet threw all of his traditional naval leadership training at the problem to no avail. It was practically by accident and in desperation, as he told us during the conference keynote in 2017, that he decided to turn the naval command structure on its head. Instead of giving orders, and expecting them to be followed, Marquet asked his crew to do whatever it was they thought they were supposed to do next, proceeded only by the loud and clear recitation of the action preceded by “I intend to…” In this way, a commanding officer could listen to the intention and only intervene if necessary.
The results of this subtle change were truly remarkable, and the entire book is well worth your time to read. Not only did the crew manage to pass the inspection and get deployed on time, they also received some of the highest inspection scores ever recorded in naval history. What is probably more important, the turnover rate by which staff requested transfers to other vessels dropped dramatically, as no one really wanted to work on another submarine with another captain.
Marquet’s newly found management philosophy brought to life Drucker’s statement above, in that authority over actions was moved down to where the information was most detailed. As in the Toyota method of “Stop the Line” (the legendary Andon cord), workers most familiar with the source of a problem on the line are empowered to take actions to adjust, improve, and execute in the way they saw fit — even if they must stop work in the entire factory momentarily in order to do it. The level of oversight by superiors was appropriately scaled back to match the level of risk embedded in that particular decision.
Similarly, General McChrystal faced a problem analogous to Marquet’s, only on a much grander scale, during his period of leading the anti-terrorism task force in Iraq and Afghanistan, a tale he recounts in “Team of Teams.” Famed for their internal cohesion and teamwork, groups like Navy Seals and Special Forces found it very difficult to work together across departmental lines. Biased by the bounded context of their unique training and experience together, McChrystal was surprised to find it so difficult to get these disparate groups to work together, to share information in a timely manner, and to trust one another to execute.
The story in Team of Teams is fascinating from the perspective of a 20th century-trained corporate manager. The patterns of behavior described by McCrystal align perfectly with the dysfunctional in-fighting and group dynamics one experiences in any large institution (indeed, that’s much of his point for the book). As I read it, I substituted the Navy Seals for software engineers in my mind, for example, and the CIA analysts as the Finance department, and so on. One could easily imagine the litany of failed projects as these groups failed repeatedly to work as one larger team across the boundaries of their individual units.
McChrystal and others in his command gradually overcame this bureaucratic inertia by a series of maneuvers designed to break down barriers between departments. They instituted an exchange program, whereby skilled members of one team would serve for several months in another group. The intended purpose of this was to build cross-departmental empathy. They instituted a more open data sharing policy, and held larger joint briefings, exchanging the risk of a security breach with the risk of moving too slowly from lack of timely information.
Probably most impactful, as in Marquet’s example above, McChrystal began giving fewer orders. He encouraged a culture of taking initiative, cross-functional and collaborative problem solving, and making pivotal decisions on the ground during a fast-moving operation without waiting for approval from higher up the chain of command. Again, decision making authority was moved closer to where the action — and information — is.
This concept of moving decision making authority down to the information is very well laid out in Donald Reinertsen’s fantastic book, “Flow: Principles of Lean Product Development.” Reinertsen shows us how there is an optimal timing for all decisions based on the economics of the environment in which it is being made. Some decisions benefit from slow and careful deliberation. Others have benefits that degrade very quickly if not acted upon. In addition, there is a cost associated with the delay required to ratchet a decision up the chain of command. We certainly see this in most large corporate environments today, as we sometimes wait weeks or even months for seemingly simple decisions to be made by a superior.
Reinertsen recommends implementing decision rules, instead, as a way to decouple leadership from the burden of making all decisions themselves, while still transferring the logic of their decision making to their subordinates. Decision rules are basically the idea of “what would So-and-So do in this situation?” Leaders can delegate both their intentions and the heuristic measures they rely on to their subordinates, and then allow the teams to operate more autonomously. Indeed that’s what both Marquet and McChrystal accomplished in their respective contexts.
By no means is this new type of command structure limited to military contexts. In fact, according to some very influential voices in the school of organization psychology, literally any profession can benefit by increasing the level of autonomy.
Daniel Pink in his 2012 work “Drive” makes a compelling case that while external motivators, such as monetary incentives, improve performance in individuals and teams if the tasks required are rudimentary and mechanical, for groups employing cognitive skills and other kinds of creative work performance actually decreases when incentivized with money bonuses. The implications are quite impactful.
Pink isolates the core motivators for knowledge work as a triad of concepts that seem to optimize teams and individuals for peak performance. This triad consists of autonomy, mastery, and purpose. We’ve talked about autonomy a fair bit already, but the other two require some further examination.
Mastery for Pink refers to the desire of individuals to improve their skills for the sheer joy of getting better. Obvious examples might be sports or playing a musical instrument, but the same concept is in play for knowledge work. Software engineers desire to become better engineers, as do designers, lawyers, and statisticians. What the data tells us is that professions that involve a large quantity of cognitive load and problem solving attract people who have a great deal of intrinsic desire to improve without any external incentives being necessary.
Purpose is deeper still. The central driving performance factor in Pink’s research is having a clear and consistent purpose for our work. In short, a clear goal. Teams that have goals that are clear and concise nearly always perform better than those who have inconsistent or ambiguous goals.
This combination of autonomy, mastery, and purpose parallels the earlier work of W Edwards Deming that led ultimately to the creation of what we now call Lean, the core value of “respect people” that underlies of the Toyota Product System, and the self-organizing teams of Agile software development methods like Scrum.
So what is a manager to do, then, to encourage this notion of autonomous teams with clear goals and a desire to master their individual and collective skillsets? Here are some suggestions:
Define A Clear Goal For Each Team
The biggest obstacle for most teams is a lack of a clear, measurable goal. Make sure that everyone on the team knows what the goal is for the short and long term. Goals should be aligned with the company strategy, not just plucked from the air. Allow the team to provide feedback on how their work priorities seem to align (or not) to the goal. Ruthlessly cut any work that isn’t moving the team toward the goal.
Make Your Workflow Pull-Based, Rather Than Push
Teams have a fixed capacity — an amount of work that they can safely complete in a fixed period of time. And you cannot change it; only they can. Measure and publicize your teams’ capacities. Then, allow them to pull work from a queue as team members become available. Do not simply assign tasks or pile on more work because it “must get done.” A pull-based system (which not only Toyota, but also both Scrum and Kanban Agile methods employ) is a good way to enable the team to work at full capacity without burning out. Then, apply regular retrospectives to discover how the team can carefully and incrementally increase their capacity.
Prioritize Self-Improvement And Learning
Invest heavily in building up the skills and capability of your individuals and teams. Make sure that each person has a clear professional development path defined that includes long and short-term goals. Enable them to incorporate skills-building tasks into their regular work, and also allow for external training and resources outside of normal work. If possible, encourage them to do talks and write articles themselves. Nothing helps learners more than having to teach something they are learning to others.
Define Decision Heuristics, But Delegate Actual Decisions
As Reinertsen notes, the cost of centralizing all decisions can be detrimental to organizations in terms of the flow of value to customers. Instead, develop broad decision rules or heuristics that you can provide for your teams so they can make most decisions themselves. These guidelines tell them “here’s what I would do” for most cases where they’ll need to make a decision. Then, step back and trust them to make those decisions. You can always include special cases in the decision rules where escalation of a particularly impactful decision is warranted.
If you’re in need of more help, schedule some time to talk with me about your specific case.
