The psychology of stressful projects: when one expert beats an entire team

Would this go faster with fewer people?

There is a question that hangs over every complex project. It usually goes unspoken, because asking it feels almost heretical in an age of agile, collaboration and daily standups: would this actually go faster with fewer people?

More often than anyone likes to admit, the answer is yes. Not always, and not for everything. But for one kind of work, the high pressure, tightly connected kind, one experienced developer who can hold the whole problem in their head will often beat a team of good developers who spend half their time explaining things to each other.

This is not an argument against teamwork. It is an argument for knowing when teamwork helps and when it becomes the thing slowing you down. Every business and every number in the worked examples below is invented.

Every extra person adds more than one conversation

Every person you add to a project adds communication overhead, and not in a straight line. Two people need one channel. Three people need three. Four need six. Five need ten. By the time you have a team of eight, there are 28 possible pairs of people who may need to talk, and keeping everyone aligned becomes a job in itself.

Fred Brooks set this out in The Mythical Man Month in 1975, drawn from his time managing the IBM System/360 project. If every part of a task has to be coordinated with every other part, he wrote, the effort grows with the number of pairs, and adding people to a late software project makes it later. That second sentence became known as Brooks's law.¹

The number of pairs is a small formula:

$$C(n) = \frac{n(n-1)}{2}$$

Here $C(n)$ is the number of communication paths in a group, $n$ is the number of people, $n-1$ is the number of other people each person could talk to, and the division by $2$ counts each path once, because the path from Áine to Brian is the same as the path from Brian to Áine. The person you add next brings $C(n) - C(n-1) = n - 1$ new paths with them, so each addition costs more than the one before. That is the gap between the marginal and the average, explained in Foundations: marginal versus average.

Worked example: a Cork checkout team grows from three to eight

A Cork studio, patrickstreetdigital.example, is rebuilding a checkout with three developers. The client wants it sooner, so the studio adds five more.

Step 1, the paths. With three people, $C(3) = \frac{3 \times 2}{2} = 3$. With eight, $C(8) = \frac{8 \times 7}{2} = 28$. The team is $8 / 3 \approx 2.7$ times bigger, and the number of paths is $28 / 3 \approx 9.3$ times bigger.

Step 2, an assumption for the example: each pair that needs to stay in step spends 10 minutes a day doing so, which costs 20 person minutes, because two people are in the conversation.

Step 3, the daily cost. Three people: $3 \times 20 = 60$ person minutes. Eight people: $28 \times 20 = 560$ person minutes, a little over nine hours.

Step 4, the share of capacity. At seven and a half hours a day, three people have $3 \times 450 = 1{,}350$ minutes, so coordination takes $60 / 1{,}350 \approx 4.4\%$. Eight people have $8 \times 450 = 3{,}600$ minutes, so coordination takes $560 / 3{,}600 \approx 15.6\%$.

The studio more than doubled its headcount and more than tripled the share of each day spent keeping people in step.

The horizontal axis is the number of people on the team, the vertical axis the possible communication paths between them. The bars curve upwards: going from nine to ten people adds nine paths, going from two to three adds two. A team of one has none.

This is why companies hire project managers: someone has to coordinate the coordination. Project management is valuable, and I am not dismissing it. But it is overhead, work about work.

Now take the coordination away. One person, one codebase, one problem: no alignment meetings, no handover documents. The paths inside the work drop to zero. The one that remains, between that person and the client, matters a great deal.

Meetings are the visible part of the tax

Meetings are where the coordination cost becomes easy to count, so let me count it.

Worked example: one sprint for a Limerick team of five

A Limerick software house, nicholasstreetworks.example, gives five developers a new feature and a two week sprint, which is 10 working days.

Step 1, the kickoff: one hour, five people, so 5 person hours.

Step 2, the technical design session: two hours, five people plus an architect who joins remotely, so $2 \times 6 = 12$ person hours.

Step 3, the daily standups: 15 minutes, five people, every working day. That is $0.25 \times 5 \times 5 = 6.25$ person hours a week, and $12.5$ across the sprint.

