Impostor syndrome, spotify model, and the three pillars 💡
Monday Ideas — Edition #133
🗳️ Answer our 5-min survey and win a $150 membership!
As you may know, we are running a big survey about how engineering teams use data and metrics to improve their practices. We will create a deep industry report about it, that will go out exclusively in the newsletter!
You can participate below 👇
The best insights will be quoted in the final report. We are also giving away 20 paid memberships for free ($150 each!) 🎁 to people who answer the survey! We will draw the winners next month as soon as the survey closes.
Back to this week’s ideas 👇
1) 🎭 The Five Impostors
Impostor syndrome is unfortunately widespread in tech.
Most of the time people are doing just fine, but they doubt their accomplishments and fear being exposed as "frauds” — despite clear evidence of their competence.
Dr. Valerie Young has identified five distinct faces, or types of impostors, each with its own set of characteristics and origins:
🧠 The Natural Genius — expects to master tasks effortlessly, and it feels fraudulent when having to spend significant effort. They have been often praised for innate intelligence rather than effort, leading to shame when facing challenges.
💪 The Superhero — strives to work harder and longer than peers to prove worthiness, needing to excel in every aspect of life. It stems from a deep-seated belief of inadequacy, compensating by overachieving.
🎯 The Perfectionist — sets exceptionally high standards and considers even minor mistakes as failures. Perfectionists come from environments where excellence is heavily rewarded or demanded, leading to a belief that perfection is essential.
🚶♂️ The Soloist — prefers to tackle tasks independently; views seeking help as a sign of weakness or fraudulence. Soloists have often been raised in environments that prize self-reliance as a measure of competence.
📚 The Expert — has an insatiable need to know every detail before starting projects; fears being perceived as inexperienced. They emerge from settings that highly emphasize knowledge and expertise, fostering a belief that one can never be knowledgeable enough.
Do you recognize yourself in some of these? But how did you get there? We explored this and how to fight back in the full piece 👇
2) 📊 The Three Pillars of Engineering Teams
Earlier this year I interviewed Rebecca Murphey, CTO of Swarmia and author of the awesome Build book.
Rebecca identified three pillars that enable effective teams:
🏆 Business Outcomes — engineering work should always be aligned with business goals, and engineering leaders should understand what value they are creating for the company. Without this, technical work becomes misaligned, inefficient, and wasteful. That’s what happens in many companies Rebecca sees: engineers work in silos, disconnected from the business value their work creates.
🔨 Developer Productivity — this involves measuring and improving how work moves through the system. Good productivity metrics should evaluate and enhance the system as a whole, without targeting individual performance, to ensure a healthy work environment.
❤️ Developer Experience — which focuses on the qualitative aspects of a developer's work environment. You should understand and address engineers’ pain points to improve overall efficiency. These pains often do not surface through telemetry, but rather through surveys and good conversations.
So, while developer productivity and experience are closely linked, they address different aspects of the development process. Improving experience often leads to enhanced productivity, as happier developers are typically more engaged and effective.
You can find the full interview below 👇
3) 🎵 The Spotify model — in a nutshell
A couple of months ago we published an extensive guide on the famous Spotify engineering team model, including upsides, downsides, and Nicola’s personal experience with it.
In a nutshell, here is what the model is about:
Squads 🎽
A Squad is the basic team unit in this model, similar to a small startup team. The idea is to create mini-teams, each with the autonomy to manage their own projects as if they were a self-contained startup.
Each squad has the following characteristics:
👥 Small — typically they consist of less than 8 people, a size that supports agility and effective collaboration without becoming unmanageable.
🎯 Focused — they operate with a clear, focused mission, aligning their efforts to specific company goals or product areas.
🤝 Cross-functional — they are composed of members from various disciplines like development, design, and QA, enabling them to operate independently.
🚀 Autonomous — they have the autonomy to decide how they work, which technologies to use, and how to achieve their objectives best.
Over the years, Spotify's number of squads has consistently grown, leading to the introduction of more forms of structure:
Tribes 👥
Tribes are collections of squads working in related areas, within the same business domain or feature set. They provide:
⛑️ Support — they facilitate collaboration among its squads.
↔️ Alignment — so that squads do not drift into conflicting directions.
A tribe is led by a Tribe Lead, who focuses on providing the best environment for squads to succeed, rather than managing the specifics of projects.
Chapters 📙
Within tribes, individuals from different squads who perform similar functions — such as backend developers, testers, or PMs — are grouped into Chapters.
A chapter is a way to organize and standardize functions across the squads.
Each chapter has a leader, usually an experienced individual in the specific field, who is responsible for the growth and development of the members, even though they work in different squads.
Guilds 🪄
Guilds are interest groups that span the whole company and anyone can join, regardless of their tribe or squad affiliation. Example topics may be web development, user experience, or data science.
They are informal communities for sharing knowledge, tools, and practices and initiating wider discussions about these topics.
You can find our full guide with examples below 👇
And that’s it for today! If you are finding this newsletter valuable, consider doing any of these:
1) 🔒 Subscribe to the full version — if you aren’t already, consider becoming a paid subscriber. 1500+ 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