Screaming in the Cloud - Episode 43: Here’s a Document on How to Best Deal with My Foibles

Episode Date: January 2, 2019

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 Links: Matt Newkirk Matt Newkirk on LinkedIn Matt Newkirk on Twitter Share your Manager README Etsy Etsy’s Job Openings Shane Garoutte on LinkedIn Kubernetes Everbridge Digital Ocean .

Hello, and welcome to Screaming in the Cloud, with your host, cloud economist Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. This week's episode of Screaming in the Cloud is generously sponsored by DigitalOcean. I would argue that every cloud platform out there biases for different things.

Some bias for having every feature you could possibly want offered as a managed service at varying degrees of maturity. Others bias for, hey, we 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 optimize for simplicity. I polled some friends of mine who are avid 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 with root access and 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 offerings. 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 button or make an API call, and you receive a cloud resource. They also include very understandable monitoring and alerting. And 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 slash screaming, and they'll give you a free $100 credit to try it out. That's do.co slash 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 sell socks, time for us to build our own Kubernetes. Welcome to the show, Matt. Thanks very much, Corey. I'm very happy to be here. 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. Wonderful. I'm glad to hear it. And you know,

my wife will be happy to hear that too. Exactly. So speaking of hostage taking, there's been a bit of a kerfuffle recently around the idea of manager readmes. And you had 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? Yeah, so a manager readme is a document that's designed to really share some clarity. And in this specific context, it's from a 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 clear to be helpful. I find the most useful in onboarding contexts. 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 of these things. And you can go at them kind of piecemeal here and there. But often, you know, as a manager, you might not be available to answer things in the time. And so as a report, there's a big question like, oh, what does my manager actually think in this scenario? Like, how can I anticipate their need? What am I going to do here? Like, 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 I'm going to 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 when that's like the best case scenario when everything goes well. Is this generally envisioned as something you give to new employees who are starting to existing employees as you assume the either mantle or shame of managing a team? Or one day you show up super excited. Hey, folks, I wrote something for you all to read. 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, really, and they're coming into you, there's a lot.

It's just a blank canvas. And there are so many questions of how do we do this? How do we do that? And with the best intentions, maybe you have really intensive onboarding. There's still going to be some things that are left out. And so 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, like, let us 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, the 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 Hacker News or whatever. What do you think about this? I think it's a way to kind of 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. 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 me, 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 slash arrogant move in some

contexts. And I fully appreciate that that is not everyone's response to this. I've known you longer than you've 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? Yeah. And I guess one thing I would point out is I have definitely seen in a lot of these readmes that are out there, as you described, here are my foibles, here's how you can work with me. And 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. Yeah, it's not great. I think it's a lot better to talk about, here are some questions that I think that you might have, and I'm trying to answer them proactively. And so whether it's like, as a team, do we have any sort of on-call time? Like for some teams,

it's really obvious. For others, it may not be. And so what does availability look like? What do I expect of you? If I send you a message at five o'clock on a Friday, and I ask you to do something like, when, when do you think that I want that response? Like, do I 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. And if it's not clear, you know, 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 just trying to reduce some of your concerns and some of your fears, which is kind of the total opposite of, you know, sometimes I am late to meetings, or, you know, those things are like, well, that's fine. But it's not your report's job to help you work on those. It's maybe appropriate to say, this is my set of goals of things that I am personally trying 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. It feels like putting that in a codified readme form sounds like the response of a almost stereotypical software engineer, where I have this conversation a lot, I'm just going to write a document. And 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 that letting me know that. If I get that in writing, it feels like, well, I've thrown that ball over into your court now, and if I don't remember what I've committed to can go wrong is kind of one, imagining how the document will be helpful and then never actually checking. It really needs to be part and parcel of a communication package. So like really any information that you want to get out there, you can't just send an email,

can't just write a wiki page, you can't just write a document or a 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've 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, 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.

And 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 lend 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 sounds terrible. This doesn't sound like a good thing to me. And if you think about the people that actually are working with those people, that's not a good thing. 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 of, 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 read-me doc would be an absolutely spectacular idea if and only if i get to write it for him and he can't edit it yeah well i i think as far as like not not being able to edit it becomes a different document i think i think there's like a description of who a person's character is, is one document. And in theory, the readme is more of an onboarding document. That is a fair assessment. I'm being slightly hyperbolic here, but not by much. Yeah, I guess maybe to use 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 year since I've written it. And even the way that I manage teams is differently, 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. And 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, you know, 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 on-site

