This document is a fork of “How to Rands” by Michael Lopp (a.k.a. Rands), and serves as the Second Edition of my personal user manual. If you work with me, you’re going to want to read this.

Hi, welcome to the team. I’m so glad you are here at $COMPANY.

It’s going to take a solid quarter to figure this place out. I understand the importance of first impressions, and I know you want to get a check in the win column, but this is a complex place full of equally complex humans. Take your time, meet everyone, go to every meeting, write things down, and ask all the questions – especially about all those baffling acronyms and emoji.

One of the working relationships we need to define is ours. The following is a user guide for me and how I work. It captures what you can expect out of the average week, how I like to work, my north star principles, and some of my, uh, nuance. My intent is to accelerate our working relationship with this document.

Our Average Week

We’ll have a 1:1 every week for at least 30 minutes no matter what. This meeting discusses topics of substance, not updates. I’ve created a private Slack channel for the two us of to capture future topics for our 1:1s. When you or I think of a topic, we dump it in that channel. After the first 90 days, we can skip the occasional 1:1 as needed, but only one in a row. If we skip one week, we are definitely meeting the next week.

We’ll have a staff meeting with your peers every week for 60 minutes no matter what. Unlike 1:1s, we have a shared document which captures agenda topics for the entire team. Similar to 1:1s, we aren’t discussing status at this meeting, but issues of substance that affect the whole team. This particular practice is on hold due to how our teams are structured. You will already have plenty of meetings with your team.

You can Slack me 24 hours a day, 7 days a week. I do my best to respond quickly.

If I am traveling, I will give you notice of said travel in advance, and you will be able to see it on my calendar. Unless one of us is on PTO, all our meetings still occur albeit with time zone considerations.

I occasionally work late into the night. This is my choice. I do not expect that you are going to work late or on the weekend. I might Slack you things, but unless the thing says URGENT, it can always wait until work begins for you the next day.

North Star Principles

Humans first. I believe that happy, informed, and productive humans build fantastic product. I optimize for the humans. Other leaders will maximize the business, the technology, or any other number of important facets. Ideological diversity is key to an effective team. All perspectives are relevant, and we need all these leaders, but my bias is towards building productive humans.

Leadership comes from everywhere. As an engineer, I remain skeptical of managers even as a manager. While I believe managers are an essential part of a scaling organization, I don’t believe they have a monopoly on leadership, and I work hard to build other constructs and opportunities in our teams for non-managers to lead.

Truth over truthiness. I believe that we work best when we have correct information and a shared understanding of the truth. If I say something that you believe to be incorrect or inaccurate, please correct me politely. I will endeavor to do the same for you.

It is important to me that humans are treated fairly. I believe that most humans are trying to to do the right thing, but unconscious bias leads them astray. I work hard to understand and address my biases because I understand their ability to create inequity.

I bias towards action and experimentation. Long meetings where we are endlessly debating potential directions are often valuable, but I believe starting is the best way to begin learning and make progress.

We’re here to solve problems. Whether we’re architecting a new feature, refactoring code, or fixing a bug, keeping the core problem in mind is key. If we’re at the whiteboard for a while, I will likely take over the top of the board to write “The problem we are solving for is…”

I believe in the compounding awesomeness of continually fixing small things. I believe quality assurance is everyone’s responsibility and there are bugs to be fixed everywhere… all the time.

I start with an assumption of positive intent for all involved. This has worked out well for me over my career.

Communication Protocol

Slack is the best way to reach me day-to-day. Always try that first.

Email works too, but I can’t guarantee I’ll see it. So if it’s important, please also follow up with a Slack message alerting me to check my inbox.

Text my cell phone if you’ve tried Slack and I’m not getting back to you fast enough.

In case of emergency, call me. I will give you my personal cell phone number. If I don’t pick up, text me, starting with the word URGENT. I trust you to appropriately judge whether something is urgent or not. If you work for me, you will never get in trouble for calling me, no matter what day or time.

