Week 12, 2025 - Managing Focus

This is a shorter edition than usual: life throws curveballs and makes me reshuffle my plans. Crises have a silver lining: they make prioritization easier. When there’s one obvious thing to focus on, the cloud of uncertainty and self-doubt disappears.

In light of this, I’ll also have to skip next week’s newsletter and will be back on the 4th of April if all goes as planned.

📋 What I learned this week

I finetuned how I use Claude AI in writing. Last week I explained the experiment I ran with Claude AI’s project context, to ensure the draft it produces is close to my leadership (and writing) style. This week I took a different approach: instead of simply asking for a draft, I put most of my energy into writing the key points myself, in the first prompt. I didn’t pay much attention to wording, and I was quite concise, but I made sure that my approach was clear to the management problem posed. After this prompt, I took the first draft to my editor and used it as a basis, making minor and bigger adjustments — which was easier because the quality of the source was better than last week.

The resulting article about a move request to another team is just as good as if I had written from scratch, but it took half the time to author this way.

🤔 An Article that made me think

You (Don’t) Need Product Managers

Great topic from Rands (of Leadership Slack fame), essentially arguing for Product(-minded) Engineers, albeit, with quite some of rage bait in it. It defines the problem of dysfunctional teams very well: anyone who doesn't nod with enthusiasm at some of the bad examples has not spent enough time in software development yet. Still, a colorful problem definition doesn’t validate the solution.

I can boil down Rand’s article to two main points:

• You need one single person accountable for the product. This person was the PM, but instead, it should be a Product Engineer, they should be the ones responsible for the success of the outcome of a product engineering team.
• Software is created by individuals, and the article advocates for the role of a Product Engineer, with a mix of engineering (”Have living breathing code in the product — right now”) and product (”Have a deep understanding of how users perceive their features and how their changes would affect their perception.”) traits. However, this person is not exceptional in either area: there are no unicorns, and even the article doesn't include characteristics of deep technical and product expertise. No mention of pragmatic, forward-looking architectural decisions; no mention of deeply understanding the business outcomes that are expected from the software they create, etc.

I disagree with both of these points.

• I believe that in high-performing product engineering teams, accountability for the holistic success of the product is shared between the EM and the PM. Parts can and should be broken down (this is a great summary of how), but looking from afar, PM and EM are jointly responsible for the team’s success. Yes, it could lead to misalignments, finger-pointing, wrong assumptions. But if that happens, then they both failed. The strength of this setup is that it forces the EM and the PM to work together, with both parties adding their expertise areas to the success of the team. I agree that single-person accountability makes a lot of things clearer and easier. However, there is value in shared accountability: it forges a strong pair and encourages effective collaboration. It's similar to what the article itself describes when talking about the value of struggling with hard decisions, and advises against a CEO-minded PM calling the shots even if it would be easier.
• Software is not created by individuals but by teams. While the advance of AI-assisted coding might challenge this, I still believe that the best-performing products are created by high-performing, diverse teams of engaged people with different strengths. A group of engineers, product managers,, and designers; where everyone has a deep expertise in their own area and a more shallow familiarity in the others’; collaborating frequently, effectively, and efficiently; can produce better results than the same amount of swiss-army-knife Product Engineers, who are okay in everything but not exceptional in anything.

Still, I agree with most of the article: Engineers should embrace the product, know what problems and opportunities they are working on, and more importantly, why. Product Managers should understand the technicalities of their product scope, and be familiar with past technical decisions and future options, and the often hidden impacts of these on product quality, reliability, and flexibility.

We don’t need Product Engineers, we need Product-minded Engineers. And we need Engineering-minded PMs too, collaborating in a high-performing team, where everyone brings their deep expertise to the mix. Achieving this will result in not an additive, but a multiplier combination.

An interesting observation: all the desired characteristics of the Product Engineer Rands describes are focusing on the past and the present. There’s not much about the future, neither engineering- nor product-wise. It’s very telling that this article was written in a high-pressure era, where companies focus on surviving today, not putting much effort into figuring out where they want to be in two years.

🏛️ Something cool: Archive Team

I just discovered this amazing initiative, despite being more than 15 years old by now. In short, this is a group of volunteers across the world, who recognized that our history, in increasingly bigger parts, is online — but anything online can disappear by a company shutting down or just switching priorities, let alone administration changes and wars. You might be familiar with Archive.org, a separate organization that stores and makes archived web pages accessible. You can look at the Archive Team as one of the big contributors to the Internet Archive.

The Warrior tool is interesting from an engineering point of view too: a consistent, cross-platform, easy-to-update environment is provided via a Virtual Machine image and Docker container. Workers talk to trackers to get their tasks in the selected project, download contents from target resources, pack them in the WARC format, and upload them for sorting and storing. This distributed architecture ensures ease of use, resilience, and scalability (both up and down: nobody wants to DDOS anyone).

Their latest project, one that I’m also participating in, is archiving the Voice of America before it gets shut down. I remember when VoA and Radio Free Europe was the literal voice of freedom in the part of the world where I grew up – and the efforts of the Socialist dictatorship trying to silence them. We owe it to the next generations to preserve their content, so all the nuances of history can remain discoverable. You can track our progress here and join the effort.

That’s it for this week, save something for the future this weekend,

Péter