Three Important Things

Congratulations! You are in a new management role. Now what?

Remember these three things: don’t fall into the safety of your old job, listen, and provide useful feedback.

These are the three most important insights I gained from working as an Engineering Team Lead at Automattic.

Don’t Fall into the Safety of your Old Job

Stepping into a new role, like managing people or projects, requires different skills than the ones that made you shine as an individual contributor. Recognizing that can be difficult.

It may be very tempting to keep on working on what made you successful earlier. Maybe you want to keep doing individual contributor work, like coding that really impactful, but difficult, feature. When you notice this happening, take a moment to pause. You’re in a different role now! Your biggest responsibility is providing clarity and direction to the team, communicating in all directions, and helping foster personal development.

Taking on both the responsibilities of an individual contributor and leader is unreasonable and unmaintainable. Not letting go of that role is an unintentional signal that you don’t trust the team. It also deprives people of opportunities for them to grow or to really excel at their craft (they may do a better job of it than you and that’s fantastic). The book Multipliers, has an excellent analogy for this. Imagine a coach that gets frustrated with how the game is going, and instead of coaching the team on their next strategy, runs onto the field to score that winning goal themselves. Just think of what the team would feel in addition to the crowd.

That isn’t to say that you never should code or design. I find that it is often the least impactful or important thing you can do to help the team. It’s still useful to keep in touch with your prior skills to understand what needs to happen to be a great individual contributor, but it’s not your number one priority anymore. I still personally code-review and code, but this comes last after all my other responsibilities. If I do take on coding it’s often something small that I know I can complete with my fragmented time or I pair with someone who can still own that larger feature.

As a team lead, you’re still part of the team, you’re just in a different role. It can be lonely at times. There can be very little actionable feedback on how well you’re doing, both good and bad. Rest assured the role you’re playing is just as important as everyone else’s position. It’s natural to fall back into these habits of doing things yourself. But when you notice, gently correct yourself and ask: “Is this where I’m needed most?”

Listen and Take Action

A key skill that is important but difficult to master is listening. Knowing when to take action from that listening will make you super effective.

I will be talking about this with the caveat that I’m still working very hard to listen better and more thoughtfully. One of my biggest fears is that I will mismanage people. I think one of the best ways of avoiding this situation is by listening.

So what do I mean by listening? It’s when I can give the space for people on the team to speak, building safety so they can voice their feelings and thoughts, and to do it on a consistent basis to help build our personal relationships and trust together as a team.

Every team is different, and every team will face different problems, but it never hurts to listen, and to listen on a consistent interval.

Listening is often formalized in the form of processes. It gives us some structure to learn how to listen and hopefully take some constructive action from that.

I’ve found Retrospectives and 1:1s to be both simple in format and useful. Sometimes when implemented poorly people find that these exercises are a waste of time. When used correctly they will help you listen to the people on your team, and will help to clarify what next steps are most impactful for both you and the team to act on.

In the next sections I’ll explain each exercise in more detail.

Retrospectives

What is a retrospective? It’s a regular meeting held to discuss three things in a structured way:

  • What worked well for us?
  • What could have gone better?
  • What actions can we take to improve this going forward?

That’s it! This meeting is all about lessons learned and trying to improve process so we can repeat what worked, and try to change the things didn’t in a completely blameless and constructive way.

The key idea here is to start a virtuous cycle where:

  • We build trust so people on the team can truly say what they think and what we probably need to change
  • We take action on that feedback
  • We do this consistently, to show that we care, and to create great outcomes for the team.

Before your team adopts retrospectives as a practice, make sure people are committed to trying to listen and that your team has the agency to take some action.

What Retrospectives May Uncover

Retrospectives have a lot of benefits and will sometimes uncover insights of surprising depth. This may include:

  • Reflections on team dynamics.
  • Daily work done well, or small things that we can all celebrate together.
  • Reality checks of how well a project is running and if we’re working on the right things.
  • How the team is really feeling.
  • Systemic issues beyond what the team can solve alone.

What Can Go Wrong in Retrospectives

