You don’t need a three-month backlog to build great software. But you do need to know what you’re doing.
If you are a Software Engineer or Tech Lead working on experimental projects, R&D teams, or internal tools, and you are looking for how to balance rapid innovation with solid engineering standards, then this email is for you.
In today’s issue, I want to share the hard-won realities of working in experimentation teams, where there is a lack of Software Engineers, and why your core engineering instincts are still your best skill.
Before you continue, if you enjoy my work and would like to support the newsletter, I’d really appreciate it if you shared it with a fellow engineer:
💚 On WhatsApp | 💙 On LinkedIn | 🩵 Bluesky
Or simply forward this email to someone who might find it useful.
🎯 1. Forget the 3-Month JIRA Backlog: The Reality of Experimentation
When you land in an R&D or experimentation team, the day-to-day looks completely different from traditional product development.
You aren’t building features for a three-year roadmap.
You are running experiments and building proofs-of-concept (PoCs).
In this environment, rigid Scrum sprints and endless backlogs take a back seat.
👉🏼 You don’t waste time grooming JIRA tickets for three months out. Please don’t unless your manager tells you to.
Instead, work is defined every week with razor-sharp objectives:
Setting up automated CI/CD for infrastructure.
Deploying microservices cleanly from day one.
Ingesting a brand new data source into the system.
You name it.
🧐 Scenario vs. Solution: If you try to apply heavy enterprise bureaucracy here, you die of slow-moving friction. Your experience tells you how to scope your own domain and deliver results. Lean into that.
Good, those agile ceremonies are out of the way... Now, what do you have to settle down from the start?
🗝️ 2. Build the Foundations, Even When Nobody Asks
In my experience, on teams like this, no manager is going to explicitly ask you to write unit tests or set up automated CI/CD pipelines for your AWS Lambdas.
👉🏼 They care about the core objective and speed.
The “how” is entirely up to you.
And they will only ask questions if something breaks.
☝🏼 But you and I both know that something will break eventually (yes, you know it by heart).
If you don’t lay down proper software engineering foundations from the start:
Nobody else will do it for you.
As the project evolves, your velocity will hit a brick wall.
And that completely defeats the purpose of an experimentation team.
👉🏼 Always put the foundations in place on day one: CI/CD pipelines, automated infrastructure deployment, and decent test coverage for production-bound code.
When your team sees how smoothly everything runs, those smiles around the room will remind you why you did it.
You have your pipelines and tests locked in... But how do you prove your progress to stakeholders on experimentation teams?
🚀 3. Demo or Nothing
In traditional product development, you are probably used to bi-weekly sprint reviews packed with slick PowerPoint slides (probably generated with Claude) to justify your existence.
In an experimentation team, that doesn’t fly.
When speed and validation are everything, slides aren’t just unnecessary—they are unwanted.
You need to show value instantly, directly, and tangibly.
🧐 For example, if you just upgraded your infrastructure CI/CD pipeline:
Don’t say: “We improved deployment speed by 3x using optimized caching.”
Do say: “New features can now be tested live in production in under two minutes instead of ten.”
Another example: if you just integrated a new data source into the backend:
Don’t explain: “We implemented an AWS Step Function coupled with an asynchronous Lambda parser featuring exponential backoff retries.”
Do show: Open the UI and let your stakeholders see the live data exactly how an end-user would experience it.
☝🏼 Your experience tells you that working software is the only currency that matters.
In fact, your manager would rather cancel a meeting than sit through a slide deck if there is no working demo to look at.
Those are the hard-won lessons from the experimentation trenches... Let’s wrap up for today.
✨ Summary & Takeaways
Ditch the Bureaucracy: R&D teams thrive on weekly, high-impact goals rather than months of locked-in JIRA backlogs.
Enforce Foundations Early: Nobody will ask you to write tests or set up CI/CD for your Lambdas—do it anyway to protect your future velocity.
Show, Don’t Tell: Skip the presentation slides. Deliver working software and speak the language of real-world outcomes.
👉🏼 Experimentation doesn’t mean abandoning good software engineering practices. It means applying them in a way that helps you learn, validate ideas, and deliver results faster.
You already have the experience. Use it to help your team move quickly without sacrificing the foundations that will make its work sustainable.
Drop a message in the comments or reply to this email; I read and reply to all!
Best,
Marcos.