On Being A Rubber Band
For most of my career, I have worked in “multidisciplinary” organizations. My teams have been built of people with backgrounds in engineering, design, human factors, science, manufacturing. I’m an electrical engineer by training, and have spent a lot of time in software; if you force me to pick a major, I’d have to say that I’ve done more software development than anything else. But that’s like saying a builder’s job is hammering - “software” is a tool, and doesn’t begin to scratch the surface of what I actually do.
It is popular for organizations to seek out “T-shaped” people, which is to say, people who have concentrated deeply on some subject but have a broad, less thorough, set of skills and knowledge in other areas. This idea was popularized in the 1990’s by IDEO, the same people who brought you “design thinking” and other buzzwords. On the face of it, T-shaped people are exactly what an organization needs if it wants diversity in thought and a “holistic” (bzz!) approach to developing a product or service. If the mechanical engineers only think about mechanical engineering and the graphic designers only think about graphic design, we end up with a product that doesn’t feel like one piece. We spent the ’90s and ’00s getting away from that in the product development world - the days when the industrial designer would draw a picture of a product and then “throw it over the wall” to the engineers so they could figure out how to build it are, ostensibly, behind us. By hiring T-shaped people, then, you can hope that everyone will understand everyone else’s job, at least a little, and so the work product will benefit from enhanced communication between the members of the team, increased sensitivity to considerations outside one’s own area of expertise, etc.
But an organization of “T” people is an organization of people who are focused on their area of expertise and who know a little about everyone else’s areas of expertise. That isn’t enough. It looks like a starfish - everyone owns their own arm, and the might get together in the middle, but the main focus for each arm is…the arm. And you can’t get arm #1 to really care about arm #3. Like the body of the starfish, the members of the team might have an “interface” where they talk to each other but what happens out on the arms - where the work happens - is opaque to each other.
What I really do is bind together a team not at their interfaces, but in the middle. I am not an expert in mechanical engineering or biology or marketing, but I have built a career on knowing enough about each of those things to be able to have a detailed discussion and to understand what’s interesting and important to someone in those fields. I don’t even always know why it’s important, and I don’t need to. What I need to do is note that when two areas of the work have a common interest that they don’t know is common, and get them to talk to each other. It shouldn’t be a startfish with a bunch of disciplines meeting at their ends; it should be a bunch of asparagus with me as the rubber band tying them together in the middle.
Sometimes it puts me in a translation role. I can remember several projects where my entire contribution was just sit with, say, the electrical engineering team and marketing team, and just go back and forth. Here’s what the marketing team wants, in engineering language; here’s what the engineers can deliver, in marketing language. Generally, engineers think the marketing team is annoying, and marketing teams thinks engineers are probably lying about what they can do. Having me in the mix keeps everyone honest and moves things forward faster.
What do you call a role like mine? “Integration” doesn’t really capture it for me. “Architect” has implications that aren’t quite right. I was once described (in a performance review) as “spackle” - as in, “I don’t know what he does, but it fills a lot of gaps” - but that’s not what I’m looking for. “Systems engineer” isn’t it, either - even though the job is often decomposing the problem and bringing it back together, “Systems engineering” is a formal discipline with specific tools. My job is… puppet master? Go-between? Krazy glue? Rubber band.