jadeforrest

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.

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!

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.

Hi, I'm the author.

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.

That was a helpful link. Could you give an example of a tenet you find more convincing?

I don't understand your critique -- the words tenant and segue do not appear in this post. What are examples of playing fast and loose with language?

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).

This thread of discussion is making my day. The Coda Hale article above gets into some of the math, but this is a great critique!

Well said.

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!

I didn't intend to argue against communication or collaboration between silos. When a leader implores the people around them to "break down silos", they're usually not being very explicit about org design or communication design or collaboration design. I argue it's important to be explicit about the collaboration model of teams -- and that can work across silos. For example, you might have a product marketing person (from the marketing silo) who is embedded in a team or a couple of teams and work closely with them. There are many collaboration models you can choose from that effectively allow teams to coordinate their work.

My next post is going to be about the structures you can use between teams and organizations.

You make a really good point about informal and expertise networks. Do you agree that good org design is often about making the value creation networks overlap to whatever degreee possible with the org structure? I enjoyed your blog post!

I wrote up a bunch of tips for hiring and recruiting within startups:

- how to make hiring faster - create a hiring strategy - improve careers page - make posts more equitable - using a candidate packet - mining your network - effective review mtg - bundled hiring

Startups usually don't focus on technical standards, because they're focused on survival. In this blog post, I describe what we can learn from explore/exploit algorithms and how they pertain to technical standards.

Added (feedback welcome):

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. If you're in an environment where there is less trust, or the leadership doesn't understand how software should be built, you may need to use the demos to educate and give context on the team's work. It's also important for you to cheerlead the work that isn't customer facing.

And added davidkunz to the Thank you section.

I would be interested in that if I was leading your part of the org. Here's the value I would get out of it:

- I could see what portion of the team's time is spent on tech debt issues, which gives me a sense of how well we're dealing with tech debt, the state of testing, and how good our technical decision making are.

- It also gives me an idea of how well the team is dealing with the real maintenance necessary for a production product. Are we improving response times for customers, how hard is it to make improvements.

- It helps me understand team dynamics. How collaborative is the team's work. Who is working with whom? How much support do team members give each other. How much knowledge silos do we have. How does the team treat each other? Do they cheer on this type of work? How do they feel about maintenance.

That's just a few things that come to mind. I have found these demos to be some of the most information rich activities I engage in, and I find it helps me support my teams.

But I get the sense it doesn't feel great to you. What sucks about it for you?

You bring up a good point -- maybe something I should emphasize more in this blog post.

Demos should be inclusive of all he work it takes to build a real, functioning piece of software. That should include the reliability work, the scaling, the testing, and the refactoring necessary to do real software engineering. And it should include APIs and containerization. So I guess I'm intending this as a fairly technical demo, but talked about from a customer and business perspective.

I personally think it's important for your stakeholders to understand the necessity of this work, and this gives the team the chance to talk about it.

Thanks for bringing up the failure mode of this -- I'll consider adding that to the blog post.