Sometimes, it feels like process is a waste of time, because it is. Retrospectives can fail to be useful in a number ways:

  • People interrupt others, or don’t let each person have an opportunity to share. The loudest voice is heard above the others.
  • People don’t feel safe to share their actual thoughts and feelings. There is not enough trust with the people involved, or trust that anything will change.
  • People never follow through on action items for any number of reasons. Maybe the action item is not actionable. Maybe no one was held accountable for it. Maybe it cannot be solved solely by the team and we cannot see a first step.
  • Action is only taken on the easy items but nothing is never done on the hard problems.
  • Tangentially arbitrary work is added as an action item that has little relation to what was discussed.

So in some cases, people may go through the motions, still feel unheard, and no change takes place. We aren’t committed to listening and taking action on it.

The Retrospective Prompt

The format I use is simple, but can be experimented with and modified. If you search for “Retrospectives” you will find other prompts on the internet that may be more suitable for you to start with and iterate on.

It’s really important to note that this entire exercise should be driven by the team, and that everyone has a safe space to share their thoughts and feelings. Yes, even Engineers have a lot of feelings because they are human. My alternative name for this exercise on Engineering teams is Engineering Feelings.

We should also remember to celebrate anything that is working well, in addition to recognizing when things are not. Some retrospectives might be gloomy if the team is facing a difficult challenge. In another week the team might be enthusiastically happy and we may have trouble finding action items.

For retrospectives to work, it is vital to do them on a consistent basis. This gives us a window of time to reflect and act on items. If the time period is too great, I find that two things happen: people don’t remember what actually happened, and action items are not accountable since the next meeting is so far away. My team holds a retrospective every two weeks because that cadence works for us.

Give Everyone 5 Minutes to Write Down Thoughts

Separately let folks write down their thoughts for five minutes (on physical or virtual stickies) with the above prompt for the time interval specified. It’s best if people can’t see what others are writing.

Everyone Shares Their Stickies

Once the stickies are ready, the team shares their thoughts verbally, one by one. People will often expand on what they mean instead of reading the note verbatim. When a person is done reading notes, the next person should start. In my case I usually just call on someone to share next, but other methods should work too.

Resist the temptation to immediately dive into a conversation on how to improve things. We’ll have the opportunity to do so after everyone has shared.

Group Similar Stickies

Group similar stickies together into common categories or themes. It’s okay if everything doesn’t fit. If you have a number of people, vote on the themes you’d like to discuss most.

Go Over Old Action Items From Last Retrospective

Before diving into each category, go over action items from the last meeting. Were they acted on? If not the old action items are automatically added to this retrospective’s notes too. If things keep getting kicked to the next meeting, assign it a higher priority to finish it, or revisit to determine if it’s still necessary.

Discuss Each Category in Detail and Create Action Items

The team can now chat about each category and brainstorm ideas of how to improve trouble spots, or celebrate wins together. If people notice that a note is more of a feeling, dig down into why they feel that way. We may still be able to create an action item out of it!

An action item should be relevant and small enough for a person to accomplish in your retrospective time period. Assign a specific person to a task, so it has a higher chance of being done.

Tasks might range from, “Let’s use a different label on issues we file” to “I need to refine and deliver feedback that the project is going sideways and why”.

Publish Meeting Notes

Regardless of whether you have a physical office, or are completely remote, having some artifact of what themes were discussed and action items were created is a must. We can’t see our progress as a team, if we don’t document it!

1:1s

One on ones are a formalized way of making sure you talk with each person on your team in a private meeting. Depending on the size of the team this may be weekly, or every two weeks.

What you talk about with each person during this time is entirely up to the participants, but may span a number of subjects, from a check-in of how each person is doing to clarification of company goals or helping spot opportunities for personal growth. Less often, it can also act as a safe space for people to feel heard during difficult moments. Sometimes active listening is all you need to do, without needing to have anything change or be “solved”.

Like with any relationship you build with another person, it takes time, and some of the early sessions may feel awkward, entirely casual (totally okay), or way too in the weeds as you get to know each other.

It’s really helpful to let team members come up with points they want to discuss first. It might even be rare feedback for you which is important to hear and act on. This time is for them! Listen before moving onto your own agenda, like feedback or personal growth, though don’t hesitate to move on if they are dominating the entire meeting.

