One of the most common failure modes for senior technical contributors is the pull toward doing rather than guiding. The pull goes like this: The problem is interesting. You know how to solve it. It would be faster to just do it yourself.

And maybe it would be, this time. But technical leadership at scale requires a different orientation: creating the conditions for others to do great work, rather than doing the great work yourself.

Raise Other’s Technical Skills

This means offering direction without over-specifying. Asking questions that help someone think through a problem rather than handing them the answer. Setting a standard for quality that others can internalize and apply independently. Giving feedback that develops judgment rather than just correcting the immediate mistake.

This is genuinely difficult for people who built their careers on technical excellence. The shift from “I’m the best person to solve this” to “I’m the best person to help this team solve this” is not a small one. It requires a different kind of confidence — and a different relationship to your own expertise.

The engineers who make that shift stop being a ceiling and start being a multiplier. The impact may be harder to measure, but ultimately it is larger.

This is part four of a multi-part series on technical leadership. Read Part 1,  Part 2, or Part 3.

First Lead Yourself includes a module on observation — seeing clearly what’s actually happening around you, rather than what you expected to see. It’s one of the capacities that makes the shift from doing to guiding possible.  If your curious, find more here. 

Technical leaders can see misalignment coming before it arrives. They notice when two groups are using the same word to mean different things. They recognize when a decision made in one part of the system will create problems in another. They know which assumptions need to be made explicit before the work starts.

Mis-Alignment Costs Time & Trust

Alignment problems are expensive. It might be an architectural decision made by one group that limits future options for another group. Or, when people use the same term but give it different meaning. It happens when groups working on the same program, prioritize different stakeholders with different interests.

By the time alignment problems surface, untangling the mess costs time and inflames tempers. The rework is demoralizing. Trust erodes, blame flows and relationships suffer.

Creating alignment isn’t glamorous. Like surfacing tradeoffs, it requires leadership skills, not just technical ones. It calls for the ability to convene people, facilitate conversation, and bring disparate perspectives to a shared understanding.

However, it often goes unnoticed. Lack of alignment eventually becomes obvious. Alignment is calm and quiet. It looks like a lot of conversations, not a concrete deliverable. But it’s some of the most valuable work a technical leader does.

The engineers who create alignment well are worth more to an organization than their job titles suggest.

This is part three of a multi-part series on technical leadership. Read Part 1 or Part 2.

Do you want to practice some of these skills?

Problem-Solving Leadership (PSL) is an immersive five-and-a-half day workshop where technical leaders, managers, coaches, and team members work on alignment and problem-solving challenges together. We’re running a public session this November. Learn more about PSL here. 

Technical decisions are almost never purely technical. They spill over into business outcomes and organizational implications. Speed versus reliability. Build versus buy. Consistency versus flexibility. Quick win releases versus long-term maintainability.

Make Tradeoffs Visible

Every significant technical decision involves a tradeoff. Many organizations make those tradeoffs with blinders on. People may choose a path without fully understanding what they’re giving up. Decision-makers who aren’t technically savvy may be attracted to the promise of new technologies without fully grasping the risks. They may expect fast results  with a new technology and not account for slower progress as people learn.

Senior, Staff and Principal Engineers are often the only people in the room who can see the full shape of a tradeoff. The ability to communicate those in language that doesn’t require a deep technical background is a real skill. The people who can connect the implications to what others care about—which may not be the technology itself—can inform decisions. Both require the ability to see the world from another point-of-view.

Making tradeoffs visible and understandable is one of the most valuable things a technical leader can do. It is also one of the most undervalued contributions, because it doesn’t look like a deliverable. It looks having lots of conversation (and maybe building a PowerPoint deck).

But here’s the payoff. Organizations that make tradeoffs explicit make better decisions. They create more sustainable systems. Further, they waste less time reversing choices that were made without full information or on the basis of hope. That’s the value of one technical leader who knows how to surface and explore issues when others lack context or expertise.

This is a leadership skill. It requires the courage to slow a conversation down. It takes clarity to name what’s at stake. Understanding impacts beyond the tech stack requires curiosity and point-of-view empathy. All of this takes enough credibility that people trust your read of the situation.

None of this comes from technical expertise alone.

This is part two of a multi-part series on technical leadership. Part 1 is here.

If you’re developing your own leadership capacity, I’d love to have you on my list. My newsletter has practical thinking on leadership, change, and the things most training programs skip. Subscribe at the bottom of the page.

Many organizations have a career ladder that splits at some point. One path goes toward management with more focus on “people stuff.” The other stays technical — Staff Engineer, Principal Engineer, Architect. The assumption built into that split is that the technical path is the one that doesn’t require leading people. It assumes technical leadership is only about the tech.

That assumption is incorrect.

Recognize that You Are Already Leading

