WDR on team composition
By Richard CrowleyThis is a story about a course I took during my junior year of college from Dr. William David Richard (WDR) at Washington University in Saint Louis.
The course concerned computer hardware design. It was the pinnacle of the Computer Engineering degree program and it was organized around a single project. The “midterm” exam came merely three weeks in. In those three weeks during lectures we became acquainted with USB, Hann windows, the ultrasound probes we’d be using, and just enough digital signal processing to do the project. The balance of the semester was spent working as teams in the lab.
WDR’s technique for composing teams was to sort the students in the class by their score on the midterm exam. The top two (because the number of students did not divide by three) formed one team, the next three formed another team, the next three another team, and so on.
Higher-scoring teams gravitated towards elegant designs that cleverly used our FPGAs to lay out small, high-performance circuits. Lower scoring teams gravitated towards brute-force designs that integrated readily available hardware implementations of the square root function and other mathematical primitives, resulting in large, high-latency circuits. Higher-scoring teams were likely to prototype a few ideas and throw some away. Lower-scoring teams were likely to slog slowly and steadily in a straight line.
Every team got something to work.
If you’ll allow, for a moment, a tenuous analogy between being on a higher-scoring team in this course and being a more senior member of an engineering staff, there’s a lesson to be learned.
First and foremost: Achievement is possible almost no matter what. Higher-scoring teams spent a lot of time arguing about the best way to do it. Lower-scoring teams spent a lot of time searching for any way to do it. And every team got something to work in the time allotted.
We could end the story here and say the moral is that team composition doesn’t matter. But it wouldn’t make sense for a company to task two or three of their most senior engineers on a straightforward project. They’ll sit around and argue about the best, most elegant, most future-proof, most conference-talk-worthy way to do it. It also wouldn’t make sense for a company to task two or three of their most junior engineers on almost any project. Yes, they’ll probably deliver and yes, they’ll probably learn a lot, albeit under great stress.
In college, a professor’s goal is for everyone to learn. At a company, though, the goal is for the business to succeed. Learning, and teaching, are techniques used to reach that goal. It’s typically expected that the senior engineers teach as well as learn. So instead of letting those junior engineers figure it out on their own, give them a mentor. With a mentor, their straightforward projects will teach them more and they’ll deliver faster, too.
Save stacking teams with your most senior engineers for problems believed to be (nearly) impossible. Set them to searching for any way to do it. Exploit their natural tendency to debate the merits of all sorts of different approaches, designs, and technologies. Use their skills and experience to break new ground and expand your business.
Even though pretty much any team can deliver results, suboptimal team composition is still a problem. It’s a problem when teams working on very straightforward projects take longer than necessary. It’s a problem when teams stacked with senior engineers are neither mentoring junior engineers nor taking moonshots. Most importantly, these problems are hard to notice because, again, everyone’s delivering results. But your competitor who composes their teams more thoughtfully is going to perpetually eat your lunch. They’ll get to market faster, they’ll innovate faster, and you’ll be left behind.