DEV Community: Jade Rubick

Your process should be open source

Jade Rubick — Sat, 18 Feb 2023 00:00:00 +0000

Process: a series of actions or events performed to make something or achieve a particular result – Cambridge English Dictionary

Today, we delve into the great debate about Process. Is Process the solution to the chaos in organizations? A way of applying good discipline and operations to make stuff happen? Or is Process itself the problem, adding overhead and getting in the way of people doing their best work?

I’ll argue there is a way to manage Process that preserves its benefits, while eliminating most of its downsides. It’s probably something you’ve never seen before. And I’ll describe how to roll it out, what the rules are for operating in in this way, and some of the surprising benefits.

Process is how we work together

The first thing to realize about Process is that it exists already, whether you acknowledge it or not. Process is the way we work together.

Process can be explicit and written down. Or it can be implicit, something people understand just because they’re used to working in a particular way as a team.

Process can be something a group of people are aligned on. They all agree how things work. Or it can be something that people don’t really agree about. They may have different ideas of how things get done.

Because Process is a part of humans working in groups, it’s nonsensical to be opposed to Process. That doesn’t stop people from trying! But the real question is how you shape and define the way we work together.

Process can be problematic

Most of the opposition to Process comes from people’s bad experiences with it. This is natural. Process is a bit like code – without attention, Process can degrade and cause problems.

The challenge with Process is that it has a life of its own.

For example, let’s say a software engineering team is only focusing on new work, and not doing any work on bugs that are coming in from the support team.

Ignoring that you should probably look deeper into why this is happening, and let’s pretend we’re just going to make a process response to this problem. You could:

Have the engineering manager and product manager decide to schedule some bugs every sprint.
Decide that the team will have the on-call person do bugs for the week they’re on call.
Add an SLA around bugs.

Whatever you decide, you’re seeing a problem, and you’re changing the team’s behavior to try and address that problem in the future. This is Process work.

So let’s say you decide that the engineering manager and product manager will meet with their support liaison once a week and prioritize the most important bugs each week. You set up the meeting, and it starts happening every week.

The problem is that two years later, the problem might evolve. And the people who created that Process may not even be there. So the people involved in that meeting two years later may not understand the problems the meeting was intended to solve.

This uncertainty about the origins of Process can make people reluctant to change things. This is particularly true if the Process is important or around something that seems dangerous. So Process can take on a life of its own, where it operates as a sort of zombie. And people follow it because they have to, even if it is bad or harmful.

Again, this is like legacy code. It works, but anytime you touch it, there is a danger that you’re going to cause other problems. So mostly people try to avoid touching it.

What if Process were fluid and dynamic?

What would ideal Process look like?

It would feel fluid and dynamic. Easy to adapt to the needs of the organization.
It would embed good context inside of it. This would make changes easier to make.
It would be clear, concise, and up to date.
It would be the source of truth, so you could rely on it.

Treat your Process like code

In short, good Process is a bit like good code:

It can be updated easily.
You have version control. You have good historical information to see how it has changed over time.
The cost of change is minimized.
You have good context that allows you to see why the process exists and what it’s trying to do.
The process is what describes how things work.

Solution: open source process

So how do you get flexible Process, that can adjust to the changing needs of your organization?

The best solution I’ve found is to open source your process. Write down your process, and allow anyone to suggest changes. Tell everyone they can change the way the company runs.

While this can be a lot of work, it can also be immensely clarifying. And it can feel empowering to be able to say: the way we work together is written down. And anyone can make changes to it.

Advantages of a written culture

Writing down your process is a core practice for an organization with a written culture. And there are a number of advantages to writing things down:

Writing is clearer thinking. It requires precision. It provides clarity.
Writing is asynchronous and always available. Writing is more scalable, because it doesn’t require meeting to share information.
Writing is thus better for distributed teams.

The primary disadvantage is that documentation requires effort to maintain.

How to open source your process: an engineering handbook

So how does one go about building a written culture, and create a flexible, maintainable process for an organization?

You create an engineering handbook. It is a repository of how things work in your organization. It represents your process documentation.

I’ve done this numerous times. Here’s the general steps I recommend.

1. Choose a format for your engineering handbook

The first challenge you’ll have is to figure out where to keep your process documentation. I’ve never found anything that works perfectly. I have a separate post which shares my notes on which tools to use for employee handbooks. The important step is to choose something. You can change your mind later.

2. Bootstrap the content

The next thing to do is to start filling in content. Anytime you encounter a process, write it up, even briefly. Describe how things currently work.

This works especially well as you join an organization. You can use these writeups to clarify how things work. You can even show your writeups to people and ask them if it is correct.

I might do this for a couple of months before proceeding to roll it out further. As I make organizational changes, I will document them, and have a before and after section. After I make the change, I’ll put the before section into a history part of the doc, so people can see how our process is evolving over time.

Often you’ll find that there are previous versions of process docs that are sitting around somewhere. They might be incomplete, or unmaintained. But they can shortcut a lot of this process. Organize them and start maintaining them.

Having enough content to interact with is important. It shows that there is momentum behind the practice, and that it will be taken seriously. This allows people to invest their own time in it.

3. Choose a maintainer: it’s probably you

You will need someone who makes sure these process docs are taken seriously. That they’re updated and organized. You can enlist help, but ultimately it needs someone to be invested in them. This might not be something you can easily delegate.

Ideally, it’s something that all management takes seriously, and you can model it but have a larger group of people helping out.

4. Communicate how it all works, and roll out the changes

The next step is to roll it out. If you’ve been bootstrapping the content, it may not be a surprise to the whole organization that you’re rolling it out. Some people might have already seen it before.

What I’ve typically done is to talk about the reasons why we’re emphasizing a written culture, and then share the rules we’re following to ensure we keep our process docs up to date (more on that in a second). And then I try to share how anyone can improve the way the organization works, and describe how that works. This can be an exciting, empowering thing for the team.

Rules for process

So what are the rules for process documentation? Here are the things I like to share.

1. Reply with documentation

The first thing I like to share is the concept of replying with documentation. I’ll usually share it with the whole engineering team, in an All Engineering meeting, or in a newsletter to the organization. And I’ll try to model it myself. What is “replying with documentation”?

When someone asks you a question, ideally you want to reply with a URL that answers that question. You do this by going to the wiki, making sure the answer isn’t there, and adding it if it isn’t. Then you send them the URL.

This does a couple of things:

It ensures that the question can be answered in the future without you having to reply to it.
It trains the person asking where they can find answers to future questions.

Replying with documentation is putting a caching layer in front of all the questions people might ask you. It makes your expertise more widely available.

For the organization, the impact of Replying with Documentation is that you are future proofing your answers. Instead of answering the question a million times, you’re ensuring it only needs to be answered once. You’re systematically solving problems rather than just doing a one-off.

2. It’s not official until it’s in the handbook

The next rule is something I repeat over and over to the management team. It’s not official until you put it in the handbook. Whenever a manager is making a change, or rolling out a plan, I say the plan needs to include a URL.

Is the team moving to two week sprints? That should be in the handbook.
Is someone moving to a different team? There should be a list of people on that team, in the handbook.

This rule is important because otherwise, the handbook is not the source of truth. People can’t rely on it to be accurate. This degrades trust in the handbook, and makes it a less useful source of information. But adding this constraint makes what is in the handbook the truth. It’s a completely necessary rule if you care about keeping your process docs up to date.

3. Editing a process document isn’t sufficient to make a change

A third rule I share is that you can’t make people do something just by editing a document. That’s not how humans work. But you need this rule as otherwise, many people will attempt it.

You will need a page that describes how changes work. I usually call it something like “How to change the way we work”. It describes:

Who the maintainer of the handbook is.
That anyone can make changes.
That you can’t dictate how things work just by editing things in the wiki. You have to communicate and get buy-in from the appropriate people. But that improvements are encouraged, and process should be fluid.
That the hierarchy of power is still in existence. Anyone can make improvements, but ultimately the VP of Engineering is delegating these decisions to the whole organization.

You will also need to describe the rules for approval and change. I’ve done things through a full approval process, and I’ve done things in a wiki, where anyone can make changes. When you do things in the wiki, it can be good to monitor the changes periodically, to make sure inappropriate changes aren’t introduced. I also would generate release notes periodically, so people knew what had changed in the way we operated over time.

4. Process should include context and history

You’ll probably want some sort of a template for your process pages, which explicitly includes a section for context and history. This can feel like extra overhead. But it’s helpful. You can explicitly call out the situation that warranted the process you’re implementing. And you can sometimes even mention when it won’t be useful any more, or when you might want to rethink this way of doing things.

Adding history can help people understand the changes that have been made over time. And the context can help people understand how to shape future changes.

Take it to the next level: make it public

If you’ve rolled out your Engineering Handbook, and it’s been successful, you might consider taking it to the next level: and opening it up to the whole world to see.

This is a radical step, and probably not a fit at a lot of companies. And it may be difficult to get people on board with the idea. But it does have some advantages:

You’re marketing your organization to the rest of the world. It can attract candidates, who see how well your organization is run, and the principles by which you’re organized.
Having a public audience will automatically result in a higher quality of process. Wouldn’t you do a better writeup of your team’s process if the whole world could see it?
Having your process in the open will also help others learn from you.

The company most notable for doing this is Gitlab. The Gitlab handbook is the operating manual for the company, and it’s quite well done.

Thank you

Bjorn Freeman-Benson came up with the idea of and practice of putting the New Relic process in Github.

Rebecca Campbell was my partner in crime for a few years with the New Relic process docs. I learned lots from our time maintaining the process docs there.

Alex Kroman asked me to write the New Relic engineering handbook, which was essentially our book on how we did product development. It included our practices, roles, and standards.

Gabriel Ricard introduced me to the idea of Replying with Documentation.

Image by Pexels from Pixabay

Uplevel your managers with Mini-M support groups

Jade Rubick — Sat, 28 Jan 2023 00:00:00 +0000

Today, I would like to share a management practice we developed at New Relic. It was one of the best things we did as an engineering organization. The practice is called “Mini-Ms”. I believe it’s as important a practice for managers as code reviews are for engineers.

This post is first of a series:

