Cover letters, the four types of teams, players vs coaches💡
Monday Ideas — Edition #56
Hey, Luca here! Welcome to the Monday Ideas 💡
Every Monday I will send you an email like this with 3 short ideas about making great software, working with humans, and personal growth.
You will also receive a long-form, original article on Thursday, like the last one:
To receive all the full articles and support Refactoring, consider subscribing if you haven’t already!
p.s. you can learn more about the benefits of the paid plan here.
⬆️ OneSchema — Import CSV data 10x faster
OneSchema is a ready-made CSV importer for developers — which automatically corrects customer data.
Validate and transform files of up to 4GB in <1 second, customize importer behavior, and launch fast with a library of prebuilt validators.
We implemented OneSchema in just one day, and what used to be a weakness in our UI is now one of our strengths. — Dominic Kwok, CTO, Heron Data.
OneSchema is a sponsor of Refactoring 🙏 here is how we run sponsorships transparently.
1) 📋 Cover letters are not useful
This might be a hot take, but cover letters are not very useful to me.
Most people are confused by what should go in there, so they roughly repeat what is already in the resume — but in prose, so it’s harder to read.
Occasionally you can find some genuine, great ones, but most suck, so many managers I know have been unconsciously trained to ignore them. Myself included.
I may read it later, before the screening — but if you already got to the screening, then by definition the letter was not useful.
If the job position requires a cover letter, then focus the story on why you want that position at that company. Tell something that complements your resume and is tailored to the application.
I also have dual advice for hiring managers that require cover letters for their positions: please don’t.
Some companies require them because they want candidates who are excited about the position. In my experience, that’s wishful thinking. It’s your job to make the candidate excited, eventually.
I wrote a full article about how to write a great resume, you can find it below 👇
2) 🎽 The Four Types of Teams
One month ago I reviewed and wrote a summary of Team Topologies, one of the most influential books about structuring tech teams.
One of the main ideas from the book is that you can identify four types of teams:
🏆 Stream-aligned Teams
These are teams who own and work independently (e.g. cross-functionally) on a slice of the business domain.
One of the key lessons from the book is that stream-aligned teams are the most important teams. Other teams are basically there to reduce the cognitive load of stream-aligned teams.
🧑🏫 Enabling Teams
Enabling teams are about developing skills.
They research new best practices, or new tech, and are consulted to improve the output of other teams. The final goal is to transfer such knowledge to stream-aligned teams, not to retain it themselves.
🧶 Complicated-subsystem Teams
These are teams that work on niche problems that require specific skills, that would otherwise bottleneck the work of other teams.
Examples are areas where you need specialized skills but only occasional involvement. Think of specific algorithmic work, audio-processing, or infrastructure tuning.
🏗️ Platform Teams
These are teams that build infrastructure that is used by other teams and enables their work. Infrastructure here is meant broadly: think of CI/CD, tooling and any product/framework born for internal use.
Platform teams are similar to stream-aligned teams in that they own their work — with the difference that their customers are other teams, so they are inward-facing.
You can find the full book review here 👇
3) 🏀 From player to coach
I am a big sports fan, and I like to think about the transition from IC to manager, like that from being a player to being a coach — things that make you effective as a coach are often quite different from those that make you effective as a player. Just like IC vs EM roles.
Let’s dissect this a bit, using basketball as an example:
🏀 As a player, you’re on the court. You’re responsible for executing plays and defending effectively. You may be the captain, in which case you’ll also make decisions in real-time on which plays to execute throughout the game.
👔 As a coach, you’re off the court. You set the strategy for the game, and build the plays that the team executes. You’re responsible for ensuring your team is healthy and strong – physically and mentally. And, when the game is not going your way, you’re responsible for picking the right play and/or changing strategy accordingly.
You can find more advice about transitioning from IC to manager, in this popular article I wrote with Louis Bennett 👇
💻 Typo — 10x your dev teams' efficiency
Last week we promoted Typo, an intelligent platform that seamlessly integrates with your dev tool stack (Git, Issue tracker, CI/CD, Slack) & connects the dots between engineering signals and developer well-being to enable dev teams to code better, deploy faster & stay aligned with business goals.
If you missed it, as a Refactoring reader, you can still get 20% off any Typo plan 👇
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. You can learn more about the benefits of the paid plan here.
2) ❤️ Share it — Refactoring lives thanks to word of mouth. Share the article with your team or with someone to whom it might be useful!
I wish you a great week! ☀️
Luca