This week, I wanted to summarize the good practices I’ve observed on the teams I’ve worked with. Or better, on the teams I was proud to be. So, after 15 years working on software development teams at consulting companies, handling different kinds of business markets, it’s tough to do it. However, I certainly remember the good ones — the ones I was happy working on, the ones where I learned something new, or the ones I worked with amazing people.

So, there are three practices I want to share and why I consider extremely important:

1. Timeline

“To go fast, we need to go well”

This is the first thing that came to my mind — because I’m not someone who enjoys doing things in a rush.

Sure, I like the adrenaline of troubleshooting urgent issues in a war room. But doing that all the time? That’s not sustainable.

If we are running projects in the same way we run a war room, something is wrong. The team is probably in pain, and we’re more likely to make mistakes.

When we go well — with planning, testing, and care — we build reliable applications. And in the long run, that’s what allows us to move fast.

2. Architectural decisions:

“To have productivity, we need organization”

This point brings back many memories. I can remember some projects I worked on where someone didn’t make proper architectural decisions, and the team paid the price. The more we worked, the more bugs appeared. We worked hard on weekends and late nights, but we had a short blanket feeling, as we covered our heads, yet left our feet uncovered.

Actual productivity doesn’t come from pushing harder — it comes from working smarter, with clear structure, aligned expectations, and a well-thought-out design.

3. Requirements engineering:

That is something I rarely see people talking about, because it is quite subjective what a team considers as definition of ready, and usually leaders confuse agile with chaos. However, it is absolutely important to understand what the user is asking, to have a clear process to get it splits in stories to the team work on, and create value for the system.

The fact is, once we work in an environment where we have the chance to do the right way, we never want to go back because we can see the benefits of it.

I would appreciate hearing from you what you think about it. Do you agree with me?