What Engineering Leadership Actually Looks Like on a Team of 14

No org chart was redrawn in the making of this post.

There’s a piece from the Software Leads newsletter on engineering leaders’ day-to-day activities that we passed around internally. Its argument is that management work looks invisible next to writing code, but it isn’t formless. It’s a cycle of six activities that repeats all day: gathering information, sharing it, making decisions, influencing decisions you don’t own, setting direction, and planning.

We recognized every one of them. We also realized we do almost none of them the way the framework implicitly assumes, because that framework is written for a manager inside a larger org. We’re 14 engineers and designers, fully remote since 2023, and we ship our own products alongside client work.

So here’s the same six activities, and what each actually looks like at our size. Some of them get easier. A couple get harder in ways nobody warns you about.

Gathering Information

The article makes a point we’d underline twice: everything downstream depends on the quality of what you collect first. Bad inputs, bad decisions, and you won’t find out for weeks.

At a larger company this is a real job. You’re pulling context from skip-levels, dashboards, incident reviews, and three teams who each describe the same problem differently.

At our size, most of it arrives on its own. We’ve written about how we run standups, and that meeting is doing more work here than anything else we do. Fifteen minutes a day where people share what’s interesting rather than report status, and you end up with a running picture of the team that no dashboard would give you. You hear the hesitation before someone says “it’s fine.”

The catch is that this only works because we’re small enough for one room. It doesn’t scale, and we know it. We’ve watched clients hit the size where informal context stops arriving and nobody notices for a quarter, because the absence of information doesn’t announce itself. If your standup has 25 people in it, you no longer have this. You have a status meeting wearing a standup’s clothes.

Sharing Information

This is where being small stops helping and starts actively lying to you.

When everyone hears everything, you assume everyone knows everything. They don’t. Someone was on holiday. Someone was heads-down in a migration for two weeks. Someone joined last month and has no idea that the thing you all call “the old billing thing” was a deliberate decision and not an accident.

Our rule from the standup post covers this: it’s ephemeral, and anything critical has to be repeated in writing. That rule exists because we got it wrong. We’ve had decisions that everyone present agreed on, that nobody wrote down, and that got relitigated a month later by people who were simply not in the room. Twice.

The fix isn’t more meetings. It’s accepting that verbal context has a shelf life of about a week and writing down the small set of things that need to outlive it.

Making Decisions

The article’s sharpest line: waiting for certainty is itself a decision, and it carries its own cost.

We’d add the small-team version. When you’re 14 people, the cost of a wrong reversible decision is genuinely low. You can try a thing, hate it, and undo it inside a sprint. The cost of a slow decision is much higher than it looks, because the whole team is blocked on it and there’s no other workstream to absorb the delay.

So we bias hard toward deciding fast on anything reversible and slow on anything that isn’t. Database schema, framework choice, anything that touches a customer’s data: slow, written down, argued about. Which library, which folder structure, how we name things: decide in the standup, move on, revisit if it hurts.

We’re not always right about which bucket something is in. The tell is usually that a “small” decision keeps coming back. When something reversible gets relitigated three times, it wasn’t reversible and we misjudged it.

Influencing Decisions You Don’t Own

For a manager inside a company, this means peer teams. For us it usually means the client.

This is the activity we spend the most time on and the one we were worst at early on. We’d deliver a technical recommendation that was correct, watch it get declined, and conclude the client didn’t get it. What was actually happening is that we were answering a question nobody had asked. The CTO’s constraint wasn’t technical quality. It was a board meeting in five weeks.

The article frames this as understanding your peers’ goals, constraints, and incentives. That’s the whole thing. A recommendation that ignores someone’s actual constraint is not a recommendation, it’s a complaint with a diagram attached.

What changed for us was tying the technical argument to the thing the person is actually being judged on. “This will bite us later” moves nobody. “This adds two weeks now, or roughly six weeks in Q4 when you’re trying to close the round” is a sentence someone can act on. We wrote about a version of this going wrong in the velocity metric that quietly broke our client.

Setting Direction

The framework describes translating organizational priorities into something the team can act on, and modeling the standards you expect.

We get the first half nearly free. There’s no layer between the people deciding what to build and the people building it, so priorities don’t need much translation. That’s a real advantage of staying small and we don’t intend to give it up.

The second half is the part that doesn’t care how small you are. If we say timelines are honest and then quietly pad every estimate, everyone learns the actual rule in about two weeks. If we say the standup is not a reporting meeting and then a founder uses it to check on progress, it’s a reporting meeting now, whatever the docs say.

Building Arheev turned out to be the most direct version of this. When you run your own product on your own process, the gap between what you claim and what you do stops being an abstraction. We found several places where our advice to clients was better than our own practice.

Planning

Getting from where you are to where you want to be, in concrete steps.

Our version is deliberately short-horizon: two-week sprints with working software at the end, and a first working demo in two to four weeks. Not because long-range planning is worthless, but because at our size the plan’s accuracy falls off a cliff past about a month, and pretending otherwise just produces a document that makes everyone feel organized.

The one thing we do plan long is people. Who’s on what, who’s getting bored, who hasn’t touched anything new in six months. That has a much longer lead time than any technical decision, and it’s the one where being late is genuinely expensive.

What We’d Take From It

The six activities hold up. We’d argue the framework is describing something real and mostly invisible, and that alone makes it worth reading.

What it doesn’t say, and what we’d add: at a small size, three of these get easier for free and you should not mistake that for having solved them. Information arrives on its own until it doesn’t. Direction needs no translation until there’s a layer that needs it. The two that never get easier, at any size, are influencing decisions you don’t own and modeling the standard you claim to hold.

Those are also the two you can start being better at tomorrow, without reorganizing anything.

No frameworks were harmed. A few were gently disagreed with.