Leading from Where You Are

When we were building Areca, a real-time billing engine for Turk Telekom, we were a small team competing against giants like Amdocs. They had the brand recognition, the scale, and the legacy contracts. We had one shot to prove ourselves.

In that environment, titles were irrelevant; in fact, we technically didn’t have them. What mattered was execution. If something failed, you fixed it. If a component was missing, you built it. If a decision was needed, you made it. Everyone carried the weight because there was no other option.

That experience taught me what leadership truly is. It’s not a position you’re given or an announcement that’s made. It’s the ability to remain steady when the system collapses. It is taking responsibility without being asked and doing the work at 2 a.m. because the release has to go out. It’s ensuring the people around you can count on you, even when you aren’t at your best.

This mindset, this consistency and sense of ownership, doesn’t go unnoticed. Over time, people see who consistently steps up. They begin to trust you, look to you, and eventually, follow you. This is what earns you trust and, in the end, the title too.

Leadership is not a formal role you wait for. It is a set of behaviors you can practice today. Here are a few ways to start.

Be the Problem-Solver

Every team has people who can identify issues. True leaders, however, are the ones who move things forward when everyone else is stuck. This might mean digging through logs at 3 a.m., redesigning a faulty API, or simply getting the right three people in a room to unblock a decision. People remember the person who reduces friction and maintains momentum. Over time, they will seek that person out first.

Deliver with Consistency

Reliability is one of the most powerful, yet overlooked, leadership traits. Anyone can achieve a big win occasionally. Real influence comes from being dependable, week after week. It means you do what you promised, even when the work is harder than expected. It means shipping on time, without excuses, and earning the trust to handle work without supervision. When people know you will deliver, they give you more responsibility.

Build Trust

Teams don’t follow people for their technical skills alone; they follow people they believe in. Trust is built by showing up consistently, being transparent when things go wrong, and supporting your colleagues when they are under pressure. It also means giving credit away instead of hoarding it. The engineers I trusted most were the ones I knew would never throw me under the bus. That level of trust builds loyalty, which is what holds a team together when the pressure rises.

Practice Leadership Daily

Leadership is not a switch you flip after a promotion. It is a muscle you build through daily practice.

• Communicate with clarity in meetings, even if you’re nervous.
• Make small, firm decisions instead of waiting for others.
• Learn to weigh technical trade-offs against business needs.
  

These skills only grow if you use them constantly. By the time you step into a formal leadership role, they will already be second nature.

Leadership is also boundaries. If you keep absorbing every loose end, you become the system’s dumping ground. Be helpful, but be intentional, take on what you can finish, document what you learn, and redirect the rest to the person who owns it.

Lead Beyond Your Own Scope

At some point your bottleneck will not be your code. It will be a dependency, a policy, a different team’s backlog, or a decision that keeps floating around without an owner. This is where many people stop and complain. Leaders do something else. They reduce friction regardless of its source.

Leading beyond your scope is not taking over. It is not acting like you own the room. It is seeing the next failure early, making it visible, and helping teams move before it breaks.

How to Go Beyond Your Scope

Start by respecting ownership. If there is a clear owner, you support them. If there is no owner, you make that problem visible first. Most cross-team issues are just ownership bugs.

Then you operate on interfaces, not implementations. You do not tell another team how to design their service. You clarify what you need, what constraints you have, what risk you see, and what trade-offs exist. This is how you influence without triggering resistance.

Practical moves that work:

• Name the owner. If you cannot, that is the issue.
• Bring options, not complaints. Two paths, trade-offs, recommendation.
• Do the legwork. Draft the doc, propose the rollout, schedule the alignment.
• Give credit away. Cross-scope trust dies when people think you are farming visibility.

How to Get Ahead

Warnings fail when they are vague. “This feels risky” is not a warning. It just creates anxiety for everyone. A real warning is specific and tied to a decision.

A useful warning has five parts:

1. What I am seeing (signal)
2. Why it will fail (mechanism)
3. What breaks if it fails (impact)
4. When it becomes expensive to change (time)
5. What decision we need now (ask)

Example: “We are about to ship a migration without rollback. If it misbehaves, support will carry it for days and data cleanup will be manual. This becomes hard to undo after 30% rollout. We need a feature flag or a staged rollout before Friday.”

With this you bring clarity as opposed to a drama.

How to Tell the Direction

People resist direction when it feels like status or overspeaking. They accept direction when it feels like service. What makes it or breaks it how you frame it.

Talk in constraints and trade-offs. Ask one sharp question to anchor the goal. Then recommend.

• “Are we optimizing for speed, or reversibility?”
• “Given oncall load, the safer rollout is the better choice.”
• “If we pick the faster path, we accept the risk explicitly.”

You are not trying to sound smart. You are trying to make the decision sane. That is what people follow.

Make Your Impact Visible

Doing great work quietly is noble, but it is not enough to lead. If no one knows what you shipped, what you prevented, or what you improved, your impact stays local. Leadership requires shared context. It requires other people being able to rely on your decisions, reuse your thinking, and build on what you learned.

Visibility is not bragging. It is documentation plus communication.

Make it easy for the team to see what changed and why:

• Write short updates that focus on outcomes, not effort.
• Send a summary after meetings: decision, owners, next steps.
• Capture lessons learned in postmortems and design notes.
• Turn repeated tribal knowledge into a doc people can actually find.

Do not wait for performance reviews to tell the story of your work. Share it as you go, in small, consistent ways. The goal is is alignment not attention seeking. When the right people have the right context, better decisions happen, and the people already leading become obvious.

In Short

Do not wait for a title to start leading. A title is not a starting pistol; it is a trophy you are awarded for a race you have already won. It is the formal recognition of the trust you have already earned and the problems you have already solved.

Leadership is not a role that is given. It is a standard you choose to meet, one decision at a time. Your team already knows who the leaders are. The only choice left is whether you will be one of them.