This won't take long, but helped bring things into focus for me.

The first one's Agile. The second one's bureaucracy.

I'm on a mission. It's a doomed mission primarily because I'm a little-known software engineer who's read by--maybe--a dozen people in the world. But that's OK. If my mission appeals to you, then that's a little bit of success in my life.

My mission is to change the phrase "work-life balance" to "HOME-JOB BALANCE"

Making my case won't take long. Here it is.

• "Work-life balance" promotes a completely wrong mental model from the start. It's saying that there are two areas of existence: work and life. Anything outside of work is life, and life isn't part of work.
• It's also implying "we shouldn't have to work at our lives."
• Finally, the syntax puts "work" at the front, when our home lives are what we're routinely missing out on. Home should come first.

We all know "work vs. life" is wrong. Work is part of our lives, it's part of life. With the increase in remote work--note: work from home--we need to be clear about what we're balancing.

"Work" isn't something we just do for our jobs. We work at being good spouses, good friends, good parents, at taking care of our bodies and minds. Work isn't bad.

So, what I'm balancing isn't work and life. What I'm balancing are my home and my job. When and where am I "at home"? When and where am I "on the job"

This is hard, for sure, especially for workers who have children or are caregivers for relatives. I think it becomes easier when we stop thinking about "work" and "life," and frame our lives as "home" and "job."

This is the first article, the "what" of the mission. My next will give guidance on how, a lot of which others have already written about.

In the meantime, here are some questions to answer:

HOME

• Where do I feel "at home"?
• When do I feel "at home"?

JOB

• Where do I do my job?
• When do I do my job?

CRUCIAL DIFFERENCES

• What separates--or can separate--being "at home" from being "on the job"?
• What are my rewards for keeping them separate?

I'll post again soon!

Lots of organizations try to prevent developers from making mistakes, or catch them doing so, leading to more bureaucracy and over-control. Some examples include:

• Requiring all teams to follow the exact same process.
• Using permissions to keep developers from rebasing code with Git.
• Managers external to the team running compliance reports on whether user stories are filled in "correctly."
• Penalizing developers using development issues/bugs as a metric.

Let's look at that last one more closely. One of the DORA group's Four Metrics is to capture how often release failures occur. One way to think of that is "how many severe bugs are we getting after release?"

It's tempting, then, to also track how many issues/bugs are found during development, the notion being that reducing bugs during development naturally reduces them in release. But this is wrong headed. There could be value in looking at issues found during development, but it's wrong to use this to evaluate, praise or punish developers. Why?

• More issues found during development isn't good or bad.
• Context is missing if you're only looking at numbers.
• Whether and how development issues are reported is highly person-dependent.

In short, you can't tell whether a developer is doing a good job based on development issues. That isn't why you'd capture development issue metrics. You would capture them as one metric to compare the effects of making development changes. For example, a team commits to increasing unit test quality. What effect did that have on the number of issues found?

What are you even tracking? Is it the number and severity of issues found by QA? That might be OK. But how do you know that Billy has the same standard for "severe" as Claudia? Maybe Rahim breaks down an issue into more bug reports than Luciana.

This is when bureaucratic management tries to get everyone working the same way with endless meetings on "what does severe mean?" and "what's the right way to report issues?" Some of this matters, sure. But thinking this way more often misses the point. Its focus is on treating people as replaceable resources, as machines.

The coercive style of management has these qualities:

Restrict. Prevent. Catch. Punish.

Those qualities can be summed up as "Developers, we don't trust you."

What if, instead, we use a reliable metric--change failure rate--to guide improvement? Further, what if we let the teams figure out how to make that improvement, allow for mistakes, and measure what matters? We'd end up with a trusted team.

In a Trust Team environment, you

• Give your developers more permissions.
• But also keep audit trails so if something goes wrong we know who did what.
• Create a robust system that can be recovered quickly.
• Notify developers of problems automatically and immediately.
• Help understand what caused issues and how to improve.

Again, let's dig into that last one and contrast to an untrusted team.

In the untrusted team, if a severe bug is discovered, several assumptions are made.

• One person is at fault. The team isn't treated as a unit.
• The developer made a mistake. There's someone to blame.
• The bug could have been prevented.
• There needs to be a meeting to put procedures in place to keep it from happening again.
• Non-team management is needed to enforce the new process.

In a trusted team,

• The team takes responsibility, knowing multiple people work on the code.
• The developer may have made a mistake. But there's no blaming because mistakes are part of development.
• Not everything is in our control. Software's very complex. The developer may have made the right decision, even though there was a poor outcome. You can't prevent all bugs.
• Adding process adds complexity to an already complex business. Sometimes process needs improvment. But often there's nothing to fix.
• As soon as external management insists on compliance reports, the team ceases to be self-managing. Quality will go down, because the focus shifts from building software to pleasing management.

In the future, when something goes wrong:

1. Determine and explain the impact on the overall business.
2. Let the team sort things out.
3. Ask them to inform management what, if anything, will change.
4. Trust their answer.

Build trust, not scapegoats.