In this post, we look at how Mini-Ms work and what they are.
Next, we learn how to implement Mini-Ms.
Then, we discuss variations you may want to consider.
Finally, we share a history of Mini-Ms, including where the name came from.

What is a Mini-M?

A Mini-M is a group of managers that meet weekly or biweekly. The meeting is a combination support group and working session. In each session, managers share challenges they face. The other participants offer support and help problem-solve.

Why are Mini-Ms effective?

What is the value in meeting with other managers and talking about your problems? It may not seem like it is worth the time. Yet, many managers claimed Mini-Ms helped them grow more than anything else.

Mini-Ms help you develop skills

There are a few reasons for that. Elaine May describes three reasons:

“Learning to manage is very different from other types of learning (like engineering, for instance). In management, the concepts are simple and the execution is not. I’ve seen this trip up many engineering managers who read a book or attend a class and find the concepts trivial and therefore easy or not very important. Learning management is more of an apprenticeship versus an intellectual pursuit.”
“In a Mini-M, you have many other people to learn from. If you are only learning from a coach, manager, or mentor, their approach may not fit very well for you, but in a Mini-M, you are getting multiple perspectives.”
Teaching clarifies your thinking. When you share your experiences and ideas with other managers, you’re forced to articulate your own practice, and consider it in a critical way.

I have a few more explanations:

Skills are unevenly distributed. You might be good at running meetings. I might be good at 1-1s. Another participant might be an effective project manager. During a Mini-M, we all share our experience with each other.

Imagine having to fill in those skills some other way. You would have to study each of those topics. Or learn each of them the hard way. That would be much slower! The diversity of the group allows the group to grow faster.

Mini-Ms meet you where your skills are. Most alternative methods of learning involve assumptions of where your current skills are. For example, a management course tries to teach you a certain set of concepts or practices. But Mini-Ms allow you to expand your skills from wherever they may be. If I am struggling with how to run a particular meeting, I can immediately add a little to my skills during a single Mini-M session.

This makes the M-team into a combination of a support group and training session for your management team.

Mini-Ms are a source of valuable support

Management is a difficult profession. As hierarchical creatures, being “higher” in the hierarchy separates you from your team members. And other managers are often busy and unavailable.

Because Mini-Ms were largely modeled on support groups, your group can become part of your support network. Even outside of the meetings, you might turn to your fellow managers for help.

Having a Mini-M helped me to build up a mental map of the skills of the managers around me. This was helpful, because I started to understand the skills that I needed to build. When I ran into problems running projects, I felt like I could go to the person I knew was good at it and ask for help. And because we had a relationship from our Mini-M, they were more likely to want to help.

In addition, many companies are distributed nowadays. This can result in less accidental interaction with peers. And it can contribute to isolation. Mini-Ms can be a source of connection with other managers.

Mini-Ms help retain and attract managers

Because managers feel better supported by their peers, they are more likely to stay at the company. Or stay in management. I anticipated that benefit.

What surprised me was that people outside the company seemed to keep hearing about these Mini-M groups. And they would bring it up during interviews and mention it was why they applied in the first place!

Why were they so attracted by Mini-Ms?

They demonstrated that we took management seriously as a role.
They showed that we valued developing our people, which was a signal that their job as a manager would be better here.
They showed we experimented with our organizational practices. And would welcome further innovation.

Mini-Ms help build a management culture

Along with a support group, the other inspiration for Mini-Ms was a conspiracy. The idea was to bring a few managers together, gripe about the problems in the organization, and come up with solutions. Mini-Ms naturally became the graph along which many management practices spread through the organization.

In the Five Dysfunctions of a Team, Lencioni talks about the importance of managers seeing their “first team” as the management team. Mini-Ms helped develop a community of managers that all were focused on improving their skills and their teams. And many of us felt empowered to address the problems we saw in the organization around us.

How does a Mini-M work?

There have been a lot of variations to the way Mini-Ms have run over the years. What follows is a good way to start Mini-Ms.

The Organizer of the Mini-Ms assigns each manager to a Mini-M. Each Mini-M has five to eight managers. The Organizer sets the expectation that managers attend.

Each group has a Facilitator. They schedule and facilitate meetings. They usually start with a standard meeting format. Here’s an example format:

Each person brings a topic: something that was challenging from last week, or something they are facing now.
In an in-person meeting, the Facilitator would go around and ask everyone for their topics and put them on a whiteboard. In a distributed setting, all the participants would add their topics at the same time to a shared doc.
Everyone gets three votes. They put them on the topics they would like to discuss.
The group goes through the topics and discusses them in turn, ordered by the topics that have the most votes.
The Facilitator checks in every five minutes to see if the group is finished with the current topic, or wants to continue the discussion.

This is based on the Lean Coffee meeting format.

The Facilitator sets the expectation that meetings are safe places. Participants discuss sensitive topics and there is an expectation of confidentiality. For example, a manager might talk about the challenges they were having with their manager.

When to use Mini-Ms

You should design your Mini-Ms based on the particulars of your company. The size and company culture are particularly important.

One precondition to this being successful is that the environment be a supportive one. If the leaders value learning and growth, they are more likely to support Mini-Ms properly. A competitive culture may not be a good fit.

I recommend Mini-Ms to companies with product-market fit. Early in the growth of a company, product-market fit is the most important factor in a company’s success. After you’ve found a good fit with the market, organizational effectiveness moves up in importance to become one of the most critical factors for your success. At that point, M-Teams begin to contribute more directly to the success of the company. While you can lay the groundwork for M-Teams earlier, I wouldn’t recommend them in most early stage companies.

You can use Mini-Ms globally, across an organization, or within a smaller group. You can even implement a Mini-M informally, with a smaller group of managers. If you start informally, be sure to read the History section to see how they evolved at New Relic.

How do I implement Mini-Ms?

We will get to that in our next post. Stay tuned!

Thank you

Not a lot has been written about Mini-Ms, but there is one post currently on the New Relic blog, and another that has mysteriously vanished.

Darin Swanson authored some content that were inspirations for large parts of this article. He and I have worked together on helping other companies implement Mini-Ms, so contact me if you’re interested in help. He also provided feedback and suggestions on drafts of this article. He encouraged me to explain the first team concept more fully, and to describe why pre-product market fit companies may not be a good match. And he suggested I split the content into separate articles.

Nic Benders was one of the cofounders of Mini-Ms. He reviewed this post, offered feedback, and contributed to the history section and described some of the design goals for Mini-Ms.

Elaine May provided feedback, some of which was so good I just ended up quoting her. She was gracious enough to offer some talk to talk about her experiences setting up or participating in similar programs at other companies. And she talked about her experiences with me in New Relic’s Mini-Ms. Elaine introduced me to the Chatham House Rules, which I incorporated into the post.

Bjorn Freeman-Benson was the grandfather of the Mini-M. He shared a lot of his thinking about the principles behind why Mini-Ms were successful and what they were aiming for. He advised me to break up this post into sections and make it easier to get to the implementation section. And shared overall feedback.

Merlyn Albery-Speyer helped me improve the section on “when to use Mini-Ms” by pointing out some preconditions for success. He pointed out that the structure became less important after the Mini-M is established. Merlyn pointed out that we tried to keep people from being in the same Mini-M as their managers, or other people reporting to the same manager. He also shared the theory about VPs not being willing to be vulnerable as a possible explanation for why the Mini-Ms never took off in manager of manager groups to the same extent they did for frontline managers.

Jason Poole shared his experience as an Organizer of Mini-Ms. He pointed out a now mostly disappeared second post on Mini-Ms. He also suggested ways Facilitators could counter unproductive ranting.

Marty Matheny shared feedback based on his experience as an Organizer. He helped improve the advice for Organizers. And he pointed out that engineering adjacent departments participated.

Chris Hansen pointed out that confidentiality was an issue with whiteboards. He noticed an error that would have been embarrassing. He pointed out the value of M-teams in distributed organizations to counter isolation among managers. He also added some advice for participants.

Teresa Martyny reviewed a draft of this post and pointed out some redundant assertions I was making. And she recommended I break this into multiple posts or edit for brevity.

Natasha Litt was another early Mini-M leader, and she reviewed a draft of the post and contributed to it.

Image by J Garget from Pixabay

Books on management

Jade Rubick — Sat, 14 Jan 2023 00:00:00 +0000

Introduction

Management is a deep topic, and there isn’t a formal program for learning. Books are an essential part of deepening your skills as a manager. Here are my recommendations for books.

Overall management

High output management. One of the better all-around engineering management books.

An Elegant Puzzle, Will Larson. Covers a lot of topics of engineering leadership.

The Louis Allen books on management are out of print and there are a lot of versions, some of which aren’t as good as others. These are perhaps the best overall books on management I’ve read, but they’re out of date. I’m working with someone else to get these revised and republished. Let me know if you would buy a copy.

Decentralized leadership

Turn the ship around. How to make an organization where everyone leads.

Warfighting Some of the best info on decentralized leadership comes from the US military.

Org design

Team Topologies. The nuts and bolts of how to organize teams into organizations.

Strategy

Understanding Michael Porter. This is an essential intro to business strategy.

Good strategy, bad strategy. How to make strategy that is actually strategy and not wishful thinking.

Lean thinking

Principles of product development flow. This is a hard book, reminding me of text books from graduate school. However, it covers the principles and laws behind making product development work effectively. It’s extraordinary, but a lot of effort. I have had at least one person I recommended this to say they didn’t like the tone of the book and couldn’t get into it. But I think an essential part of engineering leadership is understanding Lean approaches, and this book, though difficult, covers it better than anything else I’ve seen.

Black Swan Farming How to find the most highly valuable work to focus on.

Thank you

Image by Mystic Art Design from Pixabay

This post originally appeared at https://www.rubick.com/management-books/ and the most up to date version will always be there.

Leaders make their own problems

Jade Rubick — Sat, 07 Jan 2023 00:00:00 +0000

At some point, you begin to lead. This is very different than managing. The difference can be summed up with the phrase, “leaders make their own problems”. I’ll explain that in a bit, but first, let me tell you a story.

When I first realized I was missing something

When I first became a director, I had a conversation with another Director named Jim.

Jim: “So, you’ve been in this role for a month now. Have you figured out your vision for your organization.”

Me: [What is he talking about?]

