My favorite recent management post is about “radical candor.” It’s the way you give feedback when you care about someone personally and you are willing to challenge them directly. I don’t want to steal the best content of the post (especially the two by two matrix that describes alternatives to radical candor that are problematic), you should go and read it.

Even though this post is targeted at managers, its contents are actually useful for everyone, at least in terms of understanding why our behavior may be surprising to other people. The axes on the matrix are “caring about someone personally” and “willingness to challenge people directly.” In a relationship where you do care about a person, and they know you care, a space exists where you can give even tough feedback without making the person feel threatened. Under ideal circumstances, we spend most of our time with people who we care about personally and who care about us personally, and we can be honest with one another even when it’s painful. If, at your job, people who work together closely don’t care about one another personally, it may be time to change jobs.

When one or both of these ingredients are removed, things get interesting.

Generally, engineers run into trouble when they challenge people directly who they don’t care about personally. I think this is often at the root of conflict within teams — people tend to become very defensive when they are challenged by someone they don’t really trust. The post refers to the willingness to challenge someone directly when you don’t care about them personally as obnoxious aggression.

Managers often get into trouble when they are in the ruinous empathy quadrant — this is when you care about a person personally but you’re not willing to challenge them directly. There are lots of reasons not to challenge people directly, many of them really well-intentioned. In fact, timing is everything. I believe it can be OK to wait on challenging someone directly if the timing for delivering negative feedback isn’t right. If a person is really struggling to meet a tough deadline, explaining to them how they could avoided their current problems by doing a better job of planning probably isn’t a great idea, even if it’s true. The empathy becomes ruinous when you rob people of a chance to improve by being nice when what they need is more accurate information about how their performance is perceived.

The post refers to the case where you don’t care about someone personally and you refuse to challenge them directly as “manipulative insincerity” and describes it as being pretty rare. I don’t think that’s the case at all, it happens all the time. This is the state where pretty much all relationships begin, and where relationships are when people have given up, and the relationship becomes purely transactional. Caring about someone on a personal level is an investment, and challenging people directly requires an emotional commitment (for people who aren’t jerks). When you start working with someone new, you don’t know whether they care about you personally, or if they ever will. You also don’t know how they will handle being challenged directly. “Manipulative insincerity” is the only rational strategy until you figure some stuff out. The hard work for managers is demonstrating to people that you care about them personally, and that it’s OK for them to challenge you directly. (If you are a manager who doesn’t care about people personally or don’t like being challenged directly, just quit and stop making people unhappy.)

I could probably write thousands of more words on this model of professional interactions, which convinces me of its usefulness. If you’re struggling with a relationship at work, I’d encourage you to take a look at the matrix in the article, and see whether that relationship is in the wrong quadrant. If so, that’s the first thing you have to fix.

If there’s one person who I feel really said the things that need to be said in 2015, it was Maciej Cegłowski. He gave a number of talks last year, and posted transcripts of them so that we can all read them and get smarter. The theme is common across all of them – that preserving a Web we can be optimistic about is going to take work and directed effort.

Here are the three talks from last year:

• The Website Obesity Crisis – why Web pages have gotten so huge, and why slow download speed isn’t the only reason this is a problem
• Haunted By Data – why collecting tons of data about your users’ activities and storing it forever is a bad idea
• What Happens Next Will Amaze You – privacy and corporate surveillance on the Web
• Special bonus: Web Design: The First 100 Years – this one is actually from 2014, but don’t miss it. “What if instead of dreaming about changing the world with tomorrow’s technology, we used today’s technology and let the world change us?” Sounds pretty great.

Working “in the industry” these are the oftentimes unacknowledged challenges we face every day – it’s easy to discount the total impact of the decisions we make about how to build Web pages, or how long we retain behavioral data, or what kinds of advertising we choose to purchase. I’m glad somebody brought it up.

One question I’ve been grappling with lately as we’ve been interviewing manager candidates has been, how much programming do we expect an engineering manager to do? It’s an important question, because most engineering managers started out as engineers, and most engineers got into the profession to write code. In a recent post, Cate Huston gets at why it’s difficult letting go:

