The Engineering Manager

If there’s one thing as sure as death and taxes, it’s the fact that you’re going to have many managers over the course of your career. Even if you stay at the same company for decades, it’s unlikely that your manager is going to as well.

What’s more likely is that you may find yourself with a new manager every few years, due to one or more of the following reasons:

• You change jobs.
• You move to another team, either by choice or because priorities have changed.
• Your manager leaves.
• Your manager moves to another team, for the same reasons as above. You get the picture.

So, this week, we’ll look at the following question:

Q: How do I deal with my manager changing?

Change isn’t all bad

I think it’s important to begin by addressing the elephant in the room: changing managers shouldn’t be avoided at all costs. 

In fact, it can be good for you. Sometimes getting too comfortable under someone can hold your development back, compared to someone that could push you outside of your comfort zone, help you work on something new, and make you see sides of yourself that you hadn’t been made aware of before.

If you really want to work on something different, but you pass because it means changing managers, then you’ll eventually regret missing that opportunity just for keeping the familiarity of your current relationship. 

However, the reason that people avoid changing is completely understandable: we’ve all had our share of experiences with our managers, from the good to the bad. Reporting to a good manager is a joy. And when you’re reporting into a bad manager, work can really suck. So why take that risk?

After all, your manager is responsible for your performance reviews, finding opportunities for you to grow and progress, and for making sure that you’re happy and productive day to day, week to week.

Even if you try your best to stay with the same manager, much is outside of your control. They may leave. You might get moved to another team. So, with time, it only becomes more likely that you’ll be reporting to someone else.

Therefore the question remains: how can you get things off on the right foot when you make the switch?

We’ll break this into three different parts that represent the past, present and future at the point of changing. But first, let’s look at some general advice.

Own your own development: push, don’t pull

Actors in a system can only affect what they can fully control. Everything else is up to the altruism of others or just pure luck. This holds for your career as well. 

If you give complete control of your growth to your manager, then you may get lucky with someone that truly dedicates their time and attention into finding opportunities for you, lays out clear goals for you to reach, and ensures that you’re always progressing at all costs. However, the likelihood that you’re going to find a manager that does this consistently is low. 

Why? Well, not only does it take a huge amount of time for any manager to plan development for each of their direct reports, fundamentally you are the one that best knows yourself and where you want to go, not your manager. 

Instead of seeing your manager as the pilot and yourself as the passenger, you need to work that relationship differently with yourself as the pilot and your manager as the copilot. 

You need to know where you want to go, and you need to steer in that direction with their help. 

Think about it: if you were managing someone and they were able to take the lead on suggesting their goals, asking you for more work, and encouraging you to delegate things to them, wouldn’t that be wonderful?

Being proactive with your development ensures that you get what you want since you know yourself best, and it makes your manager’s life easier because they can be the copilot, rather than the pilot. Yes, you can ask for advice. But you take control of planning your direction of travel.

And, if you have managers that you don’t really gel with—as we all have had in the past and will in the future—then having them occupy a position where you can set the direction and then mostly get out of your way can be liberating for both of you.

So always own your own development and push towards it, rather than waiting for your manager to find you opportunities and to pull you along. The latter rarely ever yields optimal results.

The past: the handoff and your audit trail

Let’s now look at the switching point.

When you change managers, they won’t know your past. They might have access to your previous performance reviews, but they weren’t written by you, nor do they represent your whole self. 

What can you do?

If you can, try to arrange a manager handoff with your previous manager and your new manager. This is a 1:1:1 (read: one-to-one-to-one) where all of the important information is passed from your old manager to your new manager whilst you are there. 

This is important because that transfer is transparent to you, ensuring that you have the opportunity to know that it’s happened, can hear what is being said and therefore reduce the friction in the process.

The agenda of the meeting is as follows, mostly driven by the former manager:

• Details from your most recent review cycle.
• Your recent feedback, current projects and other relevant information.
• Your goals, growth areas and any important things for the new manager to know.

Read Lara Hogan’s post in detail to see exactly how to structure the meeting and ensure that all parties leave satisfied.

Also, in the spirit of pushing, rather than pulling, we wrote last week about how you can ensure that your work is visible. Check it out if you haven’t already. 

The core of the practice is creating a habit of writing “brag docs” at regular intervals—say, weekly or fortnightly—that detail everything that you’ve been working on, from the tangible (e.g. shipping a feature) to the less tangible (e.g. that you made a decision, or mentored a colleague).