Step 4, the total: $5 + 12 + 12.5 = 29.5$ person hours of scheduled meetings across the sprint.

Step 5, the share: five people for 10 days at seven and a half hours is $5 \times 10 \times 7.5 = 375$ person hours, so the meetings take $29.5 / 375 \approx 7.9\%$ of the sprint.

The alternative: one developer, experienced in the domain, given the same feature. One requirements conversation, about 90 minutes, and then a week of building. The scheduled overhead is 1.5 hours.

And this is a well run team. I have seen worse. I have seen projects where the meeting load was so heavy that developers had two hours of uninterrupted coding time a day, and spent most of it recovering from context switches.

The cost you cannot see in the calendar

The 7.9% is the honest number for the meetings themselves, and it is not dramatic. The larger cost hides between them. Gloria Mark and colleagues observed 24 information workers in detail and found their work highly fragmented: people spent about 11 minutes on a piece of work before switching, 57% of those pieces of work were interrupted, and although most interrupted work was resumed the same day, more than two other activities usually came in between.²

In a later experiment, people who were interrupted actually finished their tasks faster with no loss of quality, but paid for it with more stress, frustration, time pressure and effort.³ So an interruption rarely costs a neat, fixed number of minutes. It costs fragmentation and strain, and on a hard project strain is what breaks quality. I go into how to protect focus under a deadline in time to market and the critical path.

The arithmetic favours one person whenever the coordination cost is larger than the benefit of working in parallel. For tightly connected work, where every piece depends on every other piece, that is often the case.

Experience is pattern recognition

Experience is not just a number on a CV. It is pattern recognition.

The research on expertise says the same. William Chase and Herbert Simon showed chess masters positions from real games for a few seconds and asked them to rebuild the board. The masters recalled far more than weaker players, but the advantage largely disappeared when the pieces were placed at random. What the masters had was not a better memory. It was a large store of familiar patterns, which let them see a position as a few meaningful chunks instead of many separate pieces.⁴

When I look at a new problem, I am not reasoning from first principles. I am matching it against thousands of similar problems I have seen before. That database schema looks like the one that caused performance problems at an eCommerce company in 2019. That API design feels like the one that broke when the team tried to add webhooks at a fintech startup in 2021. That caching strategy is identical to the one that corrupted data at a marketplace in 2017.

I do not need to think through every possible failure, because I have already lived through many of them. The failures are not hypothetical. They are memories. I can see the bug before it exists because I have fixed that bug before, or one close enough that the shape is unmistakable.

This is what people mean when they say senior developers are faster. It is not that they type more quickly. It is that they skip much of the exploration. They already know which approaches tend to fail, so they start with one that tends to work.

Worked example: two developers and one stock problem

A Galway bike parts shop, spokeandchain.example, keeps selling items it no longer has in stock. Both of the developers it asks have the same brief.

The first, newer to eCommerce, tries three fixes in turn: a nightly stock sync (still oversells during the day), a stock check when the basket is viewed (still oversells when two people check out at once), and finally a database lock when the order is placed. Each attempt takes about three days, so the fix arrives after nine.

The second recognises the pattern from the brief, two customers buying the last item at the same moment, and goes straight to reserving stock inside the same database transaction as the order. One attempt, three days.

Same intelligence, same tools. The difference is six days of exploration the second developer did years ago.

Thinking 15 steps ahead is scar tissue

There is a skill that develops over years of building systems: playing out the consequences in your head before they happen.

You learn to ask questions that do not occur to you early in a career. If the data is structured this way, what happens when a new type has to be added? If this service sits behind that cache, what happens when the cache is cold? If users can do this, what happens when someone does it 10,000 times in a row? If this change goes out, what happens to the requests already in flight?

These questions are not cleverness. They are scar tissue. Each one corresponds to a production incident or a late night debugging session that someone could have avoided. After enough scars, the questions become automatic.

This is why experienced developers can often build things right the first time. Not because they are smarter. Because they are more paranoid, and reality has calibrated the paranoia.

Worked example: the cold cache at a Kilkenny tea shop