I realized I was used to taking direction from others, and I had become a sort of “execution” focused manager. I didn’t have any idea what my organization needed. I had no idea what the future should look like. I was managing my organization, not leading it.

Interrogate yourself

I brought this up with an executive coach I was working with at the time. He encouraged me to set time aside every week to really think deeply about my area of the product.

At first, it was hard to preserve the time I set aside. In my busy schedule, it seemed luxurious to save a couple hours just for thinking. But it quickly became some of the most valuable time I spent each week.

I would spend time each weeking thinking amount my organization, about the product, about how things were going. I researched other products that competed with mine. I spent time using the product. I thought critically about our technical and product failings.

I ended up developing a better sense of what possible futures I could create. I started to see possibilities that were invisible to me. I started to learn how to lead.

Mental models: try and catch them all!

At around this time, my manager challenged me to start using more mental models in how I assessed my organization. He suggested looking at the situation from the point of view of:

A systems thinker. (this was my default)
An architect
A product manager
A designer
Etc.

Most leaders use their own experience as their main mental model. Being able to add new mental models to your toolkit makes you more flexible. Each mental model can alter what you think the future should look like. And what the present should look like. It can also inform you of the actions you should take to make things happen.

As I started developing a habit of looking at things from other mental models, I began to see blind spots in my previous ways of looking at the world.

Interrogate yourself with what exactly?

Each week, I sat down and looked at an evolving set of questions. I would go through the list and write answers to the questions on the list. Here is my list of questions:

Review high level objectives

What are the results that are needed? What needs to be true in a year? X needs to be Y by Z. What would need to change for that to happen? What are the implications of that need?
How are the teams performing? On time, hitting the mark, right characteristics? How are they performing AS a team?
Where are things on the path to fail?
What’s the worst thing that could happen?
Is there anything I think my boss is making a mistake on?
Can all of my reports take over my job in 1-2 years?
What seems like it’s not working right now?
What’s going well that could be turned into a repeatable process?
What should I worry about?
What do my managers need?
What does my org need?
What do I need?

Review progress against objectives

How on track is everything?
How long should the rope be for all of my objectives? Agree to them with other people. For ex: when should we expect reliability to improve?
Review team health
Review progress against goals.
How are team members doing against their goals?

Identify next actions

What actions should be taken?

I found writing down the answers to these questions to be tremendously helpful.

If you’re an external processor, you might find it more useful to talk with others about these questions. For me, I did a bit of both. I found a few other people that I would talk about these things with. But I found the private thinking time valuable — it gave me more material to test with others in conversation.

Leaders make their own problems

A leader is a person that asserts a future for a group of people.

If you want to lead, you have to learn to make your own problems. And hopefully, you’ll find some of the process I’ve used to develop that future useful. Do you have your own methods? Please share them with me!

Thank you

Robert Goldmann helped me learn the perspective I needed to lead better. He helped me develop some of the questions on this list. Alex Kroman challenged me to consider things through multiple mental models. Image by Arek Socha from Pixabay

This post appeared originally on rubick.com

A weekly project plan you will want to frame

Jade Rubick — Wed, 21 Dec 2022 00:00:00 +0000

Today, I’ll share a few thoughts on what makes a good project plan. And I’ll provide a sample project plan.

Why have project plans

Many agile teams focus on sprints or chunks of work. But they don’t really plan — instead they do what they can each sprint, plot out their velocity, and determine what they can accomplish over the next sprints.

This is fine, but project plans are a tool for getting you to think about the contours of your projects. They have the following advantages:

You can play with different ways of structuring the project, so you can sequence the value of delivery easier. This makes it easier to play with scope, incremental delivery, and to adjust to changes.
You think through risks better with a project plan. You have to explicitly list things like when people are on vacation or on call. This can result in better planning.
Many teams use sprint cycles or kanban cycles that are longer than a week. Weekly project plans give you more frequent signals if you’re on track or not.
Sprint plans track all the work, which is useful. But that also makes the plan harder for stakeholders to understand.

Keep your project plans simple

Typical failure modes for project plans are no project plans at all, or overly complex project plans.

Complex project plans…

can have many project artifacts.
require time to keep up to date.
can be brittle, requiring fixes or maintenance. They are highly dependent on the person who made the plan.
sometimes create the illusion of more certainty. For example, the project “will be done in 23.53 to 27.55 days”.

I know a project plan is in dangerous territory when I see people allocated as fractional “resources”. Or when the plan is something that only one person can update.

Why keep it simple

One of the dangers of plans is that they can cement things into place. You want a project plan that allows you to make changes in seconds, not minutes or hours. Most complex project plans disincentivize change.

You also want a project plan that clearly communicates. An outside observer should be able to look at your project plan and figure out what will happen when. This requires the right altitude. Keep it simple.

Qualities of a simple project plan

Here are some things I recommend in a simple project plan:

Make it week by week. List out what should happen each week, with a couple of bullet points. Doesn’t need to be more complex than that. What should the bullet points be? Things you will demo at the end of each week.
Estimate milestones, not projects. You should plan milestones, not projects. Yes, a high-level project plan can be important, but you also shouldn’t overinvest in it by planning out the whole project in advance. That prevents you from making changes to sequencing or adapting based on things you’ve learned. You should make a high-level technical plan, and make a list of sequenced milestones. And to estimate the overall project, you might do some high-level estimates. But I recommend only having a week by week plan for the current milestone. [Does that mean these are really milestone plans? Yes, but I call them project plans anyway, because that’s what people are used to.]
Milestones should be less than a month in length. See the milestones post for more details. The key insight here is that small projects typically go way better than large projects, so make all the projects small projects.
Combine plans with weekly communication. It’s helpful to combine project plans with project reporting. Use a style of communication that is concise, represents the state of things dispassionately, surfaces risks, but maintains a “I’m taking care of things” tone. Combining plans with project reporting ensures the plan will be updated at least once a week. I’ll write about project reporting soon.
Make text-based plans. I’ve found it more useful to have project plans be text-based, rather than tied to tooling like Jira. Tooling based approaches are fine. But text-based approaches force people to really think through everything in a different way. You can use links to link to sprint plans or individual stories, or whatever. But it keeps it easy to understand for someone not aware of the project. I sometimes don’t insist on this, but it depends on the circumstances.

Weekly project plan template

This is for a milestone within a larger project

Week of Jan 4th

Single chart shows up in Slack. Data is canned.
Schedule risk: we’re validating our list of chart types are all technically feasible. We’ll demo outcome of that investigation.

Week of Jan 11th

Chart data reflects live information, and is functional in Slack chart.
Additional chart type shows in Slack room, with most basic visual design.
We’ve shown to at least one alpha customer for feedback. We start sharing with them every week from here on out.
Jessica is on-call and doing interrupt-driven work for week.

Week of Jan 18th

Most important feedback from alpha customers incorporated. Other work is prioritized to future milestones.
Last chart type added.

Week of Jan 25th

Holiday Jan 26th.
Charts look great and are thoroughly tested, instrumented. We’ll show usage dashboards.
Release end of week.

Thank you

Thanks for putting up with the click-batey title. It’s truly terrible.

Also, this post is available at https://www.rubick.com/weekly-project-plans/
and that's also where you can subscribe to future posts.

Image by Gerd Altmann from Pixabay

How to not screw up your product strategy

Jade Rubick — Fri, 25 Nov 2022 00:00:00 +0000

An updated version of this post, with images, is available at How to not screw up your product strategy.

As a consultant, I have a view across many companies. So I’ve seen a lot of product strategies. Most have been problematic. Occasionally, I see an example of a product strategy that stands out. Today, I review common problems with product strategies. Then, we’ll cover how to craft a product strategy that avoids these problems.

Problem: product strategies take too long to create

Putting together a product strategy is fucking hard. And while it is important, it’s easy to defer.

Sometimes, you don’t have all the information you need. You need to develop deep expertise in your area or market. That requires time – contacting people, having lots of conversations, and developing a deep sense of the dynamics of your space.

Writing down your thoughts requires sustained, focused time. The people who usually write product strategy (CEOs or heads of product) have hard jobs that lure them from that focused effort. This can result in it taking a long time to put together.

Creating the strategy also requires influencing and collaborating with many people. All of these interactions require time to get people on the same page, discuss disagreements, and incorporate improvements or changes.

Finally, your market can change quickly. New competitors can emerge, technologies change, and customer feedback can shift. These all can result in changes in perspective or emphasis, which can further slow down putting together a product strategy.

And finally, even after you’ve done all the hard work putting the strategy together, you have a lot of work to do communicating that strategy, and getting people to understand it. This also takes a lot of time.

The end result of all these steps is that a common failure mode is “the product strategy is coming”.

My recommendation is to always have a working product strategy. Because strategy work takes time, you shouldn’t make people wait for it. If you don’t have a real strategy, start with a temporary, short-term strategy, based on your best thinking at the moment. Saying the product strategy will be created in the next few months creates the opposite of clarity, and is a common product management failure mode.

When you’re starting out, it will be a bad product strategy. And you can be up front about the fact that it is temporary. But people often need some sort of guidance about direction, and having temporary guidance is way better than no guidance at all.

Problem: product strategies that are a roadmap

I’ve seen some leaders view the product strategy as a communication challenge. They know what needs to be done. They just need to tell their vision to a bunch of people.

So, they write down some themes to focus on. And they share a roadmap, and talk about why it is important. Then they clap their hands together and say, “done!”. They’re not done.

Usually, they then get feedback that people are still confused. So they give another presentation on the “strategy”, and it helps, a little. But all they really did is communicate what the company will be working on. People are still confused.

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.

We’ll discuss the parts of a real strategy later in this post. But for now, my advice is to view a product strategy as a larger piece of work than a communication exercise, or a prioritization exercise.

Problem: product strategies that are goals

Leaders often view the product strategy as a tool to get people aligned. And goals are a way to get people aligned. So many leaders muddle the two together.

They say:

“Our strategy is to land five big enterprise customers next quarter”
“Our strategy is to grow our business 20% compared to last year.”

A goal is not a strategy.

Your goals should emerge naturally from your strategy.

