Category: Blog

Management and Leadership

The following is the text of a talk I gave internally at Automattic last week. It was part of Simon’s Developing Leadership workshops series. The idea was not to assert static truths. Instead my goal was to sketch out an idea that’s been kicking around in my mind about how management and leadership are, at their core, different mindsets. It’s been a useful framework for me in thinking about things.

What I’m going to talk about today is an idea that’s been kicking around in my head for a few months. I’ve been thinking more about the role of a manager and that of a leader; and I’ve been asking myself whether they’re really the same role at all.

Broadly speaking we tend to use these words interchangeably. Your boss is your manager and that person leads your team. That might work in some companies. For Automattic, though, I think there’s value in distinguishing between the roles. What makes someone a great leader? And how do the mindsets, tools, and habits they employ differ from that of a manager?

I find those interesting questions to dive into given Automattic’s growth and evolution. As we’ve become a larger and more complex organization the distinction between manager and leader is one that has become trickier to navigate. There is both more clarity and more questions around a team lead’s role. Our lead role is also different from many companies; this makes it trickier to grok as we don’t fit into the more traditional mental model. Our leads tackle things that many companies place in other departments.

I’ve talked with leads who ask themselves whether their role is to be a manager, a boss, a leader, a coach, or some combination of all that. My hypothesis is that the success of our distributed nature hinges upon strong leaders, not strong managers.

Let’s first take a half step back. What do I really mean when I say that a manager and a leader are different roles? Let me explain a bit via contrasting examples.

The manager focuses heavily on what tasks need to be done. That focus on tasks ensures that the work is going to get done. The leader sets the vision for Why the work needs to be done. That focus on meaning ensures that the right work is going to get done.

The manager is deferential in waiting for direction. Before acting they expect deference from their team members; you’ll find their team asking, “What should I do next?” The leader takes initiative to seek out the right direction. Before acting they do their homework and investigate different paths; you’ll find the leader asking their team, “For these reasons I think this is the right thing to do next. What are your thoughts?”

The manager is rooted in a mindset of distrust. They are the helicopter parents of a company and constantly worry that if they miss a correction the whole house will fall down. The leader is rooted in a mindset of trust. They understand that success comes not through constant monitoring but through creating the right environment for progress to happen within.

These distinctions will surface again so keep them loosely in mind.

So why is the manager not a great fit for a distributed company? Am I saying that success cannot happen under a manager?

As a distributed company it’s important to remember that, well, we’re distributed. There’s no 9-5 office schedule to keep. A team lead may overlap only a few hours at most with their individual team members. When you work with a manager’s mindset you miss an opportunity for empowerment and you limit the growth of your team members. If, instead, you work with a leader’s mindset you seek to build the right environment for success to happen, and then you get out of the way.

Here’s the danger in a manager’s mindset: it may very well outperform the leader’s in the short run. Their heavy focus on tasks may appear, at first, to be the best decision. The team starts fixing bugs, answering tickets, and incrementally getting things done. All the while, though, they lay the seeds for future pain.

Our distributed nature works best when we also distribute trust, ownership, and the capacity for acting on our best judgement. When every team member understands Why the work needs to be done the team itself will successfully get all the right work done. They’ll minimize false starts, sunk costs, and eventually leave the manager’s team in the dust. A leader outperforms a manager in the long-term; and we’re a long-term focused company.

With all that in mind, here are a few ideas for how you can work as the very best leader you can be. If you, and your team, execute on these things then you don’t need a manager. You can leave that helicopter parent behind.

The core building block to successful leadership is to really own your work. A successful leader takes responsibility not just for their own job but for anything that will impact their team’s work. A leader acknowledges that there are no bad teams, only poor leaders. This means that when things go awry it’s your fault, not your team’s.

Second, think of goals as hinging upon setting the right expectations. It’s not about telling folks what to do next. Successful projects have a rationale for the work that is clearly stated upfront. That rationale is built upon to set realistic milestones for work. And those milestones are clearly communicated so that everyone on the team can sense when things stray off course.