A Kilkenny tea shop, kellsleaf.example, serves 2,000 product page requests a minute at its busiest. A cache answers 95% of them, so the database sees $2{,}000 \times 0.05 = 100$ queries a minute. The database can comfortably handle 300.

Now ask the question: what happens when the cache is cold, say right after a deployment clears it? Every request goes to the database: 2,000 a minute, which is $2{,}000 / 300 \approx 6.7$ times what it can take. The shop goes down at exactly the moment the deployment was meant to improve it.

The fix is not hard: warm the cache before switching traffic, or let only one request rebuild each cached page while the others wait. The hard part is asking the question before the outage, not after.

Understanding the requirement before building

Here is where the solo approach shows its real strength.

Teams tend to start building before they fully understand what they are building. There is pressure to show progress, and the illusion that typing code is progress. So the work is divided on an incomplete understanding, and the team discovers at integration that the pieces were designed against different assumptions.

I do not start building until I understand the problem completely. And I mean completely. Not just the happy path, not just the feature specification. The whole context.

What are the legal requirements? In Irish eCommerce that might mean data protection under the GDPR and the Data Protection Act 2018, which gives it further effect in Ireland,⁵⁶ the card industry's security standard, PCI DSS, for anything that touches payments,⁷ the Consumer Rights Act 2022, which sets the information and cancellation rules for distance contracts,⁸ and the accessibility requirements of the European Accessibility Act, which Ireland brought in through S.I. No. 636 of 2023 from 28 June 2025 and which cover eCommerce services.⁹ What are the real performance requirements, not the aspirational ones in the brief but the ones implied by the traffic and the hosting budget? Will this need to handle 10 times the load in 12 months, and if so, which part breaks first? What other systems does it touch, and what are the contracts with them, written or unwritten?

This takes time. In a team setting it can look as though I am slow to start. But the questions remove rework before it exists, and when I do build, I build fast, because I am not discovering requirements while coding or waiting for someone else's piece to see whether mine fits.

Worked example: the Cork gift subscription

A Cork subscription box company, youghalhamper.example, wants gift subscriptions. A team of three splits the work on day one: one builds the checkout, one the account area, one the emails.

At integration in week three they find that the checkout assumed the buyer and the recipient are the same person, while the emails assumed they are not. Untangling it takes each of them four days: $3 \times 4 = 12$ person days of rework.

One person spending two days on questions first would have asked "who receives the box, and who receives the receipt?" on the first morning. Two days of questions against 12 days of rework is the trade this whole section is about.

The projects where one expert wins

Not every project suits one person. Large new builds with lots of independent parallel work suit a team, and so does ongoing maintenance spread across many unrelated issues. But some kinds of work often go better with one experienced developer.

Emergency production fixes

The site is down. Revenue is draining away. Everyone is panicking.

This is not the time for a war room of 15 people, half of whom do not know the system well enough to contribute. It is the time for one person who knows where the bodies are buried to find the problem and fix it.

A crowd creates noise. People suggest causes they have not checked, several engineers chase the same idea, someone changes something to test a theory and tells no one. A close knit group under pressure can also slide into what Irving Janis called groupthink: the urge to agree overrides a realistic look at the alternatives, and the room settles on the loudest explanation instead of the right one.¹⁰

I have fixed production issues in systems I built years ago, systems that dozens of developers have changed since I left, because the core architecture is still familiar and my mental model still roughly applies. I can trace a request from the load balancer to the database faster than a team can agree on where to start looking.

An example: a Galway shop, athenrycandles.example, goes down at 8pm on Black Friday. Twelve people join the call, which by the formula is $C(12) = \frac{12 \times 11}{2} = 66$ possible conversations about what might be wrong. One engineer and one person from the business is $C(2) = 1$.

Complex migrations

Moving from one system to another while the old one is still running, with data that cannot be lost and customers who cannot see downtime.

You have to hold two complete systems in your head at once, plus the mapping between them and the order of operations that moves from one to the other without dropping anything. Dividing that among a team means dividing the mental model, and the mental model is where the value lives.