It is useful to keep shared notes with your reports that outline briefly what was said and any action items created (for you or your report). This shared document acts similarly to the written meeting notes in retrospectives. It will help spot themes or repeated conversations, and add accountability to making sure action items are completed before the next 1:1 meeting.

Like Retrospectives, 1:1s are simply a tool to help listen and to maybe act on what is being said.

Providing Useful Feedback

One of your new responsibilities will be letting others know how they’re doing, why that’s so, and shining light on their strengths or areas where they can improve.

It’s unkind to leave people without this feedback, especially if you’re holding onto constructive feedback, because you’re scared that you won’t be liked, or that you’re personally friends. Similarly, if you focus all your time on folks who are having more trouble, this isn’t fair to the people doing well who could use guidance on how they can grow even faster.

Providing useful feedback is a lot of work, but it is very necessary work to help people grow.

Delivering any feedback, both good and bad, is its own subject and skill to master. There are entire books written on how to listen, craft, and deliver feedback well. I would highly recommending reading a few. After you do this, note that you can read and understand the theory but applying this on the spot, in the heat of the moment, is extremely difficult. I am very much a novice at this. Very briefly, here are a few things I wanted to highlight:

  • Great feedback comes from a place of care. You are taking the time and effort to craft this feedback to help someone improve their behavior and succeed, or are highlighting what they are doing great so they can better understand themselves and maybe even build on their strengths.
  • Giving positive feedback requires as much care as constructive feedback. People need to understand what they’re doing well, in what specific instances and why. They won’t be able to apply this feedback otherwise. In a lot of cases the compliment may even feel insincere. “Keep doing what you’re doing!” Is not helpful. Keep doing what?
  • Constructive feedback is best delivered privately and as timely as possible to the situation you noticed. Be careful to avoid value statements. It isn’t a quality of the person that needs to change say “John Doe is a mean person.” It’s trying to highlight a person’s behavior in a specific instance, explaining the impact that it had on others, and what behavior would be more appropriate in a similar situation, or opening a conversation on what that might look like.
  • Constructive feedback is always difficult to hear and to deliver, so take care that the listener is in a good space to try and listen, and that you are ready to try and deliver that feedback.
  • Despite your best intentions, the burden is on you to deliver feedback in a way that is both respectful and can be understood by the listener. It is very easy to get this wrong and hurt people unintentionally.

Listening To Feedback

In some cases people will be giving you feedback. Feedback given to you is a rare gift, but oftentimes, really listening and understanding that constructive feedback can be difficult.

Many people find that the body enters a fight-or-flight mode. Try and notice what you’re feeling. Do you maybe deflect and become defensive? Do you freeze and are unable to hear the rest of the message? Maybe you just feel bad about it, and miss what is being said that is supposed to help. This is something to keep in mind when you write feedback for others, it can be really difficult to hear what is being said.

More often than not, the feedback you receive may not be well-crafted. It may lack specifics, be a value statement, or you may not even agree with the points being said. Instead of dismissing this, maybe take some time to understand what the person really means by it. After all, the easier move is to say nothing if they didn’t care about you. With more conversations, you may be able to find that step of personal growth for yourself.

Coda

So, as a new manager, remember these three things: don’t fall into the safety of your old job, listen, and provide useful feedback.

Don’t fall into the safety of your old job. As a manager your role isn’t the same as an individual contributor and relies on different skills. The team needs you to provide direction and clarity. Don’t be the coach that runs onto the field!

Listening is a powerful tool. Over time, team trust and cohesion may be earned by listening well and sometimes taking appropriate action from that listening. Retrospectives and 1:1s are simply tools to help make this happen.

Useful feedback will help accelerate the growth of each team member. Individuals will better understand their strengths, areas of improvement, why that is, and what they could try instead.

Code Reviews 📚

The following is a collection of my thoughts about what makes a good code review. This is a repost from the internal Calypso blog with a few modifications made from feedback. I have also included a few tips to structure PRs in a reviewer friendly way. It’s my hope that this post will help encourage folks to get excited about code reviews.

Frame of Mind