And, finally, when things do stray off course be clear in your correction and gentle in its directional change. Corrections are bound to happen, that’s ok. Remember that mistakes in direction are your fault, not your teams. And the greater the deviation from that direction the more unclear your plans were upfront.

These three principles are important because what we do is knowledge work. There frequently isn’t just one right answer to a question.

Those three pieces above may help you get started. They’re really just starting points, though.

If you’re wondering what habits form the basis of the best leader, I have a couple ideas. These come with the upfront caveat that they’re easier to state than do well. They’re the milestones I personally aim toward but frequently come up short against.

The best leader is one who’s responsible for the team’s performance as a collective unit. They ensure that every team member is aware of the team’s overall performance and what the team’s primary and secondary foci are. The best leader ensures that any Automattician can find clearly communicated updates that reflect on that team’s performance. The goal for the best leader is one of mentorship and development; it’s to build a team into a collection of people that you trust deeply.

The best leader is one who’s responsible for the team’s performance as a collection of individuals. They ensure that every individual is improving in both a measurable and a qualitative sense. The best leader ensures that a significant regression in performance is addressed quickly and that each individual knows how they are performing in their role.

The best leader encourages meaningful communication. They seek to create an environment in which people feel compelled to communicate publicly with the team rather than sit on their answers.

The best leader aims to create the healthiest team environment for successful work. They understand that it’s about providing resources, information, and measurable accountability. The best leader also understands that it’s not on the them to improve a team member’s work, it’s on the team member.

Finally the best leader is also one who asks, “Why?” They ask this of their team, of themselves, and of their lead as well. The best leader doesn’t just accept a course correction they don’t understand. They ask, “Why?” to make sure that they understand the intent. Only by understanding intent can they best relay the direction to their team.

If these ideas sound interesting but you just don’t know where to start here are three questions to ask yourself:

  1. When things go off track, do you say, “My fault.” or do you think it’s the team’s fault? Remember that leadership starts with ownership.
  2. If a team member’s performance regressed, how long would it take you to notice that? To be a strong leader you need a strong and repeatable process for yourself.
  3. Have you asked your team members what, in their words, the expectations you have for them are? What you say and what they hear are not the same things, that’s ok.

If you want to I’d recommend reading this book about the Navy SEALs and this book about company leadership.

A note on feedback

I had an epiphany recently about performance feedback that seems so obvious in hindsight. One of those things you realize and then think, “This took me 6 years to figure out?”

At Automattic a lot of our feedback conversations take the form of a 3-2-1-Oh chat. It’s a mix of a team member writing a self-assessment and a team lead writing a review. The conversation centers around answers to these bullet points:

  • What are 3 things you’ve done well?
  • What are 2 areas or skills you’d like to develop?
  • What’s 1 way your team lead or Automattic itself can support you?
  • And, oh, can you write a sentence or two about how you see your career developing?

I’ve done these conversations with team members for over 3 years. In every instance I approached the 3-2-1 as an exhaustive review of each and every aspect of someone’s work. I tried to solve all the problems in one go. I’d review hundreds of ticket replies, P2 posts, and try to cover an evaluation of everything. It took me until this week to realize that’s an untenable position.

That exhaustive approach was time-intensive and, likely, did each team member a disservice. On my side it took at least 10 hours for each person. On their side it resulted in a deluge of ideas on what they should improve.

If timely and meaningful feedback is your goal then spending 10 hours to put it together is near-impossible. If regular and incremental growth in a person’s work is your goal then an avalanche of ideas for improvement inhibits that.

I now realize that spending a little less time, more regularly, to generate fewer ideas will better serve my team members. It’s better to keep someone on course through a series of small adjustments than through a U-turn. My goal is to have these conversations on a quarterly basis. Trying to improve a host of things about your work in that limited amount of time isn’t realistic. It’s better to narrow your focus and then regularly revisit and adjust goals.