There’s something we all talk about in becoming a manager – and that’s the process of writing less code. We bemoan it because it’s hard to let go of that part of our identity. But also because it’s so quantifiable. Today I wrote X lines of code. Today I deleted Y lines of code. Today I implemented feature Z. Concrete achievements are reassuring. Today I left the codebase better than I found it. Good job.

Read the whole post, it’s really good.

One interesting part of being a manager of managers is that it’s part of your job to set the larger team’s expectations around managers writing code. When you’re hiring managers, it’s also really important to give candidates a proper sense of what will be expected of them on the job. Some candidates really want to keep writing code, and others may not have the coding skills to be hired as an individual contributor on the team any longer. It’s up to the hiring manager to figure out what will work for the team.

What individual contributors really want is someone who could probably do their job and who can help them solve hard technical problems one on one, but will embrace the role of facilitator and avoid creating situations where their desire to code is a blocker. Perhaps most importantly, they don’t want a micromanager who will second guess all of their decisions but they do want someone who can help them improve their craft.

It’s also true that understanding the stack is really useful for managers as well. It helps to be able to explain your team’s work effectively when working with other teams. It’s fun and useful to help individual contributors solve technical problems as well as people problems. As a manager, you also have the privilege of working really closely with excellent engineers. It would be unfortunate not to learn from them.

So I’ve been working out a rule of thumb that captures how a manager (or would-be manager) should think about programming as part of their job, if that job is managing one of the teams that ultimately reports to me. That rule is:

A manager actively avoids creating situations where their coding is necessary for the success of the project.

That leaves a lot of leeway for managers to pick up technical skills and do some coding within the confines of their schedule. There’s always a long list of things that would be nice to have or tasks that crop up that aren’t project work and if managers want to do some of this work, so much the better. It’s a great way to learn and it helps the team focus on the big stuff. At the same time, it establishes a clear line between a manager, even a “technical” manager, and a tech lead. It should also keep the manager out of the way of the individual contributors.

Regardless of your philosophy, as a manager of managers, if the teams that report to you don’t have a clear understanding of what’s expected of managers as technical contributors, it’s going to become your problem at some point, and will end with people being profoundly unhappy with their jobs.

I should also add that one skill really good managers have is knowing how to surf this wave – applying their technical skills when it really counts and keeping their distance when that’s what the team needs. If things are really working, maybe it’s best for you not to be a micromanager and to let the team work it out among themselves. Nobody ever said this job is easy.

Have I really not written a blog post since October?

It’s probably worth discussing what’s been going on with my blog for the past four years or so, and why I’ve been so much less prolific in recent years than I was in years prior.

One answer came to me not long ago when one of my colleagues asked on Twitter about the value of blogging. After thinking about it, I realized that one of the big reasons is that I was trying to generate the kinds of conversations I wanted to participate in. I hadn’t found a venue for these conversations in the offline world, so I wound up trying to create it online.

These days, I have the benefit of having a job at Etsy where many of the technical conversations I once had to go online to find are happening every day. If I want to talk about the ins and outs of engineering management, or the difficulties of releasing an internal tool as open source, or the pros and cons of typesafe languages, I can just grab someone at work and hash it out. Talking about this stuff in the offline world has consumed some of the energy that I once channeled into the blog.

Another complication is that as a manager, management is one of the topics I really want to write about. Unfortunately, it takes extra care to write about management in a way that doesn’t generate anxiety at work. I don’t want to air people’s dirty laundry here, even anonymously, and more importantly, I don’t want to give people them impression that I’m writing about them when I’m not. The person who was the subject of this post read the post, and it wasn’t hard for them to figure out it was about them. Oops. I probably should have told them about that in person rather than blogging about it.

Finally, over a very long period of time, as blogging has become more popular and more professional, I’ve become less willing to air my dilettantism publicly. I once wrote frequently about ecomics and politics without self-consciousness, but I don’t feel very comfortable doing so any more. The world is full of too much armchair analysis by the underinformed. I don’t enjoy feeling like another noisemaker.

There’s plenty of room out there, though, to write about things I do know about, and I do plan to write more. I just thought you might be interested in why I haven’t written as much lately.

Here’s the reading list to accompany my Monktoberfest talk on just culture, blameless post mortems, and local rationality.

