This post was written by Stig Brautaset, CircleCI Staff Software Engineer, in collaboration with Cian Synnott, CircleCI Senior Staff Software Engineer.

What is a personal retrospective?

Retrospectives are a well-established resource in the software and systems engineering toolbox. From sprint retros through to post-incident reviews, we look back on our work to learn from it and to get better.

We can apply the same ideas to our professional practice with a personal retrospective: writing an analysis of our experiences to learn as much as possible. We could look over a whole year of work, or focus more closely on a particular project.

Compare this to learning a musical instrument: paying close attention to a recording of a practice session can be a powerful way to improve.

Why write a personal retrospective?

Assessing our own performance as individual engineers - and telling the story of that performance to our colleagues - is difficult, and gets harder as we grow in our careers.

A written retrospective is an opportunity to stop and think: to step back and view things at a high level. We can more easily learn and self-correct, as well as imagine possible futures. We can model and normalize learning “in the open” by sharing our personal retros with our colleagues.

Taking a relatively formal, personal system with us from role to role “frees” us from local performance management systems. Rather than getting stressed, we can just copy or reword parts of our personal retros as input.

Who are personal retrospectives for?

  • Ourselves: to remind us what we’ve done, and to create an opportunity to reflect on how things have developed since.
  • Our team(s): to give them a broader view of our work, to demonstrate openness about the highs and lows of being a software engineer, and to encourage a growth mindset.
  • Our manager(s): to “manage up” and give them what they need both to assess our performance and to provide input on our goals.

Structure for personal retrospectives and examples

Choosing a retrospective format gives some structure to your reflections. Here we will show two types we’ve used, but there are lots available. For example, if you have a production engineering background you might prefer a simple “incident review” format: what went well? What went badly? What will we change?

4Ls: Liked, learned, lacked, longed for

The output of “4Ls” is terse, readable, and easy to translate into talking points with your colleagues. For example: “here’s what I need more support with,” or “this is great, let’s do more!”.

Excerpts from Cian’s 2021 yearly retro:

Liked

  • My manager has been outstanding throughout, sometimes in difficult situations.
  • The Pipelines team is flexible and has a growth-mindset. We’ve been able to use a rapid set of experiments with process and working agreements to learn together and cohere as a team.
  • Let’s Talk Engineering is always such a pleasure to attend. Thanks Jacque!

Learned

  • Over the year I built up more regular 1:1 relationships with colleagues.
  • These have proved a powerful way to both help and get help with context, advice, and feedback.
  • Maintaining these with Identities and Permissions colleagues as I moved on from the team was particularly valuable.
  • This may be the most important/impactful way I spend my time.

Lacked

  • The emergency $service database upgrade took up a lot of time that could have been saved - I think! - by a better original plan.
  • I’m hopeful that work to document and generalize our approaches to software and infrastructure migrations will help in future.

Longed for

  • The end of the pandemic! The “free-floating anxiety” it added to every professional and personal problem I had to deal with throughout the year has been exhausting.

Narrative

A narrative format, perhaps divided into themes, is a great way to reflect on a specific chunk of work.

Excerpts from a retrospective Stig wrote recently for a long-running project:

Stressing about perceived lack of progress

I started working on the $project proposal as part of my 2020 Q4 goals. I didn’t meet that deadline, and carried it over to Q1 of 2021. For months I stressed about this slow progress, and felt side-tracked by answering questions from outside the team in Slack, PR reviews, and jumping in to pair with on-boarding team members.

I introduced an interrupts rotation, loosely modelled on Id&P’s, so I could ignore questions from outside the team N-1/N weeks, safe in the knowledge our interrupts person would deal with them.

On-boarding new team members was also part of my quarterly goals, and arguably a more important & urgent one. So in hindsight prioritising on-boarding even though my planning suffered was the right choice. If I had been able to be more rational about that it might have caused me less stress.

At some point I added planning tasks to the Jira board, in an effort to increase accountability and visibility of my planning. (And also because I felt guilty about not picking up coding tasks while doing the planning.) I had mixed success with this. The planning work & discussions were not great fits for tracking in Jira, but it was easier to get help pairing on them.

I reached out to a couple people asking about their perception of my progress (or lack of it) and they had no complaints. This makes me think that the story Jim sometimes tells about the ducks that look serene above water, but if you could see them underwater their legs are busy, feels slightly apt. (That, or I chose well when deciding who to ask!)

Pairing as a driving force

During the early parts of the planning (late 2020-early 2021) I struggled with motivation and focus, at least in part due to COVID lock-down fatigue. I found that pairing helped me, as I got to “borrow my pairing partner’s motivation”.

I tried to pair with people on much of the work, particularly from the start of 2021 onwards. It was not always easy, because of poor overlap (time-zone wise) with my most enthusiastic pairing partners.

Pairing also helped me to introduce more people to the ideas behind the project. They had questions that I hadn’t thought of, that in turn improved the project proposal.

