Insights · Stable Collaboration · Video Transcript

How to Lead as a Senior Engineer Without Becoming a Manager

Transcript of the video Leadership for Technical Individual Contributors.

Prefer to watch? Leadership for Technical Individual Contributors on the Neuvero YouTube channel.

This article is the transcript of a spoken talk. The brain and behaviour mechanisms described are simplified for a general audience and are not clinical guidance. Sources for the research referenced appear at the end.

I love working with technical folks. They can be insightful, productive, cynical, and hilarious, but as you grow more senior, things get harder. Here are three big reasons. Number one, it's always easier to do it yourself than to mentor or delegate to someone else. Number two, meetings, especially with managers and non-technical folks, feel like a complete waste of time.

And number three, it's frustrating when others don't share your point of view or just don't get it. The problem is that no matter how smart or productive you are on your own, it can only scale so far. Getting results through others is the only way to get more done. I'm Floyd Kelly, former software executive and founder of NEUVERO.

Getting results through others doesn't mean you have to become a people person. Or spend all day drawing lines and boxes, or live in Slack, you can still lead through code. Think about it. If you build an API or a module that other developers adopt instantly.

You've just multiplied your brain power by enabling others, but writing all the code yourself, that's just not gonna scale. You need others rowing in the same direction. Now that doesn't make you a manager. Somebody else can worry about the schedules, the performance reviews, and the cross org politics, but your manager can't mind meld what's in your brain into someone else's.

That job is gonna be on you. One way of thinking about this is to productize and package your ideas, so others can use them. Here's three things you can do. Number one, rigorously, document your solutions in a public place and keep them updated. Number two, record short videos walking through your designs.

Number three, talk to your customers, other architects and developers, understand their questions and concerns, and then update your documents and videos to respond. It sounds simple, right? But here's the catch. Humans, our brains are all wired very differently. And that makes communication messy. That's where a little neuroscience can help.

Here are three techniques you can use. Number one, repetition builds reliability. So most brains don't learn from hearing something just once. Neural pathways strengthen only when they're activated again and again. That's why great teachers repeat themselves. So write this on your whiteboard.

Say everything 10 times. It's not condescending. It's reinforcement learning. Repetition makes your ideas retrievable and reliable. Number two, context is the missing dependency. So your idea makes sense to you because your brain already has all the dependencies wired in, but others' brains don't. Without context, they can't scaffold up to your elegant idea.

So before a meeting, map the context tree. What assumptions or background knowledge might your audience be missing? Surface those items first and you'll get alignment instead of blank stares.

Number three, regulate yourself to stay effective. Look, as technical people, we all like to think we're highly rational, but stress can make us anything but. When we're angry, afraid, or frustrated, even if we don't notice it, we lose access to a good deal of our prefrontal cortex capacity. That's not the state you want to be in when you need the smartest ideas and the highest performance.

So when you're feeling annoyed with somebody or stressed out in a meeting, take a second to pause. Take a deep breath. Notice where your body is holding tension. That's a signal to you. Box breathing was popularized for this exact reason by a former Navy Seal. When the stakes are life or death, calm and collected is the way you want to be.

So just becoming aware of your bodily reactions is the first step. To accurate communication. Creative collaboration, and productive discussions.

Leadership as a technical IC isn't about abandoning your craft or becoming touchy, feely, or soft. It's about recognizing the patterns of how different brains are processing and connecting. Repeat yourself, provide context and regulate yourself. Start there and you'll see your influence expand far beyond what you can do by yourself.

If this resonated, I'd love for you to follow along and subscribe for more practical neuroscience-based tools that will help you expand your impact.

References

  • Camerer, C., Loewenstein, G., & Weber, M. (1989). The curse of knowledge in economic settings: An experimental analysis. Journal of Political Economy, 97(5), 1232-1254. doi:10.1086/261651
  • Sweller, J. (1988). Cognitive load during problem solving: Effects on learning. Cognitive Science, 12(2), 257-285. doi:10.1207/s15516709cog1202_4
  • Bliss, T. V. P., & Lømo, T. (1973). Long-lasting potentiation of synaptic transmission in the dentate area of the anaesthetized rabbit. Journal of Physiology, 232(2), 331-356. doi:10.1113/jphysiol.1973.sp010273
  • Datta, D., & Arnsten, A. F. T. (2019). Loss of prefrontal cortical higher cognition with uncontrollable stress. Brain Sciences, 9(5), 113. doi:10.3390/brainsci9050113

Adapted from the Neuvero video Leadership for Technical Individual Contributors. Related: Why Smart Teams Leave the Same Meeting With Different Conclusions (why the pipe between brains is so narrow) and The Five Animals of Product Management, on getting specialists to think as one system.

Frequently asked questions

Can you be a technical leader without managing people?

Yes. Leadership is getting results through other people, and that never once required a management title. If you build an API or a module that other developers adopt on sight, you have multiplied your brainpower across everyone downstream, and someone else can still own the schedules, reviews, and org politics.

How do you scale your impact as an individual contributor?

Productize your thinking so others can pick it up and run with it. Three concrete moves do most of the work: rigorously document your solutions somewhere public and keep them current, record short videos walking through your designs, and talk to the architects and developers who build against your work so you can fold their real questions back in. Past a certain point one person only scales so far, so the leverage comes from packaging ideas, not doing more yourself.

How do you delegate as an IC when you have no direct reports?

You lead through influence rather than authority, which means getting people to row in the same direction without owning their schedules or reviews. The one thing nobody can do for you is transmit what is in your head, so your job is to package the idea clearly: repeat it enough that it sticks, supply the missing context so people can climb to your conclusion, and regulate your own stress so your explanations stay sharp.

If your impact has outgrown what you can build alone

Executive coaching at Neuvero works on exactly this: expanding a technical leader's influence through others without losing the craft, using the neuroscience of how different brains actually connect. One-to-one, video, worldwide.

Explore Executive Coaching

Or start with a conversation: book an intro call. Leading a team, not just yourself? Try the self-paced Team Velocity Accelerator.