---
author: "[[Bob Marshall]]"
tags:
  - blogpost
publish: 2026-08-11
sources:
  - https://flowchainsensei.wordpress.com/2026/08/11/truly-modern-software-engineering-means-not-focusing-on-software-and-not-calling-it-engineering/
---

## Truly Modern Software Engineering Means Not Focusing on Software, and Not Calling It Engineering

Nobody that has ever asked me how to build great software has been pleased with the answer. The answer is: build a great team and have them build the software. What people want is a _practice_ — a framework to adopt, ceremonies to run, a coverage threshold to enforce, a squad model to restructure into. What they _get_ is a sentence that appears to hand back the question they asked.

It only appears to. The sentence is doing something specific: it moves the question off the artefact and onto the conditions that produce it. That move is unwelcome because the conditions are slow, awkward and mostly outside the remit of the person asking, whereas a framework can be bought on Thursday. It is also, as far as my 50+ years in the industry tells me, where _all the leverage actually lives._

Three conditions, none of them technical.

- The sociology of how people work together, which decides what can be built at all.
- Where attention gets spent, which decides whether what is built matters.
- And whether anyone is attending to folks’ needs, which decides whether any of it was worth doing.

Code is what falls out of the bottom when those three go well. It is not the subject.

### It’s Sociology, Not Technology

Start with the part that gets misread first. The industry’s default reading of ‘build a great team’ is ‘hire exceptional individuals’, which is why so much organisational energy goes into recruitment funnels and so little into what happens to people after they arrive.

The intellectual justification for that reading usually turns out to be the 10x developer, and the 10x developer usually turns out to be Sackman, Erikson and Grant, writing in 1968. _It is worth actually reading them_.

Their study was not designed to measure programmer variability at all: it compared online with offline access to a computer, using twelve experienced programmers on one task and a smaller group of trainees on another. The order-of-magnitude spread in individual performance was an incidental observation, drawn from a tiny sample, on tasks lasting hours, with one participant using a different language from the others. It is a _curiosity_, not a finding, and half a century of hiring philosophy has been quietly resting on it.

Set against that, the more careful work keeps landing somewhere else. Google’s Project Aristotle, popularised by Charles Duhigg in 2016, went looking for the right mix of individuals and _largely failed to find one._What predicted performance was:

- How members treated one another:
- Whether people spoke in roughly equal measure, and
- Whether it was survivable to admit a mistake or float a half-formed idea.

Gerald Weinberg had reached much the same conclusion in 1971, when he coined ‘egoless programming’ to describe teams in which code belonged to the group and finding a defect in someone’s work _counted as a service_ rather than an accusation. Richard Hackman spent a career on the question and reduced it to five enabling conditions:

- A real team with stable and bounded membership,
- A compelling direction
- An enabling structure
- A supportive organisational context and
- Competent coaching.

Nothing about hiring stars. Four of the five are things done to the environment, not to the roster.