This isn’t to say using goals is a bad idea. You should be familiar with all the tools at your disposal: Goals, tenets, standards, metrics, and centralized prioritization are all valid and effective coordination models. A product strategy is another. I recommend looking through each of them and understanding their tradeoffs. The product strategy is probably the most foundational of all of these options, though, so it’s the place I would recommend you start.

How to put together a good strategy

So how do you go about crafting a product strategy? Here is some advice I’ve given. And I asked product leaders I respect what they thought, and they added their advice as well. Here’s my synthesized set of recommendations.

First, stop what you are doing and read these two books

Clear your schedule, and read this book: Understanding Michael Porter. If you’re not sure if it’s worth reading or not, start by reading this summary of Understanding Michael Porter. You’ll learn more about strategy from reading that book than anything else I’ve encountered.

A second book on putting together your strategy is Good Strategy, Bad Strategy.

Second, study your business and market

You need to understand the market you’re in to make a good strategy. This seems obvious, but I’ve seen a lot of product leaders try to make a product strategy without fully understanding their customers.

You should be able to answer these questions:

What are the various segments of customers you have? (This should be as detailed as possible. It can include size of business, types of problems they face, how they purchase the product, what other products they use, and many other factors)
Which customers are your best customers?
Why do your customers choose your product? Why do customers choose competing products?
What are the trends in your area of the market?
Which trends are you well positioned to take advantage of? Which are you poorly positioned for?
What is it like to purchase your product? What kind of an experience do people have when getting support, or learning your product?
What is it like to sell your product?

Third, talk to a lot of people

How can you possibly learn the answers to all these questions about your market?

You need to be talking with as many customers every week as you can. In some companies this is a challenge. This has to be solved immediately – if you and your peers aren’t connected with customers, your company will eventually fail.
Go through the experience of signing up for your product. Try it out. Pretend you are various types of customer, and go through the experience you think they would have. Try the same thing on competitors’ and see what they are like.
Talk with people within your company that have good information for you. Sales people. Analytics people. Support people. Partnership people. Finance people. Come prepared with lots of questions.

Fourth, start sketching out a draft strategy

Your strategy work should be iterative. So start clarifying your thinking by putting together a rough draft of an early strategy.

I recommend an outline similar to the following (similar to Good Strategy, Bad Strategy’s format):

The situation. Outline the environment the business is in. This should include the business environment (runway, financial strengths and weaknesses, overall trends), what changes are happening in your space, what direction things are going (generally and with each competitor), if there are timing considerations where opportunities will close or open, and what the competitive environment is like. After reading this, everyone in your company should have an elevated understanding of the business situation and market conditions.
The current product. Describe the state of the product. What are its capabilities? What are your liabilities, both in terms of what the product can do, and your ability to evolve it? What tech debt issues are you facing? Are you meeting goals for usage, user experience, and adoption? How does it interact with the current situation the business is in?
The diagnosis. What is the most effective path forward? Describe what should be true in the future that isn’t true today, the path forward, and the implications of that choice. The path to being successful should be clear, and risks outlined. The purpose of this section is to be crystal clear — everyone who reads this section should understand why the company is focusing where it is and how that will connect with the company being successful. This section should outline your target customers, and how you will differentiate or compete.
The argument and alternatives. You almost certainly have alternative approaches floating around. There are people within your organization that are committed to them. This is the section where you make the case for all the alternatives, and explain why they are less compelling choices than the one you’ve chosen.

As you’re writing the strategy, you’ll realize there are gaps in your understanding. That’s fine — highlight that there is missing information, and start tracking it down. Strategy work takes time and is a lot of work.

Use offsites and regular strategy sessions to talk through the various ways your company can succeed. And make sure you can articulate what the rest of the actors in the market are aiming to do strategy-wise.

Your work on this should be iterative, and even after you produce the first version, you’ll want to revisit it periodically.

Some tips while developing a strategy

Good strategy takes advantage of your strengths, and minimizes your weaknesses

I like to think of companies as being in an ecosystem in the same way that species are part of an ecosystem. If your strategy is to compete directly with another company, you better have a really strong reason to believe that you’ll outcompete that competitor. Head to head competition is usually not good for either party, so you have to have some sort of innate advantage that your competitor can’t compensate for. This is likely something like a capability they can’t easily add, or because your product is much less expensive than theirs due to some sort of structural reason.

When you key in on your competitive advantage, you have to be consistent with using that as a part of your strategy. For example, Google Docs was able to outperform Microsoft Word mostly because the value of collaborating on a document was so much greater in Google Docs, because it was web-based, and able to maintain centralized state. New Relic was able to establish itself in a whole new category of Application Performance Monitoring, because it was SaaS based and had a product led growth approach to purchase.

Strengths are usually structural like that, based on

Network effects. The more customers you have, the more valuable your offering.
Cost differentials. You can offer your product much less expensively than your competition. Or,
Capabilities that aren’t easily replicated. You provide capabilities that a competitor would struggle to replicate, or it would degrade their product to replicate.

These are worth thinking deeply about. How can you build a business where someone can’t just come along and replicate everything you’ve done and destroy your business?

One exercise I like to do if you’re a market leader is to imagine what product you would build if you could take the best people from your company and to go off and create a competing product that would aim to destroy the original company. If you do this exercise, and your competition is pretty similar to what you come up with, you might be in trouble.

Good strategy includes where you don’t plan to win

Organizations also tend to want to do everything, so it’s important to make it explicit what you’re not planning to do.

Nadya Boone: “So much of strategy is focusing on few things with enough vigor to make a difference. When I outlined a recent strategy I made an explicit section for ‘What we’re not doing.’ There are plenty of good ideas and they will ooze into the workstream unless you build a way to keep them out, and then dilute your focus on the big rocks.”

Henry Shapiro: “[A particularly good strategy we saw at New Relic] outlined the things we were not doing as a result of the strategy. This was part of jettisoning [an important but off-strategy new product], deciding to focus on our core audience, and not get sidetracked with adjacent markets.”

Good strategy addresses how you’ll overcome obstacles

Many times you won’t be in an ideal situation. You might have some big hairy problem you need to solve with product-market fit. Or you may have a competitor that you haven’t figured out how to compete against. You can outline the bets you’ll make, even if you don’t fully understand them yet.

Your strategy is a plan to be successful in the environment you’re in. It’s incomplete if it doesn’t meet that goal. It’s fine for your strategy to be incomplete, but you should continue to work on it.

Get buy in from the right people

The best strategy in the world won’t go anywhere if you can’t convince people it’s the strategy to follow.

Henry Shapiro: “I think one of the central challenges of the product strategy stuff is that strategy often has to balance buy-in with inertia. That is, the larger your cohort of ‘writers / feedback-givers’, the more the strategy suffers from groupthink and long collective bargaining efforts. I think [the thing to do is] to get buy-in from the right-people, which is a skill unto itself. Part of that is working with a single partner on the eng side to assess capacity and skill gaps, and having a similar partner on the biz / sales side, and maybe an exec who is going to have to buy in as well.”

Use “invent the future” meetings to focus creativity on the future

I read once that Steve Jobs dedicated most of his Mondays to talking with his most trusted advisors about the future. They spent all Monday talking through various aspects of how the future could play out, and how they could shape it. I don’t know if he actually did this, but after reading it, I played with something I started to call “Invent the Future meetings”.

Sometimes groups can have a vision that is too focused on the next month. If you need more focus on where you’re going, try an “invent the future meeting”. Here’s how I ran it:

I’d select a topic, like, “what should customer sign-up look like over the next few years?”, or “what should our product look like in two years, so that it’s much more useful to site reliability engineers?”. I’d ask people to think about the question, and come prepared to present their thoughts. (No slides or excessive preparation).
At the meeting, we’d go around the table and each present what we thought the future should look like, and why.
People could ask clarifying questions, but after going through all participants, we would discuss the tradeoffs of the different approaches.

What I found is that we would often settle on some new possibilities that we weren’t even considering previously.

How to know when you’re done

Gregory Kim: “It might be worth mentioning adding rules for knowing when your strategy is good enough. I.e., would I stake my future livelihood on this? The more critical the need for success, the higher the bar should be for the strategy.”

Remember the opposite rule

The opposite of your strategy should be a viable strategy.

Update it regularly

Gregory Kim: “I think one of the arts of implementing a strategy is knowing when to be fluid and adapt to incoming information and when to stay the course. Supporting this is a couple of mindsets. Be confident in what you propose and understand what it is based upon. Be flexible to change if important underlying assumptions are proving to be inaccurate or if new unexpected opportunities become known.”

Make multiple versions

Henry Shapiro: “I think what made Patrick Lightbody’s product strategy so successful is that it was 12-13 pages long. Having something that is visual and instructive and brief is powerful. The other thing Patrick did was make a slide version of it, which was helpful as a way to communicate it to that 20% that didn’t read it.”

What if you’re not responsible for Product Strategy but need it?

Ask the VP of Product or CEO to present the Product Strategy to your group, or ask for a written version of it for your team to use as guidance. It likely will be insufficient at first, but it can start the conversation. Or send them to this post.

Communicating the strategy

Like most things, strategy work benefits from repetition. Here’s what I’ve seen work:

Get leadership aligned on it.
Send it out in written form.
Communicate it at an all-hands.
Do follow-up Q&A sessions
Repeat yourself.

You may be surprised at the appetite for hearing about product strategy. When Patrick Lightbody and his team came up with New Relic’s first written product strategy, they sent out a link to it ahead of the All Hands. Patrick asked who had read the product strategy, and a stunning 80% of the audience raised their hands to say they had read it!

Executing on the strategy

Once the Product Strategy has been finalized, it’s often a good next step to have various parties write down their Execution Plans in response. You want them to think deeply about the implications of the plan, and reconcile it with what they were already planning on doing. And then you want to rationalize these plans against each other — sharing what people are thinking, and dealing with the inevitable conflict between plans and reality. Sometimes this will require further revisions to your strategy, if you uncover anything major.

You should make sure you make space for people to surface the tradeoffs and implications of executing against this new strategy. Your product strategy is a tool for improving and communicating your strategy, not holy scripture. You may not realize some of the tradeoffs you are making, so ask people to be explicit about what implications they see. Team should volunteer the things they’re giving up or deprioritizing, so everyone has full visibility into it.

Thank you

