Human systems and the stuff they make

Also a mechanical navigation computer for Soviet spaceflight

Feb 7, 2023

There’s so much goodness in Mandy Brown’s latest management post Made It, but it’s this paragraph that gets to the heart of it:

This is one of the ways that the adage about “maker time” versus “manager time” does harm. Setting aside the fact that it’s not even coherent—managers make decisions and plans and systems and visions all day long!—it also serves this notion that the stuff is what matters and the humans are just an unruly mess that gets in the way of the stuff. This is a self-defeating story, inasmuch as you don’t get good stuff without a system that takes care of the humans.

I have been thinking about human systems a great deal over the past few weeks. It started when I read Donella Meadows’s Dancing With Systems. When I applied that lens to my own work it was impossible not to see it in absolutely everything we do. Take this quote, for instance:

Don’t maximize parts of systems or subsystems while ignoring the whole. As Kenneth Boulding once said, Don’t go to great trouble to optimize something that never should be done at all. Aim to enhance total systems properties, such as creativity, stability, diversity, resilience, and sustainability–whether they are easily measured or not.

There are so many implications of this principle for the way we make software today. Here are a couple I’ve been thinking about in particular.

Quality

When we have quality issues in our product it’s tempting to try to solve those issues with process and overhead. Common ways to do that include instituting additional approval gates before code can be deployed to production environments, or adding “QA periods” where the entire organization is asked to test a feature before it goes live.

These solutions optimize for parts of the system—such as deployments or manual testing—while ignoring the system that is responsible for introducing quality issues into the product in the first place. To quote Deming:

Inspection does not improve the quality, nor guarantee quality. Inspection is too late. The quality, good or bad, is already in the product. As Harold F. Dodge said, “You can not inspect quality into a product.”

We have to look at the system as a whole. What kind of automated test coverage do we have? What bottlenecks exist in our CI/CD pipelines? What level of responsibility do we ask of engineers to be stewards of their own code? Do teams have enough time to make sure that quality is built in from the start and not an afterthought? These are the total systems properties questions that have to be addressed in order to fix quality issues.

Team stability

One of the bigger leadership mistakes we make is to think that the humans that make up a social system are interchangeable and can be moved around at will without impacting the system as a whole. You see this especially in engineering teams where “resources” are constantly moved from one project to another—usually to speed something up that is perceived to be behind schedule. But we forget that it is the human system that produces the stuff, not the individuals.

Similar to the discussion about quality, if we perceive a project to be off track we need to understand how the project came to be off track, and then find ways to improve the system to correct that. Did we place unrealistic deadlines on the team without getting their input? Are we asking teams to build features that have not been validated with customers? Do teams have adequate autonomy and ownership over the way they prioritize their work? Do teams have the business context they need to make the best possible decisions?

If we instead go for the shortcut of moving people around, we will never get to the heart of the matter. Inserting additional humans into a system can inadvertently break it—and worse, moving folks from one project to another leaves a gap that is very likely to destabilize the project that they were working on before. Suddenly Customer Success doesn’t have an Engineer to talk to about documentation, or the Marketing Team doesn’t have anyone to fix an issue with a piece of demo software.

Once again, Donella Meadows says this well:

Before you disturb the system in any way, watch how it behaves. If it’s a piece of music or a whitewater rapid or a fluctuation in a commodity price, study its beat. If it’s a social system, watch it work. Learn its history. Ask people who’ve been around a long time to tell you what has happened.

Stable teams that work together for an extended period of time all have a steady beat, and we shouldn’t make changes to the system until we know exactly how that beat works. Here’s Donella again: “Before you charge in to make things better, pay attention to the value of what’s already there.”

And that’s how all this connects to Mandy’s piece that I linked to at the beginning. If we want the stuff to be good, we have to pay attention to the beat of the system of humansthat make up an organization. We have to understand how they work, and we have to ask them how they want to work. We have to listen to the people who are beating the drums.

