Conway's Law observes that a system's architecture tends to mirror the communication structure of the organization that builds it — teams that don't talk to each other much tend to produce, deliberately or not, correspondingly separate pieces of software. This is often stated the other way around in practice, as the Inverse Conway Maneuver: if you want a particular architecture (say, cleanly separated services), it helps enormously to first structure the teams that way — one team per service, with real ownership — rather than expecting a shared team working across a shared codebase to somehow maintain clean service boundaries purely through discipline.
This is also the honest answer to "why does company X have microservices" in many real cases — it's not always (or even usually) purely a technical scaling decision. A large organization with many independent teams often adopts microservices specifically so those teams can work independently, deploy on their own schedule, and not be blocked waiting on a shared codebase's release process — a genuinely organizational problem, solved with an architectural pattern. A five-person team doesn't have that coordination problem yet, which is a large part of why microservices tend to suit large organizations much better than small ones, independent of either one's actual traffic or scaling needs.