I’ve been working in tech for a while, and one thing that’s becoming increasingly difficult to ignore is how quickly software development is changing.

Features that once took months to build can now be delivered in weeks, sometimes even days. Better tools, automation, and AI are accelerating the entire software development lifecycle.

But while much of the conversation focuses on how this changes the way we build software, I’ve been noticing something interesting from the other side.

The software we use every day is getting better, and as consumers, we’re starting to feel the difference.

My changing experience with Air Canada

I used to avoid Air Canada whenever I could.

It wasn’t necessarily about the flights themselves (mostly 😉). The digital experience just wasn’t something I could reliably depend on. Finding the right information could be frustrating, and the app didn’t always have what I needed.

After a few recent trips, that perception has changed quite a bit.

The Air Canada app has become something I actually enjoy using. From flight delays and incoming aircraft information to gate changes and in-flight details, it has become a much more useful companion throughout the journey.

Even the ability to arrange an Uber through the Air Canada app makes the experience feel more connected.

Individually, these might not seem like groundbreaking features. But when you’re travelling, having the right information at the right time makes a real difference.

Travel is stressful enough without having to jump between apps, search for updates, or wonder whether the information you’re looking at is current.

The app has gone from something I didn’t particularly trust to something I actively rely on. And that has changed how I feel about the airline itself.

That’s a meaningful outcome for what is, essentially, a software experience.

Uber is another example

Uber has also been making its core ride experience more thoughtful.

Booking a ride is straightforward, but some of the capabilities go beyond simply getting you from one place to another.

Consider airport trips. Using flight details as part of the destination information adds useful context. Combined with route options, including toll roads where available, this can help make the journey more predictable when getting to the airport on time matters.

Then there are the smaller details: pinning the pickup location, setting preferences around conversation and cabin temperature, and specifying luggage requirements.

None of these features will change the world on its own. But they address the little things that can make an otherwise ordinary experience frustrating.

The product starts to feel less like a tool that simply executes a request and more like one that accommodates how you actually want to use it.

Uber Eats, on the other hand, is still a sh*tshow in my experience. But Uber Rides? That’s a different story.

And that contrast is worth noting. A company can deliver very different experiences across its products. Having the same brand doesn’t automatically mean every product is equally good.

The real benefit isn’t more features

These experiences got me thinking about what faster software development actually means for us as consumers.

For years, we’ve talked about development velocity. How quickly can teams ship features? How much can they deliver in a release?

Those are useful questions, but they don’t tell us whether the product is getting better.

A product can ship dozens of features and still be frustrating to use.

The more interesting question is how quickly a team can turn a real user problem into a meaningful improvement.

Historically, even a relatively small improvement could compete with months of engineering work, testing, and release planning. Teams had to be selective about what they built, and smaller quality-of-life improvements could easily fall behind bigger initiatives.

As the time and effort required to develop software come down, that calculation changes.

More small improvements become viable. Teams can experiment, learn from how people use their products, and make adjustments without every change becoming a major undertaking.

And those improvements compound.

A better notification might not make much difference on its own. Neither will a more reliable source of flight information or another ride preference.

But when enough of these improvements come together, the entire experience changes.

The opportunity isn’t simply to ship more features. It’s to make products better, more often.

What happens when building gets easier?

AI is an important part of this shift, but it isn’t the whole story. Better development tools, mature infrastructure, automation, and established software platforms have all helped reduce the effort required to build and release changes.

AI is accelerating that progress further.

But making software easier to build doesn’t automatically make it better.

We can build unnecessary features faster, introduce bugs faster, and make products more complicated without making them more useful.

If implementation becomes less of a constraint, knowing which ideas deserve that effort becomes even more important.

Understanding users, identifying the right problems, prioritizing effectively, and knowing what not to build still matter. Perhaps they matter even more now.

The advantage won’t necessarily belong to the teams that ship the most. It may belong to the teams that can identify a problem, deliver a meaningful improvement, understand whether it worked, and repeat that process faster than their competitors.

That’s a much more useful way to think about development speed.

The consumer should be the real beneficiary

What excites me about this shift isn’t the idea that we can produce more software with less effort.

It’s the possibility that we won’t have to live with frustrating software for as long.

An airline app that once left you searching for information can become something you rely on. A ride-hailing app can account for more of your preferences and the context around your journey. Everyday experiences can improve through small, continuous changes rather than waiting for the next major redesign.

Of course, faster development doesn’t guarantee that companies will make the right decisions. Some will use it to flood their products with features. Others will focus on shipping faster without asking whether any of it actually helps.

But the opportunity is there.

We’ve spent years trying to make software development faster. Now, we’re starting to see what that speed can mean for the people using the products we build.

The real measure of progress isn’t how quickly we can build software. It’s how quickly we can make life a little easier for the people using it.

That’s it for this one, folks!

If this resonated with you, I’d love to hear your thoughts. Have you noticed the same shift in the apps you use every day? Thanks, as always, for reading all the way to the end. If you’d like to support my work, feel free to buy me a coffee.

Signing off,
Kavindu Narathota
blog.narathota.com

Because finding the right chords shouldn’t be harder than playing the song.

I’ve had a guitar in my hand for most of my life. Not because I was ever planning to be a musician, but because music always had a way of finding me.

I didn’t grow up in a particularly musical family, yet music somehow always showed up at the right moments, at house parties, school functions, or those evenings when a song would turn into a singalong without anyone planning it.

In middle school, I had to pick an elective. Eastern music, Western music, drama, or art. My sister had chosen Eastern music a year earlier, and since I was already tagging along to her classes, I went with it too. That’s how my formal connection to music began.

Our home slowly turned into a mini music corner, a Yamaha keyboard, a violin my sister used, and eventually, my first guitar when I was in Grade 7. It instantly became my favorite. It wasn’t just an instrument; it was a doorway. It made me one of the “cool kids” back then, sure, but more importantly, it gave me a way to express things words couldn’t.

All through high school and beyond, I played in school bands and orchestras. I wasn’t a pro by any means, but I could read sheet music, follow chords, and play with others. I always felt comfortable when I had the chord chart or notation in front of me. I still remember carrying a small songbook in my guitar case, pages filled with scribbled chords, notes, and lyrics I wanted to remember.

When smartphones took over, that little book got replaced by free chord websites. And for a while, it worked… until it didn’t.

The Problem: Too Many Chords, Too Many Tabs, Too Little Flow

As much as I’ve always loved playing music, these days it’s more of a weekend ritual, usually with my toddler as the audience. But even for a casual musician, the friction starts early. Every week, I find myself playing the same set of songs, yet still needing to look up the chords each time.

That means hopping between multiple tabs, digging through saved links, or trying to reopen that one website buried in my history. Most chord sites today are cluttered with ads, popups, and autoplay videos, and when you’re trying to keep a toddler entertained while juggling a guitar, that experience gets frustrating fast.

It reminded me of how this problem isn’t new. Years ago, when we’d grab a guitar at a house party or a late-night hangout, we’d waste half the time searching for the right version of a song. Someone would find a site full of broken formatting, another would pull up a YouTube tutorial that didn’t quite match, and before we knew it, the mood was gone.

There are tools for everything now — music streaming, editing, recording, but none built around the simple experience of storing, organizing, and recalling the chords you actually play. Something that helps you focus on the music instead of managing the mess around it.

The Spark: From Frustration to a Simple, Practical Solution

As a product manager, I’m wired to think in systems and solutions. So when the same pain kept repeating every week, I decided to approach it the same way I do at work, identify the problem, test ideas, and design something that actually works.

At first, I just wanted to solve my own problem. I thought, what if I had a single place to keep all my chord links neatly organized? Somewhere I could create folders by artist or mood, and when I wanted to play, just open one app and tap on a song instead of searching all over again.

That simple thought became the starting point. I drafted the requirements, listed out pros and cons, and walked through the same product-thinking process I use for professional projects. But the more I explored the idea, the more I realized it could be much more than just a personal shortcut.

Why stop at saving links? What if the chords themselves lived right inside the app? No ads, no clutter; just clean, readable chord sheets you could access anywhere, even when you’re offline.

After some late-night research, design iterations, and early testing with a few other hobby musicians, the concept started to take shape. And that’s how ChordVault was born. A space built for everyday musicians like me who just want to play without the hassle.

Now, weeks later, that early idea has grown into a working app that’s ready for anyone who’s ever struggled with the same messy process.

Let me show you what ChordVault can do.

What’s Inside ChordVault

At its core, ChordVault is built to make playing music simple again. No distractions, no messy tabs, no searching for that one song link you swear you saved last week. Just open, pick, and play.

Here are a few highlights:

🎵 The Public Song Library
A growing, free-to-access library available to anyone, anywhere. Songs are grouped by artist, country, language, and genre, so whether you’re into Sinhala classics, indie hits, or modern pop, you’ll find something familiar waiting.

🔐 Your Personal Vault
This is the heart of the app. Signed-up users get their own Vault, where they can store up to 50 songs for free, either by adding from the ChordVault library with one click or by saving links from other chord sites. It’s your personal songbook, finally in one place.

🗂️ Vault Folders
Create folders to match your vibe or occasion. Got a list of songs you always play at family gatherings or campfires? Group them in a folder and jump straight into the mood when the guitar comes out.

💎 Upgrade When You Need
For those who need more space, we’ve kept the paid tiers simple and affordable. Unlike most alternatives that lock you out without a subscription, ChordVault always has a free tier because music should be accessible to everyone.

✨ And That’s Just the Start
Smart tagging, auto-scroll with “screen always on,” offline mode, and a built-in chord view for guitar, ukulele, and piano, all designed to make playing seamless on both web and mobile.

But this is only the beginning. The future of ChordVault looks bright, expanding beyond hobby musicians into early-stage bands, jam groups, and even party playlists that never stop. Imagine discovering songs, learning to play like a pro, or getting instant chord suggestions for your next get-together all in one place.

Because the goal isn’t just to store music. It’s to make playing music effortless again.

From a Personal Fix to a Public Launch

What started as a simple frustration, having to search for the same chords every week, closing ads, and juggling tabs while trying to keep my little one entertained turned into something much bigger.

I didn’t set out to build the next big music playing app ever. I set out to solve my own problem. But like most good ideas, I soon realized this wasn’t just my problem. It’s something every hobby musician has faced, from house parties and road trips to lazy weekend jams.