I have migrated payment systems for retailers processing millions of transactions, where not a single transaction could be lost or duplicated. I have migrated customer databases holding years of purchase history, where every record had to match before cutover. I have migrated login systems, which means migrating passwords, which means understanding hashing schemes, transition strategies and session invalidation. Those migrations worked because one person understood all the pieces. A team would have needed weeks of documentation and alignment. I needed days of deep focus.

Compliance work

Compliance is not a feature you can build in isolation. Personal data flows through every system, card data has handling rules at every layer, audit logs and access controls have to work the same way everywhere. A team spends weeks making that consistent, because each developer reads the rules slightly differently. I read the regulations, work out what they actually require, and apply one approach across the whole codebase, so when the auditor arrives, everything matches.

Performance work

The system is slow and customers are complaining. A slow page is a symptom. The cause might be a database query, a missing index, an N+1 problem (one query for a list, then one more for every item in it), a badly sized cache, or several of these interacting under load.

A team tends to optimise its own layers, and the page may not get faster at all, because the bottleneck was somewhere none of them looked. I profile the system end to end, using flame graphs (charts of where the processor spends its time) and database query plans, fix the actual bottleneck, measure again, and repeat until the target is met.

Cleaning up technical debt

Years of shortcuts, dead code and outdated dependencies, and every change now means navigating around the debris.

Cleaning up technical debt is surgery. You need to know what every piece does, which pieces are actually used, which depend on which, and in what order you can remove or refactor without breaking something. A team will have gaps in its shared understanding: one developer removes a class they think is unused, not knowing another module relies on its side effects. I read the entire codebase and trace every dependency before I touch anything, so the refactoring happens in an order that does not break things.

When a team is the right answer

I am not saying teams are bad or collaboration is wasteful.

Teams are a tool, and like every tool they have right and wrong uses. You do not use a hammer on a screw.

Some problems split cleanly. Ten independent features can be built much faster by ten developers, minus the coordination overhead, and the overhead is worth paying because the parallel gain is large. Other problems do not split. One deeply connected feature, where every piece depends on every other piece, will not go ten times faster with ten developers. The coordination cost grows faster than the parallel gain, and past a certain point adding people makes the project take longer, which is Brooks's law again.¹

The diagram reads from the top. The first question is whether the work splits into independent pieces: if it does, a team wins. If it does not, the second question is whether one person can realistically hold the whole thing within the deadline. If yes, that is the one expert case. If no, the answer is still not a crowd but a small team with a single owner of the design, so the mental model stays in one head.

Worked example: ten features or one

A Limerick SaaS company, patrickswellbooking.example, has two pieces of work. The first is 10 independent report screens, each about five days of work for one developer. The second is a new pricing engine that touches billing, invoicing, the customer portal and the tax logic, about 50 days of work for one person who understands all of it.

The reports: one developer takes $10 \times 5 = 50$ days. Five developers take about $50 / 5 = 10$ days, plus some coordination. A clear win for the team.

The pricing engine: split across five developers, each piece depends on the others. Five people have $C(5) = 10$ paths, and every design decision has to cross them. Assume, for the example, that coordination and rework eat half of each developer's time. Then the five deliver $5 \times 0.5 = 2.5$ developer days of real progress a day, so the 50 days of work take $50 / 2.5 = 20$ calendar days, and that is before anyone has learned the parts they did not write. One person who already understands it takes 50 days of focused work, but with no integration seams.

So for the pricing engine the team may still be faster on the calendar, yet it costs $5 \times 20 = 100$ person days against 50. Whether that is worth it depends on the deadline, which is exactly the judgement the diagram asks for.

The skill is recognising which kind of problem you have. Most organisations default to teams for everything, because teams are easy to see, manage and put in spreadsheets. One developer who disappears for a week and comes back with working software cannot be tracked in Jira. But it works.

Working without a net

The mental state this kind of work needs is not a comfortable one. You carry the whole problem yourself. No one shares the load, no one catches your mistakes, no one else is to blame if it goes wrong.

