Péter's Updates #72 - Less is More

(Belated) Happy New Year! I gave up naming these updates with the week numbers when the issues became more sporadic and decided to switch to simply numbering them. 72 already! Back when I started this newsletter, the regularity gave me some structure that, back then, I missed from my professional life. Since then, work picked up, I got more clarity about what I wanted do, and the role of a periodic, almost ceremonial routine got less important.

Since I last wrote, we published another episode of our podcast with Jeremy, this time about Timeboxing. If you regularly miss deadlines and lose control over time and scope, this can be a good listen.

Also, together with my coaching partner and fellow engineering leader Emese, and with the help of the Craft Conference organizers, we're starting something super exciting: an in-person, English-language series of events in Hungary for engineering leaders; a safe space where honest conversations and a meaningful exchange of experience can happen. Not a conference or a traditional meetup, but a professional community for tech leaders who don’t want to face leadership challenges alone. We're calling it Tech Leaders' Forum, and during the first session, we'll discuss the efficient, ethical, and effective use of AI tools in the work of an Engineering Manager. Register if you're in Budapest during mid-February, we have intentionally limited the number of participants to create a more intimate environment.

📋 What I learned recently

I mentioned earlier that I use Granola to take notes during meetings and mentorship sessions. This works pretty well for English, but they don't support Hungarian yet. Since most of my client sessions are in Hungarian, I've been looking for a tool that transcribes video calls and creates a high-level summary in my mother tongue. I also value privacy, so the more I can keep this local, the better.

First, I experimented with recall.ai. Their offering looked promising, an SDK-as-a-Service, that I could easily plug into my scripts.

Side note: I believe that with the advance of AI-assisted coding, SDKs like this that can handle complex parts of a system, tools that allow vibecoders to just glue them together to create something new, have a great future. I think this is the UNIX philosophy in the age of AI: interoperable, modular components that users can easily integrate into their own tools. Investors seem to agree.

That being said, after playing 30 minutes with their SDK, I couldn't even get their demo app to work the way I wanted, so I gave in to the temptation to go one level deeper. I can record audio; all I have to do is transcribe and summarize it. How hard could that be?

Well, it was a journey!

The first thing I learned is that while audio transcription is relatively easy, identifying who is talking (called diarization) is harder. OpenAI's Whisper API supports it, but has size limitations and various issues that pushed me towards a different approach. Since my use case is 1:1 discussions, I could assume that everything I record from my microphone is said by me, and everything that's played through my computer is from my client via a video conferencing call. OBS Studio can record these as separate tracks, so I trivially have diarization solved; I just have to transcribe the two audio channels and merge them with timestamps to have a transcription ready. Smooth!

Then came the second learning. After using whisper-large-v3 to transcribe the separate audio tracks, I was shocked to see that my transcripts are full of repeated lines! Literally, hundreds of lines of the same "Thank you!" or "OK, that works." After some debugging, these repeated lines happened during the quiet parts of an audio track – when the other person was speaking. Researching the issue, I learned that this is a common problem for transcription models: they keep some previous text while transcribing the current one as context, to enhance the quality of the transcription. However, when there's just quiet in the track, they tend to get into a hallucination loop of repeating that previous text, due to a lack of finding something else to transcribe. Filtering out quiet parts solves this, and VAD, Voice Activity Detection, is implemented in whisper-ai, and turning it on and finetuning some other settings solved this problem pretty well. All that was left was to have some clever prompting to summarize transcripts, key points to pay attention to, etc, and I was done.

🤔 Articles that made me think

Early-stage Startups don't need Managers

Love this article. I mean, I don't agree with it, or, to be more nuanced, I agree with the gist of it, just not with some of the (I suspect intentionally triggering) details. Things like "The only place where managers motivate people is in management books." Bullshit. But I love articles that try to challenge my worldview.

I fully agree with the author that a fresh startup has only one priority: finding product-market fit. Nothing else matters because if you miss it, your company is over. So, as the article compares, on the tech front, you run node with postgres, and you choose similarly boring but proven management practices, if any. Full transparency is a great idea too, and can work very well at an early-stage startup.

I also agree that hiring at this stage can make or break a company. So can delaying a termination too long. It's just numbers: one bad hire is already ~10% of your small staff, add their influence on the others to the mix, and you see how big a difference this could make.

This is actually one of my problems with the ideas here: it assumes that you managed to find highly motivated and capable engineers, and also that this motivation is something that will automatically stay like that. Two very, very strong assumptions. Let alone hiring, the motivation part is far from trivial. It's usually high at early-stage startups, because the triad of Autonomy, Mastery, and Purpose is strong there: you get to do a lot of technically interesting development, on your own, in a new product that you believe in. However, all three of these can start to deteriorate as the company ages, people start to burn out, products pivot, the mission takes compromises, tech debt accumulates, and new colleagues take away from your autonomy. This can happen way before the 20-50 engineer limit the article mentions, and this is just one of the many situations an Engineering Manager can and should handle.

To be clear: I don't advocate for managers monopolizing leadership. To the contrary, good managers build leaders around them. This is the value they add, and the role they fill is not absent in early-stage startups: it's the CTO who does it. Amongst the million other things they are responsible for. Is it so bad to offer them some help?

Why are we Adding when we should Subtract?

Great piece of advice from Jenni Jepsen, from David Marquet's Leadership Nudges channel. She talks about how our biological wiring pushes us towards adding more, getting that reward of accomplishing something, ticking a checkbox, crossing out an item on our task list, etc. It made me think of two other things why we would be tempted to add instead of subtracting:

• Saying "yes" to something is inherently easier than saying "no" because the risk of doing the wrong thing feels smaller than the risk of not doing the right thing. Adding stuff has better optics, too. Which team gets the praise usually, the one that juggles 100 different stuff and still starts a new project, or the other one that announces during quarterly planning that they are intending to remove a feature?
• The temptation of trying to do more is even higher in the age of AI-assisted product development. Quick early wins give an illusion of progress that makes us push towards building more, instead of focusing on building the right thing.

The End of Scarcity

I had my entire career as a software engineer in an era when the differentiator between a good and bad developer was about craft. How much did someone learn, practice, and experience with the technical stack they had to work on?

With the advance of AI-assisted coding, this moat was filled, but another one emerged: taste. Those developers became successful who had the right judgment about what to build and how, regardless of who did the building itself. But taste, while harder than craft, is still learnable. As models get larger, and training data contains more specific good and bad examples, AI's taste will definitely improve too.

What's next then?

According to the author, it could be trust, ownership, responsibility, grit, accountability... the fact that the product is not a one-shot vibecoded Potemkin village that inevitably collapses in time. Interestingly, these all capture one thing: "I stand behind this thing." In short, the moat to great products is that, regardless of all the AI stuff, an accountable human is behind them.

By the way, if you look at where online media was heading towards in the last 5-10 years, you'll see something similar: next to the bloodbath of old media companies, individuals with distinct human voices, paid for by their audience, are popping up left and right.

That’s it for today, stop doing something this weekend,

Péter