If you get into the habit of writing these and sharing them with your manager, then the archive can come along with you when you switch, giving your new manager the ability to read through what you’ve been up to for the last weeks, months, and years if they wish.

By lining up a manager handoff, and by having a past audit trail of your work as written by you, not only have you given your new manager plenty of opportunities and material to understand where you’ve been and where you want to go, you’ve also been present and have had complete control of the process and information.

The present: contracting

Now, let’s move on to the present. You’ve had your manager handoff and you’re about to have your first one-to-one meeting. What do you do? 

I always recommend an exercise called contracting, which I learned a long time ago from a workshop with Conscious Business People in my early management days. 

The idea is that you’re starting a brand new relationship and your first meeting together is an opportunity for both you and your new manager to make it really clear as to what you both need from each other in the relationship.

The contracting exercise is just a few simple questions that you prepare beforehand. You then come to the meeting to talk through your answers with each other and to discuss how you feel about them. 

The questions are as follows. They’re two-way, as a direct report supports a manager by helping their team succeed.

• What are the areas that you’d like my support with? This can range from technical challenges, performance management, visibility into other areas of the company, and so on.
• How would you like to receive feedback and support from me? This is about working out how the other person likes to operate. Do they prefer written or verbal feedback? Do they prefer synchronous or asynchronous communication? Everyone’s personalities and preferences are different, so this gives an opportunity to uncover that.
• What could be a challenge in us working together? As before, everyone’s personalities and preferences are different, so that can cause some clashes, and these can be explored. Additionally, are there big skill set gaps that might make the relationship harder because one person doesn’t have in-depth knowledge of the other’s world and vice versa?
• How might we know if the support I’m offering isn’t going well? If there are occasional flashpoints, or if the relationship really starts to go downhill, how will both parties know? Do they feel comfortable just saying so, or are there particular behavioural signs that each other can look out for such as quietness, frustration, or lack of responses to messages?
• How confidential is the content of our meetings? Since one-to-ones are private, sensitive topics can arise. Should those topics stay completely private, or are there circumstances where that information could generate some actions? If so, how should permission be granted to share private information if it needs acting upon?

Contracting is a great exercise to get relationships off on the right foot, and it doesn’t have to be used exclusively between managers and direct reports. It works between any two people. It’s also a neat tool that you can use to reset relationships as time and circumstances change them.

The future: your goals

With the relationship with your new manager grounded, you should also take ownership of coming up with your goals and trying to achieve them. I’ve always been a big fan of the 30-60-90 day plan when moving into a new role, but it also works really well when starting out with a new manager.

The reason is that when you start with a new manager, you want to build two-way confidence in that relationship from the start to show that you’re someone that they can rely upon to get your job done. 

By starting with this short time frame of three months with a check-in every month, you get plenty of opportunity to start building a goal-centric relationship with your manager, which will frame the rest of the relationship that you have with them.

Doing so is simple: you just come up with some objectives to achieve within each of those time periods. The goals themselves don’t need to be ostentatious: they should just be your usual job, and the kinds of things that you’d be writing about in your brag documents.

However, you’ll find that by being able to show your new manager that you’re actively planning and achieving, they’ll more quickly give you autonomy and think of stretchier and more interesting goals that you can achieve.

Resets are good

With these tools, changing managers can be a great opportunity for a reset and a chance to shape a future relationship exactly how you want it.

You can use a manager handoff accompanied by your brag docs to cover the past, contracting to cover the present, and a 30-60-90 day plan to move you into the future. 

Even if you’re not changing managers, why not give these tools a go as a way of rebooting your current relationship? Try it out.

If this article was right up your street, then there’s plenty more ideas and tools in my book, Become an Effective Software Engineering Manager.

Until next time.

Before we get started

As you may have seen, unfortunately around 10% of Shopify staff were laid off last week. It sucks to lose talented friends and colleagues. 

If your company is currently hiring, then we are providing outplacement services for our affected staff. All you need to do is contact placement@shopify.com and we’ll provide you with contact information. They will make incredible additions to your teams.

Thank you in advance on behalf of the colleagues that we lost. Let’s now continue with this week’s article.

---

It’s all a blur!

