Space for innovation, continuous things, and scaling yourself 💡
Monday Ideas — Edition #178
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
1) ⚖️ Build or Buy? Yes
This idea is brought to you by today’s sponsor, Aboard!
I have known Aboard for a while now and I am happy to promote it in today’s newsletter, because to me it is the perfect example of what today can be uniquely enabled by AI.
Aboard is a development platform — it lets you build software with AI, but it also has human experts who can guide you, take over and take it across the finish line.
So you can seamlessly go from prototypes (which, let’s admit, is where vibe coding usually stops) to tightly-crafted, production-ready code, while keeping things fast and cheap.
You can learn more below 👇
2) 🪄 Making space for innovation
My friend Aviv Ben-Yosef argues engineering teams often overly fixate on tech debt, while they should think about tech capital: improving devex, empowering teams with great internal tools, and more.
But how do you make space for it in a packed roadmap? Here is his advice:
🎒 Piggybacking — the easiest first step is piggybacking, following the “Boy Scout Rule” from Clean Code. Are there ongoing tasks where a small experiment can be added without too much risk or time?
🗓️ Intermissions — real experiments require more time. Enter Intermissions — innovation weeks where teams focus on shortened iterations to explore novel ideas and create tech capital. Teams work on experiments for a week, get close to completion, and make informed decisions about next steps.
⭐ Focus on novelty and embrace failure — avoid using intermissions for routine “tech debt” tasks. Focus on novel experiments that aren’t guaranteed to work—if everything succeeds, you’re not innovating! Celebrate good bets even when they fail.
🤏 Start small — Start with a single intermission, even just four days or with select groups. Done well, you’ll demonstrate enough value to secure buy-in for future ones. I’ve seen skeptical CEOs become enthusiastic after witnessing their first successful intermission.
You can find the full article below! 👇
3) 🔄 Continuous… things!
There is still a lot of confusion about the differences between continuous integration, continuous delivery, and continuous deployment, so here is a recap:
🥉 Continuous Integration — means that pushing new code into a shared repository triggers an automated build & testing process. Example: a dev opens up a PR → automated tests run in CI → if tests pass, the code can be merged into the main branch.
🥈 Continuous Delivery — means that code on the main branch can be deployed at any time — i.e. it is always in a deployable state. Example: code passes CI tests → it is automatically deployed to a staging environment → a human manually approves the release to production.
🥇 Continuous Deployment — means that every change that passes automated tests gets automatically deployed to production.
So, continuous deployment extends continuous delivery by removing manual approvals. This enables faster feedback loops and ensures code changes don’t get stale or batched in pre-prod stages like staging.
Small + frequent changes vastly reduce risk and improve developer productivity because there are fewer handoff steps.
Also, deploying code doesn’t necessarily mean releasing it! In fact, you can decouple the two things with things like canary releases, feature flags, and more.
We covered many of these techniques in our 2025 tech radar at the beginning of the year 👇
I went through it again recently and I have to say I am pretty happy with the things we included! Even with all the AI craze, it held up pretty well!
4) 🎙️ Camille Fournier’s advice on scaling yourself
One of my all-time favorite interviews on the podcast is the one with Camille Fournier, author (among other things) of the timeless book The Manager’s Path.
During the interview, Camille shared some timeless advice for founders and tech leaders about scaling their work:
Find your “area of genius” 🌟
To stay engaged in daily work and not fall into detached manager mode, she advises to identify their “area of genius”:
I think, as a founder, you’ve got to figure out what your thing is. Like, what is the genius that you have brought to this business where you just have that clarity of view?
She points out this could be in product development, marketing, or shaping company culture. Leaders should focus on these areas while delegating others.
Delegate wisely + stay accountable ⚖️
She also stresses the need for balance in delegation:
You have to pay some attention unless it’s totally unimportant. And then you may ask yourself, […] why are we doing it at all?
She stresses that even for delegated areas, leaders need to understand how to manage them effectively from an accountability perspective.
Cut unnecessary red tape 🚫
Camille also cautions against excessive bureaucracy, especially during growth:
Please pay attention to your bureaucracy. That is one of the most important things you can do if you want to stay in founder mode […] be a successful company is like constantly evaluate the processes and ways of working and ask yourself, you know, do we need this extra approval? Do we need this meeting?
Here is the full interview with Camille:
You can also find it on 🎧 Spotify and 📬 Substack
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. 1700+ engineers and managers have joined already! Learn more about the benefits of the paid plan here.
2) 📣 Advertise with us — we are always looking for great products that we can recommend to our readers. If you are interested in reaching an audience of tech executives, decision-makers, and engineers, you may want to advertise with us 👇
If you have any comments or feedback, just respond to this email!
I wish you a great week! ☀️
Luca