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
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.
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!
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!
Can you explain more? I don't see it that way, but it might be we're defining things differently. Milestones are defined in a specific way within the article, and in that way they don't seem orthogonal to me.
This isn't a post about scrum vs kanban. It's primarily about the value of using a specific definition of milestone to encourage incremental delivery. And to highlight some of the benefits of delivering in this way.
A fun exercise would be to make up tenets for existing companies. Let me start:
Tesla
* We value aspirational storytelling over the "truth". [We might make it true later!]
Apple
* We think different, except when it comes to creating a non-toxic environment.
Facebook
* We value making money and engagement over democracy, people's lives, or their mental health.
Google
* We value starting things over making them successful. [We will definitely kill it in a few years, but don't worry, we'll try again later.]
* Don't be evil, unless you're an executive or it will make the company a lot of money.
I love the point you're making, and perhaps what I'm trying to say isn't coming through in the piece.
Another way I've talked about this (to myself) in the past is that there is something akin to the cathedral vs the bazaar approach. One is designed, intentional, centralized, and structured. The other is informal, emergent, and distributed. I think this is what you're getting at with the organic structure of natural cities?
I believe the best organizations actually have some attributes of both -- tension between design and emergent structure.
Companies usually lack the right structure to really have emergent properties without bad results (see the excellent Coda Hale article referenced in another comment for some of the math behind this). I believe it takes some design to set things up so that emergent qualities can be successful.
You shouldn't squash things that arise between silos, like new communication pathways and even some collaboration. Those are very necessary and important. But I do think you need to keep an eye on collaboration, because it's often a sign that there are structural problems that will break down without further design.
The best designs, I think, allow for emergent qualities naturally.
I guess I also agree with Hayek's hypothesis, except that I'm not sure it applies here. For example, if your problem is that the go to market organization doesn't understand what is happening within the product development organization, that is a very solvable problem -- you can solve that many different ways -- the two that come to mind are role definition and communication channels.
A lot of what I'm advocating for is design that is compatible with how human beings work together, and sensitive to their limits.
I'm super curious if I'm missing your point or if you'd suggest adding anything to the piece to clarify this point. Thank you for your thoughtful comment!
They're organized functionally, and are one of the only companies in the world that seem to have cracked this at scale. I've always been super curious how that works in practice.
This article argues against functional organization (as in most cases organizing functionally increases your coordination needs within a company).
I don't think you need a matrix management system, and actually kind of hate matrix management. In general (there are exceptions) I AM arguing for cross-functional teams. More like D&D teams, with Fighters and Wizards and Rogues and Clerics on the same team.
The management structure is a kind of separate topic. You can have cross-functional teams with or without matrix management, and I'd argue it's way better to have it without matrix management. But this is a complex topic and a separate one.
Thank you so much for introducing me to that article. It's fantastic! I've made this comparison forever, and used a lot of the same arguments -- I wish I had written this!
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