Feedback Protocol

I firmly believe that feedback is at the core of building trust and respect in a team.

At $COMPANY, there is a formal feedback cycle which occurs once a year. The first time we go through this cycle, I’ll draft a proposed set of goals for you for the next review period. These are not product or technology goals; these are professional growth goals for you. I’ll send you these draft goals as well as upward feedback from your team before we meet so you can review beforehand.

In our face-to-face meeting, we’ll discuss and agree on your goals for the next period, and I’ll ask for feedback on my performance. At our following review, the process differs thusly: I’ll review you against our prior goals, and I’ll introduce new goals (if necessary). Rinse and repeat.

Review periods are not the only time we’ll exchange feedback. This will be a recurring topic in our 1:1s. I am going to ask you for feedback in 1:1s regularly. I am never going to stop doing this no matter how many times you say you have no feedback for me.

Disagreement is feedback and the sooner we learn how to efficiently disagree with each other, the sooner we’ll trust and respect each other more. Ideas don’t get better with agreement.

Meeting Protocol

I go to a lot of meetings. I deliberately run with my calendar publicly visible. If you have a question about a meeting on my calendar, ask me. If a meeting is private or confidential, its title and attendees will be hidden from your view. The vast majority of my meetings are neither private nor confidential.

My definition of a meeting includes an agenda and/or intended purpose, the appropriate amount of productive attendees, and a responsible party running the meeting to a schedule. If I am attending a meeting, I’d prefer starting on time. If I am running a meeting, I will start that meeting on time.

My preferred output of any meeting is a published document of meeting notes. Ideally, one person types the notes live, projected on screen for the rest of the attendees to see. When I am the note-taker, I will frequently pause to ask “Did I capture what you were trying to say correctly?” This gives both the person speaking and the other attendees a chance to ensure we have a shared understanding. This also enables publishing the notes immediately at the conclusion of the meeting. Unless the contents of the meeting are private or confidential, I prefer to make those notes available to everyone in the company, to help those who are interested stay in the loop.

If you send me a presentation deck a reasonable amount of time before a meeting, I will read it before the meeting and will have my questions at the ready. If I haven’t read the deck, I will tell you.

If a meeting completes its intended purpose before it’s scheduled to end, let’s give the time back to everyone. If it’s clear the intended goal won’t be achieved in the allotted time, let’s stop the meeting before time is up and determine how to finish the meeting later.

Nuance and Errata

I want you to read Crucial Conversations – Tools for Talking When Stakes Are High (by Patterson, Grenny, McMillan, and Switzler). It’s an easy read, it’s practical, and I believe it will make you a more capable adult.

YYYY-MM-DD. Using this date format, especially at the beginning of file names, makes everyone’s lives easier. I use it and suggest that you should too.

When I ask you to do something that feels poorly defined you should ask me for both clarification and a call on importance. I might still be brainstorming. These questions can save everyone a lot of time.

I can be hyperbolic but it’s almost always because I am excited about the topic. I also use curse words sometimes. Sorry.

I’m an open book and I play well in environments where we can all share information openly. Never be afraid to ask me any question. Unless I don’t know or I’m expressly forbidden from sharing, I’ll happily tell you what I know.

I take confidentiality requests seriously. Occasionally, you may want to discuss a sensitive topic, that you would prefer does not get shared beyond the two of us. If you clearly indicate that to me, by saying things like “Can we keep this confidential?” or “verbal NDA?” and I agree, then you have my word that I will maintain confidentiality.* I may ask if I can share the information as long as I keep your identity private.

*with the exception of specific scenarios that I would be legally required to report, such as a threat to hurt yourself or others.

This document is a living breathing thing and likely incomplete. I will update it frequently and would appreciate your feedback.

This document is licensed under Creative Commons Zero v1.0 Universal, which waives all copyright interest and dedicates it to the world-wide public domain.