At the start of my career, I didn’t understand why good code reviews were helpful. This was partly because I hadn’t seen a good code review yet. At best someone might have rubber stamped my change, and at worst code gatekeepers nitpicked irrelevant details in the patch leaving both parties in a foul mood.

My thoughts on reviewing changed drastically once I realized I was approaching this with the wrong frame of mind. We are rewarded by what effort we put into it, and as part of that participants must share some common understandings to avoid an unproductive review.

At Automattic, I think we already have a very strong reviewing culture. The following are a few points I personally remind myself, before starting a review.

We all share ownership of the code. It is not yours, or mine, it’s ours. Always welcome improvements and share knowledge freely.

Many programing decisions are opinions. There is often no one right answer. Discuss tradeoffs in a productive way and move on quickly. Stick with project convention for stylistic things like tabs vs spaces, even if you don’t agree with it. Changing convention can be done outside of the PR as a larger discussion with the group.

We can always learn new things. No matter how much one knows, we can always learn more. Folks can expose you to new ideas. Explaining concepts you’re familiar with can help improve your understanding of it.

Communicating

Another huge part of a successful code review is good communication. We’re all nice folks at Automattic, but text communication is tricky. It is very easy to misinterpret feedback about code as something more personal. I think we’ve done a very good job at avoiding this, but here are a few techniques to lesson confusion.

  • Avoid separating code ownership. Do not assign ownership of the code with words like “my code” or “your code”. Doing so makes code reviews feel more like a personal judgement. We all share ownership of the code. Remember that the code is also a product of many constraints (time, familiarity with the codebase, etc.) and is not a personal reflection about the author. Even the best developers will produce code from time to time that has some issues to work through.
  • Assume best intent, stay positive. Avoid sarcasm and negative descriptors like “terrible” or “dumb” that may be misread.
  • Avoid demands, offer suggestions instead. “What about moving this into it’s own file?” It’s also helpful to phrase these as questions. Often times the reviewer may be missing context on why a particular suggestion will not work.
  • Authors should respond to suggestions. “Great catch! Updated in 565acae.” “We went ahead with the original approach because of timing concerns.”
  • Be explicit. “Let’s do change X because of reason Y”
  • Say if something is a blocker or optional. “Due to security concerns we should update this method before shipping.” “This is optional but I think this reads better if we move this into it’s own method.”
  • If something is confusing, ask. “What is the reasoning behind these changes?”  “I don’t understand what’s happening on this line, could you please explain?
  • Let the author know when you appreciate a change. “Thanks for taking on this task!” “I really ❤️ how this new workflow feels, I left a few notes on some things we can improve.” “This PR drops our build size by 500kb! Great work!”
  • Explain next steps, or complete the review. “I noted a few blockers I’d like to see resolved before we 🚢” “Changes here look great. 🚢 when you’re ready.”
  • Keep up momentum. If a PR looks stalled ask if anything needs to be done. This is especially important for OSS contributors. It is usually better to accept a PR that has a few issues left to work through, and fix it up later, than have the OSS person abandon the PR.

Preparing your PR to be Reviewed

If folks are always waiting for a code review it helps to have some empathy for the reviewer too!

  • Explain why. Assume reviewers have little or no context when reading the PR. Explain why we need this PR and what it does. (This is also very useful when looking at past decisions). Screenshots and gifs are appreciated when behavior is complex.
  • Add Step-By-Step Test Instructions. Can someone unfamiliar with the changes test your PR by reading the summary?
  • Keep changes small. Large changes are difficult to review and understand. Try to separate janitorial changes from PRs that change behavior.
  • Note weird things. This includes explaining any odd code workarounds, or buggy behavior. This can save some back and forth between the reviewer and author, and may also expose existing bugs.

Code Review Benefits

When done well, code reviews can help on many different levels.

  • It spreads code ownership.
  • Communicates changes across teams.
  • Serves as a sanity check to verify that requirements make sense.
  • Allows folks to find bugs though both manual testing and in code.
  • Lets all folks involved learn new things!
  • Can also serve as documentation for how something worked, and why certain decisions were made. Perhaps even for a future you!

Anyone can be a Reviewer!

