Reading the market and the org

Problem. An engineering manager who only pays attention to their own team gets steered by whichever function makes the loudest case at planning time, and the loudest case almost always comes from the function whose work is easiest to count. Revenue is easy to count, and so are roadmap dates. Churn that has not happened yet is not, and neither is the cycle your company has been running for three quarters without anyone naming it. If you are not looking outside your team, you absorb someone else's picture of where things are going by default.

Frame. Most engineering-management books frame this work as a peer network for getting promoted. What I mean by reading the market and the org is different: a small set of conversations across non-engineering functions, where the views often disagree, fed back into how you spend your team's time. Books written for senior executives describe this work in sharper terms than engineering books do, and on a small team nobody else is doing it, so the engineering manager picks it up in a lighter form.

The moves below are what I have settled into. None of them requires a title change or a new ritual, and every one of them requires defending a small amount of attention every week.

Build a cross-functional signal stream

I keep one trusted contact per non-engineering function:

• Product, the person closest to what is coming three months out.
• Sales, the one who will tell you what is closing and what is stalling, and why.
• Support, the one who can name the recurring themes in tickets and not just count them.
• Marketing, the one tracking how the company is being positioned in the market and what competitors are saying.
• Finance or ops, where they exist, for the true cost of each customer and how much runway the company has.

That comes to five conversations of twenty minutes each, on whatever cadence your calendar will hold. They are the first thing to get cut when things get busy, because skipping one costs nothing anyone can see this week. Defend them anyway.

It is easy to slide into the other kind of cross-functional network, the one most engineers were taught to dislike, where favors get traded for political cover and a path to promotion. What I want from this one is narrower: to know what each function is feeling about the next two quarters, because each of them sees something about where things are heading that I cannot see from inside engineering. When the conversation drifts into who is in and who is out, the signal collapses, so I pull it back.

Hold the conflicting views together

Most of the time the functions agree, and the valuable moments are the ones where they do not.

Here is one example I have watched play out. Sales sees ten features they could sell this quarter, while support and product see existing users hitting stability and performance issues. Building the ten brings in new customers while existing ones leave, and two quarters later churn is the dominant story, with sales asking why nobody fixed it. By the time customers refuse to renew, it is too late to fix cheaply.

The engineering manager ends up the only person able to hold both views at once, and not through any special virtue: product is focused on the roadmap, sales does not feel churn until renewal season puts it on their number, and support, which sees the tickets, has no say in how engineering's time gets spent. The job is to figure out what each path costs two quarters from now, then shift engineering's time accordingly. Engineering's time is the only resource you control, and the other functions still own their own decisions.

Read the loop, do not run another lap

Some of what looks like a decision is the org running a cycle:

• Centralize platform, decentralize platform, centralize again.
• Quality push, velocity push, quality push.
• Hiring freeze, hiring spike, freeze.
• Start the initiative, stop it, restart it twelve months later with a new name.

When the déjà vu hits on a planning call, name the cycle to yourself first, then propose a smaller version of the work, small enough to survive the next swing back. You are not fighting the cycle when you do this. You are choosing work that stays worth doing whichever way it swings. Seeing the cycle also makes cynicism tempting, but if you stop participating because you know how this round ends, the cycle runs anyway, and you have given up your one chance to make the swing smaller.

Run the three-step pass

Run a three-step pass on the decisions that matter:

• Perception, what am I taking in.
• Comprehension, what does it mean in context.
• Projection, what does it imply two or three quarters out.

Most of us collapse all three into gut feel and move on. Projection is the step most often skipped, which matters because a decision that does not survive its own projection is just a preference. It is also possible to perform all three steps on paper without letting them change the answer, which is theatre with better documentation.

Keep a standing outside-the-org watch

Set aside a standing block of thirty to sixty minutes, on whatever cadence your market warrants, and defend it the way you would defend a one-on-one. The sources:

• Competitors' changelogs and shipping cadence.
• Public posts from competitors' leaders.
• Hiring patterns on competitors' job boards.
• Customer discussion on forums and review sites.
• Broader shifts that touch the team's domain.

Bigger companies sometimes hire a dedicated strategy or competitive-intelligence role to do this full-time. Smaller teams cannot afford that, so the engineering manager carries a lighter version of the work themselves, and the carrying has gotten easier: it used to take hours of reading per signal, and with the summarization and monitoring tools available now it is closer to a habit than a project.

The watch has a failure mode of its own, which is hoarding: if the outward signal never feeds a team decision, the watch has turned into a personal hobby, funded by attention you needed elsewhere.

Notice early, intervene quietly

The last move ties the rest together. When you notice something quiet that is not yet worth raising with the team, write it down and watch for confirmation, then act at the earliest point where the fix is still small. Most leaders default to one of two timings: raising it too loudly and too early, which burns credibility, or waiting until the problem shows up in a number, because a number is safe to raise and a hunch is not, by which point the cheap fix is gone.

The other way to waste a signal is to sit on it until it is too late to act and then tell everyone you knew.

When not to

This work stops in two places. The first is when what you see genuinely conflicts with what leadership has already committed to. That belongs to a different conversation, making the upward case and disagreeing and committing honestly, and reading well sets that conversation up without replacing it. The second is when the reading starts producing more notes than action. If you can name the org cycle, see the competitor shift, and write the projection, but engineering's time never moves because of any of it, you are doing the work for its own sake.