Jade Rubick

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 then we talked about SCRUM and some of the downsides in the way it's practiced.

It was a great conversation, hope you learn a lot from it!

www.youtube.com/watch?v=p2PB...

open.spotify.com/episode/5M2O...

Elaine was an early agile practitioner, using it in very non-agile environments! She wrote about using agile methods *five years before the agile manifesto*. She taught me about a concept she calls change budgets. And shared how to deal with critics and naysayers.

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.