Leadership

via Barney Dellar (he/him) (@BarneyDellar@mastodon.scot): “Do you still read the code?” This is a very interesting article on the state of software development, and what it means to write software. https://zanlib.dev/blog/do-you-still-read-the-code/

A familiar state of affairs: teams now share codebases without agreeing on whether anyone is still expected to read the code. Zanlib draws a useful distinction between “accelerators,” who use AI to translate their own understanding into code and stay responsible for it, and “vibe coders,“ who delegate implementation and its revision entirely. The costs of either choice won’t be visible until the code has to survive changes in requirements, tooling, and people.

via Nando161 (@nando161@partyon.xyz): Attached: 1 video

A short Mastodon post riffing on the Dunning-Kruger effect from the other direction: the more expertise you accumulate, the more acutely you notice everyone else’s gaps. A pithy reminder to stay humble about what you think you know — and charitable about what others don’t.

Also, a rather hilarious video about shoe sizes and how they differ across the world

Brené Brown and Adam Grant explore why toughness and kindness aren’t opposites but rather complementary qualities that need each other. A thoughtful conversation about how effective leadership and relationships require both directness and compassion.

At 21:58 (linked), Adam introduces the concept of a kvetching circle, that describes a model for thinking through various people’s roles in responding to a tragedy or difficult circumstance. Comfort in, dump out.

BTW this new podcast, The Curiousity Shop, is fast becoming one of my favorites. I’ve been listening since they launched a few months ago.

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.

A short segment near the end of Tim Ferriss’s conversation with Craig Foster (of My Octopus Teacher) about how to approach debates on contentious political issues. The advice — lead with genuine curiosity rather than the intent to win — applies just as well to technical disagreements as political ones.

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.

via Rust Weekly 🦀 (@rust_discussions@mastodon.social): Linus on Rust in the Linux kernel (December 2023)

Linus Torvalds sits down with Dirk Hohndel for a wide-ranging keynote conversation at the Open Source Summit. Always interesting to hear Linus’s unfiltered thoughts on the state of Linux, development practices, and the open-source ecosystem.

Will Larson on Irrational Exuberance: Navigators

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 Martin Fowler: I’ve written a brief summary of Team Topologies, the model created by @matthewskelton and Manuel Pais at @TeamTopologies. Many of my colleagues are finding this to be a useful tool to think about how best or organize software development teams.

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

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.

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

via kottke.org: Can Everyone Take a Sabbatical? “Sabbaticals also provide …a ‘check against total burnout.’” Feeling very grateful for the support of my readers in taking a sabbatical last year.

via Kevin Stewart:

via Kevin Stewart: Better Software Engineering teams — Structures, roles, responsibilities and comparison with common approaches.

via Dare Obasanjo: Abraham Lincoln famously said “Give me six hours to chop down a tree and I will spend the first four sharpening the ax.”

via Mike Sperber: Easily the best post I’ve read on tech debt.

via jadeforrest: 🧠 FAST agile is the most interesting organizational practice I’ve learned about in a while. Today I share what FAST agile is, and explore whether it’s worth experimenting with.

via Kevin Stewart: Leader as Shock Absorber (Ed Batista)

Poignant read on how demand (“burden” in his wording) inevitably expands to reach and strain capacity, both for computers and humans:

Gabriela Riccardi at Quartz: How to frame questions to get honest answers from people you manage

via Matt Weagle: “If you want your colleagues to own their plan, they need to come up with their next steps themselves — with your support.”

via Kevin Stewart:

Via Matt Weagle: First, when you implement RFCs, you will be introducing friction to your team. Instead of going straight to building, we are required to think and write about what we’ll build. Friction brings frustration. Our industry has convinced us that programmers are supposed to be writing code for as much time as possible, leading to negative sentiments to practices that keep programmers away from their editors.