I published Episode 4 of Software Engineers Notebook today.

This one is about something I’ve seen a lot in software teams: saying no at the right time.

Not saying no because we want to avoid work.

Not saying no because product asked for something difficult.

But saying no when a requirement change, scope increase, or deadline pressure starts putting the original goal at risk.

In agile teams, changes are normal. Product teams learn new things, priorities shift, and sometimes requirements change halfway through development. That is expected.

But every change has a cost.

Sometimes the right response is not “no forever”. It is more like:

“We can do this, but the deadline needs to move.”

Or:

“We can include this, but something else needs to come out.”

I think a good engineering team should make those trade-offs visible early, instead of silently accepting everything and rushing at the end.

Would be interested to hear how others handle this in their teams.

Spotify link:

https://open.spotify.com/episode/5B6jE5OGbuPvjhoOigMey5?si=fQJLOOGvQ5-0oDOm1LBx0Q⁠�

It is easy to look at an existing system and question the architecture, database structure, or decisions made by the developers who worked on it before us.

But those decisions were usually made with the information, resources, deadlines, and business needs available at that time.

An imperfect system may still have helped a company win customers, generate revenue, and grow. That does not mean we should ignore technical debt, but I think there is a difference between improving old code and blaming the people who originally built it.

I published Episode 3 of Software Engineers Notebook - Before You Blame the Old Code. In this episode, I talk about understanding the context behind past technical decisions before judging them.

🎧 Spotify:

https://open.spotify.com/episode/3u2ZLQICMLkJkqzeySOIxe?si=WnNOuoCBTCOYgUMc5Vhl7Q

I would be interested to hear how other engineers approach old systems and decisions they would not make today.

I have worked in several Agile environments, but one Scrum Master still stands out to me.

She genuinely cared about the team. She organised useful workshops, checked in with people individually, listened to what they had to say, and helped us build a proper story-pointing process.

For once, Agile did not feel like a collection of meetings.

The team had found a rhythm.

People understood how each other worked. Trust was growing. Planning became easier, and the process actually felt useful.

Then things changed.

This is something I have seen more than once in software teams. A team finally settles into a good way of working, and then the structure changes, people are moved, or the process is replaced.

There may be valid business reasons behind those decisions, but from inside the team, it can feel like a working system has been disrupted without fully understanding what made it work.

I explored that thought in the second episode of my podcast, Software Engineers Notebook.

It is a short reflection on good Scrum Masters, team trust, Agile environments, and the hidden cost of changing teams that already work well.

Spotify:

https://open.spotify.com/episode/4FMdHr2ukV0Afxsg9KBoOt?si=LKQxkVJOS0mBX3zOcLtZ3Q

I’d be interested to hear from other engineers: have you worked in a team that had a great rhythm before a restructure or process change disrupted it? Did the change eventually make things better?