Why Big-Company Engineers Struggle at Startups | Fredrik Wallenius, CTO, EsterCare
My Dialog guest this week is Fredrik Wallenius, CTO at EsterCare, a Swedish digital health company focused on women’s healthcare.
Prior to EsterCare, he served as Engineering Director at Tink, the Swedish open-banking fintech that scaled to 600+ employees before its acquisition by Visa, where he led a platform team supporting hundreds of engineers. Before that, he led cloud engineering teams at Google.
I reached out to Fredrik to discuss what changes when you go from scaling a high-growth fintech to building a team from scratch at an early-stage startup.
Takeaways
The big-company hires who thrive in startups are the ones who see nothing as “somebody else’s problem,” and don’t mind shifting their priorities depending on what the company needs.
Engineering ladders and performance reviews feel boring and corporate, but they’re what keep expectations consistent when headcount crosses into the hundreds.
Distributed teams work better when you mix locations within teams rather than grouping by site, even though co-located teams seem simpler on paper.
Autonomous teams sound good until each one becomes a fortress with its own agenda. Fluid structures and rotating people between teams prevent that from hardening.
Yassine: You’ve hired engineers at Google, Tink, and now EsterCare. When someone from a bigger company wants to join an early-stage team, what separates the ones who thrive from the ones who struggle?
Fredrik: Obviously it depends a bit on the role but one thing that everybody will notice is the breadth of the role. In larger companies, there are so many support structures and different teams in place that your role is often to do one specific thing. In small start-ups, there are no such structures, or maybe even other teams, so the job is more to do what is most needed at any given time.
Using myself as an example, yes most days I spend time on our technical strategy or implementing new features. But another day my main priority might be buying a laptop for a new employee. Or watering the plants in our office :)
So to answer your question about who will thrive, the people here really must be problem-solvers and without too much prestige. Someone who understands that very few things are somebody else’s problem.
On the flip side, this comes with many benefits. In large companies, even in senior roles, you often work on things with a narrow scope and a limited impact on the overall business. In smaller organisations, your individual impact is so much bigger.
And not to mention the speed of getting things out the door. Here we can go from idea to having the feature in the hands of our customers within days if we want to. That is very challenging to achieve in larger companies with quarterly planning, organisation-wide prioritisation, dependencies between teams, and so on.
Yassine: Tink scaled to 600+ people across Europe during your time there. Looking back, what did you put in place that felt premature at the time but you’re glad existed before the growth really hit?
Fredrik: I’m surprised at myself for saying this, as I find these kinds of things a bit boring and “corporate-y”, but we did get a good engineering ladder definition and performance review structure in place fairly early.
It creates a lot of work and adds new processes which will inevitably take time away from core tasks. But when your headcount starts climbing into the hundreds, you have to have something in place that ensures everyone is working to the same expectations. The end result is that wherever in the organisation you are, and whatever job you are doing, your performance is rewarded equally, regardless of who your manager is.
It also allows engineers to understand what behaviours and efforts are valued the most, and provides a mechanism for them to grow into more senior roles, if that is their ambition.
And finally, the tougher but very important reason for role definitions and performance reviews: it allows you to systematically identify people who are not meeting the standards you have set and hired for. This will then force you to manage poor performers by either helping an individual to get back on track or, in the worst case, explain that this might not be the right place for them.
Yassine: Tink had teams spread across a dozen countries. What did you learn about making distributed teams actually work?
Fredrik: Make the teams spread across several sites, i.e., have people from different countries in the same teams. It seems obvious at first to do the opposite, i.e. that you should have teams that are built with just people from the same location as they then speak the same language and work from the same office. But in my experience, this creates weird conflicts and lack of understanding between the teams.
And then the obvious: make sure that virtual teams have the opportunity to meet in person, at least once, but ideally more regularly. Just working together in the same room for a couple of days and then going out for dinner and drinks does miracles to the level of collaboration.
Yassine: You saw Tink’s full arc, from growth to the Visa acquisition. What lessons from that experience are you applying as you build EsterCare’s engineering team?
Fredrik: Three things come to mind:
1. If you are growing very fast make sure you have people in charge of the overall architecture in place. Call them Staff Engineers or System Architects or whatever fits your liking. Put them in charge of making sure your overall system architecture stays sound and coherent, that you have the same practices and processes in the whole organisation for things like incidents, API design, testing, deployments and so on.
2. Don’t go too hard on the “autonomous teams” strategy. Try making things stay a little bit fluid with people moving around in the organisation, with teams that grow and shrink depending on workload. Otherwise you will end up with each team being almost like a little fortress with their own agenda and very few contacts with the wider organisation.
3. Don’t just add more things in perpetuity. Be it on system level or feature level. You have to be able to “kill your darlings”. Or take the tough decision that a part of a system just is beyond salvation and needs to be rebuilt.
📚 Fredrik Wallenius’ Go-To Resources:
3 people I follow and recommend:
Authors of the best engineering books out there:
1 podcast I make time for:
Mellan Kodraderna (Swedish podcast on engineering leadership)
A book that shaped my thinking:
Thank you Fredrik for your time and insights!
This interview is part of the “Exec Engineering Dialog” series where I interview seasoned tech leaders on the topics of talent, product, management and culture.
If you liked the insights shared in this interview, consider giving feedback and/or sharing it with your network, it’s the best way to help this segment improve and grow.
Yassine.