In 2013, I wrote a post on how continuous deployment helps developers avoid getting stuck. Figuring out that you’re stuck and how to get unstuck is probably the single most important thing you can do as a developer to improve your own productivity.

Friend of the blog Camille Fournier just published a post on the same topic that I really enjoyed – How Do Individual Contributors Get Stuck? A Primer – in which she lists some common ways people get stuck. I have gotten stuck in all these ways at one time or another. She also observes that helping people understand how and when they get stuck is one of the most useful forms of feedback you can give.

What I’d add is that this ability falls under the general category of coaching. Anyone who would aspire to be a good leader (as a manager or individual contributor) would benefit from building theirt coaching skills. Coaching is more than just helping people, and it isn’t applicable to every problem. When somebody is stuck and they’re super stressed because they are on deadline, it’s probably not a great time for coaching. Just get them unstuck and save the coaching for a more appropriate time.

What individual coaching is about is teaching people how to instill the habits or instincts that enable them to improve their own performance. In sports, an individual coach observes someone’s performance, identifies ways that performance can improve, and then gives the person the mental cues needed to improve their performance in the future. The main thing about coaching is that a coach can’t help when the skill is being applied, they can only help prepare the person they’re coaching for next time.

One tricky aspect of coaching is that unless you are, in fact, a coach, your job is always more than coaching. Maybe you’re a manager, or a tech lead on a project. You have your own goals and deliverables, and it can be really easy to forget to incorporate coaching other people into your job. In fact, spending time on coaching is usually not the fastest way to get things done in the short term. It’s a lot easier to just tell people who are struggling what to do.

However, if your goal is to build a strong team for the long term, coaching is essential. If you care about the personal development of the people on your team, coaching is also essential. The beautiful thing about coaching is that it’s what enables you to help develop people so that they’re ultimately better at their job than you could ever be. Track world record holder Usain Bolt runs faster than any human alive, and coaches who could never hope to run that fast helped get him there. I’ve had the privilege of helping people whose skills vastly eclipse my own through coaching.

How do you get better at coaching? First and foremost, you have to hone your powers of observation. You can’t be a good coach unless you evaluate people’s performance effectively through observation. Great coaches notice things that are imperceptible to regular people. From there, you have to find people willing to be coached by you. Finally, you have to take an experimental approach. The most important part of coaching is giving people feedback in a way that they can apply when they need it. Many times you have to deliver the same message in many different ways before people can turn it into a cue that works for them.

Finally, I’d add that one of the best way to get better at coaching is to be coached by a good coach yourself. It doesn’t have to be coaching for your job, you can learn a lot from being coached by a fitness trainer, a music teacher, or a cooking instructor. Getting better at coaching is worth the effort, nobody ever forgets a great coach.

I’m here to write about an incredibly annoying op-ed that I saw in the New York Times entitled Sorry, Liberals. Bigotry Didn’t Elect Donald Trump. by David Paul Kuhn. In it, Kuhn breaks down the poll numbers to take down what I see as a straw man — the purported argument made by liberals that people voted for Donald Trump because he is a bigot. I suppose some people think that, but that’s not an argument that needs rebuttal.

Kuhn’s argument is, for all intents and purposes, the argument made by everyone who attempts to vindicate Trump voters, which is that they are economically disadvantaged and they voted for the person who promised change (the reasons why none of those promises will be kept should be obvious to anybody actually paying attention). Here’s the crux:

By 2016, Mr. Trump personified the vote against the status quo, one still not working out for them. A post-campaign study comparing the George W. Bush coalition in 2000 to the Trump coalition in 2016 found that Mr. Trump particularly improved in areas hurt most by competition from Chinese imports, from the bygone brick and tile industry of Mason City, Iowa, to the flagging furniture plants of Hickory, N.C. The study concluded that, had the import competition from China been half as large, Mrs. Clinton would have won key swing states and the presidency with them.

And here’s his description of how Trump is regarded by those who did vote for him:

Bluntly put, much of the white working class decided that Mr. Trump could be a jerk. Absent any other champion, they supported the jerk they thought was more on their side — that is, on the issues that most concerned them.

