Welcome to the Engineering Leadership Newsletter - your weekly dose of real-world insights from experienced engineering managers.
Each issue is hosted by Rick Boone, who sits down with experienced leaders to unpack how they build great teams, make hard calls, and grow in their roles.
“How do you go from a PHP monolith serving food delivery to a $320 million super app spanning groceries, logistics, e-commerce, and laundry – all while keeping your tech team sane?”
That’s the challenge Nikita has been navigating for the past 4.5 years at Snoonu, Qatar’s fastest-growing tech company. He joined right after their Series A as a tech lead – the first engineer from the CIS region.
Today, as CTO, he leads ~200 engineers managing 150+ microservices across multiple products.
But here’s what makes Nikita’s story fascinating: He didn’t just scale technology. He reimagined team ownership, microservices architecture, and staying close to the code while managing at scale.
In this edition of the Engineering Leadership Series, we explore:
Why network monoliths are worse than actual monoliths
How to structure teams around business domains
The real role of AI in production systems
Why your CTO should still check dashboards at 6 AM
Let’s dive in.
🎯 From $5M to $340M: The Super App Strategy
Snoonu started like most delivery startups: focus on food, nail the experience, then expand. But there was a problem.
“We quickly recognized that the size of the market in Qatar for food delivery is not enough to achieve our goal – become a unicorn,” Nikita explained.
So they went wide. Really wide.
Today, Snoonu is:
Food delivery
Grocery delivery (retail partners + quick-commerce dark stores)
Last-mile logistics (B2B & B2C)
E-commerce marketplace
Laundry services
Event platform (Snoonu City)
Power bank sharing
And more
With only $17M total investment, they reached a $340M valuation when Jahez Group acquired 75% of the company.
“This huge surface area impacts everything,” Nikita said. “How the organization is structured, how the tech team is structured, what processes we apply.”
🔥 The Network Monolith Problem
When Nikita joined, Snoonu was mid-transformation. They were migrating from a PHP monolith to .NET microservices. The mobile apps were being rewritten from React Native to native Kotlin and Swift. Everything was happening at once.
“It was a really interesting time to not sleep at night,” he laughed.
But here’s the twist: the migration to microservices didn’t solve their problems. It made some of them worse.
“It was a network monolith,” Nikita said bluntly. “Very coupled microservices exchanging massive amounts of data over the network.”
I leaned forward. “So you had all the complexity of microservices without the benefits?”
Not exactly. One clear advantage was improved ownership. With a monolithic codebase, incidents often turned into blame games: “That’s the other team’s fault.” We needed to eliminate that back-and-forth over who broke the system.
And they took it even further. Split even more! Microservices by business vertical, not technical layer.
Now they’re working toward a future where:
Food, groceries and every vertical has its own stack from gateway to domain services
Each vertical can deploy independently
Each team own their code
“If something goes wrong with groceries, food keeps working,” Nikita explained. “Yes, we duplicate code. Yes, we implement gifting separately for the marketplace and food. But we’re fine with that because we know if the marketplace breaks, food continues.”
The trade-off is intentional: duplicate some work to gain reliability and clear ownership.
🧩 How to Structure Teams That Actually Own Things
Early on, Snoonu tried the classic startup approach: small cross-functional feature teams. Two teams of about 10 people each - backend, mobile, QA - all working together.
But they hit a wall.
“At some point, I had around 20 backend engineers reporting to me,” Nikita said. “It was really tough to even evaluate performance or support them properly.”
The matrix structure - engineers reporting to platform leads (backend, mobile, QA) while working in feature teams - created a disconnect. Leaders couldn’t stay close to their people.
So they made a critical shift: empower tech leads as direct managers.
Now each tech lead manages their own team and pairs with a product owner.
The tech lead owns delivery
The product owner owns discovery
Responsibilities are clear.
The org structure mirrors business domains + logic:
A squad for food
A squad for groceries
A squad for marketplace
A squad for new businesses
Each squad consists of 2–3 teams working on a single domain.
“From an organizational point of view, we have very specific domains for each team,” Nikita said. “From a technical point of view, we’re still behind. We still have core microservices serving multiple verticals. But we’re on a long road of refactoring to solve it.”
📊 The CTO Who Still Debugs at 6 AM
Here’s where Nikita breaks the mold of what a CTO “should” do.
Most CTOs at his level are levels detached from the code. They set strategy, they align with the business, they manage executives. Nikita does all that - but he also wakes up, opens Datadog, and checks for performance spikes.
“The first thing I do in the morning is check my dashboards, check alerts, sometimes check database performance,” he told me. “We have 150, maybe 200 microservices now. I can’t know them all. But if I see an interesting spike, I go deep. I check metrics, traces, and sometimes read the code. Then I throw it to the team and say, ‘I think here’s the performance issue.’”
I asked the obvious question: “How do you know when to stop? When to hand it off instead of fixing it yourself?”
He had a clear rule: “The last stop is definitely when I need to write code. If I find something and the next step is to just write and fix the issue, it’s time to stop.”
He gives himself 10-15 minutes to investigate. If he can identify the specific issue, he hands it to the team with context. If not, he lists the steps he took and passes it along.
This isn’t micromanagement. It’s about maintaining enough context to make decisions during emergencies.
“I don’t want to be the manager who, when the system is down, is calling 20-30 engineers one by one trying to get someone on the call,” Nikita said. “I’ve seen that. I don’t want to be that person.”
Two weeks before our interview, Nikita spent 3 AM to 6 AM on a call with his team debugging an ERP issue. He wasn’t coding. He was watching, asking questions, checking metrics.
“I didn’t do anything,” he said. “But I was just watching what they were doing. And I actually figured out some issues we need to solve in the future.”
🤖 The Hard Truth About AI in Production
Nikita uses AI extensively - but not where you’d expect.
“Personally, I found it very cool. I can code tools or automate stuff much faster than before,” he said. “But I’m pretty convinced it’s not enough for production-ready systems.”
The problem? Context.
“We have 150, maybe 200 microservices. There’s no solution that can have all this context. Or to provide all this context, the engineer needs to grab it and put it in the prompt - which takes the same amount of time as just writing the code.”
Snoonu’s approach to AI is pragmatic:
What they encourage:
Engineers can use any AI tool they want (OpenAI, Cursor, Claude, JetBrains AI Assistant)
Use AI for prototyping, MVPs, and internal tools
GitHub Copilot for basic code checks (saves time on routine comments)
Automating boring tasks like updating package versions across microservices
What they’re cautious about:
AI-generated production code without human review
Letting juniors push “orphan code” that passes tests but has no clear owner
Using AI for business-critical logic
One clever use case: an intern built an AI agent that automatically creates pull requests to remove feature toggles that have been turned on for over a month.
“It’s very boring work to remove feature toggles,” Nikita said. “But AI does it well.”
For customer-facing features, they’re experimenting with agentic AI - like an AI assistant in their marketplace that helps customers find products through conversation.
But for the core engineering work? AI is a tool, not a replacement.
“We can’t routinely entrust AI with sophisticated tasks and expect production-grade results.” Nikita said. “We’re not there yet.”
🔄 Junior vs. Senior: How Different Generations Use AI
I asked Nikita if he sees differences in how junior versus senior engineers use AI.
The answer was striking.
“Juniors are much more open to use AI tools,” he said. “With seniors - engineers with 10, 15 years of experience - there’s much more resistance. Maybe because they better see the downsides. Maybe because they’re just more conservative. But juniors are born with AI. It’s more natural for them.”
Senior engineers use AI differently:
Explaining unfamiliar code (like a backend engineer reading Swift)
Generating Python for AWS Lambdas (when their main stack is .NET)
Side tools and background checks - not critical paths
Nikita also noted that frontend and mobile engineers use AI more than backend engineers. “Their frameworks are changing every month. They’re always more open.”
This observation mirrors what I’ve seen elsewhere: the resistance isn’t necessarily about age or experience. It’s about how confident you are in your ability to spot AI mistakes.
📏 Performance Reviews Without KPIs
“There are two periods each year at work that I’m not a fan of.,” Nikita said. “It’s winter performance review and summer performance review.”
He’s not alone. Most engineering leaders hate performance reviews.
But Nikita’s critique goes deeper: there are no good KPIs for engineering teams.
“When I’m leading a small team of six people, I can say who’s working well, who’s not, who’s outperforming. There can be a team of great engineers who didn’t deliver a feature because requirements kept changing. But they’re still great engineers.”
When you’re managing 40 teams? You can’t go that deep.
Nikita’s vision for the future is bold: use AI to analyze unstructured team data.
“Each team generates tons of artifacts: code, JIRA, Figma, Notion, Confluence, Slack conversations, even daily standup meetings. If we can have AI analyze this unstructured data for each team, each feature, each project - it can say, ‘This person wasn’t engaged. This person behaved well. For this feature, the design changed constantly, that’s why it was delayed.’”
He’s already prototyping this internally.
“I’m not really interested in individual performance,” he said. “I need to know that every team delivers the results expected from them in the time expected. It’s about reaching commitments. And if a team isn’t reaching their commitment, I want to know before it fails - and why.”
Engineering performance data, without the manual work
HackerPulse pulls signals from Jira, GitHub, and the tools your team already uses — delivery patterns, focus time, workload distribution — so you stop guessing and start seeing.
🧠 Final Takeaways
As we wrapped, I asked Nikita for his biggest lessons. Here’s what stuck:
Ownership beats architecture: Duplicating code across verticals is fine if it gives teams true ownership and prevents the blame game.
Stay close to the system: Even as CTO, maintain enough context to make decisions during emergencies. Check dashboards. Read traces. Watch your team work.
AI is a tool, not a strategy: Use it for automation, prototyping, and boring tasks. But don’t ship production code without human review.
KPIs are broken: The future of performance management is analyzing unstructured team data with AI - not counting lines of code or story points.
Nikita’s journey from backend engineer to CTO shows that great technical leadership isn’t about distance from the code. It’s about knowing when to dive deep and when to trust your team - and building systems that make the right behaviors inevitable.
Really insightful piece, especially your perspective on how AI changes execution and organizational bottlenecks, not just productivity. It’s refreshing to see such grounded thinking from someone building at scale. Truly impressive what you’re building at Snoonu, and I’d honestly love the opportunity to work and learn alongside teams with this kind of vision someday.