It was deep into winter, and dark on my drive home. I’d finished another days’ work, leaving late due to a presentation up to my senior management for a cross-departmental project I was running. As I was driving home, avoiding the blinding lights of the oncoming cars, I was pondering whether I’d been influencing the right people. The radio playing in the background, and I was replaying a presentation I had made to the steering committee in my head. The steering committee was formed of the senior executives, both business and technical, across the large department to keep abreast of the latest technology changes. This was the fourth update I’d given since the summer and despite all the presentations, status reports, and alignment meetings, the project still felt stuck. As I drove home, I wondered whether I was spending time with the right people. 

We were struggling to gain momentum, the project was across 4 different teams, each with competing priorities, and I thought that the best way to get the teams together was through the management. I was under the impression that authority through management was the best way to go. The next week, after spending half an hour attempting to find a slot across three time zones and calendars that were packed with half an hour meetings, I found a slot for five managers and myself to get together to discuss alignment. The agenda sent out beforehand, and I’d personally reached out to all attendees to ensure they’re aligned before going in. The meeting was a success on paper. Everyone agreed with the direction, committed their teams, and supported the objectives. Yet when I left the room, very little had actually changed. I still owned the roadmap, the communication plan, the alignment across teams, and the challenge of turning agreement into action.

I was under the impression that management would be the ones to help me drive this forward. In fact, they were the people that were accountable for the results, not responsible for creating the day-to-day momentum. The managers were accountable for their products roadmap – delivery of certain features for their customers, new versions, making sure their bosses were happy. They weren’t going to help me influence the people working on the project to get the cross-departmental deliveries across the line. I then hit a crossroads. How was I to influence those in the project if their managers were generally supportive, but not there to provide direct guidance? How was I supposed to drive a project where I needed to influence the team, not deliver through authority?

I began to do a few things. The first, being that I went to the technical leadership, we had several alignment documents and meetings to discuss and agree the higher-level strategy. Secondly, I began to build relationships across the delivery team and those that were key stakeholders in getting the project written and delivered. I spent time with them individually, ensuring that the team were all aligned and happy. Thirdly, I began to shift my thinking from ‘how do I use authority to get what I need’ to ‘how can I influence the hidden network to get this achieved’. 

That was something I hadn’t realised. There are two organisational charts in a company or group. There’s the official organisational chart – individual contributors, first-line managers, and then up to the CEO. That type of authority was all centred around the specific outcomes that the team were accountable for. The second, you discover over time. The architect that everybody trusts, the engineer who knows where the bodies are buried, the product manager who connects teams, the person everyone calls before making a decision.

I had assumed that if I found the reporting line, then I would find how decisions were made. What surprised me was that the most important people in the room were rarely the ones with the biggest titles. It would be the longest-serving employee that has deep and in-depth experience into how to solve a problem, the connector who knows the right person to solve a difficult technical problem. Alternatively, it could be the person that everyone stops and listens to. The engineer that hasn’t got a fancy title but has command of the room in a meeting.

As we approached the first beta release, the project gradually found its feet. Not because I became more senior, gained more authority, or found the perfect steering committee presentation, but because I learnt where influence actually lived. The deadlines only started to become real when the people doing the work believed in them. Momentum came from building relationships across the team, understanding different priorities, and creating enough trust for people to challenge the plan rather than quietly disagreeing with it. I also discovered that driving a project wasn’t about telling people what to do, it was about creating direction, removing obstacles, and giving the team confidence that the work mattered.

Early in my career, I assumed that if I could understand the reporting line, then I would understand how decisions were made. What I eventually discovered was that reporting lines explain accountability. Relationships explain influence. The organisations that move fastest understand the difference. The managers were responsible for outcomes, alignment, and ensuring the right decisions were made. The momentum, however, came from the architects, engineers, product managers, and connectors who carried ideas between teams and turned agreement into action. Once I understood that distinction, the project became much easier to navigate.