Many people weighed in on early drafts of this post – any mistakes since then are probably my fault. Big thank you to Nadya Boone, Henry Shapiro, and Gregory Kim for substantial critique and improvements. Gregory Kim suggested contrasting the value of product strategy to other coordination models. Nadya suggested adding in the current state of the product to the outline for a product strategy. Patrick Lightbody showed me an example of what a good product strategy could look like. Todd Etchieson, Kevin McGuire, and Nic Benders taught me a lot about strategic thinking. Alex Kroman not only introduced me to Michael Porter, but taught me the nuts and bolts of strategy. Thank you to @gabor on Twitter for the great strategy quote.

Cover image by Steve Buissinne from Pixabay.

Why are process gates the hellish spawn of evil you should avoid at all costs?

Jade Rubick — Mon, 26 Sep 2022 00:00:00 +0000

Today, I’d like to talk about a common mistake leaders make. Let’s see if you can spot the pattern:

Engineering is shipping too many bugs, so you bring in a QA team that reviews everything before it goes out to production.
There has been a history of making poor architectural decisions, so you put in place an architecture review.
The team keeps shipping completely unusable UIs, so you add a designer review step before anything can ship to production.
The team keeps having cost overruns in AWS, so you have a central team that controls all infrastructure code.
People are doing a shitty job with code reviews, so you add a group of the most senior people who are the only people able to merge PRs, and they review everything before it goes out.

As a leader, you are a designer. Many times you’ll face organizational challenges that will require you to design solutions. The name for what you’re doing in all of these examples is adding “process gates”. (If this was a TV show, I’d have scary music play every time you read the word “process gates”)

What are the problems with process gates?

Like any management technique, process gates are a tool you can use. But they have consequences that tend to be much worse than most people imagine.

The issues with process gates are many:

Process gates tend to persist over time
Process gates increase cycle time, and that is a very, very bad thing.
Process gates tend to proliferate into a death spiral (things aren’t working, add more)

Process gates tend to persist over time

One of the dangers of process gates is that they’re difficult to remove. Because they’re usually done as a response to something bad happening, removing them feels scary. Removing a process gate is usually seen as reintroducing the original pain. So they persist, and tend to cause subtle damage over time.

Process gates increase cycle time, and that is very bad

Most engineering organizations focus on speed, but they should be focused on cycle time. Cycle time is the primary indicator of how successful your engineering organization will be. Or at least this is true for 99% of modern software-based product development.

This is an important concept, so if you don’t believe this already, please read my post on this topic: What can air combat can teach us about software project failure?

The reason process gates increase cycle time is that they’re adding steps to a process. Mathematically, there is no way they cannot increase cycle time. So what that means in practice is, they do something like the following:

Increase the amount of time before a PR is merged.
Increase the amount of time before a release goes out.
Increase the amount of time before an infrastructure change can be made.
Increase the amount of time before an architectural design can get approval.

The problem with these cycle times is that they’re also difficult to see. They tend to accumulate over time, and not be the obvious problem to why engineering is slowing down or delivering less. And they result in an overall less effective, less responsive organization.

Another way process gates increase cycle time is that they often increase the amount of passing back and forth between people. For example, if you add a QA step before work goes to production, you’re adding a whole set of work that needs to go back and forth before things can be released. While this may seem desirable, what it often accomplishes is to create a whole new category of work that bounces between teams. This work has its own latency, because it may only be reviewed once a day. This can add days and days of cycle time to releasing code.

Process gates tend to proliferate into a death spiral

When cycle time increases, the predictable result is that batch size increases. So this also means you have larger chunks of work moving through the system, instead of smaller chunks of work. This decreases the flow of your overall product development, and results in lower quality, less responsive work overall.

So the thing you’re trying to do (improve quality, for example), tends to actually get worse as a result of adding a process gate for quality.

There can also be moral hazard issues with process gates. If the development team is handing off their work for testing, then they are less on the hook for quality themselves. Again, this can result in things backfiring, and actually getting worse instead of better.

What should you do instead of process gates?

So instead of process gates, you should reach for alternatives:

Temporary or narrowly focused process gates
Automation and alerting
Non-gated checks
Do it in the same cycle
Learn more from failure

Make your process gates temporary or narrowly focused

It is possible to use process gates responsibly. The best way to do so, is to make them temporary or narrowly focused.

Temporary process gates are something you use to get people to pay attention to things. Or you can use them so you can be made aware of exceptions that might show your process changes are inadequate.

My favorite example of this is as a method for moving to services. If you have a long-term initiative to move your organization to services, it can be quite painful at first to use services. The most elegant way to handle a servicification initiative is to spin up a team completely focused on eliminating the obstacles to services. Their job is to always work on the thing that is most standing in the way of people using services in new projects. The process gate to add is to say that all teams that are planning work need to share any pain points that are preventing them from doing work as services rather than in the monolith.

Note that in this example, the process gate is very lightweight. You’re making people think about these things, and share some information with the team that is working on services. But you’re not truly making a process gate, because they’re not being blocked by this team. So in a lot of ways, it’s not even a real process gate.

Also note that it is temporary in nature. Over the course of time, this process gate should become less and less necessary. As services become easier, this process gate becomes less relevant.

And also note that this process gate is helping this team focus its efforts in reducing cycle time. So it’s counterbalancing a lot of the disadvantages of typical process gates. So this is a nice example of how to do it right.

You can also focus on making your process gate very narrowly scoped. If you have a high number of problematic PRs getting merged, you might want to have all PRs go through a set of experienced reviewers, for example. You can flip it around so it’s much more narrowly scoped: people go through a probationary period for a few months where other people review their PRs, and then they graduate to being able to merge them for peers.

For example, you have people tag their PR based on the risk level that it will cause problems. High risk PRs can be reviewed by the most experienced team members. One of the advantages of doing this narrow scoping is that you avoid some of the problems with process gates. If the most experienced team members have to review everything, they’ll be overwhelmed and everything will take much longer. If it’s narrowly scoped, they’ll have less overall burden, so the increase in cycle time will be more modest.

A common way to scope down a process gate for PRs, for example, is for changes that involve a database migration to receive more scrutiny, because they can be more devastating when things go wrong.

Use automation and alerting instead

One of the better ways to avoid process gates is to use alerting or automation instead of process gates.

So instead of reviewing PRs for their impact on infrastructure costs, alert when the infrastructure costs spike. Run automated QA tests to make sure functionality isn’t breaking, instead of having a human do it. It can be helpful to consider: “how could I alert on this instead of have an extra step for it”.

Use non-gated checks

Automation and alerting are two ways to make your checks non-gated. Non-gated checking is when the checks happen, but in a way that doesn’t block things from moving forward.

For example, a security team might do automated security checks in production, instead of adding a step before things go out to production. This is a non-gated check. If the security checks find a problem, you can quickly roll things back to a safe checkpoint. Or have a well defined way to quickly resolve the issue within a certain SLA.

The challenge with non-gated checks is that they work best when you have low cycle times in your engineering organization. A team that can notice a significant problem and push out a fix within a few hours can use non-gated checks much easier than a team that takes a few weeks to push out a change. So moving to this tends to go hand in hand with other efforts to reduce cycle time.

Do it in the same cycle

Another way to avoid process gates is to do it in at the same time as other work. So you can have a QA person that works side by side with engineering, instead of reviewing their work afterwards. You can have an SRE that is working like any other member of the team, but has the expertise on operational matters. Having them work side by side, they can often respond to requests quickly, or even be pairing on the same part of the code together. Embedding expertise so that the work is done side by side is often an effective way around process gates.

This type of working together at the same time is something that takes a while to get right. You’ll face resistance and it won’t feel natural at first. But it’s a competency worth building. Have your designers and QA and ops people working more closely with your engineering team. You may be surprised at the results!

You can also employ peer to peer options. So instead of having a centralized team reviewing PR requests, have their peers on the same team do so.

Learn more from failure

Finally, process gates are usually a response to failure. Something bad happens, so you add a process gate in response.

This can be the result of a culture where mistakes and quality problems are to avoided. Sometimes, I’ve found that it can be useful in these cases to try and embrace the failure, because the avoidance is part of the problem.

So when you encounter a problem, try to approach it with curiosity instead of blame. Why did this happen? Is it likely to happen again? How bad is it really?

Try to dig in and see if there are ways you can make this class of problem less prominent that don’t require process gates. Is it training for this individual? Is it better observability?

Sometimes the thing to be learned from a failure is that you have a problem that shouldn’t be solved with process. For example, you might find that you don’t have enough senior engineers on your teams.

Adding process gates is usually not the best solution to failure. But failure is often a good way to learn a lot about how your organization works, and with curiosity and imagination, you can often come up with ways it can improve your team.

Thank yous

Image by Ulrike Leone from Pixabay.

If you want to be a terrible manager, focus on being a shit shield

Jade Rubick — Tue, 19 Jul 2022 00:00:00 +0000

💩🛡️

Many new managers think their job is to “protect the team”. In fact, they see that as their primary function.

This is a mistake. I’ve interviewed hundreds of managers in my career. Usually, when people talk about protecting the team, it is a sign of inexperience. It is a common trap for new managers.

Why do new managers focus on being a “shit shield”?

If you’re a new manager, you may be stepping out of an individual contributor role. This makes you biased towards your old needs. And you are unaware of the new skills you may need to master.

You may hear phrases like, “you can be a shit shield, or a shit funnel”. The virtuous answer to that phrase is to say, of course, I’ll be a shit shield. It sounds like an honorable thing to do. And it seems like it will make your team successful.

Also, most people find their first exposure to management politics to be painful. My first thought was, “oh my god, has this been going on all the time?” It’s easy to come to the conclusion that protecting your team from that mess is desirable. You may see that as a large part of your role.

Sometimes it is necessary

There is some value in shielding your team. In some organizations, it may even be necessary. Dysfunction is common! You’ll find it everywhere you go.

So why isn’t positioning yourself as a shit shield a good idea?

Protection sets up an adversarial relationship

When you’re focused on protecting your team, you’re setting up the rest of the organization to be your enemy. You’re setting up an adversarial relationship when that may not be necessary.

This can prevent you from being effective. Sometimes, the solutions to your team’s problems will come from collaboration. Sometimes, the solution requires structural changes. People won’t see you as a person to engage with that type of work if they see you being defensive all the time.