Leading well means enabling your team to do their best work. But one problem that many leaders face is feeling like their effort is completely invisible: they spend their time making decisions, prioritising, reviewing, connecting and removing blockers. It’s messy, often intangible work.

At best, this can make great managers feel like sometimes they’d like a little more time in the spotlight. At worst, others might not understand the depth and impact of the work that they’re doing, meaning they miss out on praise and even promotion.

In this week’s post, we’ll be covering:

• The difficulty of remembering what you’re working on in a fast-paced environment when every week feels like a blur.
• Brag documents, which is a great way to tackle the above problem.
• The process I use to write mine, which is an iterative process throughout each week.
• An evolution of brag documents into internal newsletters, a technique that I currently use at work.

So, this week, we lead with this question:

Q: How do I make sure that my work is visible?

This is something that I began to feel acutely once I got to the point in my career where I was leading other managers. Each of those managers ran different teams, and each team had different projects. 

For the first time, my attention and role definition wasn’t characterised by being the lead for one clear thing. Instead, there were multiple projects and priorities, and I was primarily there for my managers, doing what I could to ensure that each of their teams could make efficient progress in any way possible.

On a day to day basis, my work was never the same. I was, as an example… 

• Doing one-to-one meetings.
• Attending team meetings where I was able to help with technical direction and decisions.
• Going deeper into some of the projects than others, depending on the number of issues or the specific technical aspects that I could help with.
• Discussing details with people outside of the team and on connected projects.
• And, of course, helping put out occasional fires, whether technical or interpersonal.

This was, and still is, a lot of work. But because of the depth and breadth of that work, and because of the continual context switching, I would find myself drawing a blank when people asked me what I spent my week doing—especially my manager in my one-to-one meetings. 

The actual answer was that I’d done a huge amount, and it was totally varied and dependent on the needs of the day, week, or month.

But it was too much to explain—and potentially unexciting to recall and narrate—so I would elide most of the detail. With time, I’d worry that my manager would think that I wasn’t doing as much as I knew I was, and that in the long run this wouldn’t help me when it came to my performance reviews and my career progression.

What was even worse was that I was doing a bad job at making my work visible to myself. As an individual contributor, you can more easily assemble a picture of your contribution over the previous months: you can find new features, code commits, pull requests, design documents and many other artefacts that you can point to and say “I did this!”

As a manager, I had no such audit trail to point at in order to calm my anxiety by understanding that I was contributing to a high standard and I was making a difference.

What could I do?

The approach I began to take was one that Julia Evans—creator of the excellent Wizard Zines—later coined as brag documents, with a few extensions and twists that I used to make it my own and increase the impact of what I was writing.

Let’s begin by looking at brag documents themselves.

Brag documents

As I explained above, you’re not going to remember everything that you did. And your manager definitely isn’t going to remember everything that you did. So you should make sure that you do and they do.

The idea is that you maintain a document that lists your accomplishments, which can range from the concrete and tangible (i.e. links to a design that you wrote, or some code that you shipped) to the fuzzy and intangible (i.e. the fact that you spent time pair programming with a less experienced engineer to help them ramp up, or that you made a process better, or were on call and responded to an incident).

In Julia’s original post, the suggested cadence of producing this document is every two weeks, but I find that every week works well for me. 

Here’s what my weekly process looks like.

• First thing on Monday morning, I start a blank document. This is where I’ll capture my notes as the week goes on.
• Every time I contribute to something worthwhile, I’ll capture it as a bullet point note. I make sure that I include links to supporting evidence where possible.
• I also jot down interesting conversations, ideas and links that I’ve seen. This can range from Slack posts, news articles, tweets and emails.
• I start grouping these bullet points as they form patterns. A typical grouping is by team or project, or it could be an initiative I am running.
• On Friday morning, I block out time to turn the bullets into a narrative. This involves expanding out the grouped bullet points to form something that I’d be happy for others to read and to find informative. I then make editing passes on it until I’m happy with how it reads.

I’m a Director with multiple teams and work streams, so my groupings typically cluster by project. If you were writing this from a perspective of one team, then you might find that you group by the different parts of your project, such as the technical areas or features being worked on.

When I’m finished writing my document, the structure of the document usually looks a little something like this. 