This is the terrain of [_The Team Fruit Bowl_](https://flowchainsensei.wordpress.com/2023/06/19/what-kind-of-team-fruit-are-you/). Each fruit in the bowl is a kind of team: the banana, ripening together and prone to bruising; the coconut, hard-shelled with depth inside; the kiwi, whose worth lies entirely beneath an unpromising surface. The bowl is the organisation, holding an assortment of them at once. The point is that teams differ in kind, not merely in quality — which is why the reflexive managerial move of imposing one template on all of them, the same ceremonies and structure and metrics and everybody a squad, _makes about as much sense as treating everything in the bowl as an apple_. And it is why ‘is this a good team?’ is a far less useful question than ‘what kind of team is this, and what does it need?’

Which raises the obvious question: if any of this is right, _why is so little of it ever acted upon_? The answer, after a half century of observation and study, is unflattering but I believe simply true. Managers and executives do not understand teams. Not the value of them, not how to build one, not what separates a real team from a group of people sharing a reporting line and a Slack channel, not what it costs to break one up — _the whole nine yards._ And the gap is wider than simply teams, because most have no working model of [collaborative knowledge work](https://flowchainsensei.wordpress.com/2021/02/21/management-monstrosities/)_at all._ They manage it as though it were manufacturing with keyboards: output proportional to input, people interchangeable, a project a pile of tasks to be allocated, progress a matter of allocating harder.

Every habit I have called ineffective in this post follows on rationally from that mental model. Splitting attention across three initiatives is sensible if people are fungible units of capacity. Reassigning someone mid-flow is free if the theory really does live in the documentation. Individual performance ranking is obviously correct if performance is an individual property. These are not lapses of care by careless people. They are what competence looks like _when the underlying picture of the work is wrong_ — which is why exhorting managers to try harder achieves nothing, and why _the picture itself_ has to be the thing that changes.

Setting out the replacement picture is why I wrote [_Quintessence_](https://leanpub.com/quintessence). The short version: the quintessential development organisation is not the one with the finest engineers or the tightest process, but the one whose whole shape — structure, relationships, remuneration, flow of value, purpose — is arranged around attending to the needs of the folks that matter. And the measure of quintessence is not velocity, throughput or any other proxy for busyness. It is the consequences of failing to attend to those needs: the cost of ineffectiveness, which is to say [the Cost of Focus](https://flowchainsensei.wordpress.com/2018/09/13/cost-of-focus/). The three keys in this post are that book compressed into a few pages.

There is a stronger version of the claim, and it is the one that makes the sentence non-circular. Melvin Conway’s 1968 paper is remembered for a single line, and the popular paraphrase softens it: his claim was that organisations which design systems are _constrained_ to produce designs that copy their own communication structures. Not tend to. _Constrained_.

If that is even approximately right, the team is not the thing that produces the product architecture. The team, in a meaningful sense, _is_the architecture, decided in advance and enacted later in code. Every reporting line, every team boundary, every choice about which two groups sit in different buildings is a design decision that shows up as a module boundary eighteen months later. Which means a reorganisation is not an HR event that happens to inconvenience the engineers. It is a _large, uncosted, unreviewed architectural change_, usually made by people who would never approve a schema migration without review.

Peter Naur got to the same place from another direction in 1985. The real program, he argued, is a theory held in the minds of the people who built it; the source code is a lossy projection of that theory. A team that has been together for four years is therefore not merely experienced, it is the only surviving copy of a substantial technical asset. Disband it and you have not reassigned headcount, you have _deleted_ the design. DeMarco and Lister catalogued the managerial habits that dissolve teams decades ago in _Peopleware_: fragmented attention, interruption, phoney deadlines, quiet churn. Teamicide, they called it. Melodramatic, and about right.

### The Cost of Focus

The second key is where attention goes, and it is the one I have written about as [the Cost of Focus](https://flowchainsensei.wordpress.com/2018/09/13/cost-of-focus/): the cost of _suboptimal_ focus, of attending to some less relevant needs of some [Folks That Matter](https://flowchainsensei.wordpress.com/2018/06/22/the-folks-that-matter/) to the detriment of other, more relevant needs of other Folks That Matter. Resources are always finite. Choosing where to point them is not an administrative afterthought, it is the decision that determines what the work is worth.

It helps to name the thing being spent. Call them our Attentions: the set of things an organisation actually attends to, as opposed to the set it claims in its strategy deck. Attentions are finite, they are always allocated whether or not anyone decides to allocate them, and what we attend to determines what gets done. Most organisations point theirs at velocity, utilisation, cost, tooling, compliance and the quarterly deck. Each of those is a need of somebody, which is why it survives. The question is never whether we are attending to something. It is _whether we are attending to the things most worth attending to._

Which begs the question: worth most to whom, and how would we know? I gave my answer years ago in _What is Value?_, and it is Goldratt’s. The things most worth attending to are those that relax the customer’s constraint, thereby increasing the throughput of their business — not the features they asked for, not the ones we find interesting to build, but the small number that unblock the thing actually limiting them. Everything else is elaboration. And since you can only identify a constraint you understand, the corollary is to work with the customers or segments you understand best, or can realistically come to understand.

Note how badly that sits with the way most backlogs are assembled. A backlog ranked by stakeholder seniority, or by shouting volume, or by an estimate of effort divided by a guess at value, is not an attempt to find anyone’s constraint. It is a queue of elaborations, sorted. And a team can work through such a queue at impressive velocity for years without ever achieving anything of value.

The common organisational failure is not a failure to assemble capable people. Most companies of any size have these. The failure is what happens next: the good team is assembled and then systematically prevented from building anything, through decisions that all look, locally, reasonable.

It happens through split attention, three initiatives per person so that nothing is anyone’s. It happens through handing down solutions rather than problems, which converts a group of expensive people into a group of expensive typists and discards precisely the judgement you hired for. It happens through reassignment at the six-month mark, just as the theory has finished forming. It happens through measuring output rather than needs met, because output is legible and needs met is contested.

The common thread is a decision to move judgement away from the people holding the context and towards the people holding the org chart. That is the expensive move, and it is expensive in a way no budget line records. A team that cannot change its own system, choose its own tools or refuse a request has been quietly converted into a queue, and queues do not build great software. _They process tickets._

And this is not only a question for executives. Everyone faces the same dilemma several times a day. Which module first? Which test is worth writing? Whose understanding is it most valuable to go and acquire this morning? Where we choose to focus determines what gets built, and how others come to see us and our efforts.

### Attend to Folks’ Needs

The third key is the one that makes the other two coherent, and it is four words: **attend to folks’ needs.**

The word carrying the weight is not ‘needs’. It is ‘attend’. _Meeting_ needs implies action, solutions, gaps filled — a transaction. _Attending_ to needs means presence and recognition, actually orienting towards the person in front of you rather than harvesting requirements from them. Most people have little conscious awareness of what they need. You will not get it from a form.

Nor is attending merely passive. [Attentiation](https://flowchainsensei.wordpress.com/2025/06/16/attentiation/) is the deliberate act of bringing something forth through focused attention and care, and it sits exactly at the intersection of observation and creation: sustained caring focus does not just notice what is there, it participates in bringing forth what could be. That is a more accurate description of good development work than anything in the engineering vocabulary. The needs of the folks that matter are not sitting fully formed in someone’s head waiting to be elicited. They are brought forth in the attending. Which is why a team that spends real time with the people it serves ends up building something nobody could have specified in advance, and a team fed tickets from a backlog does _not_.

‘Folks’ is doing work too. It means everyone involved, not just the paying customer and not just the end user: the colleague who maintains the code, the person carrying the pager, the support team who inherit the consequences, the developers themselves. A team is great to the precise extent that the needs of the folks in and around it are being attended to. That is not a poetic restatement. It is the thing that dissolves the apparent circularity in the opening sentence, because it names a condition you can act on this morning rather than an outcome you can only score after the fact.

It also explains why so much conventional practice produces so little. Ceremonies, frameworks, estimation rituals and coverage thresholds are all ways of attending to something other than folks’ needs — usually to the need of a distant manager for the appearance of control. Which is a need, and belongs on the list, _but rarely the most relevant one._

Notice that none of the three keys is about software. That is the point of the title. The artefact is downstream of the sociology, downstream of where attention goes, downstream of whose needs get attended to. Calling the discipline ‘engineering’ points us at the artefact and away from all three.

### What This Means for Hiring and Job Titles

If the three keys are indeed key, then most of what we do to bring people into this work is aimed at the wrong target.

Start with the titles, because they are the cheapest thing to be wrong about and the most expensive to leave alone. Software engineer. Developer. Programmer. Coder. Every one of them names the artefact and says, plainly, that the job is producing it. Titles are not decoration. They tell the holder what excellence looks like, they tell everyone else what to ask for, and they filter who applies in the first place. Advertise for a software engineer and you will get people who believe their job is engineering software, and be faintly puzzled when they turn out not to attend to anyone’s needs (if you ever notice at all).

I have gone as far, elsewhere, as suggesting that the honest name for someone who orients their whole practice around the needs of the folks they serve is not ‘developer’ but something closer to social worker. That will strike most readers as absurd, and the absurdity is the useful part: notice how much of the profession’s self-image has to be true for it to sound ridiculous. The same reframing works on management. A manager, on the definition I have used elsewhere, is a person whose role is to coordinate how folks’ needs get attentiated — and in non-hierarchical settings that function tends to _distribute itself across the team_ rather than sit with one titled (and entitled) individual.

Whilst we are at it: ‘resource’, ‘headcount’ and ‘FTE’ are not merely impolite. They encode interchangeability, which is exactly the assumption Naur’s theory-building demolishes.

Hiring follows the same logic. The standard interview isolates one individual, removes their team, removes the domain, removes the codebase, and measures how well they solve an unfamiliar puzzle whilst being watched. It is a near-perfect instrument for measuring the one attribute least predictive of what we actually care about — and it is built on the 10x assumption, which as we have seen was a fallacious accident of a 1968 study about terminal access.

What would follow instead:

Hire for how someone attends. In conversation, do they ask about the people affected, or only about the stack? Do they listen to an answer or wait for their turn? Can they hold a disagreement without needing to win it? These are observable in an hour, and they are the traits that determine whether a team gets better or worse when this person joins it. (See also Lencioni’s Ideal Team Player).

Hire into a specific team, _and let that team decide_. A candidate is not an abstract quantity of capability to be added to a pool; they are a change to a particular set of relationships. Nobody upstream is qualified to judge that.

Stop calling people resources, and mean it. Naur’s argument makes the fungibility assumption not merely rude but _factually wrong_: the theory lives in people, so moving a person is deleting and rewriting part of the design. An allocation spreadsheet cannot see this, which is why it keeps authorising it.

Write job ads that describe the folks that matter and the needs to be attended to, rather than a list of technologies. You will get fewer applicants and better conversations.

And look hard at the career ladder, which is where all of this either sticks or unravels. Most ladders promote for individual technical output, which quietly informs everyone that attending to folks’ needs is what you do until you are senior enough to stop. If ‘senior’ does not mean ‘attends better’, the ladder is teaching the opposite of everything above.

### Where the Argument Is Weakest

I should mark the limits, because I have made this sound tidier than it is.

The circularity does not vanish entirely. ‘Great team’ remains partly defined by outcome, which makes the sentence easy to apply after the fact: the project failed, so the team cannot have been great. That is unfalsifiable and worth resisting.

A great team on the wrong problem produces an elegant failure. Team quality is close to necessary and nowhere near sufficient; nothing in any of this tells you whether anyone wants the thing.

The two middle keys are also in real tension. Attending to folks’ needs pulls towards inclusion — everyone’s needs matter. Cost of Focus insists that in any resource-constrained situation, some needs get discounted or deferred, and pretending otherwise is just a slower way of serving nobody. I do not think that tension resolves. It has to be held, _deliberately and out loud,_ which is harder than either principle alone. The idea of the [Needsscape](https://flowchainsensei.wordpress.com/2018/09/10/the-needsscape/) makes this tension at least visible and trackable.

And the evidence is softer than confident citation suggests. The Google result reached most of us through a newspaper article rather than a published study, and describes one very unusual company. Hackman’s conditions came largely from orchestras, cockpit crews and analyst teams; the transfer to software is an assumption. Conway’s law, read strictly, asserts a correspondence between communication structure and system structure without settling which way causation runs, so the use I have made of it goes further than the paper licenses.

### What to Do on Monday

Keep teams together for longer than looks efficient on a resourcing spreadsheet. Give one team one thing. Hand down problems, not solutions, and be specific about constraints instead of specific about design. Treat every reorganisation as an architectural review. Protect uninterrupted time as infrastructure, because it is. Make it survivable, in public, for the most junior person present to say that something will not work. And make explicit, at least once a quarter, whose needs you are currently attending to and whose you have chosen to defer — because you have chosen, whether or not anyone said so, or even noticed

Then have them build it, and be disciplined about the difference between wanting to know how it is going and wanting to be involved.

### Further Reading

Conway, M. E. (1968, April). How do committees invent? _Datamation, 14_(5), 28–31. [https://www.melconway.com/Home/Committees_Paper.html](https://www.melconway.com/Home/Committees_Paper.html)

DeMarco, T., & Lister, T. (2013). _Peopleware: Productive projects and teams_ (3rd ed.). Addison-Wesley Professional.

Duhigg, C. (2016, February 25). What Google learned from its quest to build the perfect team. _The New York Times Magazine_. [https://www.nytimes.com/2016/02/28/magazine/what-google-learned-from-its-quest-to-build-the-perfect-team.html](https://www.nytimes.com/2016/02/28/magazine/what-google-learned-from-its-quest-to-build-the-perfect-team.html)

Goldratt, E. M., & Cox, J. (2004). _The goal: A process of ongoing improvement_ (3rd rev. ed.). North River Press.

Hackman, J. R. (2002). _Leading teams: Setting the stage for great performances_. Harvard Business School Press.

Marshall, R. W. (2012, May 6). What is value? _Think Different_. [https://flowchainsensei.wordpress.com/2012/05/06/what-is-value/](https://flowchainsensei.wordpress.com/2012/05/06/what-is-value/)

Marshall, R. W. (2012, May 27). Focus. _Think Different_. [https://flowchainsensei.wordpress.com/2012/05/27/focus/](https://flowchainsensei.wordpress.com/2012/05/27/focus/)

Marshall, R. W. (2013, October 12). The antimatter principle. _Think Different_. [https://flowchainsensei.wordpress.com/2013/10/12/the-antimatter-principle/](https://flowchainsensei.wordpress.com/2013/10/12/the-antimatter-principle/)

Marshall, R. W. (2018, June 22). The folks that matter. _Think Different_. [https://flowchainsensei.wordpress.com/2018/06/22/the-folks-that-matter/](https://flowchainsensei.wordpress.com/2018/06/22/the-folks-that-matter/)

Marshall, R. W. (2018, September 13). Cost of focus. _Think Different_. [https://flowchainsensei.wordpress.com/2018/09/13/cost-of-focus/](https://flowchainsensei.wordpress.com/2018/09/13/cost-of-focus/)

Marshall, R. W. (2021). _Quintessence: An acme for highly effective software development organisations_. Falling Blossoms. [https://leanpub.com/quintessence](https://leanpub.com/quintessence)

Marshall, R. W. (2023). _The team fruit bowl_. Falling Blossoms (Leanpub). [https://leanpub.com/theteamfruitbowl](https://leanpub.com/theteamfruitbowl)

Marshall, R. W. (2025, June 10). The antimatter principle: Why nobody needs their needs attended to. _Think Different_. [https://flowchainsensei.wordpress.com/2025/06/10/the-antimatter-principle-why-nobody-needs-their-needs-attended-to/](https://flowchainsensei.wordpress.com/2025/06/10/the-antimatter-principle-why-nobody-needs-their-needs-attended-to/)

Marshall, R. W. (2025, June 16). Attentiation. _Think Different_. [https://flowchainsensei.wordpress.com/2025/06/16/attentiation/](https://flowchainsensei.wordpress.com/2025/06/16/attentiation/)

Marshall, R. W. (2025, June 18). Defining attentiate: A new word for our language. _Think Different_. [https://flowchainsensei.wordpress.com/2025/06/18/defining-attentiate-a-new-word-for-our-language/](https://flowchainsensei.wordpress.com/2025/06/18/defining-attentiate-a-new-word-for-our-language/)

Marshall, R. W. (2025, June 21). The vocabulary problem. _Think Different_. [https://flowchainsensei.wordpress.com/2025/06/21/the-vocabulary-problem/](https://flowchainsensei.wordpress.com/2025/06/21/the-vocabulary-problem/)

Marshall, R. W. (2026, April 28). Honestly: What is software for? What is software development for? _Think Different_. [https://flowchainsensei.wordpress.com/2026/04/28/honestly-what-is-software-for-what-is-software-development-for/](https://flowchainsensei.wordpress.com/2026/04/28/honestly-what-is-software-for-what-is-software-development-for/)

Naur, P. (1985). Programming as theory building. _Microprocessing and Microprogramming, 15_(5), 253–261. [https://doi.org/10.1016/0165-6074(85)90032-8](https://doi.org/10.1016/0165-6074\(85\)90032-8)

Rosenberg, M. B. (2015). _Nonviolent communication: A language of life_(3rd ed.). PuddleDancer Press.

Sackman, H., Erikson, W. J., & Grant, E. E. (1968). Exploratory experimental studies comparing online and offline programming performance. _Communications of the ACM, 11_(1), 3–11. [https://doi.org/10.1145/362851.362858](https://doi.org/10.1145/362851.362858)

Skelton, M., & Pais, M. (2019). _Team topologies: Organizing business and technology teams for fast flow_. IT Revolution Press.

Weinberg, G. M. (1971). _The psychology of computer programming_. Van Nostrand Reinhold.