The talk was very much inspired by Sidney Dekker’s fantastic book The Field Guide to Understanding Human Error. Here’s a short video where he explains Just Culture. There’s also a PDF of an old edition of the book available online.

The rationale and methodology for post mortems at Etsy are explained in Blameless PostMortems and a Just Culture, written by John Allspaw in May 2012.

Daniel Schauenberg, an engineer at Etsy who serves as a post mortem facilitator, wrote up our process in Practical Postmortems at Etsy for InfoQ.

The source code for Morgue, Etsy’s post mortem tracker, is available on GitHub.

This talk was in part based on a post I wrote last year, also entitled Management is not about sorting apples.

Other links:

• The Symantec blog post mentioned in the talk, A Tough Day as Leaders.
• Also mentioned: Summary of the Amazon DynamoDB Service Disruption and Related Impacts in the US-East Region
• Loss of Thrust in Both Engines After Encountering a Flock of Birds and Subsequent Ditching on the Hudson River, the NTSB report on “The Miracle on the Hudson.”

Kellan Elliott-McCrea, the CTO of Etsy for my entire time at the company, writes about the theories under which Etsy’s engineering team, as we know it, was constructed. It has traveled a whole lot further than he could have predicted:

Five years ago, continuous deployment was still a heretical idea. The idea you could do it with over 250 engineers was, to me at least, literally unimaginable.

Etsy has been the validation of many theories that still must seem heretical to many people, and I want to thank Kellan for the part he’s played in formulating them and seeing them tested in production.

If you are a person who is responsible for interviewing engineers, or more importantly, running an interview process for engineers, you should drop everything and read Ann Harter’s discussion of interviews through the lens of research psychology. It’s also useful for people who are the subjects of interviews and are surprised by the way their brains work in interview situations. As an industry we are shockingly bad at evaluating candidates for engineering jobs and the Dunning-Kruger effect is rampant. Let’s get better.

Here in management-land, the New York Times story on workplace culture at Amazon has been the talk of Twitter for the past few days. The story paints an ugly picture of hyper-competitiveness, unreasonable demands, and exploitation that have caused many people to recoil (and some others to applaud).

I’m certain that the article isn’t comprehensive. It probably isn’t even fair. It’s a critique, and should be taken as such. I really liked Ellen Chisa’s explanation of why Amazon and Jeff Bezos should not take it personally.

Update: Ezra Klein’s followup is noteworthy:

But it’s important not to lose sight of a more urgent reality: As bad as white-collar workers may have it at Amazon and elsewhere, their blue-collar brethren have it much, much worse, and have much less power to negotiate better conditions.

I’m sad to see the site This Is My Jam shut down, I found it to be a pretty fun way to share a little music with people you know from Twitter and to be a good source of inspiration for new music to try. In shutting down, they are setting the standard for how social sites should be taken offline in an ideal world. The details:

This Is My Jam will become a read-only time capsule in September. This means you won’t be able to post anymore, but you’ll be able to browse a new archive version of the site. You’ll be able to explore all the people and music that made Jam, and listen to everyone’s jams as Spotify playlists as well. Think of it as the best record collection you’ve ever walked through, like this, curated by some of the best tastemakers we know (aka you!).

You can also export your data or opt out of the archive. Companies shut down all the time, or just retire old features. This Is My Jam is establishing a pattern for how this can be done in a thoughtful way that shows respect for the contributions of users over time.

Why are they shutting down? Here’s a big reason:

But keeping the jams flowing doesn’t just involve our own code; we interoperate with YouTube, SoundCloud, Twitter, Facebook, The Hype Machine, The Echo Nest, Amazon, and more. Over the last year, changes to those services have meant instead of working on Jam features, 100% of our time’s been spent updating years-old code libraries and hacking around deprecations just to keep the lights on.

Unfortunately, everything has to be maintained. Even if you’re not adding new features, there’s work to be done, especially when you’re integrating with third parties. This is why features on sites that aren’t actively maintained get worse over time rather than staying the same. Designs get stale, shared dependencies get upgraded, and things break in subtle ways. Entropy is real. This is no knock on This Is My Jam, it’s a reminder to everyone else in the Web business that ongoing maintenance can’t be avoided, even if a feature or site isn’t under active development.

I’ll miss This Is My Jam, but I’m grateful for their leadership and openness.