Are you hiring for a Team or building a system?
In Architecture, it’s often both.
When I speak with technology leaders about scaling teams, transforming legacy estates, or launching greenfield projects, the questions aren’t only around skills - They’re around how the architecture shapes the kind of people they need. And the reverse is true too: the team you have, or want to build, directly influences what kind of architecture makes sense.
Let’s explore the 3 most common architecture approaches; Monolith, Microservices, and Serverless . . through both a technical and team-building lens.
Monolith. The one big brick
A monolith is a single, unified application where everything (from user interface to business logic to data access) is packaged and deployed together.
It’s simple, reliable, and often easier to get off the ground.
When it works:
· Start-ups getting an MVP out fast
· Tight-knit teams with shared domain knowledge
· Legacy systems that are too interdependent to break apart (yet)
As a Recruiter:
Hiring for a monolith tends to focus on generalist engineers or full-stack developers who understand the entire system and can navigate dependencies across layers. Communication lines are shorter. You want team players with broad skills and high resilience under pressure.
Watch out:
Scaling becomes difficult. Release cycles slow down. A bug in one module can bring the whole system down. And over time, technical debt builds silently - until suddenly, you’re firefighting instead of innovating.
Microservices. Divide and conquer
Microservices split an application into small, independent services that communicate via APIs. Each service handles a specific function and can be deployed, scaled, or even re-written independently.
When it works:
· Scaling teams across multiple domains
· Modernising legacy systems incrementally
· Demanding environments with frequent releases
As a Recruiter:
We’re looking for Specialists. Teams tend to be cross-functional and domain-driven, and success relies heavily on strong API design, DevOps maturity, and cloud infrastructure fluency. Think SREs, Platform Engineers, Back-End Developers with distributed systems experience.
Collaboration and communication are key. Even if services are decoupled, the people building them still need to work as one.
Watch out:
It’s easy to over-engineer or end up with distributed spaghetti. Governance and observability become critical. And if teams aren’t aligned, the promise of autonomy can turn into a free-for-all.
Serverless. Code without the heavy lifting
With serverless, developers write functions, not servers. The cloud provider manages infrastructure, scaling, and resource allocation. You just focus on code.
When it works:
· Event-driven workloads
· Spiky traffic patterns
· Lean teams that want to ship fast
As a Recruiter:
You’ll want cloud-native developers, DevOps-aware engineers, and problem solvers who understand event-driven design. You’re hiring for mindset as much as skillset: people who embrace automation, scalability, and performance as code.
Serverless teams often move faster, but need disciplined architecture . . otherwise, you’re left with a mess of disconnected functions no one can debug.
Watch out:
Cold starts, vendor lock-in, observability challenges. It’s not a silver bullet . . it’s a paradigm shift.
So what should you choose?
The right architecture is about your people, your processes, and your purpose.
· Do you need speed or scalability?
· Do you have generalists or specialists?
· Are you building from scratch or untangling legacy?
Entasis Partners help our Clients shape what to build and who they need to build it.
Hiring for architecture is never one-size-fits-all. So why should your architecture be?
