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:

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

The Engineering Manager

How do I make sure my work is visible?