Menu

New advice for aspiring managers

Great advice here for new managers in this wild time we find ourselves in. In general:

Whereas the previous focus of managers was to rapidly hire and scale their teams, today’s focus is on expanding impact. This is because in today’s macroeconomic environment, output is key. In the eyes of a 2025 company, the more that you can do with fewer people, the better. There are very few additional people to go around, so the focus is on how you can help your team do more with less.

James focuses specifically on EMs, but the advice definitely applies to PMs too, so check out his post if this is you!

New advice for aspiring managers

Automatic syncing from Raindrop.io to Wordpress link posts

I read Ethan Marcotte’s Link bug this week, which led me to Sophie Koonin’s Automated weekly links posts with raindrop.io and Eleventy, and that is such a cool idea that I had to do something similar.

Thanks to getting nerdswiped by Ethan and Sophie I now have a Cloudflare Worker that takes links that I tag with blog on Raindrop.io, and posts them (with excerpts taken from the Notes section) as link posts to this blog. You can just scroll down to see a bunch of examples.

It’s not fancy but it works beautifully! Every hour it checks for new links in Raindrop.io with the blog tag, and then it creates a posts like this:

Link title

This is my note about the article, with markdown support.

Article Title

If this is something that could be useful to you, you can view the source code here and deploy to Cloudflare Workers to make it your own.

On estimates as navigation, not promises

I’ve been thinking about engineering estimates a lot and need to write about it. But for now, Adam Keys sums it up nicely:

Everyone knows surprises will happen. The estimate should help the team make better decisions when they do, not box them into promises they can’t keep. The best estimates I’ve given weren’t the most accurate—they were the ones that helped teams navigate uncertainty instead of pretending it away.

On estimates as navigation, not promises

Interdependence is My New Retirement Plan

Ok I love this story.

I’ve been reading a lot of Robin Wall Kimmerer lately. She tells a story in The Serviceberry that’s become a sort of guiding star for me, about the experience of a linguist who was studying a hunter-gatherer community in the Brazilian rainforest.

“He observes that a hunter had brought home a sizable kill, far too much to be eaten by his family. The researcher asked how he would store the excess. Smoking and drying technologies were well known; storing was possible. The hunter was puzzled by the question […]‘Store my meat? I store my meat in the belly of my brother,’ replied the hunter.”

And yes to this:

I’ve been thinking so much about what it would mean for me to “store my meat in the belly of my brother”—to give to my loved ones and communities and trust that my generosity will circle back to me when I need it. I know it’s how I want to live. It’s how I want us all to be able to live.

Interdependence is My New Retirement Plan

My AI Workflow for Understanding Any Codebase

Great tip!

Convert GitHub repos to markdown with repo2txt, drag into Google AI Studio, and ask questions. Gemini’s massive context window makes it amazing for code comprehension.

The rest of the article goes into Peter’s AI coding workflow. I’ve mostly been using ChatGPT o3 for spec creation, but this is another compelling alternative.

My AI Workflow for Understanding Any Codebase

Field Notes From Shipping Real Code With Claude

I know we’re drowning in vibe coding stuff right now, but this extensive post about shipping code with Claude is a fantastic resource. Great prompt rules and tips, and also solid advice for what the humans are for…

Your role as a senior engineer has fundamentally shifted. You’re no longer just writing code—you’re curating knowledge, setting boundaries, and teaching both humans and AI systems how to work effectively.

Lean management and continuous delivery practices help improve software delivery performance, which in turn improves organizational performance—and this includes how you manage AI collaboration.

Field Notes From Shipping Real Code With Claude

How to provide feedback on documents.

This is great advice on providing feedback on docs. This especially resonated:

Before starting, remember that the goal of providing feedback on a document is to help the author. Optimizing for anything else, even if it’s a worthy cause, discourages authors from sharing their future writing. If you prioritize something other than helping the author, you are discouraging them from sharing future work.

How to provide feedback on documents.

In Praise of “Normal” Engineers

