Something a lead engineer told me recently. The kind of developer who designs and strategises architecture underneath a whole team. Not a junior finding their feet. Someone senior, trusted, technically excellent.

But that wasn't really the problem.

The problem was this: he'd share his thinking openly. Collaborate on the tradeoffs and contracts. And BAM, once in place the manager usually got the credit.

This problem got me thinking...

Every Team has an API that isn't Code

Every engineering team has its own API. I am not talking about a codebase, either. A team is a unit in a business that has an outward facing interface. Directors, stakeholders, other teams interact wit this API and don't see the internals. They have nice, tidy endpoints to interact with the team.

Someone is always writing the docs for that API.

For the most part, that someone is the manager.

They take the team's output and route it through the API back into the business. They summarise it. All the grisly technical detail is translated into clean metrics and KPIs. They advocate for it, or they don't. They attach names to it, or they don't.

Developers are often happy to be an internal service, abstracted from the world of the business.

As a consequence, like any undocumented internal, they are invisible to the consumer.

The Law of Demeter

This is probably not a grand conspiracy to keep developers down. It's the principle of least knowledge. There's no need for external teams to be reaching deep into the internals of development. It's an org smell.

On the contrary, I've seen the damage this can do to effective software development.

We are better off assuming that the people closest to the work understand it best. As the work of engineering and organisational strategy are undertaken by wholly different people, there is always a translation layer between value creation and value recognition.

"Who controls the translation layer controls the influence."

When a developer shares their thinking generously: bringing tradeoffs, alternatives, contracts, they are being collaborative. They are being professional. They are doing the right thing technically.

But unless they also own the translation, they are losing the influence they could have gained.

The Point of Leverage

The moment where the influence has been assigned is much earlier than we suspect.

A retroactive "good work" after shipping rarely does justice to the contribution of a senior, or lead developer.

Usually the decision is made as part of a messy internal---a PR comment, some archived ticket, an in-person meeting---the influence internally is created here.

However, it is shared organisationally during a status update, a board meeting, a strategy session. Rarely, is the primary source cited.

That is the moment that the communication happens. And it doesn't involve the internals of the system at all. It's an abstracted, packaged version from the translation layer.

The Undocumented Endpoint

This is not generally visible to developers because it is often a harmonious arrangement for shipping a quality product. Not everyone is talking to everyone.

But undocumented functionality is quietly overlooked. A slight frustration when a colleague gets recognised for something you contributed to. A sense that your manager likes you but never quite advocates for you. Performance reviews where you are solid but somehow not quite ready for the next level. It might even be when there are strong disagreements in the internals where one party holds a lot more influence.

And to developers, these often don't feel like 'communication issues' at first. They might feel like 'office-politics' (honestly same thing). They might feel like a bad culture.

Truthfully, they are interface problems where the docs are not properly updated by the maintainer.

Noticing this is the first step. If there are signs that your work is too internal, keep looking. It's likely that you are too removed from defining the API contract of your organisation.

Becoming a contributor to that contract is engineerable. If you want to know how, book a call.

Book a call

Armstrong's memo is explicit. Coinbase is eliminating pure management roles entirely. Every leader going forward is an "active individual contributor" and a "player-coach." The org caps at five layers. AI handles the coordination work that used to require a layer of people between you and the business.

Those left are no longer cushioned by a communication layer between them and management. Decision-making is more direct. Value-sharing vital.

Et Tu Coinbase?

In September 2024, Amazon CEO Andy Jassy wrote directly to staff instructing every S-team organisation to increase the ratio of individual contributors to managers by at least 15% by the end of Q1 2025. His reasoning was structural: fewer managers, faster decisions, ownership pushed deeper into the SWE role.

(Source: Message from CEO Andy Jassy: Strengthening our culture — aboutamazon.com, September 2024)

Meta went further. Its new applied AI engineering division (handling its superintelligence efforts) runs at a 50-to-1 employee-to-manager ratio, double the 25-to-1 figure widely regarded as the outer limit of managerial control.