If you’re a team lead tasked with helping people grow and improve, try distilling your feedback down to just 2 ideas. It will add clarity to your own thinking and definition to your team member’s plans.

Support Ops Hangout

I joined Chase, Carolyn, and Jeff on the Support Ops podcast yesterday afternoon. We talked about goals for 2016 and how to make the most of the new year.

With the Happiness team at Automattic we set some OKR-like goals for the second half of 2015 and made a lot more progress than we did in prior times. If that interests you I’d highly recommend this Google Ventures video about OKRs.

The audio version is live as well as the video recording. It was a lot of fun to join the podcast and I think it turned out well.

SupConf

I’ve worked in customer support for almost 9 years. When I started it was just something I enjoyed doing. I liked tinkering with technology and figured, why not use my experience to help others? Pretty quickly I realized I would be very happy if I could find a way to do this for a long, long time. Customer support is my career.

That’s why I’m beyond thrilled to help Scott and others plan SupConf, a conference for folks who want to build a career in support.

I’ve written before about how customer support, when done well, is a career. SupConf is about how to make that happen.

The event is May 23rd and 24th. It’s two full days of well-considered talks that will impart lessons for you to take back to your day-to-day work. Plus, we’re designing the event with conversations and opportunities to meet others in mind. Speakers are important, but they aren’t the whole event.

If that sounds interesting, I’d highly recommend signing up for the newsletter. In the meantime, you can read about some of the themes we’re looking to cover.

It’s time we think about support as more than just an entry-level job. Support is a career, a craft, and something to be proud of.

Customer success

Last week I tweeted about separating customer success/support/service teams. Today I read this comment:

This highlights something that is really important and that is the separation of Customer Success and Customer Support. In most ways, they are not related, they are opposites. Reactive vs. proactive, case-oriented vs. success-oriented, cost-center vs. revenue-driver, etc. It’s one of the reasons that Customer Success won’t (can’t?) work if it’s part of Customer Support.

Opposites? Fuck that.

I try to give people the benefit of the doubt. At a certain point, though, enough instances of something becomes a trend. And the trend I’m seeing in conversations about the customer experience is deeply frustrating.

Too many people who lead “Success” teams seek to define all the valuable pieces of the customer relationship as Theirs. They draw a line in the sand and say, “This is my fiefdom. Back off.” In doing that they push all of the labor and time-intensive aspects of the customer experience onto someone else.

Replying to support tickets becomes not about the opportunity to have meaningful conversations with your customers. It pushes support into a box that’s solely a cost-center, case-oriented, and unconcerned with helping customers successfully use your product. As part of this success-advocates elevate their teams as somehow inherently above and better than those mere peons who handle tickets.

That’s crazy! Even the most reactive, labor-intensive ticket represents an opportunity to earn goodwill with your customers. When you nail that experience you can create a ripple effect across revenue, social media, and the broader marketplace. That is customer support. It’s only an opportunity, though, if you choose to seize it. If you chalk support up as just a cost-center, that’s your loss. Good riddance.

This whole trend of customer success is a tired repetition of customer support as an entry-level-dead-end job that people simply seek to move out of. Customer support, when done well, is a career. Every conversation, whether it’s reactive or proactive, is an opportunity to learn from your customers. That is immensely valuable no matter your departmental definition. Every time you try to isolate certain elements into a single department and declare that proactive support won’t, and cannot, work with customer support you do the broader community harm. Every one of us is in this to help people succeed.

Survey fallacies

Support teams are frequently tasked with figuring out “what the customer wants” with some sort of pre-defined survey. As if a well-constructured set of questions will miraculously fix latent problems in the product.

My two cents: a survey is only worth doing if the product team is willing to devote non-trivial resources to what the survey illustrates as meaningful improvements to make. Without that commitment you’re just wasting everyone’s time.

On certainty in support

People turn to customer support for help, expertise, and reassurance. However, in my experience customer support teams too often respond with uncertainty.

I find a core cause of this to be one particular way of phrasing written replies. It stems from how we try to make replies conversational and relatable. We throw around words like “should” or “looks like” without understanding what they convey to someone confused and frustrated with your product.

