How to Write Your Own User Manual: An Example to Get You Started

I’ve been a huge fan of the personal README (or user manual) ever since I first heard of the concept.

Documenting for people how they can best work with you (and asking the same of others) is a great way to build empathy and understanding within a team.

What’s your preferred communication style? How do you like to receive praise or criticism? What assumptions do you typically make in situations?

I wrote mine a few years ago, and while I haven’t dusted it off recently (oops), it’s still an accurate explanation of both how I work and what a personal README even is. Feel free to borrow, steal, or otherwise take inspiration from it if it’s something you would find personally valuable.

Most of it was inspired (and, honestly, probably a little plagiarized) by other far more competent leaders than myself, and in its writing, I did a poor (read: nonexistent) job of citing the original sources.

If I lifted anything below from you or someone you know, please shoot me an email, and I will update this post with the proper backlinks.

Hi, I’m Zach.

I’m looking forward to getting to know you, and I hope this README will help you get to know me just a little bit better. To be clear, this document is not intended to replace or override the relationship and trust we will build as we work together, but instead, exists to give you an idea of how I think and how I work.

My Role & Responsibilities

As an engineering manager, I am here to make sure our team is successful, motivated, and working on the things that are most valuable to our customers, our product, and our business. That said, my responsibilities can be broken down into three primary objectives:

1. You are set up for success. I want you to improve your technical skills, grow in your career, enjoy your work, and believe in both our team’s and our company’s mission.

   
   

2. Our team is set up for success. This means ensuring that we are pointed in the right direction and are getting what we need from both the business and from other teams.

   
   

3. Our team is delivering on our commitments. If our team is getting what we need from the business, then it is critically important that the business is getting what it needs from us.

These are in approximate order of importance. If you are not successful, our team is not successful. If our team is struggling, then other teams will struggle. To that end, I may write some code from time to time (gotta stay sharp), but writing code will most likely not be my top priority unless all the other needs of our team are met.

My Assumptions

1. You are good at your job. You wouldn’t be here if you weren’t. If it feels like I am questioning you, it will almost always be because I am trying to gather context.

   
   

2. I am not good at your job. My job is not to tell you exactly what to do or how to do it. I might have thoughts on your code, and I expect you to have thoughts on mine (in the rare situations where I will be able to write some), but in the end, you are accountable for your work, and if you have a good reason for doing something, you should do it. I, on the other hand, am accountable for the decisions the team makes (even if I’m not the one making them).

   
   

3. You will let me know when you can’t do your job. My primary responsibility is ensuring that you are set up for success (see above). Sometimes, things slip through the cracks, and I may not know that I am failing in that responsibility, so please let me know.

   
   

4. You feel safe disagreeing with me. Ideas improve by being examined from all angles. If it sounds like I am disagreeing with you, I may be playing devil’s advocate, or I may have legitimate concerns that should be addressed so I can speak confidently about the guiding factors behind a decision later. This relies on us being able to have a safe debate.

My Expectations

1. If you have feedback for me, give it. It could be something you liked and would like to see more of, something you thought I could do better, something you thought I totally screwed up, or something that doesn’t fit in any of these categories. Even if you think it might not be the case, I do want to hear it. And if you think I don’t want to hear it, I’d love feedback on why you feel that way.

   
   

2. Do your best. Seems pretty reasonable, right? If, for some reason, you find yourself unable to do your best, please let me know and we will work to figure out what we can do to get you there together.

   
   

3. Overcommunicate. I hate micromanagement, but there’s no such thing as “microreporting” (which is 100% not a word). I’d rather you give me too much information too frequently than the other way around. It’s my job to make sure you are successful, and I can’t do that unless you keep me in the loop. Failure is normal, and something we can learn from, but failure to communicate hurts us both.

My Beliefs

1. We move forward together, or not at all. I am a firm believer in the “disagree & commit” methodology of decision-making. Everyone is free (expected, even) to have their own opinion when debating a decision as a group, but once that decision is made, execution must start with 100% commitment from the group.

   
   

2. “We” cannot be accountable for something. Accountability must always fall to a single individual. If “we” need to do something, then “nobody” will end up doing it. If a meeting generates an action item, it must be assigned to someone.

   
   

