Being an Engineering Manager at IKEA businesses
On anti-corruption, legacy systems and business orientation. How it feels to manage engineers in a 'real' and huge business.
Continuing the series of insider takes from Engineering Managers at interesting companies!
Previously, we covered:
Today, we are going to cover Group Digital, IKEA’s IT unit. I was always curious how it feels to manage engineers in a ‘real’ and huge business, and what the challenges are.
I learned a lot from Nikolay! Passing the mic 🎤:
Hello everyone, my name is Nikolay, and I lead a team of 10 software engineers at Group Digital, IKEA’s IT unit. Our job is turning IKEA’s iconic, historically successful processes into modern digital experiences.
It’s not the kind of “digital transformation” you complete in a single quarter (or even a year) - it’s ongoing, iterative, and complex. We’re continuously investing in business workflows proven over many decades, rethinking any ageing automation systems, and finding ways for tech to serve IKEA’s customers better every day.
Today I’m going to cover:
The challenges of software engineers and EMs at Group Digital of IKEA
What’s different about engineering in such a company
Tech tradeoffs aren’t just for startups - a recent tech challenge we faced
Integrating a team after an acquisition
One thing I wish I knew as a first-time EM
Of course, bear in mind that my experience is in just a small part of the huge IKEA ecosystem.
The challenges of being a software engineer at Group Digital of IKEA
Below are several playfully provocative statements that reflect what allows engineers to thrive when joining Group Digital:
“This tech looks ancient, how are they not in trouble?”
Legacy used to mean something positive - the good things we pass on to the next generation. But in engineering, we tend to use it negatively. At IKEA, some systems have run for a long time to service the business well. They work. They support essential parts of a global business. Replacing them can be like open-heart surgery on a live person.
Sometimes you need to build custom tooling just to enable change. And sometimes, the ROI just doesn’t justify an immediate upgrade. Idealism around “modern” practices - agile, microservices, whatever - doesn’t always hold up in practice. A more conservative investment often serves the business better.
“Everyone here is clueless, I’ll fix it all.”
In such a huge, old, and successful business, humility is essential.
A business of this scale didn’t grow by accident. It may look inefficient to a new joiner, but what you're seeing is the accumulated result of solving real problems over time - with different tools, constraints, and people. Some knowledge has been lost along the way, but it was valuable at the time. This isn’t a sign of failure, it’s an opportunity to learn, contribute, and improve. Arrogance helps no one.
“This is the best approach, obviously! There is even a scientific article about it!”
The “best” approach isn’t useful if it solves the wrong business problem or no one else can follow you. Other teams may already be committed to different solutions, and that context matters. Leading a change well becomes more important than the best contribution. Just being right isn’t enough - alignment, timing, and understanding the broader business reality are what make you effective.
“It’s not my role, it is the PO’s responsibility.”
Understanding what “in service of the business” means can be frustrating to a new engineer.
The ones who do well are product-oriented: they connect the dots, solve problems end-to-end, and don’t wait for others to fill in the gaps. Growing into this role means developing stakeholder skills and learning the business deeply. Engineers who expect to only code will struggle. Willingness to learn and push through the upskilling curve is key.
In short: engineers who succeed here understand the business, take ownership, and respect the history behind the systems they're improving.
The challenges of fresh EMs at Group Digital of IKEA
Similarly, Engineering Managers also have their own adjustment struggles:
“Just send a meeting invite”
At Group Digital, people are collaborative and quick to jump on a call. It reflects IKEA’s value of “Togetherness” - but it can backfire. New EMs often get buried in meetings, especially when nothing is written down.
Pushing back gently seemed to work: no agenda, no meeting. I always prepare in advance, which helps me personally. What helps the team however, is that we regularly review every recurring meeting - its length, cadence, purpose, and attendees. Technical writing is key. When work is documented well and collaborative sessions are prepared in advance, then meetings become shorter, fewer, and more useful.
“When unsure, just get a consultant”
At Group Digital, we work with top-tier consultants. They help us fill skill gaps, move faster, and reduce budgeting risk. But it’s tempting to overuse them.
I’ve seen teams delay investing in internal skills because consultants did the job well instead. That’s a mistake. When we do bring in consultants, we expect them to coach as well as deliver - so when they move on, our teams are stronger, not dependent.
I’ve written more extensively about my personal preferences on the topic in the section “Make consultants useful again” of this article.
“Professional growth is about delivering the roadmap”
This one is subtle. Engineers often think consistent delivery = growth. But roadmap delivery is the team goal and the engineer's primary responsibility. Personal growth is different. It comes from feedback, reflection, and stretch goals.
I encourage engineers to define growth objectives independent from delivery and revisit them regularly. You often formulate the best goals with the help of people you respect pointing out your blind spots. Your success will depend on how you bring about change in your organisation. This will require your upskilling in soliciting useful feedback. I’ve written a deeper dive into my approach in this article.
What Makes Engineering at IKEA’s Group Digital Different
At Group Digital, engineering is tightly linked to the business. You’re not here to just write code, you’re here to really understand how IKEA works, and to make it work better.
1. Everyone works in a store.
At least once a year, every engineer spends a day on the retail floor. Yes, that means putting pillows on shelves or helping customers. It’s a simple but powerful way to stay grounded. We call it an “anti-corruption” practice - it keeps us connected to what really matters, and reminds us who we’re building for.
2. Business knowledge isn’t optional.
At Group Digital, domain knowledge is critical. You can't fake it. Engineers are expected to understand how the business actually works, beyond just the code. The ones who thrive are curious about supply chains, store ops, and the customer experience.
3. Engineers are product partners, not just implementers.
Engineers don’t just take tickets from the prepared backlog - they help shape the work. Specs are rarely more than 60-70% complete, and we’ve learned not to wait for perfection. Instead, engineers step in as problem-solvers, working with POs to clarify requirements and push for access to the underlying problems. works if product roles are willing to open up their decision-making process. Read more about why articulating the right problems matters.
4. We track how “done” a feature really is.
We’ve seen what happens when “done” is assumed but not defined. That’s how fake technical debt creeps in, and how expectations get misaligned. We now track outcome maturity explicitly: what’s the real level of completeness, what’s still missing, and what value is being delivered? This has helped stakeholders make better business decisions, and helped engineers focus on what matters first. (More on outcome maturity and alignment via live architecture documents)
5. We build resilient teams.
Resilient teams don’t burn out. We reduce the bus factor of siloing, avoid hero culture, and control consultant dependency. The goal is long-term value delivery with a sustainable pace. (More on my approach for building resilient teams)
Together, these practices create teams that are not only effective and enjoyable but also deeply connected to the business they serve.
Tech Tradeoffs Aren’t Just for Startups
We face the same infrastructure decisions as any modern tech org running its operation. Our backend team (Java for prototyping, Go for production) recently evaluated whether switching from Google BigTable to managed MongoDB could reduce cloud costs.
We ran a short PoC using real, replicated data. Performance and cost were nearly the same - but MongoDB’s managed service came out as more expensive once we factored out its advanced features, which we didn’t need. So we stuck with BigTable.
The point isn’t just about databases. A small, focused experiment gave us three things: leverage in cloud pricing negotiations, a deep review of our logic on two platforms, and better test coverage - we caught edge cases we hadn’t seen before.
You don’t need a complex AI use case to justify a short, practical reimplementation. Sometimes the ROI is in what you learn, not what you change.
Rushing to Integrate an Acquired Team
Sometimes, you don’t just build teams, you inherit them. After a new acquisition for Ingka Group of IKEA, the leadership team and I jumped in to help integrate the incoming IT team, their product, and their way of working into ours.
I didn’t realize how overwhelmed they were. We moved too fast, and while I was well-intentioned, some of the integrations were rough. More importantly, we hadn’t built enough trust. Once I noticed, we paused and focused on improving the relationship first - we aimed for a few shared successes before picking up the pace again.
It was a good reminder: in larger and complex businesses, integration isn’t just about systems or processes. It’s about timing, empathy, and meeting new teams where they are.
One thing I wish I knew as a first-time EM
Coming from an engineering background, I used to approach management like a logic puzzle - make the right argument, and people will align. That didn’t work.
I was too pushy. I’d present my thinking too early, which shut others down, especially quieter engineers who might’ve had better ideas. I thought I was being helpful, but I was actually silencing the team.
What I learned instead is the power of pulling, not pushing. Ask guiding questions. Inspire with a hypothetical vision, like “Have you considered…?” Omit your detail, but give people time to think and let them reach the insight themselves. It sounds surreal and paradoxical - you’ve rewarded the best with the EM role, and the team stops doing their best!? It’s slower at first, but the outcome sticks, and the team’s motivation, skill, engagement and ownership grow.
Arguments don’t land when there’s no trust. Especially if someone is stressed, they’re not even hearing your logic, at least until they themselves feel heard. Emotions aren’t a distraction, they’re a signal of something important you need to pay attention to - ignoring them and trying to “win” with logic kills creativity and blocks problem-solving.
That shift - from “being right” over my followers to creating space for the growth of others was a huge turning point for me.
Final words
Many thanks to Nikolay for sharing his experience and putting a lot of effort into this article!
I found it really interesting to peek inside such a famous company, which is not a classic ‘tech one’.
If you work at an interesting company, and want to share your lessons from it, go over my guidelines and ping me :)
Discover weekly
Vibe Coding as a software engineer by
and . Great article on the state of the trend.Job interview questions engineers should ask (but don't) by
and .Crossing the cringe minefield by
.
 | A guest post by
|