Task Forces can be a sneaky way to use the resources of other departments. But other departments might feel bad about it if you don't get the effort stamped as important.

The biggest surprise for me when I moved to a pure manager of managers role was how little I knew what was going on. It was like someone had turned off all the lights.

The cross-team project danger zone occurs somewhere after about forty people. I often see it happen between forty and sixty people in an organization.

Are you a Nowist? Have you known other people that you now recognize as Nowists?

You may be able to get people to agree to a rule like that (particularly after an incident). When you do, you are adding leverage during future incidents, because every incident is now a little more expensive.

If you make improvements in a lasting way, every improvement you make adds to the last one. Having four quarters of equity related accomplishments behind you will mean your company is noticeably better than it was a year ago.

Usually the way I come up with organizational work is I spend some focused time on a writing assignment for myself. I'll list the problems I see in my organization, and try to identify the most important ones to address.

The initial group will largely set the tone for people that come later. So try and optimize for some initial participants that will be active, but also show vulnerability and empathy with each other early on.

Elaine May joined me on Decoding Leadership to discuss being a change agent, and what's not so great about SCRUM.

You may find that your managers don't have the bandwidth to take on additional work. This is actually a really good signal. Your manager is working at capacity.

The aim of a weekly project update is not to share everything about the project. It's also not to show how great your team is. When you approach project updates from either of those perspectives, your writing becomes excrutiating to read.

What matters is how long it takes from when you start working on a problem to when you're able to turn your attention to the next problem. Iteration speed is more important than perfection.

Organizational work is about creating a flywheel effect, where it gets easier and easier over time to create the same impact.

Many people, when I first describe mini-Ms, don't grasp that the boss cannot be part of the Mini-M. It's a peer group and having any senior executive or boss as a part of group, whether it was me or someone from human resources or anyone else would destroy that peer group.

A strategy document should outline where you are at today, and where you need to be. It should articulate what the gap looks like.

You are judged by the output of your organization. And specifically, you're judged by the difference you make on the organization. What do you make better? How do you improve things? What is the diff you apply to that organization?

I believe the reason this seems to happen at between ten and twenty engineers is because that's when one person can no longer reasonably manage everyone in engineering. You have to start to split the world.

With a Steel Thread approach, you build the thinnest possible version that crosses the boundaries of the system and covers an important use case.

The user experience isn't adornment -- it's actually most of the value you're providing, so spend a lot of time on that.

The problem with determining the effectiveness of an advisor is that many people will confidently give you bullshit suggestions that can actually make your life worse. As humans, we often conflate confidence with competence.

Making a leader 10% better has a greater than 10% impact on their area of the company.

Sometimes teams can be named in ways that encourage bottleneck behavior. For example, a team called the Platform team will end up owning all the services and horizontally designed work in the company.

You want substantitive, impactful decision-making to be happening throughout the company. If you don't design it that way, people will add the extra meetings anyway to get things done. You'll end up with an ad hoc, informally-specified, parallel version of what you're designing.

The team should get credit for their work. Try to fade into the background whenever there is a success, and recognize the people who did the work.

After the work is done, it doesn't end in "Done" or "In production". The final status is called "Communicated". We make sure we communicate all the improvements as a natural part of our work.

A test question to ask your customers is: if your team had to build/fix this yourselves, how much engineering effort would you be willing to invest in it? If the response is: 'well, none of course!' Then they've indirectly answered how valuable the need was to them.

I had an interview recently where two people interviewing a candidate at the same time ended up giving completely opposite feedback: a strong yes, and a strong no! You can learn a lot from that.

Functionally designed teams tend to move towards the service provider pattern. But barring those exceptional cases, I tend to make teams cross-functional in nature, to eliminate the need for a service provider pattern, and improve the coordination within a team.

You should be suspicious of anything that involves a cut-over. Do things in small increments.

If you can talk with a few people ahead of time, and ask them to speak in favor of a particular direction at that meeting, you've tilted the outcome significantly.

A better alternative to project management is **milestone management**. All you do is "replace all talk of projects with milestones"

Being on the Council was basically a full time role. Writing a product strategy, communicating that strategy, and synthesizing and coordinating the most important projects of a large organization is a lot of work.

"Breaking down silos" is an exhortation rather than a diagnosis or prescription of how to improve the situation. "Breaking down silos" blames individuals for not having a big enough vision and working across boundaries, instead of looking with curiosity at the system and asking _why_ they are doi...

Charity Majors (bsky.app/profile/char...) and I had a wonderful, very personal discussion on Decoding Leadership about 🌱 the tremendous growth you can make as a leader and 💚 the meaning from impact on the lives of the people around you.

You need to build a way to understand what is happening in your organization. You need to set up observability of your organization, so you'll know if things are going off the rails.

Apple notes is going between 100GB and 400GB of disk space. Actual size is about 25GB. Not fun when most of your devices run out of disk space due to some weird Notes bug(?)

Instead, I encourage you to think about your level of involvement as something you flex depending on the circumstances. Your goal is to be less involved, but it should depend on the level of expertise of the manager in this particular area, and the complexity and challenge of the situation they'r...

People will pigeonhole you. So it's often better to specialize than to be a generalist. Why? People will only pattern match you against one or two things. You want people to think about you as an option when a problem comes up.

Companies that implement pay equity tend to attract underrepresented employees better. Why? It is a signal that the company tries to pay people in a less biased fashion.

They go through several rotations with teams. These last several weeks. They work on real work for those teams, contributing in a couple of defined ways.

Create a Google Doc and gradually start adding useful information for candidates: answers to questions they ask, information about the company you think they might want to know. Treat it like an FAQ, and gradually fill it out until you think it reaches a critical mass of useful information.

A better approach is to use your rejected offers as a signal. If you start seeing that your offers are getting turned down, you can use that now as a signal your salary bands need revisiting.

Having a group that can set technical standards will prevent painful migration projects from blossoming. And creating a culture of discussing the long-term implications of choices can avoid lots of pain in future years.

You can destroy your team's productivity if you requiring constant communication and allow interruptions. The other failure mode is walling your team from the rest of the company.

Here’s how to lead effectively when you lack formal authority. www.rubick.com/reflecting-p...

An information system allows you to step back from directly overseeing the work, but still be confident it is going well. It's a tool for trusting and verifying at the same time.

The cost of saying something is almost zero, so people say a lot. But the cost of reading what everyone else is saying is high, and gets worse the more people there are.

"Our AWS costs were rising at such a quick rate that if we don't address it, we'll be losing money on every customer within two years". Something like that can really help people see why it's important.

If an incident takes two days of reliability improvements by the team, that adds two days to the roadmap. If you heroically fix that, you're preventing the organization from caring about reliability work.

A strategy isn't just a list of things to do. It's not merely a roadmap. So calling a roadmap your product strategy doesn't work, and that's part of the reason it doesn't clarify as much as you would like.