I agree with that! But here’s the thing. Kuhn just described what bigotry is! People didn’t vote for Trump to vote in favor of bigotry — they voted for him because his bigotry didn’t seem like it would harm them. They felt like they could afford to vote for Trump because they don’t really listen to or care about people who aren’t white or aren’t straight.

I would also make the argument that everything about Trump’s campaign signalled that his administration would maintain and even expand white privilege as a force in America. Trump himself is the personfication of white privilege — he’s a rich white guy who set out every day to show that he didn’t care about the norms established for Presidential candidates. He made it perfectly clear that the ethical standards applied to past candidates were irrelevant to him. He doesn’t think it is important for one prove they are qualified to hold a job in order to get it. If black people have to be twice as good to be recognized as successful at work, Donald Trump is living proof that there is no floor on how bad you can be as long as you can speak in bro code in a way that appeals to white people.

So yeah, white people don’t tell pollsters that holding on to white privilege (and male privilege) was a key issue for them in 2016. That is, however, what they told us when they went to the voting booth. It’s not that they saw Trump’s flaws as strengths, it’s that they felt safe ignoring them.

I’ve started publishing a newsletter, which is not unlike a blog except that I send it out via email. I’m still trying to come up with the best strategy for publishing the things I’m writing in the newsletter to the blog, but I haven’t gotten there yet. In the meantime, you can subscribe to the newsletter at TinyLetter. There’s an archive as well.

I’ve been watching the Brexit debate in the UK with interest for months, but I never really believed the British public would vote Leave when it came down to it. I thought it would turn out like the Scottish independence referendum, and that in the end people would not vote for total chaos. Obviously, I was wrong. Here are some links to articles that make the most sense to me.

The Telegraph correspondent in Brussels provides the EU perspective, and it’s not encouraging. Britain may be having second thoughts, but it seems like the EU is eager to see this through, if only to warn other countries with right-wing populist movements who might think of separating.

Kenneth Rogoff argues that a simple majority vote was too low a bar for such a huge decision, which clearly seems to be the case at this point.

Glenn Greenwald takes this opportunity to look at the conditions that lead to people voting in favor of Brexit (or supporting Donald Trump) in the first place. It’s important for everyone to understand that voter frustration is real and in large part, legitimate. It’s being channeled into nationalism and racism in an incredibly toxic way, but those impulses are being fed by a global system that has proven disastrous for large chunks of what we used to think of as the middle class. If global institutions can’t offer voters a better deal, these kinds of votes are only going to become more common.

In the meantime, the pro-Leave politicians are already backpedaling on the promised benefits of exiting the EU.

Some years ago, one-on-ones went from being an oddity to the keystone of progressive management. I’ll give credit to Michael Lopp, who wrote about them back in 2010. I’ve had (literally) thousands of one-on-ones at this point, and I can’t imagine a world in which they aren’t the backbone of an engaged professional relationship.

This week, though, I learned of yet another reason why they’re really important. I was talking to a developer who left a job because they were frustrated with how their manager assigned work. It seemed like the friends of the boss got all the good assignments, and everybody else got the scraps. People who don’t trust their managers don’t stick around, and a manager who plays favorites isn’t going to maintain the trust of the people who report to them. Anyway, I asked this person whether they had one-on-ones with their manager and I wasn’t surprised to hear that the answer was no.

Obviously, one-on-ones would have provided a venue for this person to ask about the manager’s strategy for assigning work, but what I realized is that the lack of one-on-ones created an environment where bias thrived. One-on-ones insure that everybody gets regular face time with their manager. This is obviously true, but I think its importance is largely unrecognized.

A manager who doesn’t have one-on-ones is going to spend all their time talking to the people they already have the best relationships with, and those people will inevitably receive more mentorship and more sponsorship over time. Often, this will be based not on performance but rather on shared interests outside of work, a similar sense of humor, or (ahem) demographic similarity.

Scheduled one-on-ones are an important means of preventing this pernicious means of unfairness creeping into the workplace. Managers are people just like anyone else, and they’re going to gravitate toward some people more than others. Putting measures in place to hedge against the problematic aspects of human nature is a big part of a manager’s job.

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.”