So, I did what I do best as a product manager. Took a problem, explored the possibilities, and built a solution worth using. That solution became ChordVault.

Today, ChordVault is live and open to anyone who loves playing music, whether you’re a beginner, a hobbyist, or someone picking up the guitar again after years. It’s for those who still believe that playing a song shouldn’t require battling ads or digging through bookmarks.

Music should be easy, fun, and spontaneous, just like it used to be.

So go ahead, give it a try at chordvault.online. Explore, save, and play your favorite songs the way it should be, simple and distraction-free.

Alright folks, I know this isn’t my usual type of article, but I wanted to tell this story. Unlike most of my hobby projects that quietly live on my computer, this one felt different. I wanted to share it with the world.

This aligns with my life motto: so me and someone can be better at something than yesterday.

I’m not going to ask you to support me through a “Buy Me a Coffee” this time. Instead, show your support by using ChordVault. Try it out, share your feedback, and help me make this app even better for everyone who loves playing music.

Signing off,
Kavindu Narathota
blog.narathota.com — chordvault.online

Last week, I caught up with someone I used to mentor. After a bit of life talk, our conversation drifted to work and to a question I’ve heard more than once: how practical is it to take on multiple responsibilities within a team, especially across product and engineering management?

It’s a fair question. In smaller companies, wearing both hats can work just fine. Feedback loops are short, teams are close, and decisions happen fast. But as organizations grow, those blurry lines start to hurt. The same overlap that once created speed can quickly turn into confusion, competing priorities, and conflict.

That chat got me thinking about a dynamic I’ve practiced for as long as I can remember, one I partly learned and mostly tested through experience: the Product Manager + Principal Engineer and Engineering Manager + Tech Lead partnership.

Let’s talk about it.

The Challenge: When Lines Blur

In smaller teams, it’s normal, even necessary, for people to wear multiple hats. The product person might also handle delivery. The engineering lead might act as a pseudo–product manager. Everyone jumps in wherever needed, and it works because context lives in everyone’s heads.

But as organizations grow, that shared context starts to fade. Communication scales slower than people do. Suddenly, what once felt like collaboration starts to feel like collision. Who owns what becomes fuzzy. Product starts to dictate engineering details, engineering starts to reprioritize roadmap items, and the in-between gets messy.

It’s not that anyone’s doing the wrong thing, it’s that the boundaries aren’t clear anymore. Teams need more than good intentions to stay aligned; they need clarity on who’s steering and who’s driving.

That’s where this partnership comes in.

The Partnership: Strategy Meets Execution

Every successful foundations or feature team I’ve seen has this quiet rhythm, the balance between those who look ahead and those who make things happen.

If we put it in startup terms, it’s like having a CEO and a COO for your team.

• The Product Manager and Principal Engineer play the strategy role: they define where the team should go, why it matters, and what bets to make for long-term impact.
• The Engineering Manager and Tech Lead drive execution: they focus on how the team actually gets there, how to organize delivery, manage tradeoffs, and build with quality.

Strategy (PM + Principal Engineer)

This pair looks further out, two quarters ahead or more. They define the “why” and the “what” in the context of business and technical strategy.

• The Product Manager frames opportunities, writes product briefs, and identifies where the team can create the most leverage.
• The Principal Engineer shapes the technical vision, architecture direction, and design tradeoffs that make that leverage possible.

They ask questions like:

• What will give the most long-term value for the organization?
• What technical debt are we willing to carry and what must we fix now
• How do we align our roadmap with the company’s direction?

Together, they set the course. But they don’t sail the ship alone.

Execution (EM + Tech Lead)

Once the direction is set, the Engineering Manager and Tech Lead translate strategy into motion.

• The Engineering Manager ensures the team can deliver through planning, people, and process.
• The Tech Lead ensures the “how” by designing practical solutions, guiding engineers, and unblocking delivery.

They handle the realities of execution:

• What can the team commit to this quarter?
• What technical compromises are acceptable for delivery?
• How do we balance velocity with stability?

In well-aligned teams, this dance feels natural.

• The PM and Principal Engineer look ahead, adjusting the compass.
• The EM and Tech Lead focus on the road immediately ahead, steering around obstacles.
• And they all keep talking strategy feeds execution, execution grounds strategy.

Now, if we map this partnership out clearly, it looks something like this…

The RACI: Who Owns What

To make this partnership concrete, here’s a practical way to think about who’s responsible, accountable, consulted, or informed for key areas in a foundations team.

• Half/Quarterly Planning: The PM is accountable for the roadmap deciding the initiatives the team should pursue and prioritizing them. The EM and TL are responsible for doing the technical discovery: figuring out feasibility, dependencies, effort, and constraints. They then provide the PM with a set of actionable projects that will achieve the intended outcomes. The PE is consulted to ensure alignment with the long-term technical vision.
• Roadmap & Priorities: PM leads and owns it, but PE provides critical technical input; EM and TL stay informed to adjust execution.
• Technical Vision: PE owns it, PM is consulted to align with product direction, TL helps operationalize it.
• Delivery Planning: EM leads execution planning; TL designs practical solutions; PM and PE provide context.
• Solution Design & Tradeoffs: TL and PE work closely, EM ensures the plan is realistic, PM is consulted for business impact.
• Team Health: EM leads, but everyone has a role in mentoring, guidance, and communication.

This setup makes the responsibilities practical and grounded in day-to-day reality, showing how strategy and execution feed into each other without creating confusion.

Making It Work: The Real Partnership

Having the roles and responsibilities mapped out is one thing. Making them work in practice is another. Over the years, I’ve seen this structure thrive and I’ve seen it stumble and it always comes down to trust, respect, and feedback.

Trust that each person will own their domain. Respect that each perspective whether it’s long-term strategy or immediate execution matters. And feedback, honest and constant, so that the strategy adapts to reality and execution stays aligned with the bigger picture.

In real-world teams, this looks like:

• Regular alignment: Weekly or biweekly check-ins between PM/PE and EM/TL keep everyone on the same page.
• Collaborative planning: PM brings ideas; EM/TL validate feasibility and surface constraints; PE ensures technical vision isn’t compromised.
• Grounded feedback loops: TLs and EMs provide real-world context that helps PMs make better strategic decisions.
• Mutual accountability: Everyone understands where they own decisions and where they influence outcomes.

Of course, no two organizations are identical. Some might blur these roles, combine responsibilities, or have slightly different structures. That’s fine the names aren’t the point. What matters is that the work gets done, aligned, and thoughtfully executed.

At the end of the day, it’s not about the title it’s about how well we play together.

How does your team handle the balance between strategy and execution? Do roles overlap smoothly, or do things get messy?

I’d love to hear your experiences, thoughts, or even frustrations drop a comment, send a message, or share this with someone who’s navigating the same challenges.

And if you enjoyed reading this and want to support my writing, feel free to buy me a coffee ☕.

Signing off,
Kavindu Narathota

How a YouTube channel became part of our parenting journey and reminded us that stepping back takes strength

When our son was born in the middle of summer last year, life slowed down in the best (and sometimes most exhausting) way. My wife and I were both home on parental leave, learning to be parents, changing diapers on repeat, and doing our best to keep this tiny human fed, clean, and comforted. Days blended into nights, sleep came in short bursts, and our TV became more of a sound machine than anything else.

But at some point, maybe a week or two in we found ourselves scrolling YouTube, hoping to land on something easy to watch. Nothing loud or chaotic. Just something we could play in the background while feeding the baby or grabbing those precious few minutes to sit on the couch together.

That’s when we stumbled upon a man walking through the snowy Alaskan mountains, carrying a pack, building a shelter with his bare hands, cooking a meal over fire, and talking directly to the camera with a calm, humble tone.

And that’s how Outdoor Boys entered our lives.

A Summer of Diapers and Discovery

The next video auto-played: same guy, now deep in the swamps of Louisiana, catching bullfrogs with his hands, eating crawfish, and again, just talking to the camera. No flashy editing, no gimmicks, no overhyped thumbnails. It was real. It was different. And weirdly, we couldn’t look away.

We weren’t outdoorsy people by any stretch. But something about these videos clicked. There was a rhythm to it. A calm energy. The kind of content that doesn’t demand your attention but earns it. Before we knew it, we were watching three or four episodes back-to-back, baby in arms, genuinely entertained. I hit the subscribe button, and for me, that’s rare. I keep my YouTube subscriptions clean, because it’s not just entertainment. It’s where we learn, unwind, and sometimes escape.

Then we learned something else: Outdoor Boys published new videos every Saturday. That was it. A new kind of ritual began. Saturday mornings became Outdoor Boys mornings. While our son napped nearby, my wife and I would sit down with coffee in hand, watching a man and his three boys fish, camp, cook, and explore the outdoors with curiosity and joy.

The Dad Behind the Camera

The more we watched, the more we realized that Outdoor Boys wasn’t just about outdoor adventures. It was about family. About doing things together. And behind it all was Luke, a husband, a dad, and someone who clearly lived his values.

Whether he was building a forge, catching crawfish, or smoking ribs in the woods, there was always intention behind it. His kids were often part of the action Tommy, Nathan, and Jacob, not staged or scripted, but involved and curious. It reminded us of what it means to parent with presence. Let your kids get muddy. Let them try. Let them be part of your world.

And it wasn’t just the boys. His wife, Becca, lovingly referred to as “Mama” would pop into videos from time to time. Sometimes you’d see Luke’s parents, his siblings, or extended family joining in. You could feel it: this wasn’t just a YouTube channel. It was a family effort.

Even beyond the screen, Luke’s life was impressive. We later learned he had been a missionary in Japan and, after returning to the U.S., built a successful legal career as a traffic attorney. It all made sense his calm presence, his cultural respect, his well-researched and articulate way of explaining things. He wasn’t just winging it for clicks. He cared about getting things right. And somehow, that came through in every video.

When Weekly Wasn’t Sustainable

At one point, Luke shared that he was changing the upload cadence, from every Saturday to every other week. He mentioned it casually in a video, like he was just letting a few close friends know. No dramatic explanation, no apologies just a simple truth: putting out a new video every week was starting to be a lot.

And honestly, it made sense. My wife and I looked at each other and nodded. We’d wondered before how he managed to film, edit, plan, parent, and still make everything feel effortless. The shift felt like a healthy choice the kind that a lot of creators struggle to make. But Luke made it without any fuss.

