One more reason to have one-on-ones
0

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
0

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
0

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?
0

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?
0

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
1

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
0

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
1

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.

Critiquing Amazon’s corporate culture
0

Critiquing Amazon’s corporate culture

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.

APIs and accountability
0

APIs and accountability

I love Twitter, but I’ve been unhappy with the company since they made the decision to stop supporting third party clients that compete with their own native clients. There are still some good ones available, but Twitter has actively discouraged the development of new clients by not adding third party API support for many new features, and by limiting the supply of API keys to client developers.

In the meantime, Twitter has let the native OS X Twitter application languish. Here’s Jason Snell:

If Twitter doesn’t have the resources or inclination to properly support platforms like the Mac (or, quite frankly, iOS and Android), perhaps it should rethink the decisions made by the prior regime and find a way to let other developers apply their expertise to the problem. Alternately, maybe Twitter should figure out how to use its huge team of app developers to create first-class native apps for not just iOS and Android, but the Mac and Windows too.

It’s not a coincidence that Twitter’s updates to its OS X slowed when they decided to cut off third-party clients. The third-party client market provided two things Twitter desperately needs, competition and free research and development. When the Twitter client market was healthy, there were dozens of development teams coming up with cool new Twitter features that the company could roll into its platform. Many of the features that are core to Twitter now originated in the Twitter community.

A fully functional API that third parties can use imposes a sort of accountability on a company’s engineering team. Giving users a choice of clients or tools demands that the product team at Twitter builds applications that can succeed on their own merits. Competing with third-parties on their own platform is the sort of exercise Twitter needs to stay in shape for the bigger fight with Facebook, Instagram, and whatever else comes along in the future. Killing off that competition has enabled Twitter to be lazy and complacent.

A counterargument one might make is that supporting a full-featured API for third parties is expensive, but I’m not sure that’s the case. Twitter already has, in addition to its Web site, iOS and Android apps, and an OS X app as well. What this means is that Twitter already provides private APIs for all its features that support multiple independent client implementations. In other words, the hard work is already done. Given Twitter’s size, chances are they’ve already put a lot of thought into API usability and written decent documentation for these APIs as well.

The risks of providing robust APIs are minimal. A relatively small number of users are going to seek out and install third-party applications even if they are great. The tangible and intangible benefits are large. Twitter needs to get back into being a platform provider for its own sake.