The fact that code reviews work on many levels also means that reviewers don’t need to know all things about a project in order to make a meaningful contribution. Sharpening copy, manually testing, polishing design, or asking questions about confusing things is a great help.

Code Review Challenge

If this isn’t a habit for you yet, I’ll like to challenge you to try reviewing a few PRs from a different team or one that you may have felt intimidated to contribute to.

Here are a few strategies I use to pick PRs to review:

  1. Take a look at one of the oldest PRs on the needs review list. Ping the author with questions if it looks inactive.
  2. If you don’t have a lot of time, choose a tiny PR to look at. These are the fastest to review and test, and usually have the least risk of causing a regression.
  3. Choose something you’re unfamiliar with. Reviewing PRs is a great way to learn, and to keep a pulse of what’s happening on other teams. Don’t be afraid to dive into a section you’ve never looked at before. If you don’t follow, or something is unclear, ask questions! The PR author is usually happy to explain.

Have fun reviewing!

Some Self-Improvement

I’ve been making a point to take better care of myself recently. This includes cutting out caffeine, being consistent with exercise in the morning, and completely unplugging from work stuff in the evenings. It’s definitely helped a lot with my mood, and I think I can handle more stressful situations without it sticking around for too long like an unwelcome gremlin in my head.

Coffee

One of the changes I made was around caffeine. I love coffee ☕️. I do. However, I found that the caffeine messes up my sleep schedule. Even worse, when I happened to be stressed out, it would amplify whatever anxiety I was feeling. I ended up cutting out coffee and replacing it with a placebo hot water or tea. Coffee was a habit I picked up when I started working. It was a social thing, really. It wasn’t too difficult to quit, the caffeine headache lasted for about a day or so, but I found that I still enjoy the ritual of drinking something hot right at the start of my day.

Jogging

As a person who works from home and has a zero commute time, there’s basically no excuse for me not to exercise. To cement this point in my head, I also purchased a treadmill, so in the off chance that it does rain or is too cold, I still need to move my butt.

cat-treadmill.gif

My normal workout of choice is a 3 mile jog. I say jog because I run like a sloth, but even if I’m terrible at it, I find that it helps clear my mind. You might say that it’s almost a meditative experience. For me, it requires a constant re-focusing of being in the now. If I let myself daydream while running, I will trip on something embarrassing like a tiny crack in the pavement.

I can, and have trained for longer races. I tricked myself into jogging a half-marathon twice (on my birthdays no less) but those sort of distances tend to show the grosser side of running. The black toenails, fluids everywhere, and other general carnage that your body tries to tell you about. Three miles though is a nice reasonable distance you can force yourself to do, without getting too disgusting. If you’re someone who never gets runner’s high, it’ll still feel great when you stop.

Unplug

Provided that there aren’t any real 🔥 🔥 🔥s at work I really do recommend unplugging at the end of the day. Some of my favorite ways to unwind are watching terrible tv shows before my SO comes back, catching up on the video game backlog, or having a nice dinner in the city. While I already had a do-not-disturb mode set on my phone, it really helped to make sure I had some solid hours of not-work time before bed.

unplug.gif

Of course, this isn’t to say that I don’t have any vices left. You can’t take away my wine 🍷.

wine.gif

Feels like Spring

It’s been raining so much this winter that it wasn’t uncommon to spot the odd heron hunting in the temporary puddles in front of my house. A very strange break from the drought, but not unwelcome at all.

All the cold and the rain was perfect germination weather for a lazy gardener like me. It made it rather easy for the garden to sprout from seed directly in the bed. After planting I almost did nothing afterwards, since it was raining so frequently.

Now that it’s warming up, everything is blooming, which makes coding outside very tempting.

Work and other things

I work for Automattic a completely 100% distributed company with employees from all around the world. Once a year we hold the Grand Meetup, a frenetic week long event where the whole company flies in to blanket an unsuspecting off-season ski resort with our own wifi and friendly Automatticians.

It’s a crazy-fun experience, and one of the rare chances we get to see the folks we work with in person.

team

My awesome team

 

While at the meetup, I got a lot of enthusiastic thanks from folks for helping out on reviewing their pull requests. It was extremely flattering, but I also had the nagging thought of “Is it so unusual for cross-team reviews to happen?”

