DEV Community

Cover image for Leadership Before the Title: How Engineers Can Start Leading Before They Become Managers
Shayan Mirzaie
Shayan Mirzaie

Posted on

Leadership Before the Title: How Engineers Can Start Leading Before They Become Managers

I am a young manager who is still learning.

Over the years, I have learned from amazing teammates, thoughtful managers, difficult projects, honest feedback, and a slightly embarrassing number of books and articles about leadership.

One idea keeps becoming clearer:

You do not need authority to start leading.

In engineering, leadership often begins long before someone reports to you. It begins when you make a confusing problem clearer, surface a risk early, help someone succeed, or improve the way work happens.

This is the path I now think about:

Lead yourself → improve the work → help people → create team clarity → improve the system → grow other leaders.

Three myths that stop people from leading

Myth 1: “I need a title.”

A title can give you formal authority, but it does not automatically create trust.

Before a promotion, people are already watching how you behave:

  • Do you keep your commitments?
  • Do you make decisions understandable?
  • Do you give credit away?
  • Do you speak up when something feels risky?

The replacement for this myth is simple: make one useful contribution people can rely on.

Myth 2: “I must have all the answers.”

Engineering is full of uncertainty. Leaders who pretend otherwise usually make uncertainty harder to see.

Good leadership often sounds like:

“Here is what we know, here is what we do not know, and here is how we will learn more.”

Asking a precise question at the right time can be more valuable than giving a fast answer.

Myth 3: “Leadership means doing more myself.”

This is a common trap for strong individual contributors. You become the person everyone depends on, then mistake dependence for leadership.

Real leadership makes capability travel. If the work can only move when you are present, your influence has not scaled yet.

1. Start with self-leadership

Before you lead a team, you have to learn how to lead your own attention, energy, and promises.

I use four questions as a practical reset:

  1. Choose: What is the most important outcome today?
  2. Protect: What will I say no to so that outcome has room?
  3. Close: What loop must I finish or clearly hand off?
  4. Renew: What helps me return tomorrow with good judgment?

This is not about becoming perfectly disciplined. It is about becoming more reliable.

A small daily promise is enough:

“I will leave one important thing clearer.”

That might mean clarifying a ticket, writing down a decision, explaining a trade-off, or helping a teammate get unstuck.

2. Build credibility through visible judgment

People do not need you to be certain all the time. They need to understand how you are thinking.

For important engineering decisions, make four things visible:

  • Context: What problem are we solving?
  • Options: What did we consider?
  • Trade-off: What are we giving up?
  • Next check: When will we revisit the decision?

This is the basic shape of an architecture decision record, but it also works in a pull request, design review, incident channel, or planning meeting.

Clarity beats false certainty.

3. Earn influence without force

Influence is not the ability to make people obey you. It is the ability to move important work forward without relying on your job title.

Four behaviors help:

Listen first

Understand the system before prescribing a fix. The first explanation is rarely the whole explanation.

Frame the why

Connect the work to users, outcomes, constraints, and risks. People can make better decisions when they understand the context.

Make it easy to join

Offer a small next step instead of asking for abstract alignment.

Give credit away

Make other people visible. A leader who receives all the credit may look powerful for a moment, but a leader who shares credit builds a stronger network.

4. Build trust in small moments

Google’s team-effectiveness research identified psychological safety, dependability, structure and clarity, meaning, and impact as important team dynamics.

For someone beginning to lead, psychological safety can start with one sentence:

“What are we missing?”

Ask it before the plan is final. Thank the person who surfaces a concern. Own your part when confusion comes from your own communication.

The goal is not to make every conversation comfortable. The goal is to make important information safe enough to be said early.

5. Treat feedback as a loop

Feedback works best when it improves the next attempt instead of judging the last one.

A simple structure is:

  • Situation: When and where did it happen?
  • Behavior: What did you observe?
  • Impact: What changed because of it?
  • Next step: What would better look like next time?

For example:

“In yesterday’s release review, the rollback risk was not mentioned until the end. That left us with less time to respond. In the next review, can we surface operational risks at the beginning?”

Specific, timely feedback is kinder than a vague surprise months later.

6. Delegate to grow capability

Delegation is not simply removing tasks from your own workload. It is transferring ownership, context, judgment, and confidence.

The loop I try to follow is:

  1. Define the outcome.
  2. Transfer ownership.
  3. Coach in the loop.
  4. Review the result and reflect together.

The test is not “Did I do this faster myself?”

The better question is:

“Can the work move forward without me next time?”

That is how capability travels.

7. Improve the system, not only the task

Leadership becomes visible in recurring moments:

  • a weekly planning session,
  • a code review,
  • a handoff,
  • a retrospective,
  • an incident review,
  • a career conversation.

A good ritual answers one question and changes one next action.

For example:

  • What matters this week?
  • What is blocked or unclear?
  • What did we learn?
  • What changes next time?

You can practice this before managing anyone. Make one recurring interaction clearer and more useful.

8. Choose your leadership path

Leadership is bigger than management.

Technical leaders create architecture, standards, technical direction, and influence without formal authority. People leaders build teams, coach individuals, create clarity, and improve delivery and health.

Books such as Staff Engineer: Leadership Beyond the Management Track are useful because they show that technical leadership is a real path—not a consolation prize for people who do not become managers.

Other books have helped me build the picture from different angles:

  • The 7 Habits of Highly Effective People for personal effectiveness and principles.
  • The Manager’s Path for the progression into engineering management.
  • High Output Management for leverage and team output.
  • Turn the Ship Around! for creating leaders instead of followers.
  • Radical Candor for direct, human feedback.

A 30-day leadership experiment

Do not wait for a promotion to practice leadership.

Week 1: Observe

Ask three people: “Where is there friction, ambiguity, or risk?”

Week 2: Choose

Pick one loop you can tighten.

Week 3: Practice

Run the new behavior in public. Explain what you are trying.

Week 4: Reflect

Ask: “What changed? What should we keep?”

One visible act of leadership is enough to begin.

Final thought

Do not wait for permission to practice leadership.

Choose one behavior. Make it visible. Repeat it until people can rely on it.

Leadership is the work that makes other people more capable.

Further reading

Top comments (0)