That is stressful in a way team work is not. In a team, the failure belongs to everyone, and so to no one in particular. Social psychology has a name for a close cousin of this: Bibb Latané and colleagues found that people clapping and shouting in groups put in noticeably less individual effort than when alone, a drop they called social loafing, on top of the losses from poor coordination.¹¹

When you work alone, every decision is yours, every mistake is yours, and your name is on the commit.

Stress comes from demands without control

Some people cannot tolerate that weight, and they need the shared responsibility of a team. That is not a weakness, it is a preference. Some of the best developers I know prefer team environments precisely because the collaboration energises them and the shared ownership lowers their anxiety.

But some of us are wired the other way. For us, the stress of coordination is worse than the stress of responsibility. Depending on others, being blocked by someone else's delay, explaining decisions to people who lack the context: that hurts more than carrying everything alone.

The research gives this a shape. Robert Karasek's demand and control model holds that mental strain comes less from high demands alone than from high demands combined with little control over how to meet them.¹² A solo expert on a hard deadline has high demands and high control. A developer on a big team with the same deadline, waiting on three approvals, has the same demands and much less control.

An example: two developers in Cork face the same Friday deadline. One owns the design and can make every decision herself. The other needs sign off from an architect, a product owner and a security reviewer before each change. Same workload, same deadline. By Karasek's model the second job is the more straining one.

Pressure helps, up to a point

There is a popular idea that a bit of pressure sharpens performance and too much ruins it, usually credited to Robert Yerkes and John Dodson. Their 1908 study was actually about mice learning to tell a light box from a dark one under mild electric shocks of different strengths. They concluded that an easy habit forms best under strong stimulation, while a difficult one forms best under relatively weak stimulation.¹³ The wider claim about stress and human work came later, but the original finding is the useful part here: the harder the task, the lower the level of pressure at which people do their best work.

That is why I protect the conditions around a stressful project so carefully. The problem itself supplies enough pressure. Noise, meetings and waiting on others only add to it.

When to hire one person instead of building a team

Let me be direct about the commercial side of all this.

If you have a project that fits the profile, tightly connected, under time pressure, needing deep understanding across several areas and needing to work the first time, you have a choice.

You can hire a team, with a project manager, time for everyone to learn the existing system, design sessions and integration testing. It will become productive, but the ramp up takes time and the coordination overhead never goes away.

Or you can hire me.

I will spend the first few days understanding the problem completely: the legal constraints, the performance needs, the integration points, the politics, and the things that live only in someone's head. Then I will build it, and hand over the implementation, the documentation, the tests and the deployment plan together.

Worked example: the break even day rate

A Waterford retailer, barronstrandhome.example, is weighing up a migration. The figures are the example's assumptions, not quotes.

Option one: a team of four developers for 12 weeks (60 working days), plus a project manager at half time. That is $4 \times 60 + 0.5 \times 60 = 240 + 30 = 270$ person days.

Option two: one experienced developer for four weeks of focused work, 20 working days.

The question is not which day rate is lower. It is how high the one person's day rate could be before option two costs more. Break even is $270 / 20 = 13.5$. So under these assumptions the single developer could charge up to 13.5 times the team's average day rate and still cost the same. Even if the solo estimate doubled to 40 days, the break even would be $270 / 40 \approx 6.8$ times.

The assumptions are what decide it. If the work really is ten independent features, option one wins. If it is one tightly connected migration that one person can hold in their head, option two usually does.

This is not a fit for every project. Sustained development over years, or a broad surface of features built in parallel, needs a team. But if you need something complex built quickly and it has to work, the answer might not be more people. It might be the right person.

Smaller, not smarter

The idea that adding people slows a project down feels wrong, because most of us treat resources as additive.

But software is not digging a ditch. You cannot simply add more shovels. The work is mental, and the constraint is not effort but understanding. A problem that needs one joined up understanding is not made easier by spreading that understanding across many minds. It is made harder.

Brooks made this argument in 1975, and half a century later it still holds.¹

The answer is not to throw more people at hard problems. It is to find the right people and give them the space to work.

