Covers some chaos engineering practices that aren't very common in the wild:

1) Evil staging - make an environment less reliable on purpose 2) Gauntlet programs - gradually inject classes of failure into staging and production 3) Reliability races - team controlled race to inject classes of failure into staging and production 4) Newbie gauntlets - new environments default to having lots of classes of failure as a part of the environment

From the article:

Include all the work. One thing to be careful of is that the demos are inclusive of all the work required to build functional software. Prepare the team to demo all the parts of their work: the APIs, the infrastructure, the reliability work, and the testing. It’s important for you to cheerlead the work that isn’t customer facing.

These things don't demo well precisely because a demo doesn't help anyone to understand the decisions made in developing them. You can not just say "prepare to demo them anyway", that doesn't do anything useful.

I’m the author, and didn’t say any of those things. I said that bias can lead to harder standards for minorities. They can be judged by higher standards.

Hiring junior engineers is challenging. I’ve seen so many junior engineers get hired but then be supported poorly. This is a writeup of the best program I’ve seen for hiring and onboarding junior / new engineers.

FAST agile is an agile variant that uses self-organization within very large teams to scale organizations. This is a deep dive into the tradeoffs of FAST agile. It may not be as crazy as it looks!

Step by step guide to hiring engineering managers. Includes sample questions, interview formats, and more.

I'm the author of the piece. Yes, that's very true.

There is a difference between what you can control and what you can influence. By understanding how it works, you increase you chance of influencing things.

The salary review is something that the average engineering manager can use to both understand this all better, and more importantly, to address mistakes or issues in their team's salaries.

I'm the author of the original piece. Totally agree with this -- it can be quite simple to implement. Increasing retention makes a big difference. Unfortunately, there are more incentives to hire than to retain, so many companies do a poor job of it.

I've been at three companies that have implemented pay equity (and one of those I was the one implementing it). I wrote up a guide to implementing pay equity here: https://www.rubick.com/implementing-pay-equity/ and it's basically as you describe -- have new and existing employees get paid the same rate, with no manager or recruiter discretion.

Hi, I'm the author. Totally agree with you on this.

I do tend to focus on milestones first, because even if you're focusing on problems, using milestones to focus on what's next can sometimes be helpful. But if you can get to focusing on problems directly, that's even better.

For many organizations, there isn't the latitude to do so, so I've found this works within project-focused cultures better.

Hi, I'm the author. I'm not intending to describe working in sprints. You can implement the ideas behind this article with sprints, kanban, or something else entirely. Using sprints doesn't do what using milestones does.

So what I'm hearing is that that wasn't clear. Since a few people said that here, I'll make some edits to clarify. If you have any suggestions as to where the confusion is, I'd love to hear it. Thank you!