Engineering management in the next unicorn app
The secrets of managing a super-effective remote team
Marcin Czech is the first engineering manager I’ve talked to who experienced every possible career path:
The classic path: he was a Team Lead at Grubhub, Head of Mobile at Zoomer, and Lead Developer at Brainly and SuperSapiens.
The free spirit: in the last 15 years he also created and launched multiple products as a cross-platform indie-hacker and his own boss.
The consultant: he advised multiple companies in part-time roles.
The founder path: being a founder and CTO of Roots.
Back in March 2023, Marcin was happy working on his own apps and doing a couple of consulting projects.
Then, through a mutual friend, Clint Jarvis reached out with an idea:
Having my own thing gave me leverage to wait for the right opportunity—a person with a great idea, not just another 'for money' thing, but something actually making the world a better place. Clint and Roots just felt like the perfect match to me.
Today you are going to read about:
How does starting a product from scratch feel like.
How Marcin manages an effective remote team without any headaches.
How to handle releases in an early-stage startup (hint: no fixed 2-week sprints).
Why you shouldn’t hire more developers - the Apple approach.
Handling growth and when comes the time to replace yourself.
As many readers enjoyed Being an engineering manager at Amazon, I decided to continue writing about how Engineering Management is done in different companies. The goal is to give you some practical advice you can use at your own company. Let me know if there are specific companies that interest you!
This article is not sponsored! If you are curious about the product itself, check out How to have 27 hours in your day.
Starting from scratch
When Clint (the CEO) started to build the founding team, Roots was a mindfulness IOS app that Clint built with a freelancer developer as a side-project.
He had a powerful mission: “Help people live a balanced life in a digital world”, and he decided to become serious about it.
He recruited Marcin (CTO), Pontus (Head of Design), and Vikram (User Experience Lead), for a very unique founding team.
Marcin is a ‘hard time’ person - the harder the problem, the more motivated he is to solve it.
I love those first months at the startup because you don’t know exactly what you want to build. It wasn't like we had a set plan, like building an analytics platform or a habit tracker where the market already exists and you can just copy.
There are 3 main things Roots did exceptionally at the start:
Not being in a rush - for a full year, they experimented, talked to customers, and went back to the whiteboard. Even after they had some initial traction, they kept iterating: design, prototype, build, feedback. Sometimes a validation required a fully-baked feature to try out and not just customer conversations.
Deleting old code - there was no ego or attachment. They did 2 big pivots - the first was to make the ‘blocking’ part the main functionality of the app, instead of a hidden feature. The second one was even harder - they completely deleted the code from the original app (only the login stayed…).
Making the technical side perfect - the biggest technical challenge the team faced was using Apple’s APIs.
There are two APIs: Screen Time API, which is private and keeps data on your phone, and Device Activity API, which handles blocking mechanisms. Cracking how to work with those APIs, and dealing with limitations, constraints, and bugs (yes, Apple has them!) took them many iterations.
I think that their focus on this part is the reason Roots is the only blocking app I’ve used (tried 6-7) that works perfectly, and it created a moat for them in the space.
By the end of that first year, they finally had something that worked well and was a real painkiller.
Leading a small remote team
Marcin is responsible for the tech and product sides, manages 2 developers (who release like a team of 5), and writes code for most of his time.
He worked remotely way before the pandemic (for ~15 years) and has a unique approach: his trick to successful remote management is to not need any management…
Here are the 3 steps he follows:
Hire perfectly: it’s an overused cliche, but highly independent people can save you so many headaches! They own their own learning, are well-organized, and take full ownership.
With the right team, a lot of the usual remote management issues like tracking and organizing tasks just don't exist.
Have a motivating vision - remote work is different from on-site work. On-site has a social aspect that motivates people.
With remote work, the mission of what you’re building becomes much more important. Roots is lucky to have Clint, who spreads his vision to the team, and I feel like we actually care about what we’re building. That’s crucial because it addresses the motivation part, and people are actually excited to work.
No processes - once you follow steps 1 and 2, you can let go of 80% of the management work you used to do. For example, most of our tickets (in Trello) are just links to conversations in Slack! If something is missing, the devs fill in the gaps themselves.
Releasing software in an early-stage startup
One of the core principles of the Roots brand is to care A LOT about the design. If you tried the app you know they are serious about it - it has the best UX of any IOS app I’ve tried.
Good principles are ones that force you to give up on something. In Roots’ case, they are willing to sacrifice speed.
The sprints are not time-based - they release only when they feel the feature is ready! Some of these big features (like blocking, challenges, and intentional blocking) took a couple of months. Quicker releases took ~two weeks.
They usually follow the 'eat the frog' approach, tackling the biggest feature that they think will need the most iterations or are most uncertain about. They build a prototype, ship it internally, get feedback, and iterate - meanwhile adding the smaller parts to it. Most features take at least one or two high-level iterations and a lot more lower-level fixes.
I loved this approach. From my experience, there is a lot of pressure in startups to release as many features as fast as possible. Usually, you get some time to make very small adjustments, but you rarely make a huge change after the release, as you are too busy building the next feature.
Why you shouldn’t hire more developers - the Apple approach
I asked Clint and Marcin why they don’t hire more developers. They have a product-market fit, the retention metrics are awesome. I really loved the answer here:
One of the big mistakes I've observed in startups, especially software startups, is over-hiring too quickly. It ramps up spending and creates challenges in establishing a workflow for the engineers. There's this idea that scaling the engineering team will scale revenue, but it never works like that.
We approach it the Apple way. Google and Facebook spend tons of money on R&D, especially now in the AI era. Apple has a different approach - they wait patiently and observe what’s working in the market. Then, they’ll do it in the best way for the users.
We take a similar approach. We focus on being completely sure what are the right features worth investing in, and then hire. We have a grand vision to become a unicorn, so we’ll definitely need to scale to other platforms and expand the team. But we’re not in a rush.
Handling growth with humility
The next part of the journey is to start to grow like crazy. Clint compares it to the meditation app space - 10 years ago there were tons of different apps, with Calm and Headspace just starting. Now they're the unicorns.
The screen time space is on a similar trajectory, and their aim is to become the Calm or Headspace of this space. That means raising a seed round, finding the right partners, and getting creative with marketing.
So what will the super-hands-on Marcin do? You are going to love the answer:
I’ve been involved in many startups, but aiming for unicorn status is exciting, uncharted territory - it requires significant growth across multiple dimensions. For that reason, I believe it’s essential to periodically assess if you might be standing in the way of that growth, and if so, how.
This involves navigating around your ego, recognizing both your strengths and limitations. The goal is to release ownership of tasks and processes, allowing other highly motivated team members to take them on. In some cases, this could even mean stepping away from your current role in the company. I’ll keep running this assessment as we grow to 30, 40, or even 100 team members
Bonus: how they use their own app
Marcin:
“For me, the biggest help from Roots has been stopping my habit of getting lost in YouTube Shorts. I’d start watching one and then keep going, but now the app stops me at 5 minutes, which has been very helpful in breaking that habit.
I really depend on that, so I ended up buying an additional phone just to keep my main phone untouched with the release version during testing (actually I have 5 phones now with different setups).”
Clint:
“In the mornings, I put on Monk mode, which blocks the most distracting apps no matter what. For productive apps like Slack or email, I use an intentional mode where I can get in, but I only have a few unblocks. The goal is to push myself to use a computer to be productive because it's more effective.
Monk mode kicks in every night at 6:00 PM and blocks all apps. I've gone from spending around 3.5 to 4 hours a day on my phone to consistently around 1.5 hours, mainly by avoiding scrolling on X and Instagram.”
Final words
I stumbled on this amazing team in a completely random way. I answered an email they send to their users, and it turned out that Clint is doing the customer support, so we got to talk. I’m a huge fan of the product, and I shared my experience with it in How to have 27 hours in your day.
I became truly curious about how they built it, so I asked for a Zoom meeting with Clint and the CTO, which was one of the more interesting conversations I’ve had. One of those that you feel you have MORE energy after it’s finished.
I hope you enjoyed their story, I promise to follow along and update you on their progress :)
Great piece, the not wanting to hire aggressively sounds similar to lessons learned from Mythical Man Month - thanks for sharing
Great insights. Built proof-of-concepts / prototypes is a great way to learn. And one of the most important and hardest things to actually do is to start with a clean slate when building the real system later on.