(Source: Meta's new AI team has 50 engineers per boss — Fortune, March 2026, citing Wall Street Journal)

Now Coinbase. It's becoming a familiar pattern: flatten the structure, cut the coordination layer, trust the engineers left to take full ownership.

What has Disappeared?

For most of history, there has been a 'chain of command', an organisational hierarchy. Whatever one wants to call it, it showed up in software teams in an important way. There was always someone to translate the technical realm of engineering and code to the 'powers that be.' These managers ran the stakeholder meetings. They translated your technical decisions into language the business understood. They explained value upward while you were busy raising PRs and tuning performance.

That person is gone now. The most important gap to close is the communication one.

The VP needs to understand the cause for delays. The board still needs full confidence in the army of agents engineers are expected to control (a whole issue unto itself!). The shrinking pool of juniors still need context. Those conversations aren't going away, however much we might prefer it. Instead they are the new job description for 'Software Engineer.'

An Accelerating Trend?

The ability to communicate, facilitate, persuade, and influence was always part of the job. There were people doing exclusively this. But the best performing engineers were never just technical wizards, they were the people who could convince the organisation of their expertise and vision---those capable of executing it through their team.

Now the cover is gone and the requirement is only accelerating.

The engineers who thrive in this structure won't simply be the most technically skilled in the room. They'll be the ones who can hold a stakeholder relationship, make technical complexity legible to people who don't share their context, and advocate for their work without someone else doing it for them.

It just so happens that AI means the last excuse to ignore communication is gone. We have left the territory of 'soft skills' training. It's what we are hired to do.

You are likely to get questions passed around, and some vague 'documentation' on a complex system. No one gets a chance to review it more than once a year so... That means processes have changed. The coding standards are different now.

These are the general frustrations of the average company, where people focus on velocity more than the comfort of incoming colleagues.

Many new hires will take the time not to rock the boat. To put their head down and build some velocity. And that's a great strategy, if you want to become someone known for pushing good feature code and a 'safe pair of hands.'

The 'safe pair of hands' is someone we can trust to get things done, they are reliable, docile, and mostly invisible.

You can get on just fine as a team member who doesn't go 'above and beyond' but there is always a ceiling. It's simply the wrong approach.

If you think that above and beyond means overtime, late nights, grinding, and burnout, you are wrong.

Going above and beyond isn't about becoming a consumable that spits out code fastest (AI is always going to beat you, for people who aren't looking at the quality).

Going above and beyond is a matter of taste.

It's a matter of sharing impactful opinions, which means it's a matter of persuasion.

Because we aren't really that impactful as individuals, we are impactful when we steer our teams. Being known for opinions that create great outcomes is a skill. Being able to make them happen is a far better metric of seniority than a high velocity.

I know a lot of devs don't love leaning into these things. They are happier buried in the code. And I can understand that. Code is where we live and breathe but increasingly careers are decided outside the IDE by the 'non-technical stakeholders'.

Meetings

Warning: I am going to focus on the most controversial meeting in the dev team.

Be honest, which stand-up personality is yours? Are you more half-baked, boring festival of "err...", "um...." with people zoning out. Or the classic "Yesterday X, today Y. No blockers." Useful stuff, thanks!

I understand that most developers hate Scrum ceremonies. The stand-up more than any. An interruption to talk about work instead of working. It is so easy for it to become a status check in that nobody asked for. However, those are 15 non-negotiable minutes with time to influence.

For example, simply relating your tasks to the experiences you're hearing. If somebody is doing something similar to what you did yesterday, that's a moment to clarify that the pipelines are flaky or whatever. You can offer a hand. And when it comes to the next stand up you can remind people that "Yesterday, I helped with..." This gets you a reputation as being generous with your time, visibly.

Instead of people asking you outside of a meeting and that time disappearing from your velocity, it is acknowledged. Perhaps not for all posterity, but you leave an impression as a particular type of person. One who goes above and beyond for your team.

Even if you aren't eager to share at the stand-up, at its most basic level, communication is two-way. It's about listening as much as talking. Not listening to colleagues and continuing to clack on your mechanical keys is actually just rude. Simple as. People will notice it.

Mentoring

If you are this far into the article, I doubt this is your first rodeo. You already have tech experience. If you have colleagues with shorter tenure either overall or in the company. You can mentor them. If you know there is someone with an interest in coding outside of the dev team, you can mentor them. Potentially, if you are a career changer with some secret knowledge in a tangential field, you can mentor someone.

Mentoring provides outsized impact to your team. You are enabling people to solve problems in the future and to pass that experience forward. It creates institutional knowledge. It creates culture. There is a (clearly massively oversimplified) reason why the octopus is not the master of this planet. They don't live long enough to pass knowledge onward. That's a problem with AI too. However much you prompt it to make no mistakes and act as a senior developer, it resets. Your mentees don't.

You should even be mentoring for one wholly selfish reason, if it isn't something you enjoy. It clarifies your thinking. It makes you better at communicating complex ideas to less technically-able people. It helps you find a range of ways of explaining things that different people understand. And it makes people like you.

When I arrived fresh to my first day as a dev, I lucked out with my mentor. I had someone who told me the same thing way too many times when I asked stupid, stupid questions and rarely took notes. That's not a colleague one forgets!

Metrics

If you do any of the above, and you aren't generally miserable and difficult, your team is probably going to like you. Being well-liked is going to get people on your side.

So, by now you have demonstrated that you are a competent team player who is easy to get along with. So what about that bonus and a juicy senior or staff title?

You probably aren't getting promoted on that alone. You need a little more leverage. When we imagine great communicators we think of compelling public speakers. We overlook ongoing communication with ourselves. Something that allows us to create the story of our work before it is written by someone else.

Especially as we usually end up doing our work and forgetting. Lord knows our inundated managers aren't thinking about it. They might have some general visibility like velocity. But remember, a safe pair of hands is just that. They are doing all the feature work.

It's best not to get into your review or a salary negotiation, or even an interview with a blank canvas of what you've achieved.

So write it down!

