The practice of software managers publishing a README about themselves has recently become quite popular. While much has been discussed about these documents themselves, I’d like to explore the process that goes into writing one of these.
Writing a manager README is not only a good practice for setting expectations with your team, but also an opportunity for self-reflection about your values and quirks.
I recently started a new gig as a director of engineering and decided to try my hand writing my own README (which you can read here, but that’s not the point). The process of putting this together forced me to re-think my values as a manager. And, although it makes me cringe to confess this, I realized while I often try to project a “laid-back guru” persona I’m really more of a “prickly ball of neuroses.”
These are good things to realize. Not easy, but good.
First step: research
Of course, the first thing anyone should do when writing a manager README is to read what other people wrote (for example: this, this, and this). It’s also a nice opportunity to leaf through your favorite management books.
Other peoples’ READMEs are delightfully compact treasure-troves of best practices and nuggets of wisdom. I found myself making a lot of notes about things I really ought to be doing. In fact, I started to suffer a serious inferiority complex as I reviewed these crisp descriptions of discipline, organization, and experience.
Plagiarize, my friends
I freely copied entire areas from other people’s READMEs. Lots of people mention the importance of DRI— good idea, I will too. Feedback is important, but let’s make sure it’s safe, beneficial, and avoids making people defensive? Thanks, Matt, I’m gonna do a bit of the ‘ol Copy + Paste with that one. Oren lists his quirks? Hrm….
Here’s the thing. I don’t feel bad about the plagiarism itself. But I kept having a gnawing worry that by borrowing all these fantastic best-practices and wise approaches, I could be puffing myself up as some kind of wonder-boss. I’d be projecting who I aspire to be, not who I am.
I don’t want to undercut myself by going full imposter-syndrome-freakout, but at the same time I don’t want to oversell myself. I really liked what Katie Womersly had to say about this:
Turns out, “Manager Gameface!” is not super helpful when two humans are trying to figure each other out and build a working relationship.
My README isn’t supposed to be a manifesto on idealized management, it’s about opening up to establish trust and cut down on surprises.
With this in mind, I found myself spending most of my time writing and revising two sections in particular: towards the start, a short statement of my personal values; and a list of my pet peeves and strong beliefs (which I eventually grouped under the heading “my values and quirks”).
At the end of the day…
I wrestled with this one, but I wanted to put a stake in the ground about what fundamentally drives me. I’ve written and re-written this as I try to find the crux and express what I’m saying in as plain language as possible.
At the end of the day, here’s what I care about:
People are first. I never want to participate in an organization that causes personal harm. If you or a loved one is sick, go take care of them — we have your back.
Well-being matters. This includes an emotionally safe work environment — no aggressions, humiliations, or manipulations.
This is a business. I expect us to make decisions based on what helps the organization win, and to maintain obsessive focus.
We go out of our way to do right by our customers. We never compromise our high ethical and moral standards.
I think that’s pretty clear. But I’ll probably keep tweaking this.
Values and quirks
(The following section assumes the reader is familiar with the Big Lebowski).
I’ve always thought of myself as a fairly laid-back manager, along the lines of The Dude:
I sat down to write a short list of my few minor pet peeves. I kept on writing and ranting and well… it was pretty obvious that a lot of things bug me.
- People shooting from the hip, and not having a plan.
- Not having a deployment plan, or anticipating operational support.
- Jumping into code before planning milestones and general architecture. (You may start to see common theme).
- Allowing crisis to bubble up repeatedly, without making a plan to prevent those.
- Not having metrics or measurement — flying blind.
- Unclear ownership.
- Useless meetings.
- Dogmatic adherence to a given process, because that’s what the book says.
- Projects that take on a life of their own and become detached from the original goal.
- …and so on.
Let’s face it, I’m less The Dude and more Walter.
But until I sat down to write my README, this hadn’t occurred to me. I do have some exacting standards which I need to communicate, and I get very cranky when certain things don’t happen a certain way. I don’t have a loose, feel-good approach at all, and it would really help everyone if I tell people that upfront.
I’m glad I know this, even if it’s not an entirely pretty truth. At least this insight came as part of a writing exercise and not an employee meltdown. Taking the time to write a manager README was totally worth it. I’d be curious to hear about other people’s writing experiences, too!