

Discover more from Refactoring
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:
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 π
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 π
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 π
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
Skip levels, taking notes, and resumes π‘
Luca, I have been reading your newsletter for few weeks now and I really enjoy it. It shows that you are putting a lot of effort into writing this. Every newsletter I read was of a really high quality. I will definitely check out Readwise since I also use Notion more and more for my personal note keeping, idea and success journal and more. I am thinking about starting my own blog/newsletter and I am sure I will borrow (copy :D) a lot of ideas from your newsletter!