interviews. And 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, but especially if you're somebody like me that listens better through reading, having that written material, it 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, but it would be

different. 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 again, 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. 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 compliment it 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, gone back to one of the nice things about introducing this as part of onboarding, especially as your team grows, is that you 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 give it to the second person, it's not the same document. And 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. And so I think it's really important that it's not just something that you give out of context or as a read-only, here you go, I'm just going to shove this at you without any information kind of thing. And 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 to the level of the person with whom I'm talking to. Whether that means that some people, for example, don't respond well to anything other than a bluntness level that approaches a two by four 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 two by four 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 read me 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. Maybe a setup for a disappointing conversation. Yeah, absolutely. And I will mention, you know, it's been over a year now since I kind of coined the term

manager readme and aiming is hard. I think that it really came out of my experience working on a MUD and, you know, every project, everything had a separate readme. And in that context, it was very clear like this. It's not an aggressive, you must read this thing, or this is how you work with me. It was 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 name would have maybe been more appropriate. 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 smack 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 Garou. 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. And I think back frequently to conversations that we had about times I broke things, times I broke things worse 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 at 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. And 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, maybe it doesn't. This has impact. Getting this right matters in a way that almost nothing you'll do technically ever will. 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 consequences. Absolutely. It comes down to being the type of manager that you'd want to have. It turns out, and 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'd had in the past had done. And 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 had 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'd ever 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. In either way, it's a lighthouse. 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 they have their foibles. And, oh, yeah, I have foibles.

I should do that, too. And I'm just going to send this to everybody, and we'll see what happens. It's not the right way to approach it. One thing that I noticed other folks discussing in the last couple of weeks is also,, how would you feel if your manager 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, really helpful when I got a new manager and I had this document all queued up and I was able to say, look, this is what I share with my team. This is what you can expect of me as a manager now reporting to you. 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 are instead a manager of managers? 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, oh, 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. So 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 that it's well understood. I think that's probably a very fair assessment.

At some point as well, you almost become a founder slash CEO figure as you continue to move up the stack. Or for people who work at real companies because they don't live in San Francisco, built on an entire river of VC money, investing in things with buzzwords instead of business models, people who get promoted, hired in, wind up becoming an executive of a major corporation. an entire river of VC money investing in things with buzzwords instead of business models. People who get promoted, hired in, wind up becoming an executive of a major corporation. And at that point, it almost feels like you outgrow this type of model in that traditional sense. At that point, for better or worse, my perception is the 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 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 lens of the environment in which you and I both operate. Is that a fair categorization? I think so. When I initially wrote about manageried means I had someone write in that shared, I think they're, maybe they called it a leadership blueprint, something like that. And they were, they were from Europe, but I really don't know the broader context in

which there is similarity or difference between the more Silicon Valley, San Francisco-esque landscape that we're in. 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 a 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 sentence. Well, first, thanks, Corey. And I would be very happy to work with you as well. It's nice of you to say that, though I don't believe it. Go on. 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. So, you know, Etsy is a little bit different from other large e-commerce platforms in 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 platform team, linguistic tools. That's no small thing, incidentally. My brother include platform team, linguistic tools. 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 e-commerce

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. Yeah, and it's really fascinating just the ways, the pros and cons of that. There are many far smarter people to talk about that. So I won't,

but my, my teams are hiring right now. We're hiring San Francisco. We hire remotely in the U S you know, Etsy's headquarters is in Brooklyn. We have folks there as well. Yeah, we are hiring.

Feel free to hit up Etsy.com slash careers or hit me up on LinkedIn. I'm happy to chat. Perfect. I'll throw a link to that, to your Twitter account, your LinkedIn profile, et cetera, 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? No and no.

Wonderful. Sounds like we'd get along, except for the lack of puns on your end. Yes. I keep my puns, I don't know, outside of the programming space. I've learned that that is not my, it's not my best area for cracking jokes. 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. Absolutely.

And I can't remember if I mentioned it at the top, but I work at Etsy, but I can only speak for myself. So yeah, thanks very much. It's been really great talking to you. Thanks. Likewise. Matt Newkirk of Etsy. I'm Corey Quinn. This is Screaming in the Cloud. You can also find more Corey at ScreamingInTheCloud.com or wherever fine snark is sold.