It may sound a little counter-intuitive, but if we optimize for the humans who make up a system, the good stuff will follow.

In the post How New Managers Fail Individual Contributors Camille Fournier makes a great point about the split between “managerial” and “technical” career tracks:

Most people become managers right at the point where career tracks split between “technical” and “management” specializations. The result is that many new managers have most recently been very technical, yet they have no idea what it means to climb the technical track, but they will be managing people who want to follow that path. To be a great manager, you can’t afford to let the ICs on your team feel that they have no career path, so it’s up to you to manage this well.

She goes on to to list five pitfalls that new managers should work to avoid in order to set their direct reports up for success.

I have a few product-related articles that I wanted to reflect on and write more about, but I just don’t think I’m going to get to it. They’re all really good though, so instead of just archiving those notes I wanted to share them so you can check it out.

1.

Here’s some solid advice from

Jason Knight

on what to do when your product is a mess and you have to fix all the things all at once:

In a situation like this, you’re going to have to get super-pragmatic. You’ve got lots of fires all burning at the same time and you need to put them out before you can start prioritising ‘properly’. Your goal is to get back on track as soon as possible, and you’re going to have to do a bit of shovelling to get there. Do what you need to get done.

And:

What we’re doing here is looking to put out the fires, and get a variety of initiatives to a base level of quality. You’re very unlikely to be able to make 15 things amazing all at once. Your goal here is to make all ships rise together. This means working with your stakeholders to understand what the minimum viable solution to these issues is, getting brutal with scope, and expending as little precious development time as possible.

2.

Andy Nortrup writes about what he learned about product management from Bonsai:

Similarly, with software products, patience is an important skill to make sure we don’t push the team faster than they can write good code, or make changes to the product faster than you can learn from users’ response to the changes. Patience can help us be less frantic and pay attention to the work in front of us in this season rather than the whole roadmap.

3.

Rich Mironov talks about the differences between products and features, and I especially appreciated this point about what users care about:

Customers don’t care about how hard we worked. Our product either does what the customer needs, or it doesn’t. And it should be priced based on customer value, not recovering our expenses. Users don’t care how much we spent, how big (or great) our team is, margin demands from Finance, remote versus on-site teams, development velocity, scrum vs. kanban vs. XP vs. lean.

Some Stray Links

🌏 Inside the Globus INK: a mechanical navigation computer for Soviet spaceflight. Dang this thing is beautiful. And what an amazing piece of engineering.
🧓 Youth Spies and Curious Elders. Life goals: “Waters is what I call a Curious Elder — someone who manages to retain their curiosity as they age and stays interested in what young people are up to. The curious elder isn’t interested in judging youth, they’re interested in learning from them.”
🕸️ The Thoughts of a Spiderweb. This is a fascinating article about animal cognition but I am especially blown away by the idea of spiderwebs being “an extension of the spider’s cognitive system” because I’m reading the sci-fi novel Children of Time right now and that is how the spiders communicate in the story.
🚗 Audi’s new EV is a luxury SUV with augmented reality that doubles as a pickup. I can’t decide if I love this or hate it.
📱 Prisoners Usually Can’t Have Cell Phones. See How People Use Them Anyway. “Some men use their phones to take online classes, posing as regular students in the free-world, a ruse that only works in the age of Zoom classrooms and online meetings.”
🎸 It’s the Coolest Rock Show in Ann Arbor. And Almost Everyone There Is Over 65. “The show always starts at 6:30 p.m. and ends at 9 p.m., in time to get to bed at a reasonable hour.” Sign me up! (NYT Gift Link)
🎮 How ‘The Last of Us’ changed gaming, strained relationships and spawned an empire. Probably my favorite read of the week. “‘The Last of Us’ always felt like a mission statement, a game that wanted to prove that big-budget action shooters could not only have a sense of gravitas but could advance the medium in narrative, gameplay and representation.”
More stray links from the blog: Link roundup for February 4, 2023.