Fredrik Tjärnberg
Tech Lead at Monterro
Scaling development teams
without the growing pains
The founder-led dev trap
Most software companies begin with a compact development team. It’s usually small, reactive and founder led. Customer requests dictate what gets built. Easy wins and sales deals steer priorities and releases. It works initially, speed feels high, and customers are satisfied.
But as the company grows, this setup becomes unsustainable and counterproductive. Features pile up, the backlog balloons, release cycles slip and technical debt mounts. Decisions bounce between sales and the founder, and without a structured product roadmap, longterm direction suffers, throwing an organisation into reactive mode.
This eBook is about moving from confusion to clarity. It’s about scaling your organisation in a futureproof way that preserves momentum, growth and levels up quality.
If you take one thing from this eBook it’s to understand that more developers won’t solve anything unless teams have alignment, autonomy and a clear vision.
Fredrik Tjärnberg, Tech Lead at MonterroCustomer value is the foundation of growth; alignment and scalable systems make it sustainable.
Meet the experts
This guide distils insights from Monterro’s Tech Leads:
- Per Ivansson and Fredrik Tjärnberg
Both held senior engineering leadership roles at software companies such as Episerver, now Optimizely, at various stages, from startups to post-IPO. They now work hands-on with Monterro's portfolio companies, using decades of experience, lessons learned, and success stories to guide them through the realities of scaling and building modern development organisations that thrive.
Per Ivansson
CTO, Tech Lead at Monterro
What's inside...
Common scaling scenariosIdentifying and tackling common mistakesStructure for scaleHow to avoid disarray when your team growsProduct leadership as compassWhy scaling without product direction always failsSpeed & reliabilityBuilding confidence through automation and smart debt managementMerging & acquiringHow to integrate development teams without losing momentumHarnessing AIUsing smart tools to leverage smarter focusKey takeawaysFour rules for building modern dev teams
Common scaling scenarios
Tackling common scaling challenges
We see even the most promising software companies run into similar obstacles as they grow. Recognising these pitfalls early is the first step to avoiding them.
Watch for:
Role confusion:
In the absence of a dedicated product role, founders, sales, or the CEO often drive the roadmap. Engineering ends up reacting to whoever is loudest, rather than working from a strategic plan.
Unfit leadership:
Promoting the most technically skilled developer into manage-ment rarely works. Technical mastery doesn’t automatically translate into people leadership. Leading teams is about enabling others, not just solving the hardest problems yourself.
Interdependencies:
As teams grow, overlapping responsibilities and tightly coupled systems create bottlenecks. If one team can’t ship without another, progress slows across the board. Our mantra is clear: autonomy scales; dependencies drag.
Technical debt:
One-off features, customisations and shortcuts pile up, eroding velocity and making releases riskier.
The “big bang” rebuild:
Often suggested as a clean fix, but in reality, it almost never succeeds. Evolutionary improvements are far safer.
How to respond:
- Separate product and engineering – product defines what and why, engineering delivers the how.
- Choose leaders for their ability to grow people and organise teams, not just their technical brilliance.
- Structure both teams and architecture to minimise dependencies and maximise autonomy. Treat technical debt as an ongoing cost of doing business, not a one-off clean-up project.
- Improve architecture step by step; avoid “starting over.”
Most scaling challenges are predictable and the playbook for avoiding, responding to, or cont-rolling them are easy to action for most organisations.
Structure for scale
Disarray doesn’t scale
When you’re a team of five, hallway conversations keep everyone aligned. If you grow to fifteen-plus in a short space of time, the same approach won’t work. Coordination explodes and execution slows to a crawl.
Successful scaling starts with intentional leadership and structure. You can’t scale disarray. You need clear ownership, defined roles, and leaders who enable others to succeed.
That means putting thoughtful managers in place who can support people, not just ship code. Structure allows teams to move fast without stepping on each other.
Autonomy:
Organise teams around clear goals with minimal dependencies. Independent teams that can deploy on their own timeline. Keep momentum high.
Architecture:
Invest in modular, decoupled systems so work can progress in parallel. The “big bang” rebuild is often suggested as the answer, but in reality, it rarely succeeds. Evolutionary improvements to your architecture are a safer and faster path.
Delivery confidence:
Frequent, reliable deployments are the best signal of healthy execution. Teams that can ship weekly—or daily—demonstrate real scalability.
Per IvanssonA healthy dev org isn’t measured by pull requests, but by its ability to deploy improvements - and do it safely.
You will need to separate development from support, pre-sales, and delivery. You can’t have people doing everything. You need owners. It’s about distributing responsibility so decisions can be made closer to the work. That reduces bottlenecks and scales execution. And reduces noise.
You also need to intentionally define workflows across teams. Who sets direction? Who owns delivery? How are trade-offs made? These things can no longer be implicit.
Per IvanssonDon’t put your best engineer in charge. Put your best people person in charge.
Modular architecture:
As teams scale, monolithic architectures become bottlenecks. Build modularly with clear responsibilities — in your codebase as well as in your teams. Decoupled systems allow teams to progress in parallel without constant coordination. See your scaled organisation as small, self-sufficient entities and nurture autonomy to let them succeed.
Product leadership as compass
Focus on product, not speed
To develop and deploy efficiently, you need to have a clear product strategy and direction.
Hire a product manager early, at least have someone who owns the product. We see the Product Manager or CPO as the CEO of the product, responsible for go-to-market, the product strategy and the PnL.
Without one, you’re scaling execution without prioritisation. A strong Product Manager brings focus, helps make hard trade-offs, and connects customer value to engineering effort.
When product leadership is in place, engineering output turns into business impact. Teams move with clarity, customers see consistent progress, and founders are free to focus on growth instead of firefighting prioritisation.
Scaling requires a strong product function and product roadmap to act as your compass. A product manager translates strategy into prioritisation, filters noise and ensures engineering effort delivers long-term value. Without this role, teams chase the urgent instead of the important.
Clear ownership:
A dedicated product role defines what to build and why, while engineering decides how.
Strategic focus:
Product leaders balance customer input, competitive analysis, and company strategy to prioritise what truly matters.
Cross-functional alignment:
A single product roadmap brings sales, marketing, support, and engineering onto the same page.
Fredrik TjärnbergUse your product roadmap as a filter: saying no is just as important as saying yes.
Speed & reliability
Automate early, reduce debt, and soar
Adding people without strengthening your foundation only increases fragility. Releases become risky. Teams slow down out of fear. The antidote is automation and intelligent debt management.
Automation builds confidence. CI/CD pipelines, automated testing, and observability mean developers can ship small, frequent changes without sleepless nights. Debt management preserves that speed. It’s fine to take shortcuts but invisible debt will quietly erode your velocity until everything seizes up.
- Automate every repeatable task. Testing, deployment, monitoring…
- Track debt visibly and decide deliberately which shortcuts are acceptable
- Invest in observability and rollback strategies so you can recover quickly when things break
Build vs Buy (and now, Build with AI)
The smartest organisations don’t just choose between building and buying — they blend. Off-the-shelf tools are great for speed, but AI now makes it easier to close gaps, extend systems, and tailor workflows without spinning up full projects. Sometimes the right move is to build small, using AI to automate, connect, or adapt what you already have.
Building confidence through speed and reliability
Speed matters – but safety wins trust
Scaling software development isn’t just about shipping more, it’s about shipping with confidence. A healthy dev org isn’t measured by commits but by its ability to deliver improvements and do it safely. Frequent, reliable releases shorten the path from idea to impact without eroding trust.
- Automate tests for critical flows
- Monitor, alert and rollback fast
- Treat maintenance as everyday work, not special projects
Per IvanssonIf you can release multiple times a week, or a day – you’re doing something right.
Merging & acquiring
Integrating with another company is not soft onboarding
For many SaaS companies, scale comes not only from organic growth but also through acquisition. Buying or merging with another business can accelerate expansion, but the real challenge begins once the deal is signed: integration.
When integration is delayed or unclear, problems appear quickly. Teams stay in silos, working on different priorities. Employees who expected change are left confused or disappointed when nothing happens. And the acquired team may feel like outsiders rather than part of the future. Customers notice the cracks, too – from inconsistent communication to duplicated or conflicting processes.
The solution is to treat integration like a product launch: plan it, resource it, and move with urgency. Define a target operating model from the start, align on roles and ownership, and involve leaders from the acquired company early to preserve trust.
- Decide upfront whether teams will integrate or operate separately
- Align on tools, roles, and ownership from day one
- Involve leaders from the acquired company early
- Communicate transparently and preserve what works in the acquired team
- Resource integration like a real project, not an afterthought
Fredrik TjärnbergIntegration isn’t about consensus. It’s about alignment and momentum.
Harnessing AI
AI doesn’t replace strong teams – it augments them
AI isn’t just for busywork anymore. It’s part of the build. The advantage comes when strong product direction meets clear technical intent. Codify your patterns, let tools/agents operate with context, and use AI to push execution without losing alignment. When humans set direction and AI drives throughout, velocity turns into real progress.
Most companies have enthusiasts that start campfires here and there. Continue doing that but quickly institutionalise the use of AI across your engineering organisation – using the same way of working, the same agents, md files etc. Otherwise, the build-up of tech debt can spiral fast.
The field is evolving fast. Don’t lock yourself into tools or workflows that can’t adapt – build for change. The teams that stay flexible will keep compounding value as the landscape shifts.
- Integrate AI into your delivery flow – don’t bolt it on.
- Anchor acceleration in product priorities.
- Encode architecture and conven-tions so AI can act predictably.
- Stay tool-agnostic and design for adaptability.
- Keep humans accountable for goals and guardrails.
Fredrik TjärnbergUsed wisely, AI amplifies what already works: better pipelines, stronger testing, faster delivery.
Bringing it all together- your key takeaways
We speak from experience when we say that even the strongest teams experience growing pains. Unclear roles, promoting the wrong coders into management, lack of autonomy…
What these organisations do differently is that they have learned to spot them earlier and respond decisively. If you keep these four things in mind, you’ll be able to do the same. The teams that stay flexible will keep compounding value as the landscape shifts.
1
- Design for autonomy
- Use standard tools
- Automate early
- Keep it simple
2
- Invest early in product and leadership
- Scale through clarity - not headcount.
3
Avoid customisations
4
Adopt AI
Monterro is a hands-on growth investor. We turn Nordic software companies into market leaders by contributing our time, experience, know-how, and networks. And yes, we provide capital too. In fact, we invest our own capital, so we are personally committed to our mutual success. Monterro is headquartered in Stockholm with offices in Oslo, Copenhagen, Helsinki, and a software development center in Hanoi.