💬 Unblocked – Get the right answer, now
Developers know how to write code. Most often, what is slowing them down is having to search for the context to know what code to write.
That’s because codebases are a compilation of thousands of past decisions and discussions that live across multiple tools, like GitHub, Slack, Jira, Confluence, and more.
For this reason, I am happy this week to promote Unblocked, which surfaces hidden knowledge and gives engineering teams the answers they need to get their jobs done – without having to wait on or interrupt their teammates.
You can try Unblocked for free at the link below.
Back to this week’s ideas! 👇
1) 🔄 The W Framework
There are many company-wide systems that are challenging to put in place — think OKRs, engineering principles, or career frameworks — because they need to strike the right balance between being participated by the team (bottom-up) and following the vision of the leadership (top-down).
Both are needed:
⬇️ Top-down direction — delivers consistency and fast decision-making.
⬆️ Bottom-up contribution — makes things grounded with your team’s reality, creates consensus, and leads to better decisions in the end.
To achieve this, I am a fan of the W Framework for this, by Lenny Rachitsky and Nels Gilbreth.
It is made up of four steps:
🎯 Context — leadership shares a high-level strategy with Teams
🗺️ Plans — teams respond with proposed plans
🔄 Integration — leadership integrates into a single plan, and shares with Teams
🤝 Buy-in — teams make final tweaks, confirm buy-in, and get rolling
This is a generic strategy that you can apply to pretty much anything that requires wide participation.
What does it look like in practice? Here is an example that I adapted to create and rollout a career framework:
Context — leadership provides high level direction: fundamental levels and tracks based on current team composition and future strategy.
Plans — teams (e.g. your senior leaders) come back with the qualities and responsibilities they would like to see for the various levels.
Integration — leadership challenges, integrates these elements and shares back with teams.
Buy-in — Final tweaks, Q&A + people get assigned to the levels.
If you are interested in career frameworks, I wrote more about developing them in this past piece 👇
2) ⚖️ Startups vs big tech
Last month I talked with Rachel Potvin on the podcast. Rachel is SVP of Engineering at Sanity, which is a high-growth startup, and a former executive at Github and Google.
So, at some point, we naturally discussed similarities and differences between the two environments. Rachel pointed out two big things: strategy and agility.
Strategy 🔮
Rachel says how small teams have the advantage of being more focused and aligned on the mission, while big tech companies can become distracted and less focused as they grow.
One of the core advantages of startups is that leaders can fit in their heads the entirety of strategy, product, and everything that is going on. So they can really implement coherent, top-down plans, while still allowing for creativity from their teams about achieving goals.
E.g. at Google Cloud, Rachel worked with a large team of over 20,000 people, which made it impossible for any single person to know everything.
Agility ⚡
The scale of big tech also makes processes rigid and slow, while smaller companies are able to work flexibly and make changes quickly.
Rachel makes the example of when, at Sanity, they were building a new high-frequency caching layer which needed to support billions of requests per day. They figured out that, for the end user experience, they also needed a subscription API through which apps and websites could subscribe to the content, to go along with that.
The official event where they would announce the new caching was coming in a week, and they still were able to hack the subscription API in a few days and give a demo of it at the event. Such a speed wouldn’t have been possible at Github or Google.
You can find the full interview here 👇
3) 💼 Agencies and context
Working with an agency you trust can be a smart way to bring in full-stack product + engineering expertise for projects you don’t have either 1) the bandwidth, or 2) the skills for.
Still, not all projects are suitable for this kind of collaboration.
I have worked with agencies for 10+ years, and my main advice is to choose projects that are low-context.
Things are infinitely easier when your partner doesn’t need to know everything about your business & technology to get started.
So, speaking of context, there are many types:
✏️ Product context — how much business / domain knowledge is required to build the product? How much learning is required to do a good job?
🖌️ Design context — do you have a design language / system to build on, or you need to create one for this project?
🔨 Tech context — does the project plug into existing tech? Does your partner need to find their way into your code?
and more!
Even if some kind of context is inevitable, reflect on how much onboarding the agency will need with respect to the expected size of the work.
If the project is too ingrained in your workflows and has too many dependencies, working with a partner might not work out as you like.
A couple of years ago I interviewed two friends of mine who run successful agencies and delivered hundreds of projects, and wrote a full piece about this topic 👇
And that’s it for today! If you are finding this newsletter valuable, consider doing any of these:
1) 🔒 Subscribe to the paid 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