This can leak into how your team behaves. The team can begin to see the world as “us versus them”. I often see these teams look down on sales or support.

Adversarial relationships tend to propagate dysfunction. Look for better options.

You’re focusing on a local maximum, not a global maximum

An organization composed of self-protecting teams isn’t an effective organization. They are all focused on their own needs, but there isn’t an ability to fix problems that are larger than the team level.

For example, you may run into a problem where support is sending you too many tickets. Instead of focusing on your team’s needs, it’s preferable to look at the larger picture. Work together with the support person, and identify what is better for both of you. You might ask these questions:

Why are there so many tickets?
Are we creating features that aren’t supportable?
Are the tickets created by support because they’re not trained on new features?
Is our documentation poor?

This meeting will result in better outcomes. A “shielder” would take a different approach:

Tell the support leader to send less tickets.
Or tell the support leader you’re not going to work on many of those tickets.

This is inadequate, and results in more dysfunction.

You shouldn’t compromise on your team’s needs, but see it within a larger ecosystem. This raises your effectiveness as a leader, because you’re solving larger macro-problems, rather than just the issues within your team.

You need many management tools, not one

Protecting a team is one of many tools you need in your management toolkit.

For example, let’s say there is some conflict over the product strategy. You could try to shield the team from the messy conversations. Or you could take the approach of an interpreter: explain the situation to them so they understand what is going on.

Having the “interpreter” management tool makes you more flexible. This is an approach that improves empathy and context for your team. That context will help even if you’re not available, because the rest of the company will make more sense to the team.

You’ll find that using the “many tools to apply” as a manager is a way better mental model than the “shit shield” approach. You can be an interpreter, a system’s thinker, a collaborator, or a shield.

Managing “distributed humans”

Being a manager is working within a distributed system of humans. The more capable you become, the larger the portion of that system you’ll be able to affect. Acting as a shit shield is confining your vision to just one node of that system. That will limit your growth and potential as a manager.

So don’t be a shit shield, or a shit funnel. Instead, focus on interpreting. Focus on solving the problems around your team. Focus on delivery. And focus on making things better for your team, and the people around you.

This post (with additional images) can be shared at https://www.rubick.com/shit-shield/

You can also subscribe to my newsletter there for more content on engineering leadership.

Thank you

Image by Thomas Anderson from Pixabay

Learn the weekly rituals you should master as a software project manager

Jade Rubick — Fri, 01 Jul 2022 00:00:00 +0000

Today, I’d like to cover the weekly life of a project manager. When I’m managing a project, these are the things I do every week:

Identify the next milestone. Do you have a goal that is less than a month away? If not, make one up as soon as you can. Talk about the next milestone every meeting with the team.
Update your project plan. Schedule an hour or two every Friday to review and update your project plan.
Update your risk registry. During your project planning time, update your risk registry.
Send a weekly project update. After updating the project plan and risk registry, I send out an update that summarizes where things are at with all the projects I’m responsible for.

Putting these things together will often require meetings or conversations. But having a concrete idea of what you’re delivering each week can make it more clear what to focus on.

Identify the next milestone

People work best when they’re working towards a goal that is close and easy to wrap your mind around. engaged, more productive, and more effective when working on a milestone that is less than a month away.

This also cleaves complexity into a chunk you can manage. People can reason about about that much work. They work more effectively towards it.

Most weeks, you should already have a next milestone identified. Fantastic! However, you’ll often be close to finishing that milestone, or things will shift in a project. Or the project won’t be broken down enough to have a milestone that is soon enough.

Why a month, as opposed to something sooner or later? The short answer is that this is what I’ve seen both with my own experience, and with evidence from some limited data I’ve seen. You can read more about this in my post on milestones, not projects.

I recommend getting the product manager, designer, and people who have thought the most about the technical contours of the project in a room, and tell them you’d like to identify a milestones: “What would the best milestone be that is less than a month away? Let’s come up with a few possibilities, and choose the one we like best.”

Start with the constraint that you always need a milestone that is less than a month away. If you don’t have one, or you’re about to finish a milestone, make sure you have the next milestone identified. Refer to that milestones post to learn more about the art of breaking up projects. And also remember that this is a real skill that takes time and practice to develop.

Update your project plan

I book time every week to update my projects. I review the project plan, and make sure it reflects my current thinking. I ask myself if it still seems realistic. I think through the rest of the project, and think about potential sources of delay and risk. Wishful thinking is your enemy. Look at everything from a skeptical perspective. For some people, this is natural, and for others, it requires practice.

You will often need information from others in order to update the project plan. I usually schedule a weekly meeting per team, or per project. At this meeting, I have the main leaders present, and walk them through the next couple of weeks in detail, showing them my current thinking with the project plan, and asking them to critique it. I then go through further out into the future, but with a little less fidelity the further out we get. Usually I invite someone representing product, technical leadership, and design.

Try to keep these meetings pretty high level. You want them to not be a huge waste of time for the participants. I often find it best to join this activity into a meeting that has a larger purpose. For example, a local team’s leadership meeting might cover this in 5-10 minutes every week. But the majority of our time we might discuss other matters, like the things we’re concerned about or need to improve.

One anti-pattern for project managers is that you can get into a habit of pinging people for information all the time. This is annoying at best. Make it inexpensive for people to keep you informed. And also encourage people to surface what they’re observing, so you don’t have to update them. Switching communication to push, from pull, is preferable.

What should the project plan look like?

I make project plans that are week by week. Each week has a couple of bullet points. The bullet points are things we plan to demo that week. The demos should include technical demos, but the description of what we will deliver should be as customer focused as possible.

I also add time-based events that are relevant to the delivery of the project. For example, vacation time, on-call schedules, and offsites.

The goal for your project plan is to not be more specific that a couple of bullet points. You want a plan that is easy to change. The more specified your project is, the more expensive it is to alter it. A good project plan should be a tool for discussion and one that encourages change rather than discourages it. When I see lots of project artifacts, and things that require updating, I get skeptical. Gantt charts communicate effectively but are often a sign the underlying data is hard to change.

One thing to watch out for is many engineering teams work on a person per project. The more you can use the team as a unit of delivery for your projects, the better. This is a deeper topic, so I won’t go into a lot of detail now, but in general, when I see project plans that specify what each person is doing, I view that as a sign that the project is unnecessarily brittle. And a team that is overly specializing, and not doing enough knowledge sharing. This can be appropriate for small companies, but otherwise, I tend to discourage it. If I see fractional allocation of “resources” in a project, I typically scream, take a lighter out of my bag, set my hair on fire, and run out of the room. The fewer projects you’re managing, the better you’ll do with them, so that’s another argument for teams focusing on fewer projects.

People ask if you need a week by week project plan if you’re on a team that has two week long sprints. Of course it is up to you, but I would do it week by week. Otherwise, you have very little visibility into whether things are on course or not. If I were doing it on a two-week long sprint cadence I would tell the team, this is a plan showing whether or not we could demo this by Friday every week.

What should your risk registry look like?

As you update your project plans, you should also ask yourself what could go wrong. Here are a couple of ways to ask yourself, or others, questions that will help you plan better:

What is most likely to go wrong with this project?
What projects have been similar to this in the past? What challenges did we have with them?
What’s the worst case thing that could happen on this project that seems like it could actually happen?
If we had to bet this month’s salary on this project going well, what are things we would be worrying about right now?

Risk management is a balancing act. You don’t want to overinvest in many of your risks. But you do want to think through them. After you come up with new risks, list them as bullet points in your risk registry.

For each risk, you or your leadership group should determine if you want to take any action to mitigate that risk. Next to your risk registry, list your plan next to each. Or write down, “accept risk”.

If your leadership group is functioning well, you can have rational discussions about the risks, and the cost to mitigate the risks. I suggest when you introduce a risk registry, you have a conversation about the costs of mitigation, and be sure to have conversations about not just how you’ll mitigate risk, but whether you even want to.

Write a weekly project update

After updating my project plan and risk registry, I have a good idea of the current state of the project. So now I help the people around me by sharing that state, in as concise a format as possible.

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. Instead, you should focus on the needs of your reader, and give them just enough information that they can come to you if they need to, to have a longer conversation.

This tweet summarized a lot of the things I’ve learned over the years about writing concise, readable updates. It also features some wonderful examples, so I strongly recommend reading through it:

One thing I’d like to emphasize is that you should come across as a neutral party: objective, upfront about risk, exposing things without bias.

Your update should include a link to the source of the information: the project plan, risk registry, and a link to demo the current state of the project.

After you write your update, send it to your stakeholders. You can use a mailing list or a channel in Slack. You want to make it easy for new people to follow the information. You’ll probably be surprised who finds it useful. You might find other parts of the company who find your updates useful.

These updates help the people around you to be effective. Your manager will be informed about the state of the project, so they can represent your work in meetings (you have no idea how helpful this is for them). Other teams that depend on you won’t have to contact you to get updates. It provides a very nice communication scaffold. You may even get thank you notes!

Incidentally, these updates help demonstrate your ability to manage the project.

I find the project updates to be a good forcing function for doing the rest of the project management. By knowing that I have to send out my weekly update, it forces me to take the time to do everything else.

Ideally, the update should be just a tweet or two in length. You don’t need a lot of detail — people can talk with you if they have questions.

Thank you

I’ve had a long history with project management, even writing project management software in the past. But Bjorn Freeman-Benson really hammered into me the details of how to write a good update. He acted as an editor — training me each week on how to do better.

Thank you to Gerd Altmann for the cover image.

Can this ownership exercise improve how you work with others?

Jade Rubick — Fri, 10 Jun 2022 00:00:00 +0000

When you’re working in a group, you need to know how to coordinate. Coordination requires a shared understanding of how everyone will work together. Most human groups define Roles. Roles help clarify boundaries and expectations for people working together.

For example, in sports, these roles are called Positions. To play well, you need all the positions to understand how to work with each other. And you need everyone to focus on their position. It would be ridiculous in football (aka soccer) to have everyone try and be the goalkeeper.

People often fail to work well with each other, because they lack that shared understanding of the Roles each person plays.