We kept watching, of course. If anything, the two-week rhythm made the videos feel more special. Like waiting for a letter from a friend you haven’t heard from in a while. We’d sit down on Saturday mornings, not just to watch, but to feel connected again to something that had become part of our parenting journey.

Then, just recently, came the video titled “Good Bye.” A short message. No clickbait. No drama. Just Luke saying he’s stepping away from YouTube for now, to focus more on personal time and family.

It didn’t come as a shock. We had often talked about how much effort his videos must take, and how tough it must be to stay consistent when you’re also raising three kids, being a husband, and managing everything off-screen.

And yet, it still hit a little harder than we expected. The ritual was ending. But more than anything, what we felt was respect.

Because sometimes, walking away is the bravest, wisest thing you can do, especially when you do it with intention.

What It Reminded Me

Luke’s decision to step away wasn’t framed as a burnout story. It wasn’t a breakdown. It was a choice. And in a world that constantly pushes for more; more content, more output, more speed, that kind of choice says a lot.

It reminded me that sustainability isn’t just about resources or tools. It’s about mindset. In the tech world I work in, especially in product and engineering teams, we’re conditioned to move fast. Deliver, iterate, optimize. But not everything needs to happen at full speed, all the time.

Some of the best decisions come when we slow down, zoom out, and make space to think. And that’s exactly what Luke did. He saw the bigger picture, made the adjustment, and did so on his own terms.

That kind of self-awareness, and the courage to act on it is rare. And it’s a reminder I’ve carried with me in my own work. You can be consistent without being constant. You can do great work without burning out. You can choose to pause, reflect, and still come back stronger or not come back at all, if that’s what’s right.

During that same season of new parenthood, I found myself trying new things too. One of them was getting back into language learning, something I wrote about in a different post. It wasn’t about mastering a new skill overnight. It was about building slow habits. Showing up regularly, not relentlessly. And that small shift in mindset came, in part, from watching how others , like Luke approached their own time with intention.

To Luke — From One Dad to Another

Luke, if by any chance you ever come across this, thank you.

Thank you for showing up every week (and later, every other week) with muddy boots, a backpack full of gear, and three kids who always looked like they were having the time of their lives. Thank you for letting us in not just into your adventures, but into your world.

Your videos weren’t just about outdoor survival or DIY builds. They were about fatherhood. About being present. About raising curious, capable kids in a world that often pulls us away from the things that matter most.

As a new dad, I learned a lot just by watching how you included your boys not in staged, scripted moments, but in the little things. Letting them make fires, fall into mud, argue over gear, and ask endless questions. You made space for them. You gave them time. And you let them grow by doing, not just watching.

And beyond all of that, it was clear that your family came first. Whether it was how you talked about your wife (“Mama”), or the quiet way your parents and siblings showed up in your videos, it was obvious that you weren’t just filming for the algorithm. You were building memories. And in doing so, you helped others including us, build some of our own.

So from one dad to another: thank you for the stories, the laughs, the lessons, and the reminder that doing less can sometimes mean doing more of what really matters.

Not Every Goodbye Is the End

We may not have a new Outdoor Boys video to look forward to this Saturday, but the impact remains. The memories we made during those early, sleep-deprived weeks of parenthood with a baby on one side and Luke’s videos playing on the other, are now part of our story.

Not every goodbye has to be final. Sometimes, it’s just a gentle pause. And even if no new videos ever show up on the channel again, that doesn’t take away what’s already there, or what it meant to families like ours.

Here’s to creators who show up with purpose. Who prioritize what matters. And who remind the rest of us that the best kind of success is the kind that doesn’t come at the cost of presence.

Thanks for reading this little story from our side of the screen. If you’ve been touched by a creator like this, someone whose work became a quiet part of your life, I’d love to hear about it.

You can find more stories like this on here, or follow me on Medium for new posts when they drop. And if you’d like to support what I do, you can always Buy Me a Coffee ☕.

Signing off,
Kavindu Narathota
narathota.com

A few weeks into my new role, a friend asked me a question over dinner at his place.

“So… what exactly do you do at your new job?”

It’s a fair question. The title sounds fancy, but to someone outside the trenches, it probably feels like a jumble of techy buzzwords.

So I told him: “I work with foundation teams.”

He paused. “What’s that? Like… infrastructure?”

That moment stuck with me. Not because he didn’t know (honestly, most people don’t), but because foundation teams are some of the most important, yet least talked about, teams in any modern tech company. We celebrate flashy product releases and pixel-perfect UI updates, but rarely mention the teams that made all of that possible in the first place.

So I figured I’d write down what I explained over dinner, and why I believe these teams are the quiet engine rooms behind great software.

What Are Foundation Teams, Really?

In simple terms: foundation teams build the stuff that other teams build on top of.

They create the shared components, services, platforms, and data layers that make it easier, faster, and safer for product teams to ship value to customers. They don’t work on features you see on the surface but their work defines everything underneath.

Think of them like city engineers. You might never meet the folks who designed the plumbing, wiring, or road network, but every tap that works, every light that turns on, and every smooth commute exists because of them. That’s what foundation teams do for software.

Depending on the company, they might go by different names, platform teams, core teams, systems teams, or even internal product teams, but the role is largely the same: they build the foundational systems that feature teams rely on.

At most companies, foundation teams can span a variety of domains:

• Backend Foundations: Common libraries, services, identity/auth systems
• AI Foundations: Data readiness for ML models, inference APIs, smart agent frameworks
• Platform or Developer Experience: Internal tooling, scaffolding, CI/CD frameworks
• Observability & Reliability Foundations: Centralized logging, monitoring standards, alerting pipelines, and incident response tooling
• Security & Compliance Foundations: Identity management, access control frameworks, encryption layers, and audit tooling baked into platform components
• Frontend Foundations: Design systems, reusable UI components, accessibility tools, and framework-level utilities for consistent UX across apps

They’re not DevOps (although they work closely with them), and they’re not infrastructure either. These are product teams just with internal customers.

📚 If you’re into tech reading, books like Team Topologies and blogs from companies like Spotify, Netflix, and Airbnb frequently refer to these as platform or enabling teams. ThoughtWorks’ Technology Radar has also highlighted the growing role of Internal Developer Platforms (IDPs), which are essentially the product of strong foundation teams.

But here’s the twist: while they don’t ship “features” in the usual sense, their work is what makes fast, scalable, and reliable feature development even possible.

If a feature team is trying to launch a new checkout flow, they shouldn’t have to reinvent the login system, build the data ingestion pipeline from scratch, or figure out how to do secure authorization. That’s where foundation teams come in. They build the core services once — well — and every other team benefits.

Misconceptions and Clarifications

Let’s get one thing out of the way first:

🧩 If they don’t ship features, are they even product teams?

This is probably the most common (and most damaging) misconception I’ve heard about foundation teams. Because their work doesn’t show up in release notes or demos, some folks assume they’re “not really product teams.” That couldn’t be further from the truth.

Foundation teams are very much product teams; they just have a different kind of customer. Instead of building directly for end users, they build for internal teams: engineers, data scientists, AI researchers, and sometimes even customer support or operations. Their job is to make sure those teams can build safely, quickly, and at scale.

They still have roadmaps. They still run discovery. They still define metrics. The difference is that the impact of their work gets multiplied. One foundational service can unlock value for five, ten, or even fifty feature teams.

Just because you don’t see a shiny UI doesn’t mean it’s not product work. If anything, it’s some of the most strategic product work you can do.

And yet, I’ve seen cases where this misconception ran deep, even among experienced product leaders. In one org, I watched as well-intentioned leadership, unclear about the role of a foundation team, pushed to break it down into smaller full-stack teams in the name of velocity. On paper, it sounded agile. In practice, it broke the foundation team’s rhythm, diluted their long-term work, and created a quality gap across the board.

Not every team needs to be full-stack. Not every product outcome needs a frontend. And as PMs, it’s our job to poke at the team dynamics to ask not just who’s building, but what they’re enabling. Understanding the role of foundation teams isn’t just helpful, it’s critical to building sustainable product ecosystems.

🧹 Foundation work is just tech debt cleanup

Nope. Sure, some foundation work involves revisiting or improving existing systems, but that’s not the same as mopping up after bad code.

Foundation work is often about future-proofing, anticipating what the organization will need six months, a year, or two years from now. It’s about building things in a reusable, extensible way so that when new product lines or features spin up, the groundwork is already in place.

Done right, it’s not reactive. It’s visionary.

🧑‍💻 They just do whatever the engineers want to build

Another quiet myth, especially because foundation teams are usually stacked with very senior engineers. From the outside, it can seem like they pick their own roadmap and just run with it.

But good foundation work doesn’t happen in isolation. These teams often partner with product managers (like me) to prioritize work based on actual internal pain points. We do internal discovery, gather use cases from consuming teams, and constantly ask: “Is this the highest-leverage thing we can build right now?”

When there’s alignment between senior engineers and product strategy, foundation work becomes incredibly powerful. Without it, you just end up with really elegant systems nobody uses.

🛑 They’re blockers, not enablers

We’ve all heard this. Maybe you’ve even said it in a moment of frustration: “We could’ve shipped already if it weren’t for platform waiting on X.”

And yes, when there’s misalignment or unclear ownership, foundation teams can become bottlenecks. But that’s not because of what they are. It’s usually because of how they’re integrated into the broader product development process.

The best foundation teams get involved early, work collaboratively, and design for reusability, not control. They’re not there to slow teams down. They’re there to help them move faster without breaking everything along the way.

💤 It’s where senior engineers go to coast

This one’s low-key offensive, but I’ve heard versions of it too: “They’re not customer-facing,” “They don’t have deadlines,” “They just experiment with tech.”

Here’s the reality: these are often the most trusted engineers in the company. They’re the ones solving some of the hardest problems, scalability, reliability, security, and AI enablement. They’re the ones being pulled into urgent strike teams when an outage hits or when the business suddenly pivots.

In fact, these teams usually have more responsibility, not less.

Foundation teams aren’t where senior engineers go to coast. They’re where they go to lead.

Who’s On These Teams: The Best of the Best

If you were to peek inside most foundation teams, one thing would become obvious pretty quickly. These aren’t your average squads.

Foundation teams are almost always made up of some of the most experienced and trusted engineers in the company. Staff engineers. Principals. Architects. Folks who’ve seen scale, felt pain, debugged in production, and lived to tell the tale.

These are the engineers who not only build things, but think in systems. They understand that a small design decision made today might have ripple effects across dozens of teams tomorrow. That’s why foundation teams are so deliberate, so collaborative, and so respected. They carry the technical weight of the organization.

