Skip levels, taking notes, and resumes 💡

Monday Ideas — Edition #76

Hey, Luca here! Welcome to the Monday Ideas 💡

Every Monday I send you an email like this with 3 short ideas about making great software, working with humans, and personal growth.

Paid members also receive a long-form, original essay on Thursday, like the last one:

Atomic Habits 📙

To receive all the full articles and support Refactoring, consider joining 1400+ engineers and get the paid membership!

p.s. learn more about the benefits of the paid plan here.

---

🐶 Datadog • see inside any stack & any app—anywhere

Datadog brings together end-to-end traces, metrics, and logs for full visibility into your applications, infrastructure, and third-party services.

Businesses can secure their systems, avoid downtime, and ensure customers are getting the best user experience. With Datadog, you can:

• Break down inefficient silos between Dev, Ops, Security, and Business teams

• Combine dashboarding, alerting, APM, infrastructure monitoring, UX monitoring, security monitoring, and log management in one platform—plus 600+ out-of-the-box integrations

• Accelerate cloud migration, reduce MTTR, drive DevOps adoption, understand user behavior, and track key business metrics

Start your trial today and they’ll send you a free Datadog t-shirt!

Datadog is a sponsor of Refactoring 🙏 learn more here about how we run sponsorships transparently.

---

1) 🔀 Introducing Skip Level 1:1s

If you are introducing skip levels for the first time, be prepared for people to be confused about them. Both your reports (managers), and reports of your reports.

In both cases, you want to tell them exactly why you are having those.

Especially to managers, you should clarify that you are not going to step on their toes and take ownership away from them. Skip levels are 90% about feedback, while most of the action stays on the manager’s side.

So, as the one holding skip level 1:1s, how should you act on items that come up in conversation?

It may seem weird, but 80% of the time the best answer to anything you hear is "have you talked about this to your manager?"

What follows is most often useful, and you want to learn more about it before you take any action. A “yes” may imply the manager didn’t act on this (why?), while a “no” may hint at some communication/interpersonal problem.

The trickiest part of skip levels is being helpful—so that meetings feel valuable and the report keeps coming with good ideas/feedback—while not stepping onto the managers’ toes.

It is kind of an art, even more than with regular 1:1s.

More ideas on having good skip levels 👇

Skip Level 1:1s 🔀

---

2) 🌱 How I take notes

Taking good notes is crucial for my writing process — and I get asked a lot about it.

I read nearly everything from my backlog, on the Readwise Reader (see the reading online article). For each article I highlight the most relevant passages, and these are sent to my Notion automatically by Readwise itself.

Readwise creates a note for each article I have read and highlighted, and such notes only contain my highlights. This is all done automatically.

Once a week I review what I read the week before, link items to existing article ideas (not published yet), or create new ones specifically.

At any given time, I have tens of open article ideas — 26 right now. These are rough sketches, usually just a few bullet points. They include notes from myself, references to readings, community threads, and more.

Whenever I read something, I may think “this can be useful for this article” and link it there. I only start writing an article when I believe I have enough material to write a great piece. That means an idea can stay there for many months before I actually go and write a full article about it.

I will write an entire edition about note taking at some point, including some templates. In the meantime, you can learn more about my whole process for Refactoring in this past edition 👇

How I Write and Grow Refactoring in 2023 ✏️

---

3) 📋 Work experience and resumes

Your work experience is the heart of your resume. It is the part that I spend the most time reading, and, if it’s good, it makes all other sections irrelevant.

You don’t have to necessarily list all of your work history. Put at least the last three, and for each of them include this info:

Company

Add a brief description if not famous. Otherwise, if I don’t know it, I will have to search for it.

Title

Put the title that best represents your contribution.

If your formal title was “Product Engineer” but you worked mostly on the backend, put “Product Engineer, Backend”. If you worked on payments and this is relevant for your current application, turn it into “Backend Engineer, Payments”.

Responsibilities

For each work experience I want to understand your actual role within the team. I want to get context about what you did and the scope of your influence.

• 🟠 OK: “Worked as backend lead in the product team responsible for payments.”

• 🟡 Better: “Led a backend team of 3 people in the product team responsible for payments.”

• 🟢 Best: “Responsible for scoping, planning, and design of the backend work in the product team responsible for payments, leading a team of 3 other backend developers, and collaborating with 15+ other stakeholders.”

Impact

For each work experience I want to know your achievements in terms of impact to the business. This is crucial because it tells me that you are able to elaborate on what makes technical work valuable in the company.

Also, the reality is that companies want people that get things done. Most engineers get promoted based on impact rather than skills.

To describe impact, I am a fan of the X-Y-Z pattern, from Google:

Accomplished [X] as measured by [Y], by doing [Z].

Here is an example:

• 🟠 OK: "Grew revenue for small and medium business clients.”

• 🟡 Better: "Grew revenue for small and medium business clients by 10% QoQ"

• 🟢 Best: "Grew revenue for 15 small and medium business clients by 10% QoQ by implementing new payment capabilities that reduced delinquent churn and enabled more upselling”.

Skills

For each experience you can include the languages, frameworks, and tools that you used. You can embed them in the descriptions above, or use a dedicated bullet point to list them all.

Whatever you do, I vastly prefer seeing them here, in the context of actual work, rather than in a giant list at the end.

Learning

If relevant, describe what you personally learned from each of your work experiences. I recommend creating a first draft of your resume that includes your learnings, and then decide later whether to keep them or not.

Reflecting on your learnings is useful per se, whether or not they will appear on your CV.

Example of learning, from myself:

By moving from being CTO of a small startup to manager of a larger company I learned to deal with a large number of stakeholders and deliver impact in a role with a smaller scope.

Overall, your work experience should tell a story. As a hiring manager I want to see a trajectory of growth that makes you the right candidate for what I need.

You can find more advice about creating good resumes (plus templates!) in this previous popular article 👇

How to Create a Great Resume 📋

---

And that’s it for today! If you are finding this newsletter valuable, consider doing any of these:

1) ✉️ Subscribe to the newsletter — if you aren’t already, consider becoming a paid subscriber. 1400+ engineers and managers have joined already! Learn more about the benefits of the paid plan here.

2) 🍻 Read with your friends — Refactoring lives thanks to word of mouth. Share the article with your with someone who would like it, and get a free membership through the new referral program.

I wish you a great week! ☀️

Luca