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
Product Methodology Survival Guide 📚
This idea is brought to you by today’s sponsor, Atono!
Planning gets messy when different teams work in different ways. One team runs sprints, another uses Kanban – leadership still needs to know what’s shipping next quarter.
Atono just published their Product Methodology Survival Guide, sharing how they made cross-team planning predictable inside their own engineering org – without forcing everyone into the same process.
We’ve also previously collaborated on pieces like The AI Productivity Paradox and How to Build a Product Engineering Culture, so if you’ve enjoyed those, this guide goes deeper into the operational side.
1) 📋 Keep backlogs radically short
Speaking of Atono, this reminded me of one of the ideas we discussed in one of our articles together: backlogs — and how much we hate long ones!
Shipping fast in a sustainable way requires discipline about what you actually build. Long backlogs are one of the biggest hidden anti-patterns in product teams:
They demoralize the team — by removing the feeling of progress.
They are ineffective at capturing priorities — because items stay there for a long time, becoming sneakily obsolete.
They lead you to say yes to everything — counterintuitively, it is harder to reject feature requests when the backlog is already long, because “it’s just one more thing”. So you put it there, people get pissed when you assign “P3” to it, then you don’t touch it for six months, then it’s completely obsolete, then you delete it and piss the requester a second time.
Mary Poppendieck, Agile legend with 30+ years of experience, says “burn your backlog” every time she can, and that you should rather focus on flow:
Once you’ve established your current output rate, then you have to stop accepting anything beyond that rate. No backlog. If you can only do ten a month, you only accept ten a month. And you don’t accept work beyond a month or two.
— Mary Poppendieck
The Atono team only keeps 2-4 weeks of committed work, which means PMs and engineers reject work all the time. Small feature with unclear impact? Reject. Hard to reproduce bug on niche device? Reject. This discipline is what keeps them focused and fast.
You can find the full guide below 👇
2) 🔨 Interview methods for 2026
One of the obvious consequences of AI coding getting widespread is that the methods for interviewing engineers that worked just 2-3 years ago, are not working well anymore.
Last year I surveyed the community and ran a mastermind session with engineering managers to find out how they are adapting.
With some degree of simplification, there are three main things worth testing in any engineering interview: pure coding skills, system design ability, and how well someone works with others. The weight you give each depends on the role, but there’s a clear trend: with AI, pure coding matters less, while system design and collaboration matter more.
This reshuffles the classic methods.
LeetCode questions, long despised, have fallen further, as 90%+ can be solved with AI. Take-home assignments have a similar problem: open-ended + greenfield coding is just too convenient for models, making it hard to test real depth.
For replacing them, two methods stood out in the community:
🔬 Case studies — you bring a real problem your team worked on and ask the candidate to design a solution live. It tests system design, trade-off reasoning, and communication simultaneously.
🔍 Code review — give the candidate a PR to review. It’s faster than a take-home, generates rich discussion, and tells you a lot about someone’s taste and judgment.
Career highlight stories remain consistently useful at the end of any process, letting candidates show qualities that didn’t emerge elsewhere.
You can find the full guide below 👇
3) 🎙️ Evergreen career advice for engineering managers
A couple of years ago I interviewed Camille Fournier, author of The Manager’s Path and veteran engineering leader. She offered four main pieces of advice for engineering managers looking to stay valuable and advance their careers, which are just as relevant today:
1) Focus on relationships 🤝
Camille emphasizes the importance of good relationships at all levels:
Reports — people have to want to work for you
Peers — people have to want to work with you (peers and other teams)
Superiors — your superiors have to want you to work for them
2) Maintain technical credibility 💻
For technical leadership roles, Camille suggests maintaining enough technical knowledge to ask good questions and understand the work:
“I can ask people really good questions about what they’re doing and often understand what they say to me. And so […] because I work in pretty heavily technical areas, people like that.”
3) Represent the company well 🏢
She reminded managers that they are representatives of the company:
“You are representative of the company. You can influence the company culture. But a lot of the value and the expectations of you is like, if your boss says you have to do something or something has to happen, how good are you at driving that thing to happen?”
4) Learn continuously 📚
Camille encourages managers to stay curious and open to new ideas:
“You’ve got to challenge yourself to look outside of your own world, talk to managers at other places, make friends externally that are managers and hear about what they’re doing and just stay curious.”
You can find the full interview below 👇
You can also find it on 📬 Substack and 🎧 Spotify.
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
You’re still building that note taking app Luca? Hoping to see it..