I love this take on the “10x engineer” phenomenon. Ubuntu (the African concept, not the operating system…) strikes again. “I am because you are.”

Individual engineers don’t own software; engineering teams own software. It doesn’t matter how fast an individual engineer can write software. What matters is how fast the team can collectively write, test, review, ship, maintain, refactor, extend, architect, and revise the software that they own.

In Praise of “Normal” Engineers

Platform reality

Robin Sloan discusses Substack, and platforms in general, in another excellent post:

Expect enclosure; expect a few big winners; expect advertising, with all the attention-hacking that will demand. Expect, also, that writers will con­tinue to mold their work to fit Sub­stack’s par­tic­ular ecology, rather than “merely” use the tools to pursue their inde­pen­dent visions and ambitions. We learned this about plat­forms a long time ago.

Platform reality

Product Management: The Good, the Hard, and How to Know If It's Right for You

An engineer recently sent me some questions about the Product Management role. I took a long time to respond because I saw it as a great opportunity to reflect on the role and what it means to me. I decided to share my answers below, in case it’s useful for anyone else!

What did you like the most about your job as a PM? (I say past tense because Director can be different)

The joy of shipping, and shepherding products and features from ideas all the way through execution and user feedback and continuous iteration.

To me, the PM role is a people job. How do we get people to work together to do amazing work? How do we get the best ideas out, how do we make them real? How do we build things that people genuinely enjoy using, and don’t mind paying for? How can we understand how our products make people feel, and how can we make that better?

If you’re able to get into a product loop that does that over and over, it’s the best job in the world. You get to understand complex user, business, and technical needs, make sense of it all, and support a team of people to get useful products into the world. And then you get to talk to the people who use those products about how to make them even better.

Daniel Pink says we are all motivated by 3 things: autonomy (self-directed work), mastery (getting better at stuff), and purpose (serving a greater vision). At the best of times, I can’t think of another job that combines those 3 things as thoroughly as Product Management does.

What is the one aspect of the role that makes you from time to time (but consistently) say “I don’t think I want to do this any longer”? Or “I need a break from this”?

When we get caught up in the human tendency to forget about what we’re trying to do (that purpose from the previous question), and focus on our own needs instead. When I interact with teams and people who find their identity in their work to such an extent that it overshadows how cool it is that we get to do this stuff together. In short: when internal politics take over.

I don’t resent this tendency any more, to be honest. I used to, but not any more. This is normal human behavior—I am not immune to it, no one is. We want to feel heard, we want to feel useful, we want to be seen as competent and smart. But I now recognize very quickly when a discussion about a project or a product becomes about self-preservation vs. what is best for the team and the product and its users, and I am allergic to it. It makes everything more stressful. It requires having to “read between the lines” every minute of the day. It slows everything down. It makes everyone grumpy and wary of each other. It is poison to healthy teams and products, and it affects me deeply (too much).

I deal with it by losing myself in side projects, and spending deliberate time with the work people who don’t succumb to that behavior.

How do you advise me if I were considering either an EM or PM role to decide on which is more suitable to try out first?

I think the best starting point is to reflect on where you naturally find energy, especially when things get hard. Do you find satisfaction in crafting elegant systems and seeing the architecture click into place? Or do you come alive when you hear someone articulate a pain point and you can immediately imagine a better experience? Do you find yourself trying to optimize team throughput and code quality, or do you have an interest in clarifying ambiguity, getting people to work together happily and effectively, and shaping decisions through influence rather than control?

PMs and EMs both lead, but in different ways. Engineering Managers lead through technical insight, mentorship, and a responsibility for the velocity, health, and growth of the team. Their scope is often constrained by the product strategy/roadmap and what’s possible technically, and their main outcome is helping the team build the right thing in the right way.

Product Managers lead through context, clarity, and storytelling. They untangle complex ambiguity, and they create clarity when everyone sees the world differently (which happens on every project…). Their main outcomes are making sense out of too many chaotic inputs, aligning everyone on the problem to be solved (and how to solve it), and keeping the team connected to each other and customers.