And with that comes a certain rhythm.

🚀 High Standards, High Autonomy

Velocity is high. Quality is non-negotiable. But there’s also a deep respect for autonomy. These engineers aren’t being handed Jira tickets with every detail spelled out. They’re expected to dive into problem spaces, validate patterns, and build for the long haul.

In fact, in many orgs (mine included), these engineers get something we often forget to talk about: protected time.

Usually, around 20% of their time is reserved for exploration, optimization, or research. This could be anything from testing a new performance approach, validating a design pattern, or benchmarking a new AI model framework. And when something valuable surfaces? That’s when I step in as the PM, to shape that spark into a roadmap-worthy initiative for the next quarter.

It’s one of the things I love about working with foundation teams: they’re curious by design. It’s not just about shipping what’s planned. It’s about constantly asking, “Could this be done better?”

🧠 Enablers, Not Executors

And then, there’s a special layer within many foundation teams: the principals and distinguished engineers. These folks aren’t usually writing feature code or pairing with others on daily delivery. Instead, their role is more strategic. More horizontal.

They:

• Explore technical unknowns before others even realize they exist
• Vet big architectural bets and help avoid dead ends
• Enable teams with guidance, documentation, and reviews
• Partner closely with product to push clarity, not complexity

I’ve often joked (only half-jokingly) that these folks are the PM’s BS detectors. They challenge assumptions. They push back when something doesn’t make sense. And they help ensure that what we’re planning to build is actually the right thing for the business, not just the convenient thing.

Having that kind of partnership is rare. And when it works well, it’s a game changer.

💡 A great enabler doesn’t just make good decisions. They create conditions where great decisions happen more often.

What They Actually Build: Real-World Examples

Foundation teams might not always show up in your app’s interface, but their fingerprints are everywhere. From backend systems to frontend experiences, they quietly build the layers that power scalable, reliable products.

The best way to understand their value is through real examples. Here are a few from my own journey, simplified, anonymized, and stripped of sensitive detail, but still very real.

🔐 The Auth0 Foundation: One Login to Rule Them All

In one project, our foundation team was tasked with integrating Auth0 as the primary authentication system. Sounds simple on paper, but this meant aligning identity flows across multiple platforms: iOS, Android, web, and a few legacy tools no one wanted to touch.

We didn’t just wire up Auth0 and call it a day. We built a robust, extensible authentication foundation, handling:

• Token refresh logic
• Secure storage
• Fallback states
• Error handling
• Multi-device flows

Everything was abstracted in a way that made it easy for other teams to plug in and focus on their features.

Result: Frontend teams could implement login and session flows without reinventing the wheel. Onboarding sped up. Bugs dropped. And we had one central, auditable login system across the board.

🧠 The AI Enablement Layer: Making Smart Agents Smarter

When your company decides to build AI features, there’s always a quiet but crucial question: “Where does the data come from, and is it any good?”

Foundation teams step in to answer that.

We built the data pipelines and validation layers that machine learning models need to actually function in the real world. That meant ensuring data was:

• Clean
• Fresh
• Properly labeled
• Delivered in the right format, at the right time

We didn’t train the models. But we made sure the models could work.

Result: That foundation enabled everything from predictive suggestions to intelligent automation; without adding friction to the product teams building features.

🛰️ The Courier Locations System: Streaming Data for Feature Teams

Location is critical for logistics, but real-time accuracy at scale isn’t easy.

Our foundation team built a Courier Locations System using Kafka Streams, designed to process, enrich, and distribute courier location data in real time. Instead of every feature team hacking their own partial solutions, they could now consume standardized, reliable location streams.

Result: Teams across the company could build tracking, assignment, and delivery optimization features faster and more consistently, without worrying about the data plumbing underneath.

📦 The Logistics Engine: Proof of Delivery, Decoded

In a logistics platform, one foundation team was responsible for building the core logic for pickup and delivery proof what we called the Decision, Core, and Communication engines.

Here’s how it worked:

• Decision Engine: Determines whether an order needs proof of pickup or delivery by analyzing triggers, rules, and conditions
• Core Engine: Validates and logs these events securely
• Communication Engine: Syncs results across systems and devices

Result: Feature teams were able to easily integrate delivery confirmation flows into their apps, improving customer trust, streamlining operations, and reducing support tickets across the platform.

🎨 Frontend Foundations: Building the Backbone of UI Consistency

In many organizations, Frontend Foundations teams focus on creating design systems and shared component libraries that span across web and mobile platforms.
Their work often includes standardizing:

• Reusable UI components (buttons, forms, modals, navigation)
• Accessibility best practices baked into components
• Theming and branding systems for consistent look and feel
• Layout frameworks for responsiveness and cross-device compatibility

Result: Feature teams can ship user-facing experiences faster, with greater visual consistency and fewer bugs, while also improving accessibility and reducing frontend tech debt over time.

The foundation teams might not always build the features you see, but thanks to their work, feature teams can launch user-facing experiences faster, safer, and with far more consistency. These aren’t just backend chores or UI libraries. They’re multipliers.

Each foundational capability, whether in data streams, authentication layers, or design systems, unlocks a stream of innovation on the product side. And that’s the real magic of a great foundation team: They do the hard, often invisible work, so others can build fast, innovate freely, and scale without fear.

How They Operate: Innovation Time and Strike Missions

Foundation teams might be full of heavy-hitters, but they’re not just grinding out roadmap items day in and day out. One of the things that makes them so effective and honestly, so fun to work with is how they’re set up to operate.

They run differently. And that difference is by design.

⏳ 80/20: A Rhythm That Encourages Innovation

Most foundation teams I’ve worked with run on an 80/20 structure. About 80% of their time goes toward delivering roadmap work, prioritized initiatives that unlock value for the organization. But the other 20%? That’s sacred.

That’s their exploration time.

During that slice of the week, engineers might:

• Explore new technologies or frameworks
• Benchmark performance across systems
• Optimize a data flow or refactor a brittle interface
• Prototype a better way to do something that’s been bothering them

It’s not “free time.” It’s intentional time. A space for curiosity, craft, and creativity. And often, some of the best ideas come from it. As a PM, when I see something promising surface in those sessions, I step in to help shape it into a structured initiative we can slot into the next quarter.

This 20% time is where real innovation gets seeded.

And in the age of AI, that innovation is becoming even more critical. Foundation teams are the ones building AI infrastructure, model endpoints, inference engines, and data validators, not just consuming them. While the world debates if AI will replace engineers, these teams are too busy building the stuff that makes AI useful.

🚨 Strike Missions: The Cost (and Thrill) of Being Great

When something critical breaks… When the business suddenly needs a pivot… When there’s no room for failure…

WHO YOU GONNA CALL?

Yep, FOUNDATION TEAMS!!!

Because these are the most trusted teams, they’re often pulled into strike team mode. This might mean:

• Responding to a major outage or security issue
• Quickly enabling new functionality due to regulatory changes
• Supporting a company-wide pivot or bet

During these periods, the roadmap? Tossed out the window. It’s all hands on deck. As a TPM, this is where a lot of my work shifts to protecting the team. Re-prioritizing, updating stakeholders, ensuring we don’t lose momentum (or morale).

It’s stressful, yes. But it’s also a privilege. Because when the heat is on, leadership turns to the team that’s most capable of solving hard problems under pressure.

This is the unspoken cost of excellence. But also the reason why foundation work matters so deeply.

Foundation teams operate with a unique blend of autonomy, accountability, and adaptability. And when supported right by the org and by product, they deliver not just systems, but stability and speed for everyone else.

The Unsung Heroes: Principals as Enablers

Every foundation team I’ve worked with has a secret weapon.

They’re not always the loudest in meetings. You won’t see them sprinting toward tickets. And they’re rarely in the spotlight during demos. But they’re everywhere. Quietly shaping direction, challenging assumptions, and stitching together the tech and product landscape.

I’m talking about Principal Engineers and Distinguished Engineers. The enablers.

🧭 Guides, Not Builders

Unlike other engineers on the team, enablers aren’t primarily measured by how many lines of code they write. Their impact isn’t always in commits, it’s in clarity.

They help teams:

• Understand the trade-offs between design patterns or architectural directions
• Pick the right problems to solve (not just the loudest ones)
• Avoid common pitfalls that only experience can foresee
• Stay aligned with long-term company goals, not just quarterly sprints

They ask the hard questions that most people are too polite (or too inexperienced) to ask. And they do it in a way that doesn’t block progress but sharpens it.

🧠 The Strategic Depth Layer

If you’re a product manager working with foundation teams, here’s the best way I can describe their role: they’re your clarity compass.

A principal engineer once told me, “I won’t tell you what decision to make, but I’ll make sure you’ve thought through all the things that could break if you make the wrong one.” That stuck with me.

Enablers:

• Shape technical discovery by identifying unknowns before they become risks
• Push for organization-wide alignment when teams drift into siloed thinking
• Sense when a project is veering off-course — even before the metrics show it

They’re not just building for today. They’re guarding tomorrow.

🤝 A Partner, Not a Gatekeeper

One thing I deeply value in enablers is that they don’t say no lightly. If something doesn’t feel right, they’ll unpack it with you. They want product to succeed. They want teams to succeed. But they also want us to build things that won’t collapse under growth.

They’ve challenged me more than once on assumptions I brought to the table and I’ve come to appreciate it. If a feature seems simple but carries long-term complexity, they’ll spot it. If a technical plan feels too shiny and not grounded enough, they’ll flag it. And together, we’ll figure out a better path.

Their role isn’t just to elevate engineering. It’s to ensure product decisions are grounded in reality, and aligned with a shared future.

If you’re lucky enough to work with someone like this, listen carefully. Partner with them. Bring them in early. And if they push back, it’s not ego. It’s care.

Why Foundation Teams Are the Backbone of Product Velocity

If you’ve ever worked in a fast-growing tech company, you know the feeling: everyone’s trying to move fast. Deadlines loom, roadmaps stretch, and feature teams push hard to ship the next big thing.

But here’s the thing no one talks about enough: velocity isn’t just about how fast a team can build. It’s about what’s already been built to help them move faster.

And that’s where foundation teams come in.

⚡ They Multiply Team Velocity

When you’re building a new feature, you don’t want to be figuring out:

• How to authenticate users securely
• How to stream and transform data
• How to validate delivery events
• How to scale your backend across regions