So Many Pull Requests

stack.gif

To give some more context, I primarily work on Calypso, an open source dashboard for reading, writing, and managing all of your WordPress sites in one place.

At any given time there are roughly 3-5 pages worth of PRs with a needs review label. This is pretty overwhelming. I can understand how easy it could be to have tunnel vision and only keep track of your teammate’s work.

To encourage folks to review a bit more, here’s a quick summary of how I break up my day:

Morning – review all the things!

I happen to work in the latest time zone on my team. This means that by the time I’m online, the rest of my team already has a number of in-progress or needs review PRs that are fresh and waiting for me. This is one of my only chances to chat with folks while they’re also awake, which makes it a great time to catch up with folks or have a live video hangout.

My morning time is very interrupt-driven, which is why this is also the best time of day for me to review my team’s PRs. I have a special email filter for Calypso pings. I try to run an inbox-zero approach here, but depending on current project needs I might not be able to get through all of them.

coffee.gif

Coffee and Breakfast is also very important

 

Afternoon – Coding

By the time I’ve finished lunch, the rest of my team should hopefully be relaxing as their day winds down. Slack is mostly quiet in my afternoons, aside from helping out with a random Calypso fire or two that may occur from time to time. I usually have a solid chunk of uninterrupted time, which is great for getting into the flow, loading a complex problem into your brain, and cranking out a decent approach to a problem.

I stop when I’ve hit a good point, where I’m pretty certain I won’t be dreaming about solving the issue in my sleep.

code.gif

Evening – Trash Pickup or Cross Team Reviews

After hitting a good point with my in progress issue, I usually have a little bit of time left in my day. To wind down, I might pick out a quick janitorial issue to hammer out, or more often I might peruse that giant list of PRs that need to be reviewed:

giphy-1.gif

But how to pick one?

Picking a PR to Review:

Here are some suggested approaches:

  • Take a look at one of the oldest PRs on the list. Ping the author with questions if it looks inactive.
  • If you don’t have a lot of time, choose a tiny PR to look at. These are the fastest to review and test, and usually have the least risk of causing a regression.
  • Choose something you’re unfamiliar with. Reviewing PRs is a great way to learn, and to keep a pulse of what’s happening on other teams. Don’t be afraid to dive into a section you’ve never looked at before. If you don’t follow, or something is unclear, ask questions! The PR author is usually happy to explain.

Always Waiting for a PR Review?

Do you always feel like you’re waiting for a review? A few tips:

  • Add context and reasons of what your PR is trying to achieve in the summary, so someone unfamiliar with the issues can hop in and help.
  • Add step-by-step testing instructions! This makes it easy for people to review your code.
  • Break down huge PRs into manageable chunks. Large diffs are incredibly hard to review and test, and it’s more likely that folks just don’t have that amount of time to sit down and attempt to understand the PR.
    • The might mean adding wip PRs with feature flags
    • Sorting out janitorial things, like updating code-styles into their own PRs
    • Do things in steps. For example, first creating a PR to add a new component, before using it on a page in a second PR
  • Take some time to review a few PRs! Other folks are waiting too!

Night – Relax!

Your day might look very different, but I find that interrupted time is great for PRs, and quiet time is incredible for coding.

Remember to take it easy though and not to overwork yourself. I personally try to work somewhat traditional hours and turn on a do-not-disturb mode on my phone for night time hours. This helps me from from getting sucked back into work mode too late at night. Other folks might be able to handle a much looser schedule, but I am not one of them. 🙂

Anyway, I hope this post was helpful! To my co-workers it was great seeing you at the Grand Meetup, and I can’t wait to see you all again!

bear.jpg

 

Sunday Roast

I visited London back in January and I was particularly fond of the Sunday Roast. This example is from Hawksmoor Air Street. The menu had a number of items, but just about every order out of the kitchen was this. No wonder though, the potatoes had a perfectly crisp crust, the yorkshire pudding was an excellent gravy delivery device, and the roast was spot on.

food.jpg

It was delicious.

I followed it up with sticky toffee pudding.

stickytoffee.jpg