3. Everyone is responsible for quality. I do not believe in a “throw it over the wall” mentality when it comes to quality. Every single developer is responsible for the validity of the code they write, and that validity should be demonstrable via unit and integration tests. Untested code is incomplete code.

   
   

4. There are no lanes. Software engineering is a multidisciplinary career path. I will never ask you or anyone else to “stay in their lane,” and won’t tolerate the implication from others. Lean in, challenge yourself, and if you are working in a new or unfamiliar technology, I will make sure you not only get the support you need to be successful, but the time and space to get up to speed.

The Details

Now that we’ve gotten the “me, me, me” part out of the way, let’s talk about some of the minutiae that will come up fairly frequently.

Schedules

I will typically be in the office between 9 a.m. and 5 p.m. on Mondays, Tuesdays, and Thursdays (pending quarantines, outbreaks, blizzards, car trouble, and any other consequences of living in “unprecedented times”).

I’ve got two kids in school and a 30–40 minute commute, so these times are hardly set in stone but are generally what I aim for. If, for some reason, my schedule changes, I will be sure to communicate that in the team channel, and will expect the same of you.

As for your schedule: do what works for you, but use good judgment. If you’re a night owl and you choose to work from 9 p.m. to 5 a.m., that might not work so well. But if you’re a night owl who would rather be in the office closer to 11 a.m., or a morning person who’d rather be in closer to 7 a.m., that is fine with me.

Same goes for if you’re trying to avoid rush hour, need to drop off your kids at school or daycare, have a doctor’s appointment, etc.

Regardless of your typical schedule, I believe strongly in having a healthy work–life balance. This can mean different things to different people (coming into the office a little late so you can have breakfast with your family, leaving by 4 p.m. so you can pick your kids up from daycare, taking time off to maintain your health, etc.) but to me, work-life balance means not working at the expense of your family/health/beliefs/etc.

If something is wrong, let me know, and we’ll work together to find a maintainable solution.

One-on-Ones

I will put some time on your calendar for one-on-ones. Generally, this will be every other week for 60 minutes. Odds are good that we won’t take the whole hour, but I’d rather block off more time than not enough. To that end, if you think we will need more time, let me know, and I will adjust accordingly.

It is important for you to understand that one-on-ones are your time, not mine. I might have some things to discuss with you, but these are your opportunities to let me know how you’re doing, what you need, what you wish could be different, how you feel about our team and your teammates, what your career goals are… etc.

One-on-ones are not for general status updates. If you’d like to give me a brief status update on things you’re working on, by all means, do so, but those are generally better suited to a quick chat while I’m at my desk, an @ on a Jira ticket, an email, or the daily standup.

If you’ve never done a one-on-one before, I encourage you to write down some things you want to chat about ahead of time until you get the hang of the format because they can be hard to think of or bring up at the moment.

If you struggle with bringing them up, feel free to send me a vague agenda ahead of time. If you don’t know what to talk about, say so. We can use that as a starting topic.

If you need to chat with me outside of a regularly scheduled one-on-one, you have a few options:

• Grab me at my desk. If I have headphones on, it does not mean I am “in the zone” or expect not to be interrupted, so feel free to do something to grab my attention. If I’m about to have to run off for a meeting or other obligation, I’ll let you know and figure out a better time to chat.

• Send me an email or direct message. Even if you want an in-person meeting, just message me to let me know you want to talk, and I’ll make time. If you would rather talk about something over email or message, that’s fine too.

• Throw something on my calendar. If I am scheduled for an interview or something else I can’t reschedule and you invite me to a meeting, I may chat with you and reschedule. If you see that I’ve blocked off the day as a “meeting-free day”, that does not apply to you — it’s more to discourage folks from scheduling non-urgent meetings that day that could be scheduled otherwise. If you need to talk, schedule over this as much as you need.

Disclaimer

I have never experienced having myself as a manager, so take this document with a grain of salt: I wrote some of it, and stole the rest from far more experienced people. Just know that I want you to be successful at your job, and I want to be successful in mine. Hold me accountable, and tell me when there’s something I can do to improve.

This article was originally published at flower.codes.