You want to focus on your feature.

Foundation teams make that possible. They:

• Create reusable components that feature teams can plug into
• Build APIs that abstract away complexity
• Standardize integrations so that teams don’t reinvent the wheel

Without foundation teams, every team becomes a full-stack, full-responsibility team. And that doesn’t scale. It burns people out.

🔐 They Bake In Compliance, Security, and Quality by Default

When you centralize key components like authentication, data validation, logging, or ML access, you gain something priceless: predictability.

Security gets implemented once, and enforced everywhere. Data formats are standardized, reducing errors. Observability and alerting are built into shared services, not added as afterthoughts.

This isn’t just about engineering best practices. It’s about risk management. When things go wrong (and they will), a strong foundation gives you control, traceability, and peace of mind.

🌱 They Enable Innovation (Especially with AI)

AI is the new frontier, and foundation teams are the ones quietly making it viable.

They’re:

• Building the inference endpoints that power smart features
• Designing the data pipelines that deliver clean, labeled data
• Setting up model feedback loops to improve accuracy over time

While a lot of attention goes to the features powered by AI, it’s the foundation teams who are wiring up the capabilities that make those features possible. Without a strong backend to deliver the right data at the right time, or systems that can support reliable, explainable inference, you don’t have real AI. You have demos.

The flash might be on the frontend, but the foundations are where the future is being built.

🧩 They Bring Order to the Chaos

As organizations scale, tech sprawl is inevitable. Different teams make different choices, use different tools, and structure their services in different ways. Before long, you’ve got fragmentation, making things harder to maintain, integrate, and evolve.

Foundation teams fight this chaos by building:

• Common frameworks and libraries
• Shared contracts and API standards
• Unified tooling and developer experience layers

This is how you scale sustainably, by giving teams freedom within guardrails.

Leading Foundation Teams: The Product Angle

If you’re a product manager stepping into a foundation team for the first time, here’s your warning: it’s not like leading a feature team. And that’s a good thing.

You’re not just managing delivery. You’re helping define the building blocks of how other teams deliver. You’re not launching customer-facing features every sprint, but the decisions you help shape? They ripple across the entire product org.

This is where product thinking gets deep, strategic, and often invisible.

🎯 Your “Customers” Are Other Teams

You’re not interviewing external users or running A/B tests every week. Instead, your job is to understand internal pain points:

• Where are developers losing time?
• What’s being re-built in every team?
• What breaks when we scale?

You do discovery with engineers, data scientists, even other PMs. And your success is measured by things like:

• Time saved by consuming teams
• Increase in adoption of foundational tools
• Reduction in support requests or outages

It’s a quieter kind of product success. But it’s real, and often more far-reaching.

📏 You Work in Trade-Offs, Not Features

Foundation work is full of grey areas:

• Should we build a quick utility now, or a long-term platform later?
• Should we support every edge case, or enforce standards?
• Should we say yes to this team’s urgent need, or stick to our roadmap?

There’s rarely a “correct” answer, just trade-offs.

Your job is to help navigate them, align stakeholders, and keep the long-term strategy intact while still delivering value along the way.

🧩 You Sit Between Multiple Worlds

Foundation PMs need to speak multiple languages:

• Technical enough to work closely with architects and principal engineers
• Strategic enough to align with leadership and product org goals
• Collaborative enough to manage relationships with 5, 10, or even 15 consuming teams

You’re not leading a product. You’re helping lead the product behind every other product.

That means constant alignment, structured communication, and proactively identifying roadblocks that might not even affect your team, but will slow down others if you don’t flag them.

🧠 You Have to See Around Corners

One of the most rewarding parts of working in foundation product is that you’re often thinking one step ahead of the organization:

• What technical gaps will block us next quarter?
• What platform improvements will make future AI features faster to build?
• What internal patterns can we clean up before they turn into tech debt?

This is where working closely with enablers (like we talked about earlier) is so valuable. They help you challenge assumptions and validate direction before you commit your team’s time.

💡 It’s Quiet Work. But Deep Work

You might not be demoing flashy UIs. You probably won’t be the name mentioned at a product launch. But the foundations you help shape?

They’ll show up in every product that launches after.

For the Ones Who Keep the Lights On

To my team! Yes, this is the article I mentioned during stand-up.

When one of you said, “I love what we do, but it’s hard to explain to others,” it reminded me why I started writing this in the first place. That comment landed, because it’s not just something outsiders struggle to see, it’s something even we feel at times. And that’s exactly what this article is here to clear up.

You already know this, but it deserves to be said out loud: you’re the builders behind the builders. The ones who make it possible for everyone else to move fast, build confidently, and scale responsibly.

I’ve always said. Writing helps me think. When I want to really understand something, I research, I jot down messy ideas, and eventually, I shape them into words. And once I write something down, I rarely forget it.

This article was exactly that process.

Digging into the what, why, and how of foundation teams helped me see some things in a new light. And if it helped me, I hope it helps someone else too. Maybe a PM new to these teams, or a leader deciding where to invest next.

Let’s end where it all began, with the core message that carried through every section:

Foundation teams don’t slow you down.
Foundation teams are the reason you can speed up.
And great product orgs don’t just build features;
They build the teams that make features possible.

That’s it for this one, folks!

If this resonated with you, or helped put words to something you’ve always felt but couldn’t quite explain, I’d love to hear your thoughts.

Thanks, as always, for reading all the way to the end of this very long article. If you’d like to support my work, feel free to buy me a coffee.

Signing off,
Kavindu Narathota
narathota.com

“Hey Kavindu, I’m planning on getting Scrum Master certified. Do you recommend PSM or CSM?”

That message landed in my inbox again recently. I’ve seen variations of it many times over the years. It’s always a thoughtful question, and it always brings me back to the same internal response: It depends.

But this time, I paused a bit longer.

I got my Certified Scrum Master (CSM) credential nearly a decade ago. It was a fairly expensive (yes, paid out of pocket) two-day in-person training led by a Singaporean agile coach. We spent time in group activities, studied a printed Scrum booklet, and took an online exam afterward. I was the youngest person in the room; a lead engineer among project managers, architects, and company-sponsored leads who needed the badge to win clients.

Back then, it made sense. It opened doors (kinda… at least not for me, but I know it did for others). Today? I pay $100 a year just to keep it active, and I haven’t leaned on it in years.

Side note: I actually started writing this article a while ago, and it sat in my drafts untouched. But after getting asked about Scrum a few more times recently, I figured it’s time to collect my thoughts and finally put this out, so I can just send this link next time someone asks.

So, is Scrum certification still worth it in 2025? Let’s break it down.

TL;DR: The Short Answer First

If you’re just here for the straight-up answer, here’s my take:

Is Scrum certification still worth it in 2025?: Maybe. But don’t assume it’s a must-have.

It could make sense if:

• You’re brand new to Agile and need a structured entry point.
• Your employer (or target employer) specifically values it.

But you might not need it if:

• You’re already working in Agile environments where mindset > mechanics.
• You’re more interested in outcomes, leadership, or product thinking than process enforcement.

The context that matters:

Agile has become a mindset, and honestly, that was the original goal. For many, it’s now the default way of working. Teams aren’t “doing Agile,” they’re just being agile. Certifications don’t always reflect that shift.

So what should you do instead?

• Learn Agile for free. Practice it on the job. Seek out real-world mentorship.
• Consider bigger-picture learning: like product management, business strategy, or if it fits, an MBA. That’s where I’d personally bet on.

To be clear: I’m not against certifications. I’m just saying they’re not what they used to be, and you should know what you’re really getting out of them before swiping your card.

Then vs. Now: What Scrum Certification Used to Mean

Back when I got certified, Scrum felt like a new frontier. It gave structure to chaos and promised better delivery through collaboration, transparency, and iteration. In those early years, having “Certified Scrum Master” next to your name actually made you stand out.

I still remember that in-person session, energizing team activities, flip charts, lots of sticky notes, and the vibe of discovering something fresh. For many people in that room, the certificate was a way to unlock new client deals or bring some order to messy teams.

But over the years, things changed.

Agile went from exciting to expected. From methodology to mindset. Teams matured, and so did the way we work. Today, simply having a certificate doesn’t carry the same weight. It doesn’t always prove you can lead a team, unblock delivery, or drive value.

And honestly, it’s not supposed to. It was never meant to be the end goal, it was a starting point. That’s the shift we need to acknowledge.

How Teams Actually Work in 2025

The way teams operate today looks very different from the early days of Agile adoption. In most modern environments, especially in product and tech-driven teams pure Scrum is rare. Instead, we see Scrumban, Lean-inspired workflows, or custom blends that better suit the team’s context.

The focus has shifted from “following Scrum by the book” to “delivering value quickly and sustainably.” That includes tweaking rituals, skipping unnecessary ceremonies, and removing any friction that doesn’t serve the team.

And the Scrum Master role? It still exists, but in many teams, especially the ones I’ve worked with, it’s often a developer or engineering lead at the mid-level who wears the SM hat alongside their core responsibilities. It’s about enabling the team, not enforcing process.

Agile has become less of a title and more of a team habit. And that’s not a bad thing. It means the mindset is working. The challenge is, a certificate can’t always capture that.

Industry Signals: What Layoffs and Trends Are Telling Us

If you want to know what really matters to a company, look at who gets let go first.

Over the past couple of years, as tech layoffs rippled through the industry, there’s been a noticeable pattern: Agile Coaches, Scrum Masters, Project Managers, and Delivery Managers are often among the first roles affected. You don’t need to dig far. Sites like layoffs.fyi make these trends easy to spot.

But it’s not just about layoffs. Even hiring trends are shifting. A quick search on LinkedIn shows a clear slowdown in open roles specifically titled around “Scrum Master” or “Agile Coach.” Compare that to product roles, tech leads, or hybrid delivery managers, which are still actively growing.

That’s not to say these roles aren’t valuable. But when push comes to shove, companies are prioritizing those who can wear multiple hats, ship outcomes, and lead without depending on defined titles.

In many modern orgs, Agile isn’t seen as a job function, it’s an expectation. Product Managers, Tech Leads, and Engineers are increasingly expected to carry Agile practices as part of their core responsibilities.

The certificate might say you understand Agile, but the industry is starting to ask: Can you live it without the title?

Do You Actually Need the Certification?

Let’s pause here. The question isn’t whether certification is good or bad; it’s whether you actually need it for where you’re headed.

