Choosing Problems and Choosing Companies

Choosing Problems and Choosing Companies is the decision with the largest effect on the rest of this book, because every skill in it compounds at a rate the organisation sets. The same behaviour that earns latitude in one company is absorbed without trace in another. So the question at an interview is not whether the work is interesting. It is whether a decision you make there will still matter in two years.

Key takeaways

• DORA's 2025 report, from nearly 5,000 technology professionals, found AI acts as an amplifier of existing strengths and dysfunctions. Used as a diagnostic, that means the organisation you join decides the sign of your own effort, not just its size.
• Platform quality is the variable that decides whether an AI budget returns anything. The same report found 90% of organisations have adopted at least one internal platform, and that platform quality correlates with the ability to unlock value from AI.
• DORA's follow-on ROI work frames value realisation as a J-curve, meaning a productivity dip before long-run return, attributed to learning, code-review overhead and process adaptation. A company that has not budgeted for the dip will find someone to blame for it.
• Four dials are readable from outside: platform quality, clarity of the organisation's AI stance, capital runway and decision latency. The combination matters more than any single reading.
• Runway is a technical constraint, not a finance detail. CB Insights, reviewing 431 VC-backed shutdowns since 2023, found 70% ran out of capital and 43% had poor product-market fit.

Read this after Chapter 8, because the limit named at the end of that chapter is what this one acts on, and before Chapter 12, which is what to do when no employer is the right multiplier. Where the question is whether a product should contain a model at all, that argument is where AI belongs in a product.

Two offers, same title, same kind of product.

In the first, the team can deploy in twenty minutes, a new service takes a day to scaffold, and the last three architectural decisions are written down in the repository with dates on them.

In the second, deployment requires a ticket to another team, there is no written record of why anything is the way it is, and the AI strategy is a directive to use the tools with no statement of what for. The second company will describe itself as moving fast. The details here are composited from ordinary organisational shapes rather than one company, and the shape is exact.

A company is a multiplier, and the sign varies

The framing that makes this decision tractable is arithmetic rather than emotional.

Your judgement produces some quantity of value per year. An organisation multiplies it, by giving your decisions reach, by preserving them so they still apply next year, and by letting evidence rather than politics settle disagreements. A good multiplier makes two years of your work worth five. A bad one makes it worth nothing you can point at, because every decision was reversed by the next reorganisation.

The multiplier is not the same as prestige, and it is not the same as compensation. Those are different goods and they trade against this one, which is why this chapter does not discuss them.

What compounds is decisions that survive. So the diagnostic question for any organisation is simple: what happens here to a good decision made eighteen months ago.

The amplifier finding, used as a diagnostic

DORA's State of AI-assisted Software Development 2025, from nearly 5,000 technology professionals plus more than 100 hours of qualitative work, states that AI amplifies the strengths of high-performing organisations and the dysfunctions of struggling ones. Chapter 1 used that as a statement about scarcity. Here it is a hiring test.

If AI amplifies what is already there, then joining a dysfunctional organisation now carries a higher cost than it did three years ago. The dysfunction gets louder faster. A team with unclear ownership and thin review capacity does not stay merely slow when you add generation to it: it accumulates unreviewed change at speed.

The same report notes that adoption continues to relate negatively to software delivery stability. It also derived seven distinct team profiles through cluster analysis, which matters here because it establishes that teams are not on one ladder. There is no single AI maturity you can ask about.

So the useful question in an interview is behavioural rather than strategic. Ask what changed in how they review and release after adoption, and listen for whether anything changed at all.

Platform quality decides whether the AI money returns anything

This is the most actionable finding in the report for someone choosing an employer.

DORA reports that 90% of organisations have adopted at least one internal platform, and that the quality of that platform correlates with an organisation's ability to unlock value from AI. Read that as a constraint on your own effectiveness. Generation speed is irrelevant if the path from a merged change to production is measured in days and tickets.

Platform quality is also the easiest thing to measure from outside, because you can ask direct questions with numeric answers. How long from merge to production. How many approvals. Can a new service be created without another team's involvement. How long does the test suite take, and how often is it red on the main branch.

Vague answers to those are the answer. In my experience a team with a good platform tells you the numbers immediately, because they watch them, and a team without one explains why the numbers are complicated.

The dip is expected, and an unprepared company blames a person for it

There is a second DORA publication worth knowing about for one idea, and I am using it for the idea rather than for any figure.

DORA's ROI of AI-assisted Software Development work frames value realisation as a J-curve: a productivity dip before long-run return, with the dip attributed to learning, code-review overhead and process adaptation. The landing page I could read carries no financial figures, and the modelled returns quoted elsewhere are not on any page I could verify, so they are not in this book.

The J-curve shape alone is decision-relevant. An organisation that expects the dip treats the first two quarters as investment and protects the people doing the adaptation. An organisation that does not expect it experiences the same dip as underperformance, and looks for an explanation in individuals.