A notepad, a word doc, a git repo. It doesn't matter. Write down what you did, what changed. If you have some numerical metrics about performance or business even better. If you have a way to collect them do so. If you don't, try to make a way. Employers salivate over CVs with metrics, like 'reduced login screen load time by 800ms, reducing bounce rate by 1.3%.'

If you are keeping note of all your achievements, not only are you going to feel insanely good, you also have a powerful tool to communicate your value to the company. As Simon Pegg says in Hot Fuzz, "This is the most important piece of equipment you will ever own. This notebook has saved my skin more times than I care to remember."

And don't forget to keep it backed up to a personally accessible spot.

If you can manage these, you are in the top-tier of communicators in your team. Sometimes the bar is quite low.

These three Ms are simple areas that create a big change in one's communication habits. None of them involve drilling grammar and practising in the mirror or flashcards. They involve performing simple maintenance on the relationships at work. They involve setting an example for the team. These are the difference between a safe pair of hands who is given more velocity and an asset who is trusted with responsibility.

If this is something you would like help putting into practice for yourself, don't be a stranger. I work with devs on precisely that.

The last time you applied you drilled leetcode, prepared to talk about a side-project, gathered lots of stories about great things you did at your current job.

You know your stack. But putting that across under pressure is a different problem entirely.

Interviewers are probably using this dreaded phrase, "talk through your thinking."

In a high stress situation like live-coding, talking about what you are doing is pretty difficult. At least, I find it to be.

You are spending too much time thinking about how to say it, not what to say. And that is stopping you from showing your technical value.

It's unfair, like a lot of things in interviews. But employers can be picky.

Personally I prepare and rehearse interview answers. I have also interviewed in a second language to an offer and that was much harder to prepare, so I understand the pressure.

One of the problems is that, while there are themes of what we are normally asked, it's not possible to know exactly what the question will be.

This gap means there is always something we don't know, which can create anxiety. But the trick is to be able to move the interview question to our story.

The easiest thing to do is to prepare a few flexible answers. Those that can cover STAR answers based on a couple of themes: what went well, what went badly but you learnt from, and so on.

The best way to prep this is to simply look at your CV, and create a story from each point you make about what you achieved at the job. It's also worth looking at the job description and seeing how your experience connects with it.

If you have that skill, great. You can use the language in the description and connect it to your story. If there is a gap, prepare a bridging phrase. Something that says "while I don't X, I do Y."

(If you aren't familiar with STAR, the below example shows how it works. It's about outlining a situation, task, action, and result. An LLM is a great starting point for writing them.)

Let's look at an example:

In the job description: "Experience mentoring juniors as direct reports" for a senior role. But maybe this is your first senior role.

This kind of requirement is usually a nice to have rather than a deal-breaker.

If you don't have this, how can you prepare a great answer?

Think about what you do have. You're very active in code reviews, for example. Perhaps you would write something like this:

• Situation: During a routine code review, I noticed a junior developer had written a database query inside a loop, something that would work fine in testing but would cause serious performance problems in production at scale.
• Task: I needed to flag the issue in a way that was clear and educational, not just a rejection of their work.
• Action: Instead of simply commenting "this will cause an N+1 problem," I left a comment explaining what would happen at scale, linked a short article on the N+1 problem, and suggested we pair for 20 minutes to look at it together. In that session I walked through how to move the query outside the loop and why the database cares about that.
• Result: They fixed it confidently and independently caught a similar issue themselves two weeks later.

Now this is something you can use with a bridging phrase:

• "While I don't have any formal reports at my current role, I am an active participant in code review."
• "I haven't held a senior title yet, but mentoring has been a natural part of how I work with the team."
• "Formal line management hasn't been part of my role, but I've taken ownership of bringing junior developers up to speed on our codebase."
• "I don't have direct reports, but I'm often the person juniors come to before they open a PR or ask a question in standup."

This means you can give a proper answer like this:

"While I don't have formal direct reports yet, mentoring has been a natural part of how I work. Once I was reviewing a PR from a junior on the team and spotted a database query inside a loop. It would have passed testing fine but would have been a real problem in production.

I didn't want to just reject the PR so I left a detailed comment explaining what would happen at scale, linked some reading on it, and suggested we pair for twenty minutes. We walked through the fix together and I explained the reasoning behind it rather than just showing them what to change.

Two weeks later they caught a similar issue themselves in someone else's review. That's the outcome I care about, not just fixing the problem but making sure they understand it."

Your answers should feel like a part of you. Reciting a script from memory is not good communication. Learn the ideas, not the words. Being comfortable with the idea is what creates confidence.

The goal is to speak confidently about what you did, without getting stuck on how to say it.

Even a couple of good, practised interview stories can make a big difference. And if you're smart about what you pick, you can almost always use the same ones.

If you are interested in a more structured approach to feeling confident in software interviews, I offer a review to see if you're ready to interview and secure a role.

We will talk about any difficulties, practice some real answers based on your CV, and create a plan to get you to your dream job.

I've helped dozens of professionals improve their interview skills across the tech industry, and I've also been in awful technical interviews myself so I understand the pain.

If that sounds useful, book here or have a 20 min chat if you're not sure what's right.

Let's Talk