You might want to consider it if:

• You’re new to the industry and need a clear entry point into Agile ways of working.
• You’re applying to companies or clients that explicitly require it.
• You learn best with structure and want something to anchor your understanding.

You can probably skip it if:

• You’re already working in Agile teams and understand the mindset.
• Your company values adaptability and outcomes over formal process.
• You’re aiming for roles that require broader thinking — product, leadership, business growth.

A certification might give you a short-term boost. But it’s not a guarantee. Most hiring managers I’ve met care more about how you think and deliver than what badges you list on your resume.

If you’re serious about growing, invest in habits, not just highlights.

If Not CSM… Then What?

Let’s say you’ve weighed the pros and cons and decided a traditional Scrum cert isn’t your thing. Cool. So what’s next?

Here are some other ways people are building credibility and capability without jumping straight into CSM:

• PSM (Professional Scrum Master): Less expensive, no renewals, and focused on practical application.
• SAFe Certification: Still relevant in large-scale orgs, especially if you’re navigating enterprise-level complexity.
• Lean, Product Ops, or Strategy Courses: Great for those working at the intersection of product, engineering, and business outcomes.
• MBA (if it aligns): Not a replacement for Agile knowledge, but if you’re leaning into leadership or strategic roles, it gives you the wider lens that certificates often don’t.
• Self-learning + Mentorship: Some of the strongest Agile minds I know didn’t take a single course, they learned by doing, observing, and reflecting with good mentors.

This isn’t about skipping structure. It’s about choosing the kind that genuinely helps you grow.

The Future Is About Skills, Not Just Frameworks

If the last few years have shown us anything, it’s that tools and titles come and go, but strong core skills stay relevant.

According to the World Economic Forum’s Future of Jobs Report 2025, the most in-demand skills in the next few years won’t be tied to any one framework. Instead, they highlight:

• Analytical thinking
• Resilience and flexibility
• Self-leadership and curiosity
• Empathy and active listening
• Technological literacy

These aren’t things you get from passing a multiple-choice exam. These are the skills that make you a valuable contributor, especially in Agile environments. They’re also what help you grow beyond execution — into influence, strategy, and leadership.

So if you’re debating between a certification and building future-proof skills, you know which one I’d vouch for.

Final Thoughts: Make the Decision That Fits You

Agile isn’t dead. Scrum certification isn’t a scam. But neither are they sacred.

The industry has matured, and so have the expectations. A badge might get you through an ATS filter or add a bit of confidence early on, but it won’t carry you far if you’re not building the skills, experience, and mindset to match.

If you’re just getting started and need a structured way to understand Agile; go ahead, pick what suits you. But if you’re already practicing agility, delivering outcomes, and thinking like a product or tech leader, you probably don’t need a certificate to prove it.

There’s no one-size-fits-all answer here. Just make sure the investment you’re making aligns with the direction you want to go.

And if you’re still on the fence, take your time. Certifications can wait. Growth shouldn’t.

Have you taken a certification recently? Did it actually help you grow or was it just another checkbox?

Is Agile in your org a real culture or just a framework everyone pretends to follow?

What’s your take on learning vs. certifying?

I’d love to hear your thoughts. Drop me a message, leave a comment, or share this with someone who’s asking the same questions.

And hey, if you liked this and want to support my writing, you can buy me a coffee ☕.

Signing off,

Kavindu Narathota
narathota.com

Avurudu came and went, and like always, we celebrated it as best as we could; between errands, naps, work calls, and a very curious 9-month-old trying to grab anything within crawling range.

This year was special. It was our son’s first Avurudu. And while he may not remember it, we wanted to create the kind of memories that photographs can one day whisper back to him, the way the smell of mung kavum or the sound of the milk pot overflowing whispers to me now.

Growing up in Sri Lanka, Avurudu wasn’t just a festival. It was a feeling. A shift in the air. My mother, no matter how busy or even unwell she was, would go all in. From cleaning the house to making sweets to buying or sewing new clothes for all three of us, she made sure we were part of it. Even when we resisted (and trust me, teenagers are experts at that), she’d somehow reel us in with laughter, nostalgia, or just the smell and the sound of kokis frying.

My father, too, was always in the background, doing multiple grocery runs (often dragging me along to bulk stores), cleaning, fixing, and doing everything he could to support. It was a team effort, led with love, and every year, my mother would say, “This is how my mother did it too.”

Now, years later, standing on the other side of the world and on the other side of that parenting role, I finally get it. Today, it’s my wife who leads the way, prepping, planning, and making sure the celebration feels like something more than just a date on the calendar. And I’ve found myself in my father’s old shoes, helping out in the background, doing grocery runs, tidying up, and stepping in wherever needed. One day, I hope our son will join in too, maybe reluctantly at first, just like I did.

What is Avurudu (අවුරුදු)?

For those unfamiliar, Avurudu is the Sinhala and Tamil New Year, a uniquely Sri Lankan cultural festival celebrated in mid-April as the sun transitions from the Pisces constellation (Meena Rashi) to Aries (Mesha Rashi).

Unlike religious holidays, Avurudu is a cultural celebration, and that’s one of the most beautiful things about it. People from all walks of life, Buddhist, Hindu, Christian, Muslim, participate in the same rituals, share the same food, and follow the same auspicious timings. It’s a rare, unifying celebration in a world that often emphasizes differences.

At the heart of Avurudu is the idea of nakath (නැකත්), astrologically chosen times to stop work from the old year, and begin the new. It’s poetic, really, starting afresh with intention. Families light hearths at a specific time, boil milk until it overflows (a symbol of abundance), and prepare dishes like kiribath, kokis, and mung kavum with joy and purpose.

It’s not just about rituals, it’s about rhythm. A reminder that time isn’t just something we pass through, but something we participate in.

The Modern Critique

Lately, I’ve seen a rising wave of skepticism, especially online around festivals like Avurudu. Some call it outdated. Some say it no longer makes sense in the fast-paced, modern world. Others question the need to follow customs they no longer connect with, especially when living far from Sri Lanka.

And I get it. Not every ritual will resonate with everyone. Some customs feel irrelevant. Others can feel performative when done without meaning. The world is changing, and we should question what we inherit.

But here’s where I pause; because tradition isn’t just about doing what our parents did. It’s about understanding the why behind it, and deciding whether it’s still worth carrying forward. For me, Avurudu is a cultural anchor. It gives shape to memory, identity, and belonging, especially when everything else moves so fast.

Why I’m Writing This (Even Though I Usually Don’t)

This isn’t my usual kind of article. Most of my writing leans technical, product thinking, frameworks, industry insights. But this year, I felt compelled to write something different.

Maybe it was the smell of seeni sambol (a sweet chutney) in a pan on a cold Canadian morning. Maybe it was the moment I lit the stove for the milk to boil, just like my parents did. Maybe it was the quiet frustration of seeing traditions being ridiculed online as relics of a past that should be discarded.

I’m not here to romanticize the past or suggest that every tradition must be preserved exactly as it was. But I believe that we have the power to evolve traditions, not erase them. Avurudu may not look the same in every household, and that’s okay. The beauty lies in the choice to celebrate, to adapt, and to pass on something meaningful, however simple, to the next generation.

Culture doesn’t survive by chance. It survives because someone chooses to carry it forward. And maybe that’s what I’m doing with this post.

The Real Meaning of Avurudu

Avurudu is more than dates on a calendar or a checklist of rituals. It’s a quiet resistance to the idea that everything old is obsolete.

It’s not about tradition vs. modernity. It’s about building continuity in a world that often feels fragmented.

Whether you’re in Sri Lanka, Canada, or anywhere else, maybe the point isn’t to celebrate it perfectly, but to celebrate it intentionally. Even if it’s just by lighting a lamp, boiling a pot of milk, or remembering what your mother used to do this time of year.

You’ll often hear people say, “It just doesn’t feel like Avurudu anymore.” But I don’t think that’s entirely true. What’s changed is us. We’re no longer carefree kids just enjoying the kavili and firecrackers. We’re adults now, with responsibilities, grocery lists, crying babies, and dishes to wash. The magic feels different because we experience it differently. But it’s still there, waiting to be felt, and recreated, in our own way.

I genuinely hope these traditions continue. That our children like my son, will grow up embracing these rituals not just as something old, but as something theirs. He may celebrate Avurudu as a Canadian with Sri Lankan heritage, but I believe he’ll carry the spirit of it forward. And one day, if it still makes sense, he’ll pass it on too.

That said, I also believe that how we celebrate traditions in new countries matters. For me, it’s never about grand displays or public disruption. It’s about quiet continuity, finding meaning in familiar rituals, without imposing them on the communities we now call home.

Culture thrives when it’s shared with respect, not noise. And that’s the kind of celebration I hope my son grows up with, joyful, intentional, and inclusive.

As always, if this resonated with you or sparked a memory, let’s talk about it. Have you adapted traditions in your own way? What do you carry forward?

If you’d like to support my writing, feel free to Buy me a coffee. And don’t forget to follow along on Medium or subscribe to the newsletter!

Signing off,
Kavindu Narathota
narathota.com

🎨 Illustration Note: All featured Disney-style images in this post were AI-generated by Kavindu Narathota using original or referenced photos as inspiration.

It might feel like magic, but building great products still takes more than good prompts and good vibes.

A few weeks ago, I started writing this article. You know how it is, you get excited about a topic, jot down a few thoughts, open a dozen tabs, and then life decides to test your multitasking skills. Between work, home, and a few “let’s catch up soon” meetings that actually happened (surprise!), this post sat quietly in my drafts.

When I finally came back to it, the vibe coding scene had changed. A lot. New tools, new interpretations, and a flood of content across Twitter (sorry, X), YouTube, and newsletters. The way people talked about vibe coding today felt different than just a few weeks ago.

And that got me thinking: if a concept shifts this fast, how sustainable is it? Is this a passing trend with a cool name or the beginning of something much bigger?

Spoiler: I don’t have all the answers. But I do have thoughts. As someone who went from writing code for a living to telling others what to build and why, vibe coding sits at a really interesting intersection between engineering, product, and… vibes.

What Even Is Vibe Coding?

Let’s break it down. In simple terms, vibe coding is when developers write code by prompting AI agents instead of manually typing out every class, function, and loop. Think of it like telling your AI buddy, “Hey, I want a REST API to manage tasks,” and watching it spin up the whole controller-service-repo layer like magic.

