Week 44, 2024 - Beginnings and Endings

We have a new episode of The Retrospective Podcast live, the second one where we focus on one subject only. This time, we covered the scenario when an Engineering Manager moves to a new team. We discussed the challenges of this situation from the angle of the three main roles of an EM: execution, team- and personal support. Check it out on your favorite podcasting app - or play it on YouTube. (Yes, we also have a jingle! Exciting times!)

Jeremy and I have also been tinkering with the new website of our podcast; I can give you a sneak preview here before it goes live later in November. We still have a few odds and ends to iron out before we launch, as you will see, but you can already check our archive of 15 recordings and subscribe to get a notification when new episodes launch. Our inboxes are open for any feedback!

📋 What I learned this week

Another cool meetup after last week’s: this Wednesday I had the chance to meet some old and new engineering leader friends, and watch two interesting presentations. I’ll link the recordings once they go live in a later newsletter, but for now, a few excerpts from the notes I took during the talks.

How to Build a Great Product (and Still Fail) from András "Draven" Fincza, about the rise and demise of their sports racing video app ExperiRace.

• I loved all the shortcuts and simplifications they did to validate their ideas, using any tools and platforms available to get feedback. A small example: they were experimenting with in-race video streaming, but didn't have any mobile app yet. Instead, they simply created a WhatsApp group and invited a bunch of friends to interact like they'd use an app. One of their main lessons was this lean startup approach: don’t care about tomorrow’s scale problems today, simplify everything to validate your ideas today.
• Most painful learning: they focused so strongly on finding a Minimum Viable Product that they ignored the topic of Minimum Viable Business. They validated features and focused on user feedback, ignoring the questions of customers. This led to athletes loving their product – but the company struggling due to the lack of a scalable monetization scheme. Having no competing products in this field should’ve been a warning sign that there might be no great business opportunities here. They delayed investor outreach, and by the time they realized the need to move to B2B and focus on race organizers as the core customer base, it was too late. “Improve instead of invent” would’ve been a good guiding motto, according to Draven.
• Finally, it seemed to me that their main reason to close the company was because of faith lost in the product. By the end, they seemed to have a good chance to run a self-sustaining business, but it was not the hockey stick explosion they dreamt of and sold to their investors. I applaud the strong discipline to draw a line, call it quits, and return some of the money — but this also tells me that faith and perseverance are some of the strongest characteristics of successful startup founders.

The second talk from Ákos Kapui, CTO of Shapr3D explained their engineering team’s written communication processes under the title Why Planning is Still the Core of Great Engineering. On the surface, the practice of Product planning → Engineering design → Implementation → Release seems a bit waterfall-y, but in practice, later stages frequently refine earlier ones, and they focus on iterative and incremental progress, ensuring there’s continuous feedback between the stages.

My takeaways:

• It’s interesting to see that they prefer iterating on documents instead of iterating on code because “code is like concrete” and “nobody likes changing it”. I might be coming from a different engineering culture, but my experience would be encouraging me to focus on making sure it’s safe to change code to try out stuff. My worry with iterating on documentation is that real-world feedback is missing from this process, which can lead to a risk of either leaving out crucial aspects or premature optimization.
• That being said, I agree with Ákos’s later comment, saying “Data is even more rigid than concrete”. The foundation of most engineering products is data representation, and making changes there, when you have a significant user base, can be painful and expensive. So indeed, proper planning and having early discussions pay out. Still, especially if your product is frequently changing, investing in flexible data structures can help delay “data debt”.
• There was a great answer during the follow-up panel discussion to the question “How do you decide when Engineering Design Documents are needed?”: “When your decision significantly impacts how people write code.” I loved the Developer Experience aspect, I think it captures well the balance you need to take between moving fast and creating something solid.
• Nice quote: “Engineering culture is defined by how you communicate and make decisions.”

🤔 Articles that made me think

TrainingPeaks acquires IndieVelo

Acqui-hire story from the cycling world: the Zwift-clone focused on fair racing got bought by TrainingPeaks, one of the leading sports training platforms. I share it here not because I love cycling, but because of a small aspect a friend of mine commented about when we discussed the news, more concretely, this quote:

What’s been most impressive about IndieVelo is the rapid pace of development, with each Monday morning bringing a new version of the app and a slate of features. Just look at this list of each week’s additions (no, for real, go look at it). And the kicker? The development of the entire app has been just a single person: George Gilbert.

The joke was that this is the speed you can achieve when you don’t have to struggle with other team members. And there is some truth to this: the performance of an engineering team is directly proportional to the quality of communication within. This is the main explanation for Brook's Law, stating that adding more people to an already delayed project will further push out the completion date: because suddenly, you’ve increased communication overhead, and the proportion between team size and communication need is often exponential.

Google's failed experiment with self-managing engineering teams

Ex-googler talking about the late 2000s when near-infinite income met with the idea of hiring smart people and letting them self-organize. I never worked in one of these huge tech enterprises, but had some friends who did during the 2010s, and they said the best way to illustrate the amount of crazy going on is to just watch the TV series Silicon Valley, whose creators consulted techies during writing, but had to cut out some of their stories because they decided they didn't sound credible enough even for a comedy show. Anyway, fun story to illustrate the importance of good management.

Proxmox VE Helper-Scripts Project Update #4009

A shocking update from tteck, the creator of the awesome Proxmox Helper Scripts project. He was diagnosed with terminal cancer and has less than a month to live. My second thought on this was about the fragility of open-source projects: potentially thousands of people have systems set up that automatically download and execute updates with elevated privileges, regardless of repository ownership.

But my first thought was, of course, about mortality, and how to make the best of the unknowingly short time we have left.

That’s it for today, appreciate your loved ones this weekend,

Péter