• The big item. Usually there’s a headline story to the week that’s worth calling out, such as an important milestone that has been hit, or updates on strategy or roadmaps.
• Projects. The next section is where I group the latest happenings in the projects that my teams have been working out. I typically call out what’s shipped, what’s progressed, and give an idea of the discussions that have been going on behind the scenes. I try my best to make it visual also: including screenshots, videos and charts that break up the text and make it more compelling.
• Useful ideas and links. Next, I’ll put together a section that summarises things I’ve seen or heard over the week. These could be links to pull requests, design documents, or Slack conversations that were notable to me. I’ll include a short summary of why they piqued my interest.
• Miscellania. Any other small items that didn’t fit into the above are grouped at the bottom. These could be short announcements, such as reminding people that someone is on vacation in the coming week, or call outs to anything career-related I’ve been doing outside of work, such as blog posts, conferences, or podcasts.

I write it in such a way that anybody else at the company could read it and get a good high-level understanding of what’s been going on in my teams, with enough additional links and images that they can go off and learn more on their own if they want to.

Ideas for sharing it

When I started writing these weekly documents, I would initially share them with my manager. I didn’t expect them to be read in full every week, because at the very least they formed an archive of everything that I had been doing that I could rely upon at performance review time, or just to jog my memory around the way I’d been allocating my time and attention in the past.

However, as I began to talk about the process and then showed my colleagues what I’d been doing, the general response was that what I was producing was much more generally useful than I had intended. This evolved the process into one where I would share the document weekly on Slack to the various channels that I belonged to—covering my direct reports, teams, and other groups that I was part of.

However, this became laborious and unwieldy. After writing it every week, I had to enumerate through all of the channels that I had listed and then post it individually. This led to the current process that I use, which is an internal newsletter. We’re Google Workspace users at Shopify, which means that it was easy for me to set up a mailing list via Google Groups.

I made the newsletter accessible to anyone at the company, and I post there weekly. I started by adding my direct reports and frequent collaborators to the mailing list, but I explicitly state in each post that anyone is welcome to sign up, and people can forward the emails to anyone that they think would benefit.

Over time, I’ve noticed all sorts of people subscribing to the list, including people outside of my teams and division.

The process of writing it

Even though the distribution has grown, the initial intention is still the most important one: the process of writing is what allows me to think and to formulate my ideas about the world. If I was sending it to nobody, I’d still greatly benefit from producing it.

It has become a form of journalism for my mind: each week I need to pay close attention to what is going on because I need to document it, and in turn, that helps me discover what needs more of my attention and then I can prioritise accordingly. The fact that now a fair few people read it has made me be more thorough—the accountability of doing it well keeps me sharp.

A few weeks ago, I wrote a piece called “How do I get better at writing?” where I reproduced the diagram from Larry McEnerney, which is part of his course at the University of Chicago’s Writing Program.

In the course, he states that in order to think about any sufficiently complex problem in detail, you have to write. You produce text along the x-axis in the diagram below.

The weekly newsletter habit helps me produce the text that allows me to think about my world. However, it does still require a fair bit of editing—as Prof. McEnerney states—since the text that I produce to think about the world is not the ideal text for the reader to read: they interpret the ideas along the y-axis. 

This fits how I put the newsletter together: starting with bullet point ideas, grouping them into categories, drafting them out into long form, and then doing a final edit on Friday to make it readable to others. 

By the time I hit send, there have been multiple editing passes distributed throughout the week.

In conclusion

I think that this process can be helpful for anyone. 

You don’t need to start with the intention that you’re going to be distributing an internal newsletter. Even if you begin by making brag documents for yourself, you’ll begin to find that you have a better memory—and appreciation—of everything that you’ve been doing throughout the week.

This is extremely useful when you have weeks that feel like a complete blur: you can look back and confirm that, yes, you did indeed do a lot of work. You can also look back over your regular digests and see patterns in how you’re spending your time that may make you want to distribute your attention differently in the future. And when it comes to performance review time and you need to fill in that box that lists your achievements, well—that’ll be pretty easy, won’t it?

Give it a go. I bet it’ll be more useful than you think.

Limited time discounts on my books

Here’s something that might be interesting if you’re looking to support the newsletter and haven’t yet picked up a copy of either of my books.

Until August 5th, PragProg are offering a 40% discount on the DRM-free eBooks for both of my titles by using the code SPOTLIGHT.

Here’s the links to the titles: Become an Effective Software Engineering Manager and Effective Remote Work.

If you pick up a copy, thank you. Enjoy!