In certain cases WordPress.com users have to rely on Happiness Engineers to manually transfer their blog to another account. A couple years ago I found we frequently wrote back to those customers to say, “That blog should now be under your other account.” Should. If you are on the receiving end of that sentence your first question could rightly be, “Well is it?!”

It takes one step and one word change to improve that. First, trust that you did things correctly but verify to be sure. Second, rewrite the above example to, “That blog is now under your other account.” Simple, yes, but a much greater sense of certainty.

In support we are frequently the ones making a change behind the scenes. In some cases we manually fix something vexing the user. In others we let someone know we fixed an earlier bug. In all cases we should be certain in our language. Certainty and expertise is what builds trust.

If you write a support reply and find yourself unsure of something, do the work necessary to be sure everything is working properly. The extra time will build trust with the user by removing doubt. Removing doubt and illustrating that someone can trust you as an expert is one surefire way end up with happier users.

Scaling support teams

A couple weeks ago I was talking with other customer support folks about pain points in quickly growing a customer support team. Our team at Automattic has grown quickly since 2012, when we had around 16 Happiness Engineers. We hired close to 40 support people in 2013 and over 25 in 2014. Our job posting is always up and our only constraint on hiring is the pace at which we can find the best Happiness Engineers.

In talking through that experience with other customer support people I shared a few lessons from Automattic’s growth. These are just things I’ve found to be true about a high growth support team so your mileage may vary.

Maintain your hiring standards

As you grow you desperately need to maintain the hiring standards which formed your team. This is particularly the case if the impetus for growing your team is exploding support volume, management pressure, or a growing user base. With that pressure you become inclined to compromise on hiring standards in order to achieve faster growth. Those borderline candidates who you’d reject 6 months ago you’ll now think of as, “But we could train them…” While that may be the case every borderline candidate you hire ultimately slows down the team while they wait to catch up. Our hiring motto at Automattic is that a “Maybe” is a “No.”

The 6-month speed bump

When you hire a lot of people over a short span of time you also create a lurking iceberg of expectations. New jobs come with a honeymoon-like period. A new hire clearly wanted to join your company, else why would they have applied, and now that they’ve been hired everything smells like roses…for a while. If you hired 6 people in April that also means you’ll have 6 people coming out of that honeymoon period come the fall. Compound that by hiring 6 people a month for 6 months and, boy, is that iceberg massive! Be aware of this. It’s not to discount valid critiques from those team members, but it does need to be taken in to account. Sometimes this week’s fire is merely 6 people simultaneously hitting a given point in learning what works, over the long run, for their productivity.

Here’s one way that collective 6-month speed bump plays out. When people join their first distributed company they love the seemingly boundless freedom. They love their work, love working from home, love the schedule flexibility and dive in whole hog. Pretty soon, though, they realize that they’ve lost all discipline in setting work aside. They find they let pings interrupt them at all hours. They find themselves working 60-hour weeks. They find that they have no quiet time. When you have many people simultaneously hitting this inflection point it can be expressed as an issue with company expectations or with the team itself. You have to take a step back, though, and realize that this is a growth process everyone goes through. You have to help each person realize that, in part, the problem is one of individual expectations, workflows, and discipline. If instead you restructure the entire team in response to this pain point you ultimately withhold from people a learning experience that helps them build sustainable and healthy individual remote work habits.

Teach systems, not information

If your training focuses on simply teaching the information necessary to do the role then you’re creating a burden of technical support debt you’ll eventually need to repay. The most common way I’ve seen this come up in support teams is new hires consistently asking for a list of who owns what features across product teams. If you’re a small, agile, or continual deployment-driven company this type of list is a wild goose chase of sunk costs. The effort required in maintaining that list is crazy, particularly if your product is fairly involved. Instead, focus on teaching new hires the systems they need to learn in order to discover for themselves who owns what feature. How can they leverage the source code repository? How can they lean on the bug tracker? Do they simply need reassurance that it’s ok to ask? When that systemic knowledge becomes second nature then it frankly doesn’t matter how fast the development side of your company is moving. Your support team will be able to keep up and keep pace with where to report bugs, suggest improvements, and ask for help.