The term became popular earlier this year thanks to Andrej Karpathy, who described it as the future of programming: developers vibing with their AI copilots, rapidly building products with less boilerplate and more creativity. And to be fair, that vision is hard not to get excited about.

In the wild, vibe coding looks like this:

• You open Cursor (or Copilot, or ChatGPT, or any of the newer tools)
• You write a prompt: “Add JWT-based auth to this Express app.”
• The AI does its thing
• You review, tweak, or just run it

That’s it. It’s fast. It’s fluid. And for some use cases, it’s shockingly effective.

But here’s where it gets murky. Everyone seems to have their own definition. For some, it’s AI-assisted coding with structure. For others, it’s pure chaos in a hoodie. It depends on the person, the tool, the use case, and the stakes.

So while the vibes are real, the definitions? Not so much.

A Group Chat That Gave Me a Different View

This whole vibe coding rabbit hole got deeper during a casual chat in one of my WhatsApp groups. It’s a small circle, but probably one of the smartest groups I’m in. We’re talking subject matter experts in tech, PhDs, entrepreneurs, business professionals, sustainability leads, researchers; you name it. Friends and colleagues spread across the globe, from Sydney to Toronto.

Someone brought up the term “vibe coding” and just like that, the chat blew up. Opinions flew fast. Some saw it as the future. Others weren’t buying the hype. What stood out to me wasn’t just the disagreement, but how grounded and nuanced the perspectives were.

Naturally, I brought up a previous piece I wrote “Will AI Replace Software Developers?” and we used that as a springboard.

One person shared how their company embraced an AI-first approach. Internal agents help non-devs spin up APIs, write unit tests, manage PRs. “They felt like developers,” he said. That line stuck with me. Because that’s where this whole thing is heading. It’s not just about faster builds. It’s about removing the traditional barriers to building altogether.

Another shared how roles are shifting traditional QEs, junior devs, and even researchers are being pushed to evolve or risk being replaced. “Top talents will thrive. The rest? They’ll get squeezed.” It hit hard, but not in a negative way. It just felt like an honest look at where things are going.

The Product Perspective: Can Vibes Scale?

This is where my lens shifts. I’m not paid to write production code anymore, but I’m still very close to it. My role today is to shape what gets built, why it matters, and how to keep it sustainable. And let me tell you, vibe coding makes for a great PoC, but not a scalable product strategy.

Here’s the thing. AI can absolutely help us build faster. It can unblock teams, generate boilerplate, and even make suggestions that spark better architecture. I use Cursor or Webstorm with Co-pilot often for side projects, and I’ve seen firsthand how much time it can save.

But here’s what vibe coding doesn’t do well:

• It doesn’t understand long-term context or tech debt
• It doesn’t always follow your infra conventions
• It will hallucinate, and unless you know what to look for, you’ll ship broken logic or worse, insecure code

In a way, it’s like pair coding with a very confident junior dev. They’re eager. They’re fast. But without someone experienced to guide them, things can go south quickly.

That’s why I always go back to a phrase I used in my previous article. AI won’t replace software engineers. But a software engineer who knows how to use AI effectively will absolutely replace the one who doesn’t.

So yes, vibe coding is here. But if you’re thinking about long-term product velocity, scalability, and maintainability, you’ll need more than good vibes.

Where Vibe Coding Shines (and Where It Doesn’t)

Let’s give it some credit first. Vibe coding is amazing when the stakes are low and the goal is to move fast. It shines in:

• Rapid prototyping
• Internal tools
• Weekend side projects
• Hackathons
• Teaching and experimentation

This also reminds me of the no-code hype we saw a few years ago. Startups were built entirely around no-code platforms, promising everyone from marketers to founders that they could launch full products without writing a line of code. And while that movement brought some good things, more accessibility, faster MVPs, less gatekeeping; how many mission-critical or widely adopted apps today were built purely on no-code? Apart from simple websites or micro-tools, not many.

Vibe coding gives me similar vibes (no pun intended). It’s great to test ideas, unblock teams, or build things that don’t need to scale. But once you cross that line into “this actually matters,” things change.

If you’re building something that needs to scale, be secure, and last more than a sprint or two, you’re in a different game. Vibe coding starts to fall short when:

• You need to integrate with legacy systems
• You care about test coverage and standards
• You need consistent code quality across teams
• You’re managing multiple environments or complex infrastructure

It’s not that AI can’t help with those things. It’s that you still need someone who understands the full picture to guide the process. AI is powerful, but not magical.

A Shift, Not the End

There’s a temptation to look at all this and think we’re watching the end of software engineering as we know it. But I don’t think that’s true.

It feels more like a shift. A rebalancing of who gets to build and how they do it. And that shift is opening doors for more people, non-devs, junior devs, product folks, even domain experts; to contribute in ways they couldn’t before.

The reality is, a lot of this comes down to context and control. Vibe coding works best when there’s clear direction, good review practices, and a mindset that sees AI as a partner, not a shortcut. If you’re treating vibe coding as “just prompt and go,” you’ll likely end up with brittle systems and a headache in prod.

But if you’re intentional, if you know when to vibe and when to verify; it can be a huge productivity unlock.

And that’s the shift I’m seeing. It’s not the end. It’s the beginning of a new kind of workflow, one that blends creativity, intuition, and tooling in ways we’re still figuring out.

We’ve got time. Just maybe not forever.

Wrapping It Up: My Stance (Still) Stays

Everything I’ve shared here is based on what I’m seeing now. What I’ve experienced both in the past and in the current moment. I’m not claiming to know where this ends, but like the evolution of the human race, AI will also evolve. And at some point, we’ll revisit this conversation with a very different lens.

Right now, AI tools are acting more like virtual assistants than anything else. Take Google, for example. They recently replaced Google Assistant with Gemini, leaning into the AI-first future of helping individuals manage their day-to-day through conversations, summaries, and context-aware tasks.

Coming back to vibe coding, though? My stance still stays.

AI can boost productivity. It can help us code smarter, faster, and with fewer blockers. But it’s not the whole story.

We still need product thinking. We still need people who understand edge cases, systems, context, trade-offs, and long-term goals. Vibe coding isn’t a shortcut to good engineering. It’s a tool, a pretty good one, but only in the right hands, with the right expectations.

So yes, ride the wave. Vibe a little. But don’t forget to think.

That’s it for this one folks and thanks for sticking up till the end of this. If you’ve got thoughts, counterpoints, or just want to share how you’re using vibe coding in your world, I’d love to hear from you. Drop a comment or connect with me directly.

If this piece got you thinking, check out my other articles on blog.narathota.com or follow me on Medium for more content like this.

And hey, if you liked this and want to support my writing, you can buy me a coffee ☕. Every bit helps me keep writing, researching, and vibing through topics like these.

Signing off,

Kavindu Narathota
narathota.com

Over the years, I’ve been on both sides of the interview table, sometimes as the one answering questions, other times as the one asking them. And if there’s one thing I’ve learned, it’s that not all interviews are created equal.

Some are engaging discussions that make both parties walk away with fresh insights. Others? A rigid Q&A session that feels more like a formality than a real evaluation. This is especially true for senior roles, where the goal isn’t just to check technical boxes but to assess leadership, strategic thinking, and mutual fit.

Here’s the reality: while companies evaluate candidates, candidates are also evaluating companies. A poorly conducted interview can turn away top talent, no matter how strong the brand. So if you’re gearing up for your next interview, take a moment to rethink your approach. Here are seven ways to make it better; for both you and the candidate.

1. Do Your Homework Beyond the Resume

Senior candidates often have more to their story than what’s on their resume. Many have written blogs, spoken at conferences, contributed to open-source projects, or shared insights on LinkedIn. Taking a few minutes to look beyond the resume can make a big difference in how the interview plays out.

Why? Because they might already know who’s interviewing them. If a candidate has done their research on you, it only makes sense to return the favor. Coming into the conversation with some context about their background not only shows respect but also helps you ask better, more relevant questions.

Instead of spending time asking them to repeat what’s on their resume, focus on deeper discussions. Bring up a blog post they wrote, a project they worked on, or a unique challenge they solved. This makes for a much more engaging interview, one where the candidate feels valued, and you get a real sense of how they think.

2. Don’t Rigidly Stick to the Script

A structured interview is important, but treating it like a checklist of questions isn’t the way to go. Senior candidates have years of experience, and the best way to assess them isn’t by jumping from one predefined question to another; it’s by having a real discussion.

Think about it: if the conversation naturally flows into a deep discussion about handling technical challenges, does it make sense to suddenly switch gears and ask about a go-to-market strategy just because it’s the next question on the list? Probably not. Instead, adapt. Let the conversation evolve in a way that feels natural.

This doesn’t mean ignoring the key areas you need to assess. It means structuring the discussion so that it flows smoothly, making it easier for the candidate to engage and give thoughtful responses. And if you’ve done your research (like we talked about in the previous point), you’ll know how to steer the conversation in a way that brings out their strengths while still covering what you need.

3. Give Real-Time Feedback During the Interview

Interviews shouldn’t feel like a black box where candidates keep talking, unsure if they’re on the right track. A simple nod, a quick acknowledgment, or a follow-up question can make a big difference.

When a candidate answers a question, take a moment to respond before moving on. If their approach aligns with what you’re looking for, let them know. If it’s slightly off, guide them in the right direction. This not only helps the candidate adjust but also creates a more engaging conversation.

This doesn’t mean you have to give away whether they’re “passing” or “failing” in real time. It’s about making the interview feel more like a discussion rather than a one-way interrogation. Candidates perform better when they feel heard. And a great interview isn’t just about evaluating, it’s about bringing out the best in them.

4. Drop the “I’m the Smartest in the Room” Mentality

Some of the worst interviews aren’t bad because of the questions, they’re bad because of the interviewer’s attitude. A senior candidate isn’t someone you’re trying to catch off guard or “grill” to prove a point. They’re someone you’re assessing as a potential leader, collaborator, and problem solver.

A condescending tone, dismissive reactions, or trying to outsmart the candidate doesn’t make the process any better. In fact, it does the opposite. A great candidate won’t just judge the company based on its reputation or perks; they’ll judge it based on the people they interact with. If the interview feels like an ego battle, they’ll walk away.

A good interview is a two-way street. Approach it with humility, respect, and curiosity. You might be evaluating the candidate, but they’re evaluating whether they want to work with you too.

5. Balance Evaluating Skills with Evaluating Fit

