The Psychology of Stressful Projects: When One Expert Beats an Entire Team

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

The correct answer, more often than anyone wants to admit, is yes. Not always. Not for everything. But for a specific category of high-pressure, high-complexity work, one experienced developer who can hold the entire problem in their head will consistently outperform 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 understanding when teamwork helps and when it becomes the very thing slowing you down.

The Coordination Tax Nobody Talks About

Every person you add to a project increases communication overhead. This is not a linear relationship. It is geometric. Two people need one communication channel. Three people need three. Four people need six. Five people need ten. By the time you have a team of eight, there are twenty-eight possible communication pathways, and keeping everyone aligned becomes a job in itself.

This is why companies hire project managers. Someone needs to coordinate the coordination. Someone needs to make sure that what Developer A is building will actually work with what Developer B is building, and that neither of them is duplicating the work Developer C started last week before anyone told them the requirements changed.

Project management is valuable. I am not dismissing it. But project management is overhead. It is work about work. Every hour spent in a planning meeting is an hour not spent solving the actual problem. Every status update written is cognitive load not applied to the code.

Now consider what happens when you remove the coordination entirely. One person, one codebase, one problem. There are no alignment meetings because there is no one to align with. There are no handoff documents because there is no handoff. There is no risk that Developer A's module will not integrate with Developer B's module because both modules live in the same brain.

The communication overhead drops to zero. All of the time that would have been spent coordinating is now spent executing.

The Meeting Tax: Where Projects Go to Die

Let me walk you through the mathematics of a typical team project.

A team of five developers is assigned to build a new feature. Before anyone writes code, they have a kickoff meeting. One hour, five people. Five person-hours consumed. Then they have a technical design session. Two hours, five people, plus an architect who joins remotely. Twelve person-hours consumed. Then they break into pairs for implementation, but they have daily standups. Fifteen minutes each, five people, every day for the two-week sprint. That is six and a quarter person-hours per week, twelve and a half for the sprint.

We are already at nearly thirty person-hours of meetings before anyone has written a meaningful line of code. 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 per day, and they spent most of that time recovering from context switches.

Now consider the alternative. One developer, deeply experienced in the domain, given the same feature to build. They have a single requirements conversation, maybe ninety minutes, to understand what needs to be built. Then they disappear for a week and emerge with working software. No standups. No alignment sessions. No design reviews. Just execution.

Total overhead: ninety minutes.

Total output: the same feature, possibly higher quality because there were no integration seams, no handoff miscommunications, no code style conflicts.

The maths favours the solo approach whenever the coordination cost exceeds the parallelisation benefit. And for complex, interconnected work, where every piece depends on every other piece, the coordination cost is often enormous.

What Twenty Years of Experience Actually Buys

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

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

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

This is what people mean when they talk about senior developers being faster. It is not that we type more quickly. It is that we skip the exploration phase. We already know which approaches will work and which will fail, so we go straight to the approach that works.

A junior developer faced with a complex problem might try three or four architectures before finding one that holds together. A senior developer who has built similar systems will pick the right architecture on the first attempt, because they have already tried the wrong ones on someone else's time.

Thinking Fifteen Steps Ahead

There is a particular skill that develops over years of building systems, and it is the ability to play out consequences in your head before they happen.

You learn to ask questions that do not occur to less experienced developers. If we structure the data this way, what happens when we need to add a new type? If we put this service behind that cache, what happens when the cache is cold? If we allow users to do this action, what happens when they try to do it ten thousand times in a row? If we deploy this change, what happens to the requests that are already in flight?

These questions are not cleverness. They are scar tissue. Every one of them corresponds to a production incident, a late-night debugging session, a customer escalation that could have been avoided if someone had thought it through. After enough scars, the questions become automatic. You cannot look at a design without immediately seeing the failure modes, because the failure modes are what your brain has learned to notice.

This is why experienced developers can build things right the first time. We are not smarter. We are more paranoid. And our paranoia is calibrated by reality.

The Requirement Phase That Most Teams Skip

Here is where things get interesting, and where the solo approach shows its real strength.

Teams have a tendency to start building before they fully understand what they are building. There is pressure to show progress. There is impatience from stakeholders. There is the illusion that typing code is the same as making progress. So the team divides the work based on an incomplete understanding, everyone goes off to build their piece, and then they discover during integration that the pieces do not fit together because they 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 entire context.

What are the legal requirements? In e-commerce, this might mean GDPR data handling, PCI compliance for payments, distance selling regulations, accessibility standards. What are the performance requirements? Not the aspirational ones in the brief, but the real ones implied by the traffic patterns and the infrastructure budget. What are the scaling requirements? Will this need to handle ten times the load in twelve months, and if so, which parts will break first? What are the integration requirements? What other systems does this touch, and what are the contracts with those systems, written or unwritten?