That is a question you can ask directly. What did leadership expect to happen to delivery speed in the first six months of adoption, and what actually happened. The answer tells you how the next unexpected thing will be handled.

Four dials to read before joining

Four things are readable from outside, and the combination predicts more than any one of them.

Two combinations are worth naming. High platform quality with high decision latency is a comfortable place to become slow. Short runway with clear AI stance and low decision latency is genuinely good learning and a real risk, which is a trade you can take deliberately at some stages of a career and not others.

Questions that get real answers

Interviews are mostly theatre in both directions, and a few questions cut through because they cannot be answered well without the underlying reality being good.

I ask four. What is the last technical decision the team reversed, and how was that decided. What happens when a senior engineer and a product manager disagree about scope. Who was the last person promoted to a role above yours, and what did they do. And what is currently in the codebase that everybody knows is wrong and nobody is fixing.

That last question is my favourite and I would ask it every time. Every codebase has one. A team that names it quickly, explains why it persists, and knows what it would cost to fix is a team that reasons about its own state. A team that says there is nothing like that has either not looked or will not tell you, and both are informative.

What I have seen is that these four predict whether judgement compounds better than any question about technology choices. I cannot prove that to you. It is a pattern from being on both sides of the table.

Runway is a technical constraint

Engineers treat funding as somebody else's subject, and it decides which technical decisions are available to you.

CB Insights, reviewing 431 VC-backed shutdowns since 2023, found that 70% ran out of capital and 43% had poor product-market fit. Capital exhaustion is the recorded final cause far more often than any technical failure, which means the constraint on your work is frequently time to revenue rather than correctness.

The practical consequence is that runway sets the acceptable half-life of a decision. With eighteen months of runway, a rewrite that takes nine months is not a technical proposal, it is a bet on the company's existence. With a profitable business, the same proposal is ordinary maintenance.

Indeed Hiring Lab's 8 July 2026 post is the market-level context: postings recovering, with 71% of the increase between May 2025 and May 2026 in senior roles. Demand for judgement exists. It is concentrated, and it moves, which is another reason not to tie your position to one employer's fortunes.

Choose the problem, not the logo

The last thing to weigh is the problem itself, and it is undervalued relative to the company name.

A problem is worth your years if it has three properties. It generates real feedback, meaning you find out whether you were right within weeks rather than never. It has a technical core rather than only a coordination core, because coordination skill does not transfer as cleanly. And it is one you will still find interesting after the novelty goes, which is roughly month four.

Domain matters more than people expect, for an unglamorous reason. Deep domain knowledge is contextual by Chapter 3's classification, meaning it does not travel, but the systems intuition you build inside a hard domain does. Payments, scheduling, logistics and anything with regulatory constraints teach invariants that hold everywhere.

The counter-case is real too. A boring problem inside an organisation with a great platform and short decision latency will teach you more than a fascinating problem inside a bureaucracy. When forced to choose, I would take the multiplier.

The objection: most people do not get to choose

Correct for many readers, and the chapter is still usable at a smaller scale.

Nobody in a constrained market is choosing between two offers on philosophical grounds. What the four dials are actually for is quieter. They tell you what you are inside, which tells you where to spend effort: if decision latency is high and nothing survives, then building portable artifacts and public work matters more, and internal goodwill matters less.

There is a second, more useful application. The dials are readable about your current employer, and the readings change. A platform that improved, an AI stance that got written down, a decision record culture that took hold: those are reasons to stay that have evidence behind them, and their absence over two years is evidence too.

In my experience the people who end up trapped are not the ones who joined the wrong company. They are the ones who never took the reading, so they had no date on which the situation stopped being temporary.

Chapter summary

An organisation is a multiplier on your judgement and the sign varies, because the multiplier is made of whether your decisions reach anything, survive, and are settled by evidence rather than politics. DORA's 2025 report, from nearly 5,000 technology professionals, found AI amplifies existing strengths and dysfunctions. That turns organisational quality into a higher-stakes choice than it was three years ago, since a team with thin review capacity now accumulates unreviewed change at speed. The same report found 90% of organisations running at least one internal platform, with platform quality correlating with the ability to unlock AI value, and that dial is the easiest to read because its questions have numeric answers. DORA's ROI work frames value realisation as a J-curve with a productivity dip before return, attributed to learning, review overhead and process adaptation, and an organisation that did not budget for the dip will look for an individual to explain it. Four dials are readable from outside, being platform quality, AI stance clarity, capital runway and decision latency, and combinations matter more than single readings. Four interview questions cut through, the best being what everybody knows is wrong in the codebase and nobody is fixing. Runway is a technical constraint, since CB Insights found 70% of 431 VC-backed shutdowns since 2023 ran out of capital, and runway sets the acceptable half-life of a decision. And a problem is worth your years when it produces fast feedback, has a technical core, and still interests you in month four.

Thresholds come next, because the behaviours in Chapters 6 through 9 eventually change what your job is rather than how well you do it. Chapter 10 is The Senior Jump, and the One After It, where output stops being your code and becomes other people's decisions.