Chapter 31. You’re the lead, not the know-it-all
One of the traps team leads encounter is the need to know it all. It doesn’t matter if you’re a team lead of 3 people or 30 people; you became a team lead because of your technical skill, right? That must mean you’re pretty smart, and you’re supposed to lead, right? You’re supposed to have lots of great ideas. You’re supposed to know lots of things. You’re supposed to be able to solve lots of problems. Well, that doesn’t mean you have to solve every problem yourself.
Many years ago, when I was a technical lead, I was also the project manager. We were a three-person project. I was the team lead, Andy was my junior person, and Mark was my mechanical engineer. We were working on a machine vision project back in the mid-1980s, when cameras were able to collect up to eight bits of data per pixel. That’s not megabits; that’s only eight bits.
Andy and I were working on the software for gauge inspection. Mark helped us by creating the gauge holder. Yes, it took three to implement this project. The gauges were similar to the gas gauges or mileage gauges in cars back in the ‘80s; they were orange lines against black backgrounds with other white markings at regular intervals. Our job was to detect the angle of the orange line on the gauge.
With today’s cameras, this isn’t a difficult problem. With the cameras of 1984, the problem was huge. We needed to light the gauge precisely. We needed to know if we were picking up the orange line, not the white markings. With only 8 bits per pixel, and the computing power back in 1984, you can imagine our problems.
I’d started developing the algorithms and asked Andy to continue, but the calculations weren’t 100% reliable. We were doing a code review when Mark asked about the gauge holder. He listened for a minute and asked some questions, and soon we were discussing whether the gauge holder should hold the gauges sideways or straight up.
I no longer remember the resolution, but I do remember the power of the discussion. When I relinquished power as the only technical lead, everyone’s problem-solving skills came to the fore. Everyone engaged in solving the problem. Everyone grew excited.
We finished that project successfully. I suspect Andy’s solution won, which is why I no longer remember, but that’s the value of technical leadership—to facilitate the team to the best solution, not your solution.
Did I know it all? No. Did I know enough? Yes. I knew enough to start problem-solving and facilitate the rest of the team.
Team leadership isn’t about knowing everything and doling out information and solutions. Team leadership is about creating an environment in which everyone can flourish to the best of each person’s ability—including you.
Loosen the reins on your team. You, too, will grow and flourish. That’s the lesson I learned.
Roy’s analysis
This powerful note, in the greater context of this book, deals with a couple of ideas.
Being the bus factor
By establishing yourself as the sole tech lead, you become the main bottleneck for decision-making. You also turn into a bus factor. Without you, the team can’t function, which is a huge risk. Yes, technically maybe they could function, but they might grow afraid to function without you because they’re used to you approving all decisions. If you’re gone for a week, things will slow to a crawl in the decision-making space. This is also an example of the environmental motivation influence force at work. People will feel less comfortable making decisions because they think their leader expects them not to make decisions on their own, which might hurt their career.
Coaching vs. command-and-control leadership
Not only are you becoming a bus factor, you’re also not coaching, but “telling.” If your team wants to learn new things, or feels they could handle making decisions without you, but you keep insisting on your own ideas, that might fly for a while during survival mode; but in learning and self-organization modes, you’ll start losing people fast.
JOHANNA ROTHMAN, author of the Pragmatic Manager newsletter, helps organizational leaders see problems and risks in their product development, seize opportunities, and remove impediments. She’s the author of several management and project management books. You can read more about Johanna and find her blogs and her writings at www.jrothman.com.