How do I make sure my work is visible?

Leave a comment
Q&A

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!

How do I get better at giving feedback?

comment 1
Q&A

This week, we’ll look closer at a subject that seems simple in principle, but in practice can be quite tricky.

Q: How do I get better at giving feedback?

I’m aware that the topic of giving feedback may come across as quite dry, and that the next tab or email might appear more interesting to read; but please be patient with me here. It’s worth it.

Being able to frequently give and receive feedback—especially feedback that is clear, concise and actionable—can completely transform your relationship with your colleagues.

It works wonders in all job roles. 

If you’re a manager, it can make you far more effective at running your team and coaching your direct reports. If you’re an individual contributor, you can concurrently build high trust with your peers and also ensure that the quality of the work and the interactions that you’re having are always trending in an upward direction.

All of this is possible through the simple process of giving frequent, good feedback.

However, I know as well as you that giving feedback is hard. It can often feel awkward, forced, and worst of all, insincere—even if you don’t intend it to! Sometimes you don’t even feel like you’re the kind of person who’s good at giving feedback—or even allowed to do it—so you shy away from it.

But, with continued practice, you can build the confidence to make it as common in your daily routine as having lunch, and your colleagues will thank you for it.

Let’s explore feedback in three important ways, calling upon some excellent ideas. 

We’ll look at:

  • A model which will help you ensure that the feedback you’re giving is of high quality.
  • A process for giving feedback which is short, simple and repeatable.
  • A habit which will help you embed feedback into more of your interactions, helping you get better at giving it, and also will enable a culture of bidirectional feedback with others.

We’ll begin by looking at a model from one of the best books out there on the subject.

A model: Radical Candor

It seems that some of the best models that we call upon are arranged as quadrants. 

The Eisenhower decision matrix has helped me greatly in organising my personal priorities, and the effort versus impact matrix has helped many of the teams I have been part of over the years think about which tasks to tackle first.

There’s another excellent quadrant model that reshaped how I think about giving better quality feedback to people, and it comes from Kim Scott’s wonderful book Radical Candor.

Scott considers the two most important parts of giving feedback are that you must: 

  • Care personally about the person that you’re giving feedback to, and that you must also 
  • Challenge them directly by being clear and to the point.

When you are doing both of these things, then you are exhibiting radical candor. It’s radical because so few people are good at doing it!

What’s even more interesting is that when you visualise these two characteristics with a quadrant, it also highlights the pitfalls that we face if we only do one (or none!) of them.

Here’s what it looks like:

So what do these words mean in the quadrants? Let’s step through them:

  • Radical candor is what happens when you care personally and challenge someone directly. You say what you think and deliver the feedback precisely but in such a way that ensures the recipient sees that you are doing so because you care. This is where you want to be. It promotes trust and growth. But, as we all know, this takes practice.
  • Ruinous empathy happens when you care but don’t challenge directly. It’s either unspecific praise or diluted criticism to avoid a difficult message. This doesn’t help the recipient improve. So many new managers fall into this trap where they are afraid to say what they think because of the fear that it will cause conflict. The irony is that it’s worse for the recipient, who doesn’t know that they need to improve.
  • Obnoxious aggression is when you challenge but don’t care. It’s insincere praise or mean criticism. Insert your stereotypical hot-headed male executive here.
  • Manipulative insincerity is when you do neither. Good behaviours go unpraised, and bad behaviours are ignored. As a leader, this is a complete dereliction of duty.

Can you think of situations that you’ve witnessed in your own life that fall into the categories above? Perhaps you worked with a colleague who was performing badly and was a burden on the team. It may have been because your manager was demonstrating ruinous empathy by never tackling the performance problem directly. 

Conversely, you may have witnessed a manager who seemingly never praised their team and would get angry and overly personal in their criticism. Would you place them in the obnoxious aggression category?

Remember, whenever you give feedback, you want to be radically candid. Not only does it make you better at giving feedback, it’s essential for ensuring that those that you work with are able to improve and get better. 

Feedback is a gift.

A process that works every time

Even if you’ve fully understood radical candor, feedback is like writing, programming and exercise: you don’t get better by reading about it. You get better by doing it

The only issue is that because communication can be messy and also humans can be unpredictable, we can have many bad experiences that make us hesitant to keep training our constructive criticism muscles.

Ideally, what we want is a clear process that we can follow every time that takes a lot of the work out of delivery. We often know what we want to say, but struggle to say it in an optimal manner. 

Enter LeeAnn Renninger, who has a fantastic short video on a proven method for giving effective feedback.