Over the years, I’ve come up with a simple way to align people on roles. It’s way simpler than alternatives like RACI charts (but we’ll describe those too). You can use this exercise when it isn’t clear who is responsible for what. You can also use it for teams to define boundaries of team ownership.

Getting set up for the ownership exercise

I’m going to assume we’re using this exercise between an Engineering Manager and a Product Manager. But you can use it for any roles.

You’ll first need a whiteboard. If you’re not in person, you can do it with Google Doc, Miro, Notion, or Trello. Really most tools will work.

Start out by creating three columns on the whiteboard:

Write “Clearly Engineering Manager” as the first column, on the left.
Write “Clearly Product Manager” as the third column, on the right.
In between the two, write “Unclear”

Doing the ownership exercise

Next, you have the people involved write down stickies for all their responsibilities. One per sticky. Why stickies? You want to easily be able to move things between columns. If you’re using a tool like Trello, you should be able to drag between columns, so that works as well.

You can do this two ways:

Have each person create a bunch of stickies, and then talk through each as you put them up.
Or, you can have people put them up as they create them. Then review to make sure everyone agrees they are where you think they should be.

I usually use the second approach, as it is a little more time-efficient. Basically anything you have ANY disagreement or want to discuss should be moved to the middle column.

Here’s a messy version of how it might look after adding some responsibilities. In this example, both the Engineering Manager and Product Manager think they should be doing project reporting. And they’ve both worked in places before where their role was responsible for defining user stories for the team.

Just doing this initial exercise has already been valuable. You’ve aligned on a lot about your roles, and you’ve made it explicit what conversations you still need to have.

If you did this on a whiteboard, take a picture. You’ll need it later.

Discuss the unclear parts of your roles

Next, you want to go through each of the items in the unclear column.

You may not cover all of them within this first meeting. That’s fine. Spend the rest of the time you have figuring out as many as you can. Here’s what to do:

Figure out the tradeoffs. For each responsibility, ask yourselves: what’s the best argument for the Engineering Manager being responsible for this? And what’s the best argument for the Product Manager owning this?
Discuss the tradeoffs. Talk through any concerns or tradeoffs you see.
Make a decision, even a temporary one. If you can’t come to agreement, flip a coin and agree to discuss how it’s working after two weeks.

Get through as many Unclear items as you can, and schedule followup meetings to finish up anything remaining.

Document what you’ve learned

You’ve now done the work defining the roles. One of you now needs to write down what you’ve agreed to. Simply list the roles, and the areas of responsibility under each.

You can also categorize things, if you’ve had a discussion where you’ve come up with some larger themes. For example, you might say the Engineering Manager is responsible for People, Process, Projects. But it’s always useful to include examples. The larger themes are optional.

This is also handy when teams go through mitosis

You can follow this exact same approach when a team gets large enough that it splits in half. (Splitting a team in half is a great way to form new teams).

The team will have a lot of existing things it owns: parts of the codebase, and interactions with other parts of the organization. Run these through the exercise, and you’ll have a list of things that are clearly owned.

With teams, you’ll often have some sticky items in the Unclear column. Some of them might require technical work or projects to untangle. For example, you might have a piece of code that both new teams will rely on.

Document what you agree upon, and agree on some short-term ways you’ll move forward on the Unclear items. And make sure you have real plans in place to figure out what to do with the Unclear items.

Write roles and team descriptions down in a canonical location

Let’s say you’re a Product Manager, and you’ve just gone through this exercise with your Engineering Manager counterpart.

A question you should ask yourself is, “does anything like this exist for everyone else?“. If you don’t have role definition written up, then the artifact you came up with might be generally useful.

If that’s the case, share it or put it in a place where it can act as the canonical definition for your roles.

For teams, you also want the responsibilities to be put in their canonical location. For code, you might put it in the CODEOWNERS file, so it’s clearly marked in the codebase. For support responsibilities, you should outline how support should interact with each team. Make sure the clarity you’ve produced is put into a place where it can be used by others, if that makes sense.

People aren’t fungible, so roles need some flexibility

Roles shouldn’t be rigid. Every person is different, and every pair of people will have different strengths, backgrounds, and ways of working together.

It should be a valid option to identify that one role owns an area of responsibility, but delegates that responsibility to the other role. For example, Engineering can be responsible for projects, but be totally buried in other work. So you can agree to have the Product Manager run the projects for a period of time.

Also if you have standard role definitions, and want to change the lines between you, you should if it produces better outcomes. I find having the roles written up allows you to have more explicit conversations about these things. “Hey, it looks like you’re responsible for project reporting. How would you feel about me doing the reporting, or helping you with it?”

Some people like RACI charts

You will find a lot of managers that love RACI charts for this same purpose. I find them inscrutable — they take a lot of attention (for me) to understand.

What is useful about RACI charts is that they define responsibilities in a more nuanced way. So, for example, they make it clear who needs to be informed about certain types of changes.

I generally find them to be more effective when you’re dealing with a lot of parties. Stakeholders and multiple people, all doing similar work. The ownership exercise I share here is simpler, faster, and easier, for when you have less parties involved.

If you are in favor of RACI charts, please be aware that not everyone understands them intuitively. It can be useful to walk through them.

Let me know what you think!

I find this exercise to be a quick way to get clarity and alignment around roles. Try it and let me know what you think!

This post (with additional images) is available at https://www.rubick.com/role-definition/

Thank you

Image courtesy of UK Black Tech. Licensed under the Creative Commons 2.0 license. Image was cropped.

What do great engineering managers need to know about compensation and equity?

Jade Rubick — Mon, 09 May 2022 00:00:00 +0000

Today we’re going to do a whirlwind tour of compensation. Hopefully you’ll learn a bit along the way. And I’ll share an exercise for managers, called a compensation review.

What do you need to know about salary?

The largest expense for engineering organizations is usually salary.
Salary is mostly determined by supply and demand. Engineers are fortunate to be an industry with high demand. Companies have to compete based on salary and benefits in order to hire good engineers.

Structured pay and "pay equity"

Some companies use structured pay. Structured pay is when there is a "system" for determining pay:

Pay can be based on the employee level, tenure, specialty, or other factors.
Most companies have structured pay -- some do not.

Structured pay is a spectrum. Most companies end up having some sort of system for pay.

Companies that emphasize fairness and equity also will often implement a more extreme version of structured pay: "pay equity":

Pay equity truly uses a formula to determine salary.
The formula can be based on years experience, or engineering level, or other factors. But it's determined by a formula.
Pay equity is less biased, but also less flexible.
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.

As a manager, you need to know how pay works.

Non-pay equity pay options

If the company hasn't implemented pay equity, then you have to figure out how it works. Here are a couple of variants I've seen:

Manager discretion. Managers have discretion to set pay, based on a budget they can use.
Manager proposed. Managers propose pay increases, which are approved by their managers or some group.
Directors or VPs set pay, with input from managers. Using a budget.
Cost of replacement. Compensation increases can be justified based on proving you could make more by going elsewhere. This perversely incentivizes people interviewing outside the company. Netflix is famous for this approach.

Your homework is to figure out how your company's system works. Is it structured? Is there a formula for how salaries are computed? Do you have salary ranges?

Geo-based compensation

Companies have to make a philosophical choice in how they pay. They can choose:

Geo-blind. Pay the same amount without regard to location. Note this does NOT mean everyone gets the same salary, because taxes and expenses will vary based on location. Some people could end up getting twice the take-home pay!
Geo-balanced. Pay so that everyone receives the same amount, regardless of where they live. This means the company will pay very different amounts for each employee. For example, costs in one country in Europe can be twice what they are in another country.
Geo-based. The pay is adjusted based on what compensation people are getting in that location. People in San Francisco get paid more than people in Kansas or Poland.

Each of these has tradeoffs:

Geo-blind: you're paying high for regions where pay is, on average, lower. This makes you more competitive in those locations. Unless you pay a rate high enough you can be competitive in expensive markets, you're less able to hire people in expensive locations. In practice, this means you're not hiring out of tech hubs like San Francisco.
Geo-balanced: you're more competitive in countries with high taxes. And less competitive in countries with low taxes. But also you pay more for the employees you're most competitive to receive, which can be a disadvantage. I believe geo-balanced is a rare choice for companies -- let me know if you are at a company that does this.
Geo-based: you're able to hire in expensive markets, where there is a lot of talent and experience to draw from. But you're also able to save money by hiring outside of those locations at a lower rate. This can incentivize hiring in less expensive locations. But you face more competition in those location from companies that are Geo-blind. Often the best candidates in those regions will look for Geo-blind positions, because their pay can be so much higher. You also have to figure out your approach to having people move between locations. Do you change their pay?

People tend to be pretty ideological about which of these is best. But the important thing is you need to understand how it works at your company.

You may not be able to hire everywhere, because taxes

Most companies will have a list of locations you can hire from. The reason for this is that companies have to do paperwork and taxes for every location they have employees. And sometimes there can be additional legal ramifications for having a "presence" in a location.

There are companies that help minimize the overhead of this. But it's still an issue, so you need to be aware of the locations of your team members.

Because of these factors, an employee moving to a new location can be a "problem" you have to work through with your People Ops / HR team. And you may not be able to hire people everywhere you think you can. So consult with your People Ops team when hiring.

Generally, companies will be willing to incur the overhead for existing employees, but there are times companies will cut ties with an employee rather than deal with additional legal requirements.

Note that the differences between locales is very different between regions within a country, and between countries. The burden of dealing with international relocation, visas, and taxes can be so large that many companies will not bother to address them.

Budgets and pay

Finance usually provides a budget to each department. Depending on the size of your company, you may or may not have much interaction with the budget. But even if you don't know it's there, the budget is a hidden force that drives a lot of decisions.

Companies generally have a certain amount of money they can spend on hiring employees, promotions, and cost of living adjustments. Usually that pool of money is determined by Finance.

That pool of money for employee salaries can be divided into buckets ("salary", "promotions", "cost of living adjustments"). But it may not be.

Generally budgets are zero sum. If you give more raises, you hire less. If you give larger cost of living adjustments, you promote less.

You'll see a lot of people that talk about how things "should be". But the reality is that that is how it works in most companies. You can sometimes get exceptions, but the money has to come from somewhere.

