A Manager README is a document designed to establish clarity between a manager and those who report to them. These documents are especially useful for onboarding content. For example, if you have someone new starting on your team, there's so many things you need to share with them - pieces of advice and guidance that help them to make the best decision about what to do in specific situations. A Manager README sets some expectations in advance to make things easier and reduce friction and anxiety for team members.
Today, we’re talking to Matt Newkirk, who manages Etsy’s localization and translation group. He explains that even if your company has an intensive onboarding program and review process, some things are still left out. A Manager README is a helpful and proactive piece of content that prompts conversations about how people perceive things.
Some of the highlights of the show include:
Avoid writing READMEs that are extremely self-centered/arrogant
READMEs clarify what to do until a relationship is established between the manager and their employee
Get feedback early on to make sure that what you include in the document is helpful; it should reflect reality and be discussed
Share README with your manager to make sure you’re both on the same page about team philosophies and expectations
README is a living document that needs to be updated occasionally because things change
README adds context; it’s not designed to make employee feel like they’re back in school and panicking because they’re not prepared
Manager README - Not Matt’s best selection of terminology
Who’s the best boss you ever had? Why? They can be a force that shapes your life and career from the right perspective
Philosophy of Management: Don’t do what terrible managers have done; be transparent about strategic reasons for priorities changing
Full Episode Transcript
Corey: This week's episode of Screaming In The Cloud is generously sponsored by DigitalOcean. I would argue that every cloud platform out their biases for different things. Some bias for having every feature you could possibly want, offer this amount at various degrees of maturity. Others bias for, "Hey, I heard there's some money to be made in the cloud space, can you give us some of it?" DigitalOcean biases for neither.
To me, they've optimized for simplicity. I told some friends of mine who are added DigitalOcean supporters about why they're using it for various things and they all said more or less the same thing. Other offerings have a bunch of shenanigans, root access, IP addresses, DigitalOcean makes it all simple. In 60 seconds, you have root access to a Linux box with an IP. That's a direct quote albeit with profanity about other providers taken out.
DigitalOcean also offers fixed price offers. You always know what you're going to wind up paying this month so you don't wind up having a minor heart issue when the bill comes in. Their services are also understandable without spending three months going to cloud school. You don't have to worry about going very deep to understand what you're doing. It’s click a button or make an API call and you receive a cloud resource.
They also include very understandable monitoring and alerting. Lastly, they're not exactly what I would call small time. Over 150,000 businesses are using them today. So go ahead and give them a try. Visit do.co/screaming and they’ll give you a free $100 credit to try it out. That’s do.co/screaming. Thanks again to DigitalOcean for their support of Screaming In The Cloud.
Welcome to Screaming in the Cloud, I'm Corey Quinn. I'm joined this episode by Matt Newkirk who's an engineering manager at Etsy. Etsy is either the exception case or the poster child for we’ve missed, all sucks, time for us to build our own Kubernetes. Welcome to the show Matt.
Matt: Thanks very much, Corey, I'm very happy to be here.
Corey: Of course, I should point out as well that as of the time of this recording you're out on paternity leave for the birth of your second child. So first, congratulations. Secondly, it was super nice of you to take time to speak with me although you were very surprised to walk into your children's nursery and find me waiting there. I assure you once this recording is done, your children will be released unharmed.
Matt: Wonderful, I'm glad to hear it and my wife will be happy to hear that, too.
Corey: Exactly. So speaking of hostage taking, there's been a bit of a kerfuffle recently around the idea of manager readmes and you have a blog post that was related to this that I'll put into the show notes. But I want to start from the perspective of many of our listeners and me for a while did not know what the heck a manager readme is. What is one?
Matt: Yeah, a manager readme is a document that's designed to really share some clarity and in this specific context it's from the manager to your reports. It's really kind of setting the stage and kind of confirming what you're discussing verbally but is a way to kind of get it out there and make it clearer to be helpful. I find them most useful on onboarding contents. So for example, you have somebody new that's starting on your team and there's a million things to share. Whether it's team culture, manager report culture, all these things and you can go at them kind of piecemeal here and there.
But often as a manager, you may not be available to answer things in the time and so as for reports, there's a big question like, "What would my manager actually think in this scenario like how can I anticipate their need? What am I going to do here? They mentioned this thing that they want, do they actually want me to work late, do they want me to prioritize this differently? I'm not sure. They're not available right now so have to make the best decision." So the idea behind this manager readme is to have some of those expectations kind of set up in advance so that it's easier. It just reduces some of the friction and there isn't as much anxiety. So that's like the best case scenario when everything goes well.
Corey: Is this generally envisioned to something you give to new employees who are starting to existing employees as you assume either mantle or shame of managing the team or one day you show up super excited, "Hey folks, I wrote something for you all to read."
Matt: Yeah that’s a great question. I think it can be valuable in all three contexts but they're different. So I think that as a new member of the team joins the company and they're coming into you, there's a lot. It's a blank canvas and there are so many questions of how do we do this, how do we do that. With the best intentions, maybe you have really intensive onboarding, there's still going to be some things that are left out. I think of this as a supplemental part of that onboarding that's helpful.
I think if you are taking on a new team, it can help to set some expectations like, "Hey, this is what I think about work-life balance. What do you as the team that I am now assuming think about this? Let's use this as a framing for the discussion of how we are going to set our team guidelines because now that I'm on the team, it's no longer the same old team. It's a new team. We have to figure this out." and then as the like, "Hey, I have an existing team and I just read this thing on after news or whatever, would you think about this?"
I think it's a way to prompt a conversation about how people perceive things like, "Hey, this is what I think has been happening. This is what I think my expectations have been and how they've been communicated to you. What do you think? Do you feel like I've done a good job of communicating that or have we actually been looking at this very differently the whole time? And if so, let's use this moment to kind of figure that out and kind of crystallize that." Which can then be really valuable for when somebody else joins the team.
Corey: In the interest of I guess expressing sympathy for both sides of this debate because again, I don't have a particular horse in this race. I'm self employed, I have no direct employees in a professional context and I don't manage anyone right now with the exception of a Chihuahua who already knows what she gets when she deals with me. In a vacuum, a manager saying, "Here's a document on how best to deal with m, my foibles, how I respond well, how I don't."
My instinctive reaction to that in a vacuum is, "Who the hell does this person think they are?" it comes across as an extremely self-centered/arrogant move in some context. I fully appreciate that that is not everyone's response to this. I've known you longer than you held your current job. You're on a reasonably short list of people I would have no problem working with. But in a vacuum where there's not a lot of thought put into it, it turns into an awful lot of I guess back and forth-ism. Does that make sense?
Matt: Yeah and I guess one thing I would point out is I have definitely seen a lot of these readmes that are out there the as you described, "Here are my foibles, here's how you can work with me." I would say that that's not the way to do it. That's not the intent, that's not the original intent of this document although I think it's definitely kind of mutated into that. I would say that if you're telling people how to work with you, it's pretty ugly. It's not great. I think it's a lot better to talk about, "Here's some questions that I think that you might have and I'm trying to answer them proactively."
And so whether it's like, "Do we have any sort of on-call time?" like for some things it's really obvious, for others it may not be, what does availability look like, what do I expect of you. If I send you a message at 5 o'clock on a Friday and I ask you to do something, when do you think that I want that response back? Do you think that I want you to stay on Friday night, or work on a weekend, or is this like a, "Hey, put this on your Monday morning to-do list." If it's not clear especially if there isn't that relationship established yet, that's kind of what this is supposed to do.
It's more of a helpful bumper sticker of like, "Hey, I'm trying to reduce some of your concerns and some of your fears." Which is kind of the total opposite of, sometimes I don't say what I mean, or sometimes I am late to meetings, those things are like well that's fine but, it's not your reports job to help you work on this. It's maybe appropriate to say, "This is my set of goals of things that I am personally to work on. And so if you give me feedback that I am failing at that, I will really appreciate it in the moment because then that will help me further work on that, but I don't really think that's an onboarding document either. I think that's a separate discussion.
Corey: Yeah, that’s a conversation. It feels like putting that in a codified readme form sounds like the response of an almost stereotypical software engineer where, "I have this conversation a lot, I'm just going to write a document." This feels like an optimization that tends to come at the space of human interaction as if it were an engineering problem. And that doesn't often lead to a reasonable level of success in my estimation. It's one of those things where if someone tells me that they sometimes forget what was decided upon during a meeting, great, I appreciate letting me know that. if I get that in writing, it feels like, I've thrown that ball over to your court now and if I don't remember what I've committed to in conversation, your problem now, it's in the docs.
Matt: Yeah. Absolutely. I think the biggest ways that such a document can go wrong is kind of imagining how the document will be helpful and then never actually checking. It really needs to be a part and parcel of a communication package. So any information that you want to get out there, you can't just send an email and you can't just write a wiki page, you can't just write a document or presentation, you actually have to discuss it.
You have to get some feedback early on to make sure that it's actually hitting the notes that you want and then when you delivered it you have to make sure that it's actually getting the information across that you want to your audience and if something isn't quite as helpful as you want it, then you have to edit it and update it. and if you're saying this is who we are and it's not reflecting reality, then you either have to change it aggressively or be prepared for the fact that people are really going to perceive this as a fatal flaw and go elsewhere.
So it's definitely something that without careful consideration, a lot of editing, and feedback, it can be prone to a lot of danger and error. For folks that are kind of putting things out on the internet as finished final products and haven't really gone through the effort of thinking about how is the audience going to read this? I think it really does land to the unfortunate reality that there are a lot of folks who will see that and think, "I really don't want to work for this person. This person is terrible. This doesn't sound like a good thing to me." and if you think about the people that are actually working with those people, it's not a good thing.
Corey: The worst boss I ever had was a guy who spoke only in metaphor and pinning him down was almost impossible. "Am I doing well? Am I not doing well?" "The river doesn't ask how the riverbed feels it simply adapts to the contours…" "That's great. Am I getting a raise this year?" It wound up being a very difficult conversation. To that end, I think that in his case, a readme doc would be an absolutely spectacular idea if and only if, I get to write it for him and he can't edit it.
Matt: Yeah, well I think as far as like not being able to edit it becomes a different document. I think there's like the description of who a person's character is, is one document and in theory, the readme is more of an onboarding document.
Corey: That is a fair assessment. I'm being slightly hyperbolic here but not by much.
Matt: Yeah, I guess maybe to use it as an example. So when I share my readme which at this point as a living document, does need some updating. I've changed over the years since I've written it and even the way that I manage teams is different, the teams that I manage are different. But when I share this, I send it with a lot of other onboarding discussion or onboarding material which is really comprehensive and then we discuss it.
I think when it's in that context, it's much less about like, "Hey, this is a bio of your manager and more about, this is what you can expect. Especially in these first few days and weeks when we're still getting to know each other better. We've probably only spent maybe three hours together between phone screens and onsite interviews. As you join the company, you're going to get a fire hose of information about the company, your team and working with me professionally. And so, this is just an additional thing that you can refer to and we'll talk about and really there shouldn't be anything newsworthy in here."
Especially if you're somebody like me that listens better through reading. Having that written material makes the transition a little bit easier. But if it was really just like this is what Matt is like, I think that my reports would probably write some sort of separate different document which complements this one.
Corey: It also feels to me as someone who's been in and out of a lot of companies over the course of my career that without very clear context being set, you're setting up a scenario where someone starts a job at a new company, it's day one. Their first four hours are spent in HR onboarding and then they sit down for their first one-on-one with their new manager. Probably the first time they've spoken to this person other than hello since the interview process.
And the manager trots out this readme doc and the instinctive panicked response could very well be, "Holy crap, I didn't realize there was homework and it's due today." and suddenly we're all back in school having that panic reaction of, "Oh dear Lord, I look unprepared." So, it feels like it's something that needs to be explicitly made clear that this is something to add color and context and flavor to the relationship and short circuit some of the things that make a person unique if you're going to go down this path.
It strikes me as something that would be very easy to get wrong without that level setting and again, I've had a couple of fantastic managers that I would walk through fire for, for the chance to work with again and a litany of people who were to be indelicate about it, complete crap.
Matt: Yeah, absolutely. I think it's very similar to any other sort of communication that you have. So for example, you're doing a reorganization, you're not going to just send an email. You're going to complement that with a lot of other ways to communicate, to allow for a conversation, all of that. The same with your changing practices, you're not just going to send a memo. So really this has to be complemented with discussion and really iterated on going back to one of the nice things about introducing this as part of onboarding especially as your team grows is that usually don't hire your entire team all at once.
So you can give it to the first person. You get some feedback from them, you make some adjustments, you can give it to the second person, it's not the same document. As you go on and you've hired that third, fourth, fifth person, you've grown in all that time too so there's no reason that the context that you're sharing wouldn't change as well. I think it's really important that it's not just something that you get out of context or as a read only, "Here you go, I'm just going to shove this at you without any information."
Corey: I think that's probably a fair assessment here. The challenge that I've seen as well is when I was managing teams which I did with mixed success. There are things I'm proud of having done and there are things I wish I'd done differently. I think that's anyone who's going to realistically approach this from a point of view of honesty. I always thought that it was my role as the manager in a conversation to adjust the impedance level and feedback discussion up to the level of the person with whom I'm talking to.
Some people for example, don't respond well to anything other than a bluntness level that approaches a 2 x 4 across the snout. I am absolutely in that category. I don't like ambiguity and was that a good job I did last week or a bad one, I want to be hit with a 2 x 4 in order to understand how I'm doing. Other people despise that they find that incredibly stressful and they just prefer subtle indicators.
I always thought it was my job to align what I was saying to my direct reports. I think one of the problems I have on a visceral level with the idea of a manager readme is, I don't know if you're a person who enjoys reading, how you interact with human beings I'm going to assume you're like every other engineer in my life and just enjoy reading documentation which is incidentally a lie. No one reads the docs for anything. So I know, I'm going to put how to deal with me as a manager into a doc. I'm sure people will read that one may be a set up for a disappointing conversation.
Matt: Yeah, absolutely. I will mention it's been over a year now since I coined the term manager readme and aiming is hard. I think that it really came out of my experience working on the mud. Every project, everything had a separate readme and in that context, it was very clear like this is not an aggressive you must, you must read this thing, or this is how you work with me, this is just some additional context. But I don't think that really carried out into the broader world and I think if I were to start over, I probably wouldn't have gone with the term manager readme. I think some other sort of context sharing maybe didn’t work.
Corey: This is Screaming in the Cloud, we tend to make fun of Amazon service names almost constantly. So I'm right there with you. Naming things is super hard. The easiest thing in the world trust me on this one is, getting up and making fun of a name that someone else has picked. So I have some sympathy for that. One thing I do want to call out because, I mean I've talked a fair bit of smacks so far about different management styles and I've alluded to people in my past. I want to go a bit on the other side of that spectrum.
If anyone is in southern California and near Pasadena, there's a company there called Everbridge. Their GM and vice president of technology operations is a guy named Shane Garoutte. I haven't worked for him in 10 years. But he remains the bar by which I measure every manager I've had since. He's still the best boss I've ever worked for. I think back frequently to conversations that we had about times I broke things, times I broke things worse than that, times I broke things and was astounded that I hadn’t been fired for that.
And it's one of those things you see looking back in hindsight of the forces that shape you. So I firmly believe that people can shape careers from the right perspective. That's why messaging in this context is such an important issue for me. I'll throw a link to his LinkedIn profile in the show notes. I'm sure he'll wonder why suddenly everyone is wanting to talk to him at some point, or no one will because it turns out that only my family listens to this podcast, we'll find out. But it's definitely something that has the power to shape the course of someone else's life. This isn't like most open source projects where I throw something up there and write some documentation and maybe it helps someone and maybe it doesn't. This has an impact, getting this right matters in a way that almost nothing you'll do technically ever will.
Matt: Yeah, absolutely. I think it's on par with having a one-on-one with your reports or giving a performance review. These are things that most people I would say do but it's very easy to do poorly and when you do it poorly, it has really negative hotspots.
Corey: Absolutely. It comes down to being the type of manager that you'd want to have. it turns I'm being not at all sarcastic or joking when I say this, when I first became a manager, I built almost my entire philosophy of management on not doing what terrible managers I've had in the past had done. It got me surprisingly far, I was transparent about strategic reasons for priorities changing.
I never asked people to do things I wouldn't do. If you're carrying a pager, so am I. it became effectively a template of look back at terrible managers I've had and then do the opposite. To that end, if I had ever worked for you and you would have presented a manager readme, I would view it in a remarkably positive light based upon the years of conversations I've had with you. I put other people from my past into a list of if I never received a document from them, I would assume like everything else they touched it was complete crap and it was something to be avoided. It winds up getting flavored by the way you're introduced to it. If you see a good example of this, it's a shining beacon of hope. If you see a crappy version of this, it is a terrible warning to others. Either way, it's a lighthouse.
Matt: Yeah and I think it's exactly that and I think it runs the danger of being cargo culted. I see other people writing this thing, I saw this one person write this thing about how their foibles and oh yeah, I have foibles. I should do that, too. I'm just going to send this to everybody and we'll see what happens. That's not the right way to approach it. One thing that I noticed other folks discussing the last couple of weeks is also like how would you feel if your manager saw what you're sending to your reports.
I would say you should definitely if you write this, share it with your manager. It's really important that you and your manager are on the same page about your philosophies for the team, at least so that they understand what you are expecting of your team so that there aren't expectation mismatches there. I've done that and it was actually really helpful when I got a new manager and I have this document all to that and I was able to say like, "Look, this is what I share with my team. This is what you can expect of me as a manager now reporting to you."
Corey: So here's a follow-on question that may only now be occurring to people because it is only now occurring to me. Does the value of a manager readme change at all if you're no longer managing individual contributors but instead a manager of managers?
Matt: I think it does change. I think it definitely changes I think as far as some of the expectations, they’ll be different. So for example, accountability is something that on the face of it is the same like, everybody is accountable. But the way that managers are accountable to their managers is different because it's usually not a direct accountability. A manager reporting to me is still accountable for working with all the people under them and working things out. I think it gets a lot more complex and definitely requires more face-to-face or at least conversational understanding of things. It's not something you can just leave to a document and hope it's well understood.
Corey: I think that’s probably a very fair assessment. at some point as well, you almost become a founder/CEO figures you continue to move up the stack or for people who work at real companies because they don't live in San Francisco builds on an entire river of VC money investing in things with buzzwords instead of business models. The people who get promoted hired in wind up becoming executive of a major corporation and at that point, it almost feels like you’ve outgrown this type of model in that traditional sense.
At that point for better or worse, my perception is that people management stuff starts to matter less and less. I also want to point out that everything we've discussed so far contextually is mapped around not just San Francisco culture necessarily but north American specifically the United States business culture. I have absolutely no visibility or perspective into what this would look like in Japan, in Germany, in India, in Australia. This conversation takes place under the contextual blends of the environment in which you and I both operate. Is that a fair characterization?
Matt: Yeah, I think so. When I initially wrote about manager readmes, I had someone right in that shared I think they're called the leadership blueprint or something like that. They were from Europe but I don't know. I really don't know the broader context in which there is similarity or difference between the more Silicon Valley and San Francisco-esc landscape that we're in.
Corey: It's a very strange market with an awful lot of distortion potential. So I've alluded to it a couple of times throughout the course of this podcast but you and I do go back our ways despite the fact that I've never worked for you, you are absolutely on a short list of people where if the stars aligned and I suddenly discovered that I was employable again, that where if you were going to be my direct manager, that would more or less be the only question I needed answered. I don't expect anyone to take my word for that of course but that being said, what team do you manage at Etsy and are you hiring? Bear in mind if the answer is no, this suddenly becomes a very awkward sense.
Matt: Well first, thanks, Corey.
Corey: It's nice of you to say that though I don’t know the—go on.
Matt: I would be very happy to work with you as well. So at Etsy—it's true, it's true. So at Etsy, I manage the localization and translation group which you can think of as kind of the international platform and product space for Etsy. Etsy is a little bit different from other large ecommerce platforms and that we're a global platform. Meaning that if you are sitting in San Francisco and selling handmade socks, you can sell those to individuals in Germany and Australia, all around the world.
If you're in Australia, you don't have to go to the Australian Etsy, you just go to Etsy. So as part of that, our team is responsible for all of the different ways that we can better connect those sellers and buyers. My teams include the platform team, moves and tools, and different market…
Corey: That’s no small thing incidentally. My brother is over the moon excited having just moved from the middle east to Germany that suddenly he's in a country that he can use all of Amazon services in and get shipping on things and talk to the echo and he's sort of discovering the last decade of technological advancement in an ecommerce ecosystem all at once. So it's fun talking with him about how this goes through. So the fact that you are a global marketplace is not just one of those talking points for clarity, that is a very real thing to an awful lot of people.
Matt: Yeah and it's really fascinating just the way it is. The pros and cons of that and there are many far smarter people to talk about that so I won't. But my teams are hiring right now. We're hiring San Francisco, we're hiring remotely in the US. Etsy's headquarters is in Brooklyn, we have folks there as well. Yeah, so we are hiring. Feel free to head up to etsy.com/careers or hit me up on LinkedIn, I'd be glad to chat.
Corey: Perfect, I'll throw a link to that to your Twitter account, your LinkedIn profile etcetera into the show notes as well. I have to ask, do you wind up doing deep dive programming interviews on whiteboards and if so, is that called a binary tree grows in Brooklyn? Wonderful, sounds like we'd get along...
Matt: Yes, I keep my plans I don't know, outside of the programming space. I've learned that that is not my best, yeah, as you can tell, it's not my best area for…
Corey: No, I hear you. Making fun of language is less of a talent of mine and much more of a diagnosis. Thank you so much for taking the time to speak with me today Matt, I appreciate it.
Matt: Absolutely. I can't remember if I mentioned at the top that I work at Etsy but I can only speak for myself. Thanks very much, it's been really a great time with you.
Corey: Thanks, likewise. Matt Newkirk of Etsy. I'm Corey Quinn, this is Screaming in the Cloud.