Influence doesn't come with the title

I've spent a good part of my career involved in recruiting engineers for senior positions.

One thing I've noticed in those conversations is a recurring expectation that influence comes with the title. That becoming more senior means people will listen to your ideas, take your opinions more seriously and give you greater opportunities to change things.

I can understand that perspective. Titles do matter. But I've come to question how much influence actually comes from the title and how much you need to develop before getting there.

Looking back at my own career progression, I wanted to break down a few experiences that changed how I think about this.

This isn't intended as a guide to getting promoted. It's more of a personal reflection on what I've learnt, how my approach has changed and what has helped me grow along the way. Perhaps some of it will help others think about their own development, with career progression becoming one of the outcomes rather than the only goal.

Learning to look beyond my own work

When I was working towards becoming a Senior Technical Architect, I began to recognise that doing valuable technical work wasn't necessarily enough for others to understand its wider impact.

An architectural decision might make sense within the team delivering it. But what about the wider priorities? Was the organisation trying to reduce delivery time? Avoid disruption for customers? Make a future expansion possible?

Conversations with senior architects and other technical leaders became an important part of learning how to answer those questions. Sometimes that meant a one to one with the CTO or someone in the wider leadership group. I wanted to understand what they were working towards and where my own work might help.

Those relationships developed through taking an interest in other people's problems and exchanging ideas, not treating visibility as a goal in itself.

Over time, the same technical decision began to look different depending on who needed to understand it. An engineering leader might be weighing performance, reliability or what an architectural compromise would cost later. A commercial colleague might be concerned about customers, delivery dates or investment.

The technical detail hadn't disappeared. I was learning how to connect it to the decisions other people were responsible for making.

When the problem crosses organisational boundaries

One of the biggest challenges of my career came when I was a Senior Technical Architect helping lead Bally's online casino launch in Rhode Island.

The programme brought together engineering, infrastructure, compliance, legal, product, testing, commercial teams, customer support and 3rd party providers. And the list goes on. Colleagues from the physical casino business in the United States and the Rhode Island Lottery were important parts of that work too.

There were technical decisions to make, but no single group had the full picture. Different organisations needed to understand how the service would operate and what the requirements meant in practice.

One question from the Lottery has stayed with me. They wanted to understand how a gaming transaction travelled through the systems involved.

It was a reasonable question, but not one I could confidently answer on the spot from the application architecture alone.

I started a diagram with a player pressing the spin button on a device and followed the request through the systems involved. It captured my understanding of the broad journey, but there were assumptions about the infrastructure that needed checking.

Infrastructure leadership helped clarify those boundaries and the platform team validated the assumptions in the diagram. It became a shared starting point for the discussion rather than an explanation I could claim to have established alone.

Another colleague made an important contribution by managing relationships between the Lottery, the physical casino and our online business. That meant keeping people with different responsibilities aligned as the questions became more detailed. The technical work depended on that coordination just as much as the conversations depended on a sound technical explanation.

We worked through further questions together, reviewing the explanation several times to check that it matched the technical teams’ understanding.

That resolved one important set of concerns. But it was one part of a much larger launch, not the final obstacle standing between us and going live.

In parallel, teams were delivering and testing the application, addressing geolocation requirements, testing how the app behaved near state borders, verifying location checks on casino premises, working through responsible gaming regulations and delivering features specific to Rhode Island. Many other activities needed to come together before customers could use the service.

The programme eventually launched successfully because of that wider collective effort.

What stayed with me was how much knowledge and coordination it took to make even one question understandable across engineering, operations and regulatory stakeholders. The diagram helped, but the work was really in the conversations around it.

That experience gave me greater confidence in taking on wider responsibilities. It also made the value of trusting other people's expertise much more tangible.

It's okay to say I don't know

I've generally preferred listening to other people's perspectives before committing too strongly to my own. That wasn't something I suddenly learnt when I became more senior.

What did change was how comfortable I became saying publicly that I didn't know an answer yet.

I remember being asked a question during a meeting and choosing not to piece together an explanation from information I hadn't checked. I said I would validate it and come back.

Later, during a one to one, my manager mentioned that moment. He told me he'd thought it was a good way to handle the question.

It was reassuring. There can be pressure on senior engineers to respond immediately, especially when everyone is waiting for their opinion. But a confident answer isn't useful if part of it turns out to be wrong.

Sometimes I need to consult another engineer. Sometimes I need to think longer or look at the evidence. I'd rather return with a reliable explanation than use the meeting to guess.

Helping knowledge travel further

Those experiences reinforced something I've come to appreciate about influence. It's rarely about having all the answers yourself. Often, it's about bringing the right people together, sharing knowledge and helping others make progress.

More recently, I've been exploring another side of that idea: how to help knowledge spread beyond the people directly involved so others can build confidence and take things forward themselves.

That was part of the thinking behind the Pass It On challenge, which I started with colleagues from across the business, not just engineering. The aim was to help people become more confident using AI and coding agents in their own work.

Instead of a prepared demonstration, we worked through a real problem from their day to day context. The discussion was about how to investigate, what to ask the tools and how to check the answers. The hope was that each person could use those ideas and eventually pass them on to two or three others.

The response was encouraging and people began teaching one another. But finding time to practise something new looks different for everyone. Some had a chance to apply it quickly while others had existing commitments to work through. Enjoying a learning session and having the space to change a habit aren't quite the same thing.

I kept in touch and offered help, leaving more time between conversations when that made sense. The aim wasn't to chase people into adopting a new workflow. It was to make the next step easier when they were ready to take it.

I could help someone grow. I couldn't want it on their behalf.

I think there's a similar boundary when influencing organisational change. Understanding what matters to others, building support and helping remove obstacles can create momentum. Even then, progress depends on shared priorities and people taking the work forward together.

What a title does and doesn't change

My progression from Technical Architect to Senior Technical Architect and eventually Principal Staff Engineer came with wider responsibilities and opportunities. Those titles mattered. Sometimes a role provides the mandate or authority needed to make a decision.

But I don't think the title alone makes someone influential.

Relationships take time. So does learning how to understand different perspectives and explain technical choices in a way that helps others make decisions. That work continues as responsibilities grow.

Looking back, much of that learning was already happening before each change in title. The opportunities to ask better questions, work outside my immediate team and connect a technical recommendation to a wider problem were there long before the new role was official.

I'm still learning when to push for a decision, when to make room for another perspective and when an idea needs more time or support to move.

If I were earlier in my career again, I'd spend less time thinking about what the next title might allow me to do and more time looking for things I could already help change.

Not every opportunity will be obvious. Nobody necessarily tells you which relationships to build, which problems deserve attention or where your involvement might make a difference. Learning to recognise those opportunities and taking responsibility for moving them forward is part of the development itself.

So perhaps it's worth reflecting on your own work. What could be better? What's stopping it from changing? And what could you do to help, even if nobody has specifically asked you?

The title might give me responsibility for a bigger problem. It won't give me all the relationships or answers needed to solve it.