Management

Peter Schmidt talks with Graham Lee about whether spec-driven development is a genuine successor to agile or just waterfall wearing an AI costume. A good counterweight to the “agile is dead” hype cycle, with an extensive set of links to the broader debate in the show notes.

Lorin Hochstein stages a short play in which an engineering manager discovers the “carefulness knob” — the dial a team implicitly turns when deciding how much testing and process rigor a change deserves. The punchline is that cranking it to maximum doesn’t eliminate incidents, it just pushes delivery dates out exponentially, and teams are far worse at estimating risk than anyone would like to admit.

via Matt Weagle (@mweagle@hachyderm.io): “Mmmmmmmm, others. The ones who have always stood a little bit outside the system. Who could never quite adjust themselves to the right configuration to fit into the workings. Who have always felt a bit out of place. Who look at the systems, all of them, and wonder, Is this really the best we can do? “

Annie Mueller on how the systems we build to serve a goal eventually grow into mutant beasts whose only real purpose is their own survival — until the people no longer serve the goal, they serve the system. The sharpest part is her taxonomy of how people react when a system is threatened: those who can’t see the system as a system fight for it as if reality itself were crumbling, while those who recognize it as a structure imposed on reality are the only ones with the power to change it.

Barry Jones makes a thorough case that story points are unreliable by design: low values imply precision, high values imply ranges, and velocity quietly converts them back into time anyway. Instead of arguing about Fibonacci numbers, he argues teams should measure queues — how long work waits — which gives the business the timeline predictability it actually wanted.

The Choluteca Bridge in Honduras survived Hurricane Mitch intact — but the hurricane moved the river out from under it. Mike Bowler uses this as a memorable parable for long delivery cycles: you can build exactly the right thing perfectly and still miss, because the world changed while you were building. The antidote is shortening the time from idea to in-use: smaller slices, less work in progress, fewer dependencies, and real collaboration.

Linear is repositioning itself as “the product development system for teams and agents” — issue tracking, planning, and triage built around workflows shared by humans and AI agents. Worth a look if you’re thinking about how coding agents fit into an existing project management practice (and, as always, the design and performance polish of the product itself is exemplary).

An episode of Adam Grant’s ReThinking (via the WorkLife feed) featuring Denise Hamilton on revising the stories we hold dear — the narratives we tell ourselves about our work, our teams, and each other. A good reminder that the beliefs we’re most attached to are often the ones most worth re-examining.

Luca Palmieri fills a real gap in the Rust adoption literature: not how to convince your org to try Rust, but what to do once you’ve decided. His advice to not hire Rust specialists for your first project — and instead assess and upskill the team you already have — rings true, as does the warning about stranding a team of frustrated Rust experts if the bet doesn’t pan out.

via Luca Palmieri (@algo_luca@hachyderm.io): We all talk so much about why you should adopt Rust.

A practical guide for engineering leaders looking to introduce Rust into their organizations. Covers team building, upskilling strategies, and scaling — focusing on the often-overlooked management perspective rather than the usual individual contributor advocacy angle.

Will Larson on Irrational Exuberance: Navigators

via Johanna Rothman: Want Both Efficiency and Effectiveness? Lower WIP and Right-Size Work

via Kevin Stewart: How to communicate like a GitHub engineer: our principles, practices, and tools - The GitHub Blog

via Greg Wilson: One of the most useful things I’ve ever found on the web comes from NOAA, and is about dealing with disruptive behaviors in meetings: If you want to post a framed copy on the wall in your office …

“An example … is separating problem definition from problem solution, having two separate meetings for that.” 💡!

via Dare Obasanjo: A great question managers should ask in one on ones; are you venting or asking for help?

via Joanna Denni: There are so many really great resources I’ve come across for engineering management, it’s hard to narrow them down!

via Matt Weagle: “To change the culture, you must change the system. To change the system, you must change what you reward.”

via Kevin Stewart:

via Kevin Stewart: More Effective Remote Working | Mike McQuaid

via Jon Reid: @woolie I see very few teams functioning as teams. It might be easier if my views came out in a coherent article rather than tooted in pieces, so check this out if you’re interested. (No obligation to read! I’m also happy to continue tooting.)

via Dragan Stepanović: If developers in your team have to repeat their asks or even worse beg 🙏 for reviewing their PRs (or any other help they need), your problem is not people not prioritizing other people’s work, “lack of professionalism” or lack of “team player spirit.”

via Kevin Stewart: The farther you go up the ladder, the less it’s about your technical skills — Jim Grey

via Kevin Stewart: The Agile Manager: Resistance

via Kevin Stewart: How engineering teams handle unplanned work | by Anna Debenham | boldstart ventures | Aug, 2023 | Medium

via Kevin Stewart: Remote work requires communicating more, less frequently

via Kevin Stewart: How Managers Can Make Time for Their Own Development

via Kevin Stewart: There’s more to life than OKRs: using EOS and W Planning for effective goal-setting in empowered teams

via Matt Weagle: Share your adaptive capacity across the team

Irrational Exuberance: Manage your priorities and energy

via Emily Nakashima: I wrote about why I hate the term “tech debt” and why using more specific terminology often helps us have better conversations about tackling non-product-roadmap work.

via Kevin Stewart: If agile isn’t dead, why is it still not working?

via Matt Weagle: “By the end, you’ll be prepared to operate effectively within an existing planning process, balance functional and cross-functional demands, and diagnose how your current planning process may be holding Engineering and your company back.”

via julia ferraioli :cc_by:: July’s piece dropped late last night — and it’s about undervalued work. Specifically what @whereistanya calls “glue work”.

I’m a big fan of the Changelog podcast. This snippet was a tight reminder about staying on track when starting a new venture:

via Matt Weagle: Excellent conversation

via Olamina Free: You might want to look at Carol Sanford’s book No More Feedback. Interesting framework as alternative to feedback.

via Kevin Stewart: Managing your interrupt rate as a tech lead, part 1: You get more of what you reward - Human Who Codes

via Alper Çuğun-Gscheidel: Every time I mention slack time as one of the most important things for healthy engineering teams people look at me as if they’re seeing water burning.

via Kevin Stewart: Gelling your Engineering leadership team

via Kevin Stewart: Leading vs. Managing in the Engineering World

via Emily Nakashima: I started my role as VP of Engineering @honeycombio three years ago, and since then I’ve noticed how little candid writing there is about paths to this job or what it actually entails. I’m working on a blog post series about this, and part 1 is out today.

via Mark Levison: Kent McDonald offers a Kanban Board to visualize your current understanding of the state of the product backlog.

Michael Loop on Rands in Repose: Ask Questions, Repeat The Hard Parts, and Listen

I think I’ve made many of these mistakes over the years:

charity.wtf: Helicopter Management and Other Mistakes