Prominent among the legends of World War II is the Black Sheep Squadron, a gaggle of rag-tag fighter pilots led by Maj. Greg "Pappy" Boyington. Against all odds, the Black Sheep were the scourge of the Pacific Theater, and their legend grew until it found its way to prime-time television, which is where you’ve probably heard of them. But they were no television writer’s fantasy; they were real.
A team like Boyington’s Black Sheep doesn’t happen by accident, especially not under the conditions rampant in war. The success of the squadron ultimately comes back to Boyington and his leadership methodology. The surviving Black Sheep pilots have recently spoken on record, elaborating on that methodology.
The Black Sheep were all but unmanageable: rugged, unruly individualists who hadn’t fit in well with other squadrons. Boyington not only managed them, but he molded them into one of the outstanding fighting machines of the war with three simple practices. He did some subtle social engineering; he rotated flying assignments constantly; and he flew alongside his men.
And so should you as you are crafting your development team.
Flying in formation
Foremost in Boyington’s management philosophy was the realization that flying well in formation begins on the ground. It’s easy to teach pilots the concept of maintaining a position and a function relative to other planes while flying. But the most important point for Boyington, or any manager, is in understanding the configuration of the team when it isn’t in flight. How do team members communicate? How are knowledge and experience distributed? Who needs more flying time?
Black Sheep survivors today recall how Boyington gently mediated their interaction. When it was apparent that several of the pilots were getting chummy to the point of forming their own "crowd," Boyington would take them aside and suggest the inclusion of a newcomer, or place one of the ringleaders in a mentoring role with an outsider. While this may seem like some form of egalitarian social engineering, Boyington had a more practical goal in mind: that each man give optimum support to all of his fellows, not just those he happened to be chummy with. The result? On the ground, there were no loners, and in the air, his Black Sheep were fiercely protective of one another.
The same is true for your development team as social and communication barriers are torn down. The team members will trust each other under pressure.
Who’s got your back?
Pappy Boyington didn’t believe in the dominance of an individual style at the expense of the team. He mixed, matched, and rotated assignments freely, so that any pilot could be flying alongside someone new at any time.
What happens to "style" in such a system? Well, style goes to hell, where it ought to go in a non-competitive environment. And your team should be a cooperative environment, not a competitive one. The members of your group shouldn’t have self-expression as their primary goal; they should be focused on a shared vision.
When pilots are in the air, flying alongside someone they don’t fly with every day, their awareness of each other’s progress must be heightened in order for them to be effective. They react from that awareness, not with cultivated knee jerks. It should be the same with your team.
Here’s an example: your system programmer is a guru on a mountain, utterly knowledgeable, utterly wise. He’s worked with your lead analyst a great deal, and the two of them know each other well enough that they don’t have to explain themselves with much articulation. They know each other’s style.
But you don’t want to send other pilots into the air with these two. Why not? They know their jobs inside out, don’t they? They have a lot of knowledge and insight to share, don’t they? True, but they’re not sharing it. Worse, they are losing their articulation: They never have to explain their ideas or their work with clarity. They have fallen back on style.
What would Boyington do? He’d put a less-senior analyst alongside the system programmer on the next project team, where both would do the necessary, skill-sharpening work of communicating effectively. He’d send his senior analyst to systems school, if only for an overview, to eliminate the crutch of the shorthand between the analyst and the system programmer.
Mixing and matching your team members may have minor time costs, but you can only benefit in the long run. Each of your people will know the rest of the team much better, communicate more effectively, and take more care in presenting ideas, because those ideas will emerge less reflexively and with more forethought. You’ll be creating an atmosphere that is truly cooperative, less competitive, and less dependent on style.
Fly with your squadron
Pappy Boyington flew with his men. It was his job to lead, not simply direct. He knew all too well how the pilots taking the risks felt about the generals who called the shots. Resentment and resistance build quickly in those who lay themselves on the line, when they can see that their dedication isn’t shared.
Put on your flight jacket, strap on your helmet, and climb into the cockpit. Of course you don’t have time, but do it anyway. Carve out a piece of your team’s project for yourself. Don’t take anything away from anyone else; take the piece nobody wants. It doesn’t have to be huge. It could be something that will only take a couple of days over the next month. But it’s time well spent, because your team will see you in the air with them, and they’ll feel the camaraderie at the next project meeting.
Choose a wingman. Work with another team member. It can be a mentoring opportunity, allowing you to offer a little guidance to an up-and-coming analyst. Or it can be an educational opportunity, where you ask for some overview knowledge of some software or system you don’t know well.
One response to this idea might be, "I can’t do hands-on work—my authority will suffer." That would probably be true if you were a general sitting with other generals at Pearl Harbor. But you’re one of the people who gets the mission accomplished. You and your team aren’t planning the war; you’re fighting the battles. Sharing the burden at the nuts-and-bolts level, even as a symbolic gesture, doesn’t cost you a thing if you do it correctly. Your team won’t resent you; they’ll be pleased at your willingness to be on their level. You’ll find, in many cases, a greater openness and better communication all around.
More missions, fewer losses
Boyington’s management methodology comes down to a single principle: heightened awareness. His practices kept team loyalty and communication at a consistently high level and required every member of the squadron to pay close attention to every other member. It brought out the best in him, as well, because in order to make it work, he had to remain vigilant in his assessment of his pilots and their progress. Reviews weren’t periodic; they were ongoing.
The results were a legendary success rate and mercifully minimal losses. And isn’t that what every manager is shooting for?
Leading the troops
What do you think of Boyington’s approach? Would it work for your team? Tell us what you think or post a comment below.
Scott Robinson is a 20-year IT veteran with extensive experience in business intelligence and systems integration. An enterprise architect with a background in social psychology, he frequently consults and lectures on analytics, business intelligence and social informatics, primarily in the health care and HR industries.