The engineers at the top of the technical track are leading all the time. However, they often don’t name it as leadership. Neither do the organizations that promoted them there. The result is a kind of leadership vacuum. The people with enormous influence over how an organization builds, decides, and learns, doesn’t give deliberate attention to developing leaders on the technical path.

A Staff Engineer who raises a concern in an architecture review that causes the team to change course–that’s leadership. When a Principal Engineer sets a standard for how code gets reviewed and the whole team gradually rises to it, that’s leadership. When someone with deep context names the tradeoff nobody was seeing and creates the conditions for a good decision, they are leading.

None of those things required direct reports or the dreaded “HR stuff.” Those actions required judgment, credibility, influence.

Technical leaders may focus solely on technology matters. They may gloss over the skills that would make them more effective, because they think those skills don’t apply to them.

The first shift is noticing what’s already happening. If you’re an architect, staff or principal engineer you are already leading.

This is the first in a series on technical leadership. If it resonates, the nine-module, online course First, Lead Yourself is built for people ready to develop their leadership deliberately — with or without a management title. Learn more here.

When people in your company feel like they can’t speak up, everyone loses. 

Manager don’t learn about problems until those problems are too big to hide. Managers and teams alike miss out on ideas, different points of view, concerns, and risks. Employees feel less valued and less invested in their work and the company. They may just dial it in, figuring their managers don’t really care to hear from them. The organization suffers, too. The quality of decisions deteriorates, employee engagement drops. People expend energy fighting fires that didn’t need to get any bigger than a spark.

The benefits of creating an environment where people can speak up provides the opposite. Better decisions, more engagement, smoother operations.

So why don’t people speak up?

In a word, hierarchy. There is almost always some friction in speaking up in hierarchies. This is an artifact of status and power differences. It just is, but the degree varies greatly depending on how much those differences are enforced. 

Here’s how that can show up:

• People worry that the boss will take it the wrong way if they point out an issue.
• People fear that their idea will be picked apart in public.
• People believe that raising issues and concerns are “above their pay grade.” 

And how can we make it easier for people to speak up? These three strategies can make it easier for people to bring important information forward.

Normalize Problems, So People Bring Them Up Without Fear  

No, I don’t mean lowering standards or accepting haphazard work. Most of people don’t love hearing there’s a problem. However, they are a fact of life, and projects, and business.  But, it is important to discern the type of problem you’re dealing with. 

When a problem could have been prevented by a known approach or procedure, that’s an opportunity for learning.  Do people understand the approach?  Is the procedure so onerous that people find it difficult to follow?  Are they under so much pressure that they cut corners?

Is the problem the result of the interaction of a number of different factors? These can be hard to predict and prevent. Thinking systemically can help. Look at how the various factors that make up your system interact. Even a simple system model may help you anticipate (and potentially avoid) some of the potential problems.  And some times, things just come together in a certain way, and boom, you’ve got a problem…one which may or may not occur again.  If it does reoccur, then you can do more analysis and perhaps come up with approach the pushes it into the Preventable domain.

The final type of problem comes from intelligent experiments and risk taking. And experiment, by definition, involves an uncertain outcome. You know it may not work as planned. But you started with a hypothesis. You’ve thought about risks, downsides, and (hopefully) how to recover if things go sideways. You can learn from any problem, but learning is designed into this sort of problem.

When everyone understands that problems don’t lead to punishment, people are more like to bring them up.

Be Open to Exploring Issues, Risks, Problems and Hunches

One way to help people speak up about issues is to ask!  Seems simple.  Consider questions like these: What’s keeping you up at night? What’s worrying you?

But what happens next is important. When someone raises an issue or problem get curious.  Aim for exploration,  not interrogation. Asking for excessive proof will shut people down.  So will interrupting.

Follow up with, What have you observed about [issue]? , or another question that builds on what they’ve shared.

From there, you can probe to find out more about frequency, intervals, patterns, and so forth.  Or you can discuss what signals might be useful, and how to monitor them.

When some one says, “I’m not sure, I can’t quite put my finger on it,”  get really curious!  Hunches are often early warnings.  Explore what signals you might want to keep an eye on.  That uneasy feeling is actually pretty common with people who have deep expertise. It represents information that is so internalized that it functions at a level that is beneath conscious thought.

Be an Ally by Supporting Other’s Voices

Even if you don’t have formal power, you can help others speak up.  Build on what someone else has said (while recognizing the original speaker). For example, “I want to go back to what Dmitri said…”  Or “Building on what Andrea said…”

If you have data that might corroborate, offer it.  Or offer to help get some data to explore the issue that’s come up.

If you notice someone who looks like they’re trying to break into a conversation, see if you can create an opening.  If you see something, say something to help someone else say something:  “It looks like Sam has something to add…”

In summary:

Most organizations try to hire smart, capable people. It makes no sense to stifle their voices. Making it easier for people to speak up will lead to better decisions and actions.

You can watch the full video here.