The process breaks down giving feedback into four stages:

  1. Start with a micro-yes. Getting unexpected feedback out of nowhere can be unsettling for many people, so the first step involves getting the recipient into an open mindset about receiving the feedback. This is a “micro buy-in” and can be a simple question: “I’ve got a couple of ideas for how we could improve. Can I share them with you?”
  2. State your data point: Next, you should be specific about what you’ve observed, using as much data as possible. For example, “we said we’d ship this change by midday, but it’s now 4PM” or “this proposal is currently too technical for our stakeholders to understand”. 
  3. Make your impact statement: Following the data point, you state what the impact of the data is. For example, “our support staff are getting inundated with tickets because we said that it would be fixed earlier”, or “this will make it highly likely that we won’t get buy-in for our project”.
  4. End on a question: This opens the floor for the recipient to start discussing the feedback with you. For example, you could say “what are your thoughts about that?” or “how do you see the situation?”. You’re actually asking for feedback on your own feedback!

Try it out. Start using this model in your feedback next week and see whether you feel more confident and impactful in what you are saying. It definitely helps me organise my thoughts and ensure that they aren’t accidentally going to land in a confrontational way.

You could even share the video above with your team and spend some time roleplaying some situations with them. You could imagine some scenarios, and then pair up and take turns at applying the feedback model.

For example:

  • Roleplay 1: One person is the manager delivering the feedback and the other is the direct report. The direct report has been off sick for two days but did not contact the team at all to tell them where they are. The manager wants to tell them that this isn’t acceptable.
  • Roleplay 2: Both people are individual contributors and one of them has been up all night on-call because of a production issue. It turns out that the issue was caused by a change that the second person pushed straight to production without getting a pull request review at the end of the previous day. They need to be told that this isn’t a good way of shipping code.
  • Roleplay 3: One person is the direct report delivering the feedback and the other is the manager. The manager recently exhibited obnoxious aggression in a meeting when the team’s priorities were rightly challenged, and the team feels deflated and upset as a result. The direct report wants to tell the manager they didn’t act as a leader in that meeting.

I’m sure you can invent plenty of scenarios to practice on as well. If you find it hard to get buy-in to do some roleplaying in your team, why not give them some feedback on why it could be beneficial?

A habit: sharpening your tools

Like fitness, if you don’t keep practising, your performance will decline.

In order to get good at giving feedback you’ll need to ensure that you’re doing it all the time. I’m talking daily.

The reason that giving feedback can be so hard is that so many of us associate the term “giving feedback” with “giving bad feedback”. In all likelihood, your colleagues are probably doing many things every day that deserve good feedback, including you. 

As a rule of thumb, I find that nine out of ten pieces of feedback I give are always positive if I’m actively looking out for the opportunities to give them. This gives you a great opportunity to form a virtuous feedback cycle that acts as a flywheel going forwards.

By seizing feedback opportunities, you can do the following:

  • Practice radical candor. Remember that you want to care personally and challenge directly. You can always gain comfort and confidence by leaning strongly into the caring element. If you truly care, then the only motive that you have for giving feedback is for the other person to improve. So be sincere, and the rest will follow.
  • Practice the feedback process. Once you’ve shaped what you want to say, follow the four steps above. Open with a micro-yes, share your data point, make your impact statement and then end on a question. With time, you’ll be able to do this automatically without thinking.
  • Feel confident in your feedback skills. As time goes on, and with each piece of feedback that you give, you’ll have positive experiences that can feel like real personal breakthroughs with others. This helps form a virtuous cycle that will make you want to give feedback more often.
  • Be seen as someone who others expect feedback from. I once worked with someone who was so consistent at giving feedback that I knew as soon as I gave a presentation to a group, or circulated a document, I’d receive a message outlining what they thought about it. It was great: I always felt that this individual was looking out for me and I could trust them to call out if there was something that I could do better next time. You can be that person.
  • Ensure that you’re a well-oiled feedback machine for when you need to deliver critique. Practising positive feedback daily benefits you in two ways: not only does it make you better at doing it, it also builds trust between you and the recipients. This trust can then be leveraged when you need to occasionally give critique. It makes it so much easier to deliver.

So go on: start right away. With time, what comes naturally to you will be seen as a superpower to others. All it takes is a little practice.

Further reading

If you want to dive deeper into giving feedback, then there’s a number of books that I recommend:

  • Radical Candor is highly recommended, and it’s where the model presented earlier on is taken from. 
  • Crucial Conversations is worth a read if you’d like to delve deeper into how to handle high-stakes situations whilst ensuring that you get the results you want.
  • And of course, we explore feedback and communication in many situations in depth in my first book Become An Effective Software Engineering Manager, and we go deeper into communication in my second book Effective Remote Work. Picking up a copy of one of my books is the best way to support my writing.

Do you have any stories of when feedback has had a profound effect on you—good or bad? I’d love to hear from you.