rc3.org

Strong opinions, weakly held

Category: Commentary (page 1 of 982)

Newsletter

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.

Brexit links

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.

One more reason to have one-on-ones

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.

Thinking about Radical Candor

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.

Fighting for the Web we should have

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.

Answering the question: should managers code?

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.

What’s up with the blog?

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.

Further reading on just culture and blameless post mortems

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 theoretical underpinnings of Etsy

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.

Better interviewing through psychology

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.

Older posts

© 2016 rc3.org

Theme by Anders NorenUp ↑