This phase takes time. In a team setting, it might look like I am slow to start. Everyone else is already coding and I am still asking questions. But the questions are doing work. They are eliminating rework. They are preventing the integration problems that will consume weeks later. They are ensuring that when I do start building, I build the right thing.

And then when I build, I build fast. Because I am not discovering requirements while coding. I am not backtracking because I misunderstood something. I am not waiting for someone else to finish their piece so I can see if mine fits. I know exactly what needs to exist, I know exactly how it needs to work, and I execute without hesitation.

The Projects Where Solo Expertise Wins

Not every project favours the solo approach. Large greenfield builds, where there is genuinely a lot of parallel work that does not interact, benefit from teams. Ongoing maintenance, where the work is distributed across many unrelated issues, benefits from teams. Projects where the limiting factor is not development speed but stakeholder decision-making benefit from teams, because at least the team members can help each other stay sane while waiting.

But there are categories of work where one experienced developer will consistently outperform a team. Let me describe them.

Emergency Production Fixes

The site is down. Revenue is bleeding. Everyone is panicking.

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

A team approach to production emergencies creates noise. People suggest possibilities they have not verified. Multiple engineers investigate the same hypotheses in parallel. Someone makes a change to test a theory and forgets to tell anyone, sending others down wrong paths. The communication overhead that is merely expensive in normal times becomes catastrophic when minutes matter.

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

Complex Migrations

Moving from one system to another, especially while the old system is still running, especially with data that cannot be lost, especially with users who cannot experience downtime.

This is work where you need to hold two complete systems in your head simultaneously, plus the mapping between them, plus the sequence of operations that moves from one to the other without dropping anything. Dividing this work 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, with the requirement that not a single transaction be lost or duplicated. I have migrated customer databases containing years of purchase history, with the requirement that every record match exactly before cutover. I have migrated authentication systems, which means migrating the passwords, which means understanding hashing schemes and transition strategies and session invalidation logic.

These 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 Implementations

GDPR. PCI DSS. SOC 2. HIPAA. The alphabet soup of regulatory requirements that someone needs to translate into actual code and process.

Compliance is not a feature you can build independently. It touches everything. User data flows through every system. Payment card data has specific handling requirements at every layer. Audit logs need to capture specific events in specific formats. Access controls need to be enforced consistently across the entire application.

A team implementing compliance will spend weeks ensuring consistency. Each developer will make slightly different assumptions about what the requirements mean. Integration testing will reveal gaps that send everyone back to the documentation. Auditors will find inconsistencies that require rework.

I read the regulations. I understand what they actually require, not what the summary slides say they require. I implement a consistent approach across the entire codebase, because the entire codebase is in my head. When the auditor arrives, everything matches because everything was built by the same brain.

Performance Optimisation

The system is slow. Users are complaining. Leadership wants it fixed.

Performance problems are never local. A slow page is the symptom. The cause might be a database query, or a missing index, or an N+1 problem in the ORM, or a cache that is sized wrong, or a garbage collection pause, or a network round-trip that could be eliminated, or a combination of all of these interacting in ways that only appear under load.

Finding performance problems requires tracing requests through every layer of the system. It requires reading flame graphs and database execution plans and network traces. It requires understanding not just what the code does but why it does it, because the fix might be algorithmic or it might be architectural and you cannot know which until you understand the intent.

A team attacking a performance problem will optimise their assigned layers independently. The frontend developer will minimise bundle sizes. The backend developer will add caching. The database administrator will tune queries. And the overall performance might not improve at all, because the bottleneck was somewhere none of them looked, or because their independent optimisations created new bottlenecks in the interactions between layers.

I profile the system end to end. I find the actual bottleneck, not the assumed one. I fix it, measure again, find the new bottleneck that was hidden behind the old one, fix that, and repeat until the target is hit. The system in my head is complete, so I can optimise the system as a whole rather than optimising components that do not matter.

Technical Debt Cleanup

The codebase has accumulated years of shortcuts, abandoned features, dead code, outdated dependencies, and architectural decisions that made sense once but no longer do. The team velocity is slowing because every change requires navigating around the debris.

Cleaning technical debt is surgery. You need to understand what every piece of the system does, which pieces are actually used, which pieces interact with which others, and in what order you can remove or refactor without breaking something. It requires reading code that no one has touched in years, understanding the intent behind decisions made by people who left long ago, and making judgments about what can safely change.

A team cleaning technical debt will inevitably have gaps in their collective understanding. Developer A will remove a class they think is unused, not knowing that Developer B's module relies on its side effects. Developer C will refactor an interface, not knowing that an external system depends on its exact shape. The integration testing finds these problems, eventually, but every discovery is a setback.

I read the entire codebase. I trace every dependency. I understand the system as a whole before I touch any piece of it. The refactoring happens in a sequence that never breaks anything, because I know what depends on what before I start.

This Is Not an Argument Against Teams

I want to be clear about what I am not saying.

I am not saying teams are bad. I am not saying collaboration is wasteful. I am not saying you should never have a standup or a design review or a planning session.