Be wary of past experience

This is similar to being mindful of the honeymoon period. Part of why you’ve hired this team is the strength of their past experiences. However, when people start out they see pain points at your company which were solved problems at their past job. While a fresh perspective is valuable, be wary of someone’s desire to solve an issue using the same process their past job did. Your company is your company. It’s not the same marketplace, culture, tools, people, systems, users, or challenges as any other company. Ultimately you want to be wary of new hire-driven solutions which seek to merely transpose past solutions on to new problems.

Thanks to Erica and Simon for helping me edit and compose these ideas.

Verizon Live Chat

I shared this on Twitter earlier but wanted to log visually here. Verizon’s live chat support has three shockingly poor things wrong with it.

The text is large, blue, and Comic Sans.

The text is large, blue, and Comic Sans.

The form is broken in Safari as you get this big bar over the text field.

The form is broken in Safari as you get this big bar over the text field.

The tab title is "Engagement Window." Eww.

The tab title is “Engagement Window.” Eww.

I reported each issue to them, of course. Unfortunately they said, “we do have issues with the Safari browser” and suggested I use Internet Explorer.

People will read

Last July Ryan Pitts and Sara Schnadt led a session at SRCCON about human-driven design. It wrapped up with a discussion of various maxims that guide design processes. Someone in the room said it was important to remember that, “users won’t read, ever.” That rubbed me the wrong way at the time and I went on a mini-rant in the session. I was thinking back to this recently and wanted to sketch the idea out into a longer post.

The perception that people don’t, and won’t, read documentation is not uncommon. There’s a reason we have the acronym RTFM after all. I think it’s a perception that’s horribly misguided and short-sighted for your product.

People will read. What they won’t do is unquestioningly read on your terms.

Treat docs as product

When you’re developing a product you don’t ship something and passively wait around for it to become popular. If what you shipped isn’t gaining traction you iterate. You tweak and adjust until your product fits its addressable market.

For some reason we don’t approach documentation with the same mindset. Our predominant expectation is that we can ship docs and expect every person to read them. If the docs have up-to-date screenshots, are detailed, and are searchable then that’s enough. If people don’t read, that’s their fault not yours. That’s a fundamentally broken expectation.

Most importantly, if you react to support requests by wondering why people can’t read the docs then you are missing a golden opportunity. You are directly blaming the person using your product instead of blaming your product for requiring documentation in the first place.

Exploratory & Prompt-Driven Users

Part of the RTFM-mindset stems from an assumption that everyone is an exploratory learner. That’s wrong. It’s arguably true for many tech folks. That doesn’t make it true for many people using our products.

Exploratory people will find their own way. They are comfortable with uncertainty. They’ll use a confusing product and feel confident relying upon documentation for answers. To them this is part of the appeal. Each awkward setting or obtuse workflow is an opportunity to master the intricacies of yet another product.

Prompt-driven people will read docs, but it’s not their default. They will first look to your support team for help. You could also think of them as human-reliant people. Interactions with your support team may prompt them to read and reference docs. So it’s not that they won’t read. It’s more that they prefer human interactions to help guide them.

Here’s the thing about prompt-driven people: they are a potential gold mine of qualitative feedback. There is no better source of information to help guide your product teams. Yes, this means your support team has more tickets to respond to in the short-term. That’s a great thing.

Every one of those interactions is an opportunity to learn more about how people use your product. If you choose not to take advantage of that and instead blame people for not reading your docs and leaving you alone in your cave, then that’s your loss. The next time you find yourself blaming a customer for overlooking the “obvious” answer in your docs, ask yourself whether you’re reading enough of what they’re telling you. More often than not I think it’s those building a product that don’t read, not our customers.

Thanks to Simon for helping clarify some of the wording in this post.