Week 20, 2025 - Consolidate and Move

The biggest Hungarian tech conference is coming up in two weeks, and I’ve been asked to moderate two panel discussions on AI Security and Engineering Efficiency. I’m super excited about this opportunity: I frequently visited and wrote about the conference, and had the chance to give a talk last year during Craft Mini about staying relevant as a developer.

I tinkered with my websites this week, which resulted in final (lol) clarity about the weekly Engineering Management challenges I’ve been running since January. I decided that the best is to use the LeadTime brand I already have for this Substack newsletter, so everything has been moved to leadtime.tech. You can find the latest challenge there, where I gave ideas and viewpoints about team-building.

This meant that I had to extend the front page and About pages of peterszasz.com to include the description of the mentorship and consulting services I offer. This site has links to all the content I produce now, including the LeadTime series and The Retrospective podcast. I wired up sections on the site to display the latest publications via rss2json.com (thanks for the tip, Emese!), but it bugs me to have to rely on an external service and to do all the logic on the client side. Maybe it’s time to look into Ghost integrations to do this properly.

🤔 Articles that made me think

High-performing and Blocking Staff Engineer Behaviors

This small table is gold. Thiago Ghisi summarized dozens of first-hand cases, and identified common behaviors that drove - or halted - Staff promotions. Note that the vast majority of these areas rely on soft skills: business alignment, ownership, communication, mentorship, conflict management, influence, etc. Earlier, I wrote my notes on Becoming a Staff Engineer, but maybe in the future I’ll add this table as an illustration if managers ask me for example behaviors. It’s so common to see frustrated developers not understanding what’s missing for the next step, and doubling down on technical expertise lack of a better idea (and proper management). This table might help them too.

How to Provide Feedback on Documents

I love Will Larson’s candid, structured, and concise writing style. Here, he describes a process improvement he implemented at Carta. The way he found out what to change is exemplary too:

• he diagnosed a problem (teams making misaligned decisions),
• dug into the true reasons (teams are reluctant to share documents because they are concerned about the time overhead of dealing with comments),
• and the risks (putting more responsibility on the authors would further discourage them from sharing),
• then came to the solution: Feedback on a document should be optimized for one thing: to help the author.

This might sound scary (”but, I need to look out for the holistic good of our product / business / codebase”), but it’s the right approach. Teams already have ownership and accountability with it; the reader’s task is to only speak up if it helps them do a better job in their scope.

Side note: You might have seen someone’s feedback on a document where you guessed they were optimizing for their own time, and left random comments as they were reading the document, regardless of some of those eventually becoming obsolete or moot as they progressed. I call this Drive-by Commenting, and find it borderline disrespectful. Don’t do that, it will result in more time spent in async back-and-forths and frustration, potentially for you too. If you don't have time for this, then your comments are probably not that important. If they are, make time for expressing them efficiently. Optimize for supporting the author, not your time investment, and you will help build a culture where you will be treated similarly.

Dumb Leadership Mistakes I’ve Made

Personal, candid share from DX CTO Laura Tacho. I love how everything is framed around accelerated learning. I made most of her mistakes too: I ignored my intuition in a performance management case, worried about not being technical enough, or witnessed pointless A/B testing running amok and slowing down all development.

However, all of the areas she mentions are actually about a balance between two extremes. Intuition versus facts. Data versus vision. Buy versus build. Engineering versus business priorities. The hard thing is finding the right balance between the two, and being ready to continuously course-correct, depending on circumstances. Extremities rarely work well.

37Signals moves out of AWS

After months and months of planning, makers of Basecamp and HEY are in the final stage of migrating away from AWS data storage, bringing their hosting costs down from $1.5M to $200K per year. All this with essentially a drop-in replacement, as their new provider Pure Storage has an S3-compatible API. They managed to have the $270K fees waived for moving out the petabytes of data they have, citing Amazon’s recent public announcement. (If you’re an engineering strategy maker, take a note: you might have thought egress fees are how they’re keeping you locked in — it's not the case anymore!)

This is another sign of the high-stress era we’re in: when your main priority is growth, you don’t take risks on hosting and go with the market leader. When the priority is efficiency and cost saving, it’s time to challenge everything, including fundamental building blocks like AWS. This increased competition helps emerging new players and forces market leaders to innovate. Both are great for customers.

That’s it for today, eat some fresh strawberries this weekend,

Péter