I am saying that teams are a tool, and like all tools, they have appropriate and inappropriate uses. You do not use a hammer on a screw. You do not use a team on a problem that requires unified understanding.

Some problems are genuinely parallelisable. Building ten independent features can happen ten times faster with ten developers, minus coordination overhead. The overhead is worth it because the parallelisation benefit is large.

Some problems are not parallelisable. Building one deeply integrated feature, where every piece depends on every other piece, cannot happen ten times faster with ten developers. The coordination overhead grows faster than the parallelisation benefit. Eventually you reach a point where adding more people makes the project take longer, not shorter.

The skill is recognising which kind of problem you have. And the tragedy is that most organisations default to teams for everything, because teams are legible. Teams can be managed. Teams can be measured. Teams fit in spreadsheets.

A solo developer disappearing for a week and emerging with working software is illegible. It looks like magic, or like risk, depending on your perspective. It does not fit the project management frameworks. It cannot be tracked in Jira.

But it works.

The Psychology of Working Without a Net

There is a particular mental state required for this kind of work, and it is not comfortable. You have to be willing to carry the entire problem yourself. No one to share the load. No one to catch your mistakes. No one to blame if it goes wrong.

This is stressful in a way that team work is not. In a team, anxiety is distributed. If the project fails, there were many decision points, many contributors, many opportunities for course correction. The failure belongs to everyone and therefore to no one in particular.

When you work solo, the failure is yours alone. Every decision is yours. Every mistake is yours. If it does not work, that is your name on the commit.

Some people cannot tolerate this. The weight is too heavy. They need the psychological safety of shared responsibility. This 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 reduces their anxiety.

But some of us are wired the other way. The stress of coordination is worse than the stress of responsibility. The anxiety of depending on others, of having our work blocked by someone else's delay, of having to explain our decisions to people who lack context, is more painful than the anxiety of carrying everything alone.

For us, solo work is not harder. It is easier. The problem is simpler when it is all in one head. The execution is faster when there is no one to wait for. The outcome is clearer when there is no ambiguity about who owns what.

Why Some Companies Should Hire Me Instead of Building a Team

Let me be direct about the commercial implication of everything I have described.

If you have a project that fits the profile, interconnected, time-pressured, requiring deep understanding across multiple domains, requiring it to work the first time, you have a choice.

You can hire a team. You will need a project manager to coordinate them. You will need weeks for them to understand the existing system. You will need design sessions, architecture reviews, integration testing. The team will be productive eventually, but the ramp-up period is measured in months. The coordination overhead is measured in percentage points of total capacity, typically twenty to forty percent depending on how well the team gels.

Or you can hire me.

I will spend the first few days understanding the problem completely. Not partially. Completely. I will ask questions that seem tangential until you realise they are preventing problems that would have emerged later. I will understand the legal constraints, the performance requirements, the integration points, the scaling implications, the political sensitivities, the things that are documented and the things that live only in someone's head.

And then I will build it. Not in parallel with anyone. Not incrementally with check-ins. Just: here is the requirement, here is the implementation, here is the documentation, here are the tests, here is the deployment plan.

The project that would have taken a team three months with coordination overhead will take me one month of focused execution. The quality will be higher because there are no integration seams. The architecture will be more coherent because it came from one mind. The cost, even at a premium day rate, will be lower because fewer total hours were worked.

This is not a fit for every project. If you need ongoing maintenance, you need a team. If you need sustained development over years, you need a team. If you need a broad surface area of features built in parallel, you need a team.

But if you need something complex built fast, and you need it to work, and you cannot afford the months of coordination that a team requires, the answer might not be more people. The answer might be the right person.

The Paradox of Less Is More

There is something deeply counterintuitive about the idea that adding people can slow a project down. We are conditioned to think of resources as additive. More people should mean more output. More hands should mean faster work.

But software is not ditch-digging. You cannot simply add more shovels. The work is mental, not physical, and the constraint is not effort but understanding. A problem that requires deep unified understanding is not made easier by distributing that understanding across many minds. It is made harder.

The book Mythical Man-Month made this argument in 1975, and it is still true fifty years later. Adding people to a late software project makes it later. The communication overhead dominates. The ramp-up time dominates. The integration problems dominate.

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

I am one of those people. For the right kind of problem, I am worth more than a team. Not because I am smarter than a team. Because I am smaller than a team. Because the coordination cost of one is zero. Because my twenty years of experience mean I skip the exploration phase and go straight to solutions. Because I have seen enough failures that I do not need to discover them the hard way.

This is what I offer. Not hours. Not resources. Not a body in a seat.

Results. Faster than you thought possible. Right the first time.

If you have a project that has stalled in coordination hell, or a complex problem that a team has struggled to crack, or a tight deadline that makes the usual team ramp-up impossible, talk to me. I do not pretend that solo expertise is the answer to everything. But for certain problems, it is exactly the answer. And if your problem is one of those, I can help.