In my experience, things diverge quickly in software development when people stop talking to each other. It’s costly if we notice too late that priorities or needs have changed, schedules slipped, or features evolved in the wrong direction.

Developers, users, managers (product, project, or people managers): Keep talking – all of the time – to each other about priorities, requirements, possible solutions, schedules. (Yes, I’m convinced that every developer needs to talk to users directly.)

Even after you’re “done”, keep talking about whether the software is actually helpful (“delivers value”) and what to improve next.

Developers, keep talking to your colleagues in “ops” and customer support to learn how the software is behaving in real life.

Keep talking to other developers and your boss – share what you’re working on, what you’ve learned, whether you’re stuck, ask for their feedback and ideas.

This was one of the main points of the agile movement: In “waterfall development”, there’s no communication between developers and users about changing requirements or intermediate results. It’s why the Agile Manifesto talks about “interactions”, “collaboration” and “face-to-face conversation”, and states that “business people and developers must work together daily throughout the project.” To keep talking is the purpose of Scrum ceremonies (daily scrum, review, retrospective).

If your (agile) process gets people talking, great. Whatever stops people from communicating – “that’s the product owner’s job, not mine”, “this doesn’t belong in the 'daily'”, “just look it up in Jira” – might be a sign that things could be better.

We’re in this together – it’s called a “company”, after all. Nobody has all of the information, and every perspective matters, so we need to work things out together. Again and again. Keep talking!