One thing to be aware of is that saving money somewhere can often justify spending it elsewhere. As a frontline manager, you probably won't be in a position to be making a lot of these decisions, but understanding how it works can help you if you want to advocate for change.

How companies determine compensation

Most companies have engineering "ladders". They describe the difference between a Software Engineer and a Senior Software Engineer. And they outline the criteria for advancement between these levels.

Companies do this for a number of reasons. What you're probably familiar with is their use to help guide career discussions. And to attempt to create an objective standard you can make promotion decisions around.

What you may not realize is that companies use these ladders for another purpose. They use them to determine salary. You may think, "of course they do". But there are companies out there that provide salary information. By creating a ladder, and defining what is in that ladder, your HR people can match up your company's levels to what is done for the whole industry.

This is complicated, because engineering titles are not equivalent across companies. A senior engineer at Company X does not equal senior engineer at Company Y. So these companies have detailed ways you can map your titles to theirs.

Many companies also use salary tools, which attempt to compute a salary based on a job description and a bunch of keywords. These tools aren't perfect, but they are an attempt to use data to make sure compensation is fair.

Larger companies will have a dedicated compensation person. Their job is to determine compensation for all the roles in the company.

Pay percentiles

Companies generally target a "percentile" when choosing what salary to pay.

So you might hear a People Ops person say something like, "we target the eightieth percentile for salaries".

What this means is that in each market you're competing in, you'll use data to determine the salary ranges. You'll use the distribution of salaries to determine what to set the salaries you offer.

For companies that are not geo-based, this means you're competing in a global market. Many geo-blind and geo-balanced companies don't attempt to compete in expensive markets like San Francisco, because that means they're paying a very high rate for employees everywhere.

Pay tradeoffs

Compensation is a set of tradeoffs that companies make. They have to juggle business needs, market conditions, the employee experience, and growth and performance management.

For example, a company can offer a higher salary, but not promote its employees as quickly. Or it can choose to give more money for promotions, but not be able to hire as many people.

And, of course, each company chooses what budget to make available for hiring and promotions.

These factors are invisible to most people. But they explain why you see things like a low promotion budget, but rapid hiring. They're optimizing to bring more people in. But trading that off against future employee turnover.

Equity

The definitive guide to equity compensation is the Holloway Guide to Equity Compensation. I recommend you read it carefully.

You'll need to have conversations with your team about equity, and understanding it is beneficial in its own right.

A couple of things to remember:

For startups, the value of a share of stock changes over time (hopefully it rises). When the company is younger, equity will be "inexpensive". As the company succeeds, the value of the company will increase, so each share will have a higher value.
It's inexpensive early on, because it's risky.
Because of this, earlier stage employees get more equity. This reflects the additional risk they take on joining a company. Many companies don't make it, so the earlier you join, the higher the risk. Also the higher the reward.
The typical pattern for startups is for early employees to have lower salaries, but lots of equity. The discounted salary is somewhat offset by the large equity grant. As the companies grows, they usually correct these discounts as options vest.
To make it more confusing, companies also issue different types of equity. ISOs, NSOs, RSAs, and RSUs are all different.
So comparing equity becomes complicated quickly.

Why do a compensation review?

So, now let's talk about the compensation review exercise. Here are the benefits:

It will help you understand and support your team better.
You'll probably find some errors, and correcting those errors will earn you goodwill.
It forces you to learn about compensation and equity, which will be good for your team, and for yourself.

Are you even able to do a review?

But before we start, let's make sure you can do such a review.

Do you have access to your team's salary? Can you just look it up, or do you have to ask for it? In most companies, you'll have access to look it up. But sometimes you can get it by request. In some companies it's not available to you -- if so, you won't be able to do this exercise.
Do you have access to your team's equity? In some companies, even if you have access to salary, you may not have access to equity. And if you do, you may not have access to full information about that equity. That's fine, but keep in mind equity is complicated.

Doing the compensation review

Doing the review is actually pretty simple. I have a template you can copy and adopt to your purposes. Fill it out for every member of your team. Highlight in red the things that stick out as most problematic.

Tips when doing a compensation review

Look for salaries that seem lower than they should be. Compare to people at the same level, one level below, and one level above.
If your company does geo-adjustment, you'll need to figure out how it works, and factor that in. Usually it is a multiplier on the salary. 100K * (geo-adjustment of 90%) = 90K. Companies will usually have a table of location, or use a tool that produces the geo-adjustment. I like to produce a "geo-reversed salary", but doing so will require you to know how the geo adjustment works.
If you're not able to find how geo-adjustment works, you can estimate using cost of living calculators to get a ROUGH idea. This is highly imperfect, because cost of living is not how these geo adjustments are determined. They are determined by what supply and demand.
In the notes section, fill out anything interesting. For example, I've worked at a couple of startups that gave early employees the option to tilt their compensation towards equity or salary.

Look for edge case scenarios

If they were rehired into their position, would they get a raise?
If they were rehired into their position today, would they have more unvested equity?
Do a pass for fairness. Is everyone being paid fairly for their level?

What do you do now?

Once you've done the compensation review, you'll probably notice a few things that seem off. Your next job is to dig into that. Are there legitimate reasons for those anomolies? Or are they something that needs to be fixed? Make these changes as quickly as possible.

Thank you

I'd like to thank Zen Mak (founder and CEO of RallyWorks) for her feedback on this post. And I'd also like to thank Bailey Douglass (founder and CEO of Second Principles). Bailey is working with companies for free to come up with policies to support medical travel for team members who need it in light of the Roe v Wade leak. Bailey gave a ton of feedback on this post, and helped improve it significantly.

Image by Nattanan Kanchanaprat from Pixabay

Share this post: https://www.rubick.com/compensation-and-equity/ (this version has images too!)

This is part of an engineering management bootcamp newsletter course.

Glue your happy brains together with shared state

Jade Rubick — Fri, 22 Apr 2022 00:00:00 +0000

Operating under a shared reality is a competitive advantage, but most teams share state poorly. Let’s talk about gluing brains together!

Computers and people both have "state"

In computer systems, state is information that is remembered between interactions. A stateful service is one that keeps track of things that have happened before. Databases are where we typically store state, and we try to design our services so they don’t keep track of state themselves, but keep it in a central place.

People, as autonomous beings, require state. The way our thinking works literally requires it. So one of the great challenges of all organizations is distributing a shared understanding of reality: the organizations challenges, goals, and activities.

You don't copy state, you serialize it

With computer systems, and with people, you can’t just copy state around. I can’t clone my brain, or even a part of my brain, and give it to you for you to understand perfectly what I’m thinking. So in computer systems, we serialize information to put it in a format that can be transmitted between machines.

Human communication is also serialized. We have to put what is in our minds into words or writing to share it with others. This is necessarily imperfect. It is actually impossible for us to express our internal state to each other, so we have to choose what to serialize, and create a facsimile of what we have in our minds.

Human serialization is lossy, too

Our serialization is lossy -- people listen poorly, or use pre-existing state and biases as they listen. And we similarly are poor at serializing our thoughts to give to other people. The protocols we use for communication are ill-defined, and ambiguous. And just like computer systems, they require a lot of processing power to transfer even simple messages back and forth.

Errors compound the more people you're dealing with

This is hard enough with two humans. But as we increase the number of people involved in any group of humans that need a common understanding of something, you multiply the number of people involved. Each is deserializing that information in a different way.

What you’ll often find is that people use error-correction algorithms to verify the messages we hear. After a meeting, you’ll talk over what you heard and double check your understanding. And then the two of you will try and figure out what you each thought about what you heard.

One of the reason one on one conversations can be inadequate in a remote setting is that when you’re trying to get ten people on the same page about something, and the state is changing as you problem-solve the situation, it’s impossible for those ten people to all have the same understanding of the problem, or proliferating and evolving solutions.

In-person teams share state more easily

It is easier for in-person teams to “share state”. When you sit next to someone, you are exposed to the same information, and it’s easier to build a shared understanding. This is a prime advantage of colocated teams, working in the same time zone, on the same project.

Distributed teams often struggle with sharing state

On distributed teams, we have to take extra care to share state. I’ve learned this the hard way -- we have to be incredibly explicit in our communication with each other. On distributed teams, it feels like things are the same, but the variance in deserializing information is much higher, so it requires a lot more explicit communication. One particularly bad example of this was when I was working at a company preparing an important project for our user conference. We got two months from the release and found out the engineers thought we were delivering “something” at the conference, even though the leadership had been talking about a GA release for months!

When leaders don't share state, the results are devastating

One of the most common "state" problems on engineering teams is when the engineering manager and product manager aren't sharing state. They may each have their own version of the project plans. They might each have different ideas of what is being done or what's important.

How to merge squishy brains together!

There are a few solutions to sharing state.

Be explicit and build trust

One is to check in frequently and have a lot of explicit communication. The more trust you have with someone, the easier it is to share state, because your serialization protocols are better tuned for each other.

Use writing to share state

Another solution to sharing state is to emphasize writing. When we write something down and collaborate around that shared document, we are all participating more closely in a shared version of reality. While we may deserialize differently, we’re all interacting with the same “database” of information, and the changes are something we all participate in.

Writing is less transitory than verbal communication, and it is more precise. I believe it’s one of the key skills for a successful remote company to master.

I would pay more to make Slack MORE transitory (all messages disappear after a day), because people could rely less on being able to look up previous conversations. Chat isn't a shared document, because usually the people involved aren't starting from a shared state. That's why chat is effective for solving simple problems together, but not complicated ones. I like the pattern of posting links to information in Slack, and having conversations and decisions made around documents. And to reply to things with links to where that information is being maintained.

One of the best patterns I’ve seen for accelerating organizational leadership work is to write down your best thinking of what the problem is and what to do about it, and share it with a group of people. Ask them to make it better. You can go through a couple of rounds of sharing it more broadly, and getting feedback, but you can go through those rounds pretty quickly -- a day or two per round. Then just get started! Your plan likely is better than it would have been because you spent the time to write it down. And it’s much better still since your colleagues have improved on it. And everyone’s basically on the same page about the problem and what is to be done about it.

In any case, the important thing is to be aware of state, and how you're ensuring your messages are being communicated. Think of it like a computer system, and it might help!

Image by Willi Heidelbach from Pixabay