This retrospective

It’s been more time consuming than I thought it would be—I keep remembering more and more that I want to cover. It’s felt valuable to go over and calibrate my feelings at the time against what I’ve learnt since—both from my own hindsight and from speaking to others. And I really do hope this can help others that might experience some of the same problems I did during their own planning.

Compiling a retrospective

Like many analyses, a finished retrospective may not show all of the work that goes into it.

1. Gather and take notes

First, put together your raw material. Go through your daily notes, journal, lab notes, “brag document”, “nice things people say” file, pull requests, key documents you’ve worked on - anything that comes to mind.

Tip: It becomes a lot easier to do effective personal retros, especially for longer timespans, if you keep daily or weekly notes. (But you can still do it without them!) If you’re just starting to take regular notes, include what you’re doing, what you’re not doing and how you’re feeling.

An example daily notes file from Stig:

  • Caught up on Slack
  • Thoughts from watching Railway Programming: Maybe use cases are not complete unless they specify error handling? E.g. “As a user I want to be able to update my name and email address”
    • Implicit: “AND see a sensible error message if something goes wrong”.
    • cf “Railway Oriented Programming”, https://vimeo.com/113707214

    • Unhappy paths are requirements too (so Design for Errors)

      I’m wondering how well the error enum translates to microservices. Is there truly only one place you need to report errors to users? I’m not convinced.

  • Spent some time reading & commenting on the incident review for Monday’s incident where a bad actor caused trouble in $service.
  • Added a couple hot takes to our #incident-process channel cf . Cian chimed in to agree, which made me feel relieved :-)
  • Moved the needle on the blog post. This feels good! Even though it’s just a couple paragraphs. (And they might not stay ;)
  • Quick huddle with Fernando on where to apply $project limits - in client, or in server? My preference is for the latter, as deep as we can.
Tip: As you go through all your raw materials, take notes. Focus on issues or patterns that elicit strong emotions; if nothing did, note that! Note things that were too hard, or too easy, positive points and negatives. Don’t worry about wordsmithing. A bunch of bullet points and maybe a few timestamps will do the trick.

2. Group and analyze

Start out by grouping related bullet points together. As they become clearer, label these groups with themes. You should now have a decent overview of what happened and how you felt about it.

Consider leaving it for now and coming back another day. A little distance will help you notice things you missed on the first pass through.

3. Reflect and write

Expand on your initial reflections and feelings and start slotting them into your chosen structure.

It’s helpful here to think of your audience. If you want to keep your retrospective private, then you can of course keep it in a “raw” form, have a think about it, and take what you’ve learned with you. However, we recommend sharing it with colleagues. We all learn a lot faster when we can learn from one another.

If you’re writing narratively, you might have everything you need in your bullets and themes to expand them into paragraphs. If you’re using something like 4Ls, you should be able to snip up your groupings along those lines.

Adding context to your notes as you go is valuable: taking the time to explain your feelings and thoughts to others often helps you realize things you’ve missed. Again, consider taking a break when you feel you’re 90% there. A little perspective goes a long way.

4. Share and discuss

At this point you’ve done a lot of work to learn the most you can from your experiences. Consider writing a summary on top. Discuss it with colleagues, if you’re able, and ask for feedback or any additional thoughts they have.

If you feel your retrospective shines a light on difficulties other engineers might have, share it more widely in your organization. Learning “in the open” creates a kind of safety in an engineering culture. From Stig:

I like that Cian made his yearly retro “public” (to the company) so I could get an insight into his perspective. He normally comes across as unflappable to me, but from reading his retro it seems all was not sunshine and rainbows. It’s not that I want him to have a hard time! But it is good to see that I’m not the only one feeling squeezed occasionally, and that solutions can be found. :)

Taking action based on your retrospective

You may find that you struggle with particular situations or topics. Perhaps you can get advice or relevant training, or even seek out such situations to get more practice.

You may find that a particular aspect of your work is especially rewarding. Do you have the flexibility to pick up more of it? If not, maybe it’s time to talk to your manager. The reverse is also true! Is there a particular aspect of your job you don’t like? Is there a path to reduce it, or at least its impact on you?

Ideally, you can use your retrospective to hone your craft, to be more effective, and to maximize the enjoyment you get from work. This can help you identify what you want your career to look like, and perhaps be more intentional about what you work on. Says Stig:

While going through my daily notes to prepare for an annual review some months ago I realised that I liked pairing with people, and helping them onboard. I talked to my manager, Riasat, about it and I do more of this work now. While I didn’t think of it as a personal retrospective effort at the time, in retrospect (see what I did there?) I now do.

Treat this practice of stopping and thinking as a first-class part of your professional practice. It’s an investment: it takes time to reflect like this, but in the long run it reduces the number of times that you and your colleagues have to learn the same lessons.

If you’re looking for a team to learn and grow on, check out our job postings!