Leading Engineers Who Do Not Report to You

You cannot set the priorities of engineers who report to somebody else, you do not write their review, and you cannot move them off what their own manager asked for this week. Accepting that early is not resignation; it is the beginning of working out what you can actually do, and it turns out to be more than it looks.

What you do hold is the map. You are usually the only person who can see the whole path — from partner onboarding, through the build, through the development underneath it, to go-live and then to the running service — and everyone else is looking at their own segment of it. That asymmetry is real authority, because a team that cannot see what depends on them will optimize for their own segment every time, and they are not being difficult when they do it. They are being sensible with the information they have.

So the work is to convert the map into something each team can act on without needing to hold the rest of it. Not a plan you circulate; a sentence each team can carry: nothing you build after the fifteenth reaches the partner in time to be tested, so the fifteenth is your date rather than mine. Said that way it stops being my request and becomes their constraint, which is the only form an instruction survives in when you cannot enforce it.

The second thing you hold is the ability to make a delay visible early and without blame. A team that hides a slip is almost always protecting itself from a conversation it expects to go badly. If the first three times someone tells you they will be late nothing bad happens to them, the fourth time they tell you earlier — and early is the entire game, because early is when a sequence can still be rearranged.

When you cannot tell people what to do, you can still decide what has to be true before what. Sequencing is instruction that does not require permission, and it is the single most underused tool available to anyone leading across boundaries.

In integration work the sequence writes itself if you look at it from the partner's side rather than from yours. Credentials and environment access have to exist before anything can be tested end to end, so they are not a task for the second week; they are the first thing, and they routinely take longer than the code because they involve people who are not in any of your meetings. The specification has to be agreed before the build, not because that is good practice, but because two teams building against different readings of the same document produce work that passes both their tests and fails together.

So I put every team that has to be ready — business, technical, and external — against the same set of governance checkpoints, and I let the checkpoints do the arguing. A checkpoint is not a status meeting. It is a named condition with a date and an owner, phrased so that it is either true or it is not: the partner has issued test credentials; the field mapping is signed by both sides; the failure path has been exercised at least once against a real error rather than a mocked one.

What that buys is that nobody has to take my word for the order. A team that wants to start later can look at the checkpoint their work feeds and see for themselves what happens. Half the time they are right that they can start later, and finding that out is a gain rather than a loss — a sequence that is tighter than it needs to be spends other people's time to protect my comfort, and they can tell.

A status question invites a status answer, and a status answer is almost always a percentage that cannot be wrong. Eighty percent complete is unfalsifiable, it is offered in good faith, and it tells you nothing you can act on. Two weeks later the same task is at ninety, and the week after that it is at ninety, and then it is late.

Readiness questions are different because they can be answered no. Can the partner call your endpoint today with the credentials they hold. If a message fails validation, where does it go and who sees it. If we ran the go-live script this afternoon, what is the first thing that breaks. Every one of those has an answer somebody can check, and the useful ones come back as no — which is not bad news, it is the schedule finally becoming visible.

I have found the last question especially productive, and I ask it long before it is reasonable to ask. Running the cutover in your head on a Tuesday in week three produces a list of small unowned things — a DNS record nobody has requested, a certificate that expires four days after go-live, an account that exists in the test environment and was never created in production. None of them is hard. All of them take days of other people's calendars, and days are exactly what a compressed schedule does not have spare.

The tone matters more here than the technique. A readiness question can be heard as an audit, and once it is heard that way you will get careful answers rather than true ones. I try to ask it as somebody who expects to find work on my own side too, because usually I do, and the first time you fix something the question surfaced in your own area, the question stops being a threat.

Every integration has at least one party you do not employ, cannot call at nine at night, and whose internal priorities you will never see. That party is on your critical path, and they are usually the reason a date moves.

The mistake is to manage them through the same rhythm as the internal teams. A weekly call with a partner who ships fortnightly is a call where you learn nothing new every other week and then learn something alarming with no time to absorb it. Match the rhythm to their cycle rather than to yours, and spend the meeting on the two things only they can tell you: what is queued ahead of you, and what they need from you that they have not asked for yet.

That second question is worth the whole meeting. Partners are frequently blocked on something small from your side that they have not chased because chasing is awkward and they assumed it was coming. I have lost more days to an unasked question than to a genuine technical problem, and it costs nothing to ask it every time.

Write down what you are relying on them for, in their words, and send it back to them. Not a contract — a paragraph. We understand you will provide test credentials by the twelfth, that the sandbox mirrors production for the three fields we mapped, and that your change freeze runs from the first to the tenth of next month. Half the time a sentence comes back corrected, and the correction is a date you would otherwise have discovered by missing it.

A delivery function is measured on shipping. A continuity function is measured on the absence of an event, and the two ask for opposite instincts from the same person on the same day.

The practical consequence is that you cannot spend all of the schedule. Delivery pressure will always find a use for the last week, and the last week is the one that absorbs the thing you did not foresee. I hold it back deliberately and I say out loud that I am holding it, because a reserve nobody knows about gets spent by somebody who did not know it was a reserve.

It also changes what a good day looks like, and that is harder on a team than people admit. Weeks pass where the visible output is that the service ran and two near-misses were caught before anyone outside noticed. Nobody thanks a team for an outage that did not happen, so the thanking has to come from inside the function — which means writing the near-misses down and reading them back, because otherwise the only stories the team ever hears about themselves are the ones where something went wrong.

And it changes the go-live decision. On a delivery-only measure you go when the build is ready. On this one you go when the build is ready and somebody can operate it at three in the morning without the person who wrote it — which is a different date, and is usually later, and is the one I would defend in front of the business even when it is unpopular. Standing up new entities inside a group makes that concrete: the day operations start is not the day the technology works, it is the day the technology works for people who were not in the project.

I over-sequence. Given a path with real dependencies I will tighten it further than the dependencies require, because a tight sequence is easier for me to hold in my head. The cost lands on other people's calendars and it is invisible to me unless somebody says so, and people rarely say so to the person holding the map.

I am also slower than I should be to escalate when a team is genuinely not going to deliver. Working without authority teaches you to solve things laterally, and that instinct is right until it is not — until the sequence has absorbed everything it can and the only remaining move is to ask somebody's manager to change their priorities. I have waited too long for that conversation more than once, and waiting made it a worse conversation than it needed to be.

And I under-communicate upward while things are going well, because there is nothing to report and the function's output is an absence. The result is that leadership hears from me disproportionately when there is a problem, which quietly trains them to read my name in their inbox as bad news. That is my doing, not theirs, and the fix is boring and works: a short note on a good week, with the near-misses in it.

None of this is solved. I am writing it down because the version of this article that only contained what works would be less useful than the one that admits what a reporting line would genuinely have made easier — and there are days when the honest answer is that it would have.