For senior roles, knowing the right answers isn’t enough, it’s about how candidates think, make decisions, and navigate complex situations. Yet, too many interviews focus on checking off skill sets without considering whether the person is the right fit for the team and the company.

Instead of just testing technical or domain knowledge, dig into how they approach challenges. Ask about their experiences leading teams, influencing stakeholders, or making tough calls with limited data. Look for thought processes, adaptability, and leadership qualities.

A candidate might not have used the exact tool your company prefers, but if they’ve successfully handled similar problems at scale, they can likely adapt. The best hires aren’t always the ones who check every technical box, they’re the ones who fit the company’s needs, culture, and long-term vision.

6. Make It a Two-Way Conversation, Not an Interrogation

An interview isn’t just about assessing a candidate, it’s also about giving them a chance to assess the company. Senior candidates, especially, aren’t just looking for a job; they’re looking for the right opportunity.

If the entire conversation feels one-sided, with the interviewer firing off questions without room for discussion, it sends the wrong message. Encourage them to ask questions, and when they do, give thoughtful, honest answers. Be open about the challenges of the role, the expectations, and the team dynamics.

A great interview feels like a conversation between equals. It’s where both sides walk away with clarity, whether it’s the candidate realizing this is the right fit or the interviewer seeing them as the right hire.

7. Respect Their Time (and Energy) Throughout the Process

A long, drawn-out interview process can cost you great candidates. Senior professionals are often juggling multiple opportunities, and if your process feels unnecessarily slow or repetitive, they might walk away before you even make a decision.

Be upfront about the structure, number of rounds, and timeline. If multiple interviewers are assessing similar areas, streamline the process to avoid redundancy. Respect the candidate’s time by ensuring each round adds value rather than rehashing the same questions in different ways.

Another important thing to remember is that senior candidates often tell stories to illustrate their experiences. A quick, one-sentence answer might not give the full picture, so they need time to set the context before getting to the point. As an interviewer, allow that space while also helping them keep an eye on the clock. That doesn’t mean cutting them off; it means managing the conversation respectfully so it stays on track.

And when it comes to final rounds, if 30 minutes isn’t enough to evaluate a candidate properly, book a longer session. Wrapping up early is fine, but rushing through a critical conversation or not having enough time to understand the candidate can lead to poor decisions. A well-paced interview gives both sides the chance to evaluate each other properly; without feeling like they’re racing against the clock.

A smooth, well-structured process reflects well on the company. It shows that you value efficiency, respect candidates, and know how to make decisions, qualities that top talent will appreciate just as much as a competitive offer.

These are some of the key principles I follow when interviewing candidates, and the same things I appreciate when I’m on the other side of the table. A well-structured interview isn’t just about checking boxes; it’s about creating a meaningful conversation that benefits both sides.

Of course, there’s always room for improvement. Some companies send feedback forms to candidates after interviews, but how often do they actually use that feedback to refine their process? Interviewing is a skill, and like any skill, it needs to be honed. Ensuring that candidates have a smooth, structured, and respectful experience isn’t just a nice-to-have; it directly impacts hiring the right talent. Rushed interviews, redundant rounds, and poor time management can turn away great candidates before an offer is even made.

If we want to attract and retain the best talent, we need to do better. A well-run interview process reflects the company’s culture just as much as the job itself. Hopefully, these insights help in making the process more effective, engaging, and respectful for everyone involved. And if you have more thoughts, drop a comment below; I’d love to hear your perspective.

If you enjoyed this article, consider subscribing to my newsletter for more insights on product management, leadership, and career growth. Follow me here on Medium and subscribe to stay updated.

Signing off,
Kavindu Narathota
narathota.com

A few weeks ago, I was having a casual chat with some senior software engineers about their work with product teams. One topic kept coming up: for backend teams, having a PM who knows when to say NO isn’t just nice; it’s essential. That conversation brought back advice I once got from my old mentor when I was moving into more senior and managerial roles: Learn how to say NO.

Over the years, I’ve picked up a few tricks that let me say NO in ways that keep relationships intact and avoid negative fallout. In this updated take, I’m sharing those insights so you can protect your priorities without stepping on toes. Whether you’re a product manager, tech manager, or just someone juggling the demands of both professional and personal life, mastering the art of saying NO might be your secret weapon. So, let’s dive in.

When Saying Yes Backfires: The Perils of Overcommitment

Let’s dive into the “Yes Man” concept. Remember Jim Carrey’s character in Yes Man? Carl Allen, stuck in a rut and burdened by negativity, decides to say yes to every opportunity that comes his way. At first, this flood of affirmative responses opens up a world of exciting possibilities; new experiences, unexpected job promotions, and even a budding romance. However, as things quickly escalate, Carl finds that too many yeses lead to chaos. Overcommitting results in burnout, scattered focus, and misaligned priorities. It’s a fun, entertaining story on the surface, but it also delivers a powerful message: saying yes to everything can dilute what truly matters.

Outside of the movie screen, the reality in many workplaces paints a similar picture. In fast-paced tech environments, employees and managers alike are bombarded with requests; be it new features, last-minute changes, or ad hoc projects. While the can-do attitude of saying yes may seem positive at first, it often leads to overcommitment, causing projects to suffer from scope creep, missed deadlines, and ultimately, burnout. Think of teams that stretch themselves too thin trying to accommodate every request; what starts as enthusiasm quickly turns into chaos when focus and priorities begin to suffer.

Countless industry stories back this up. Startups, for instance, sometimes expand too rapidly by saying yes to every new opportunity, only to later struggle with misaligned goals and dwindling quality. Even in established companies, the unrestrained positivity of always agreeing can lead to an unsustainable workload, where the quality of work diminishes as teams lose sight of their core objectives. In essence, while saying yes is inherently optimistic, without a balance of strategic no’s, the approach is simply not sustainable in the long run.

Why Saying No is Critical in Product Management

As a PM, it’s common to face a constant barrage of requests. Every day, you’re hit with new feature ideas, stakeholder inputs, and those unexpected ad hoc tasks that demand your attention. Without a clear filter, even the best ideas can get lost in the chaos, turning your product roadmap into a jumbled mess of competing priorities.

Being selective about what you agree to is key to protecting your product’s long-term vision. When you say no to requests that don’t align with your strategy, you’re not just shutting ideas down; you’re keeping your focus sharp. It’s like pruning a garden; by cutting away the excess, you allow the core of your product to flourish and grow in the right direction.

Of course, saying no can feel tricky, especially when you’re trying to maintain good vibes with everyone. The secret is in how you deliver it. Instead of a blunt rejection, explain your reasoning and offer alternatives or the chance to revisit the idea later. This way, you build trust and set clear expectations, ensuring that your team stays focused while your stakeholders feel respected and understood.

How to Say No Effectively: Strategies and Best Practices

When it comes to saying no effectively, it starts with recognizing the right moments. Ask yourself: does this request really align with our current priorities? Frameworks like RICE (Reach, Impact, Confidence, Effort) can be a lifesaver here. By quantifying how much value a new idea could bring compared to the effort required, you might find that some requests simply score too low. When the evidence is clear, a lower RICE score indicating lesser priority; it becomes easier to say, “Now isn’t the best time for this,” with solid reasoning backing up your decision.

Once you’ve identified that a no is warranted, the next step is communication. Think of it as having a friendly chat rather than delivering a lecture. Start by acknowledging the value behind the suggestion: “I appreciate that idea, it shows you’re thinking outside the box.” Then, explain clearly why now isn’t the right time, perhaps by referencing your prioritization framework: “Based on our RICE analysis, this request falls lower on our priority list compared to our current focus.” This approach not only provides transparency but also grounds your decision in evidence.

Other tools and frameworks like ICE (Impact, Confidence, Ease) or even simple prioritization matrices can help make these decisions more objective. They turn what could be a subjective opinion into a structured, data-informed decision. This method reinforces that your no isn’t personal; it’s strategic.

Imagine a scenario in a brainstorming session: someone suggests a new feature that sounds exciting but doesn’t match up well with the team’s immediate goals. Instead of flat-out rejecting the idea, you might say, “That’s a creative suggestion, and it has potential. However, our current priorities, as highlighted by our RICE evaluation, need us to focus elsewhere right now. Let’s revisit this in our next planning cycle.” By offering a timeline for reconsideration and grounding your response in concrete metrics, you maintain trust while steering the team toward the bigger picture.

Ultimately, saying no effectively is about blending empathy with evidence. With the right timing, a respectful tone, and tools like RICE at your disposal, you can confidently say no without alienating colleagues ensuring every decision supports your product’s long-term vision.

The Broader Impact: Professional and Personal Benefits of Saying No

Learning to say no isn’t just a professional skill; it’s a way to reclaim your life. When you set clear boundaries at work, you naturally carve out more time for yourself and your loved ones. This isn’t about being rigid; it’s about preserving your energy for what truly matters, whether that’s pursuing a hobby, spending quality time with family, or simply recharging after a long day. A healthier work-life balance means you’re less likely to burn out and more likely to bring a fresh perspective to your projects.

By protecting your time, you also boost your productivity. When you’re not spread too thin by taking on every request, you can focus on high-impact tasks that drive real results. This focused approach often leads to better decision-making and can even accelerate your career progression. Think of it as sharpening your tools; by cutting out the noise, you create space for ideas that truly move the needle.

Surprisingly, saying no can also strengthen your relationships at work. Setting boundaries isn’t about shutting people out; it’s about creating mutual respect and clear expectations. When colleagues understand your priorities and the reasons behind your decisions, it builds trust. They come to see that your “no” isn’t a dismissal of their ideas but a commitment to quality and strategic focus, which ultimately benefits everyone on the team.

Mastering the art of saying no isn’t about shutting doors; it’s about choosing the right ones. While saying no can feel uncomfortable, it’s an essential tool for guiding your team and yourself toward meaningful, high-value work. A well-delivered no sets realistic expectations, safeguards quality, and even strengthens relationships by clarifying priorities.

So the next time you’re asked to do “just one more thing” that doesn’t align with your vision, bandwidth, or priorities, consider these strategies. It may be the most empowering “no” you ever say; and it will pave the way for more impactful “yeses” down the line.

That’s it for this one, folks! If you found this article insightful and helpful, feel free to share it with your network. For more content like this, follow me on Medium and subscribe to my newsletter to stay updated on the latest trends in tech.

Signing off,
Kavindu Narathota
narathota.com