For the right kind of problem, I am worth more than a team. Not because I am smarter than a team, but because I am smaller than one. There are no paths inside a team of one. My 20 years of experience mean I skip much of the exploration and go straight to solutions, because I have seen enough failures that I do not need to discover them the hard way.

That is what I offer. Not hours, not resources, not a body in a seat. Results, sooner than you expected, and right the first time.

If you have a project that has stalled in coordination, a complex problem a team has struggled to crack, or a deadline that makes the usual ramp up impossible, talk to me. Solo expertise is not the answer to everything. But for certain problems it is exactly the answer, and if yours is one of them, I can help.

Footnotes

1. Frederick P. Brooks Jr, The Mythical Man Month: Essays on Software Engineering, first published 1975, anniversary edition, Addison Wesley Professional, 1995, chapter 2, publisher page at InformIT, https://www.informit.com/store/mythical-man-month-essays-on-software-engineering-anniversary-9780201835953

2. Gloria Mark, Victor M. Gonzalez and Justin Harris, No task left behind? Examining the nature of fragmented work, Proceedings of CHI 2005, ACM, 2005, https://ics.uci.edu/~gmark/CHI2005.pdf

3. Gloria Mark, Daniela Gudith and Ulrich Klocke, The cost of interrupted work: more speed and stress, Proceedings of CHI 2008, ACM, 2008, https://ics.uci.edu/~gmark/chi08-mark.pdf

4. William G. Chase and Herbert A. Simon, Perception in chess, Cognitive Psychology 4(1), 55 to 81, 1973, doi 10.1016/0010-0285(73)90004-2, record at Crossref, https://api.crossref.org/works/10.1016/0010-0285%2873%2990004-2

5. Regulation (EU) 2016/679 (General Data Protection Regulation), Official Journal of the European Union, EUR Lex, https://eur-lex.europa.eu/eli/reg/2016/679/oj

6. Data Protection Act 2018 (No. 7 of 2018), long title, Irish Statute Book, Office of the Attorney General, https://www.irishstatutebook.ie/eli/2018/act/7/enacted/en/html

7. PCI Security Standards Council, PCI Data Security Standard (PCI DSS), pcisecuritystandards.org, https://www.pcisecuritystandards.org/standards/pci-dss/

8. Consumer Rights Act 2022 (No. 37 of 2022), Part 4, Chapters 4 and 5, distance contracts and the right to cancel, Irish Statute Book, Office of the Attorney General, https://www.irishstatutebook.ie/eli/2022/act/37/enacted/en/html

9. S.I. No. 636 of 2023, European Union (Accessibility Requirements of Products and Services) Regulations 2023, giving effect to Directive (EU) 2019/882, Irish Statute Book, Office of the Attorney General, https://www.irishstatutebook.ie/eli/2023/si/636/made/en/print

10. Irving L. Janis, Groupthink and group dynamics: a social psychological analysis of defective policy decisions, Policy Studies Journal 2(1), 19 to 25, 1973, doi 10.1111/j.1541-0072.1973.tb00117.x, record at Crossref, https://api.crossref.org/works/10.1111/j.1541-0072.1973.tb00117.x

11. Bibb Latané, Kipling Williams and Stephen Harkins, Many hands make light the work: the causes and consequences of social loafing, Journal of Personality and Social Psychology 37(6), 822 to 832, 1979, doi 10.1037/0022-3514.37.6.822, record at Crossref, https://api.crossref.org/works/10.1037/0022-3514.37.6.822

12. Robert A. Karasek Jr, Job demands, job decision latitude, and mental strain: implications for job redesign, Administrative Science Quarterly 24(2), 285 to 308, 1979, doi 10.2307/2392498, record at Crossref, https://api.crossref.org/works/10.2307/2392498

13. Robert M. Yerkes and John D. Dodson, The relation of strength of stimulus to rapidity of habit formation, Journal of Comparative Neurology and Psychology 18(5), 459 to 482, 1908, full text at Classics in the History of Psychology, York University, https://psychclassics.yorku.ca/Yerkes/Law/