Hey, Luca here, welcome to a weekly edition of the💡 Monday Ideas 💡 from Refactoring! To access all our articles, library, and community, subscribe to the full version:
Resources: 🏛️ Library • 💬 Community • 🎙️ Podcast • 📣 Advertise
Join our yearly industry report and win $150! 🗳️
Once or twice a year we run broad surveys to investigate the state of some important part of software engineering. We have done that in the past with AI adoption, engineering maturity, and more.
This time we want to understand what the development process looks like for teams today! Many trends have been steering it for the past few years (AI, product engineering, devex, and more), so we would like to report an updated picture for 2026.
You can answer the survey below, it should take only ~7 minutes 👇
The questions will also make you reflect on your own process, so there is utility in that! And, as always, respondents have the chance to win one of 20 Refactoring memberships ($150 value).
1) 🎨 Generalists for product + specialists for platform
I have been thinking long and hard about the role of generalist and specialist engineers in modern teams.
When you look at what the best teams do, there is a recurring pattern:
📱 Generalists work on product
🧱 Specialists work on platform
The best way to use e.g. a senior frontend engineer’s skills is not to build yet another form, but to build the component system that empowers others. That’s 1) a higher-leverage use of their time, and 2) more engaging and rewarding work for them.
So generalists scale throughput, while specialists scale quality.
You might call one “product engineering” and the other “platform engineering”, but the two are closer than they may seem. Good platform engineering suspiciously looks like product engineering, but where your customers are other engineers.
Platform engineers do pretty much the equivalent of what the best product engineers do: they design products (tools), build things that customers want, dogfood them, and ship things from top to bottom.
I wrote more about this in this recent take on what a great team looks like today 👇
📋 AI docs cheatsheet
You see everywhere that AI changes documentation, what’s worth documenting, and so on. But how? Here is my cheat sheet:
Provide business context — As humans, we often outperform AI only because we have more context into specific business nuances. These would be tedious to include in individual prompts, so provide them upfront. Hayden Miyamoto pioneered this with the Master Prompt method: a long one-pager where AI can learn everything about your company, team, and goals.
Capture decisions — The most valuable human docs aren’t descriptions anymore (have they ever been?!), they are decisions. E.g. ADRs (Architecture Decision Records) work like append-only logs: you don’t update them when things change, you write a new decision that supersedes the old one. AI can trace this evolution and understand the current state, history, and the why behind decisions.
Keep docs simple and close to the action — Markdown wins over complex formats. Docs in repos get the double benefit of being in the same context space and easy to update with code.
Automate the How — Trust AI to own the implementation layer: code comments, API docs, runbooks. Enforce updating these at every commit for disciplined doc history.
Connect AI to all your tools — Finally, knowledge is scattered across Linear, Slack, repos, and wikis. Use AI as a horizontal layer to navigate it all.
I wrote a full guide on this here 👇
3) 🎙️ The SCARF Model
Last October I interviewed Meg Adams on the podcast, and we talked about Neuroleadership.
Neuroleadership applies neuroscience research to leadership contexts, focusing on how brain structure and nervous system function impact thinking, feeling, and decision-making.
One of the ideas that stuck the most with me was the SCARF model, which represents five domains that our brains continuously evaluate in social situations:
🏆 Status — how important we feel compared to others
🔮 Certainty — how predictable the future feels
🎮 Autonomy — our sense of control over events and choices
🤝 Relatedness — feeling of connection and safety with others
⚖️ Fairness — evaluation of whether exchanges and decisions are just
“Our brains respond to social situations much like physical threat and reward. Think of how you might feel if I was holding a knife versus if I was handing you a plate of warm cookies that I made just for you.”
When these domains feel supported, our brain’s reward circuitry activates — we feel collaborative, open to change, and perform at our best. When threatened, the threat circuitry kicks in instead, limiting resources to planning and reasoning while scanning for more threats.
For engineering teams specifically, certainty and autonomy tend to be the most frequently triggered. Engineers often struggle with moving goalposts and lack of control over their time and work approach.
Here is the full interview with Meg:
You can also find it on 🎧 Spotify and 📬 Substack
And that’s it for today! If you are finding this newsletter valuable, subscribe to the full version!
1700+ engineers and managers have joined already, and they receive our flagship weekly long-form articles about how to ship faster and work better together! Learn more about the benefits of the paid plan here.
See you next week!
Luca