Posts

The code and artifacts belongs to the team, not any individual. Collective ownership means any builder can check out and improve any module at anytime. The key is to allow and encourage people to specialize, while at the same time balance that with having generalized knowledge. Team members should split their work between their specialty and other areas so they can help across the codebase. When ownership is shared, knowledge spreads, and the team can make better decisions together. ...

Working unscheduled overtime doesn’t prove dedication. A team member that routinely burns extra hours is a signal of poor planning, agreeing to risky deadlines, or over-promising - not professionalism. It makes them a manipulable laborer, not a trusted partner. Having said that, not all overtime is wrong. Genuine emergencies do happen where extra effort is needed, but those cases should be rare and an “work overtime” solution be something that is chosen deliberately from all the options available. ...

I care about how my team manages their energy. Running faster than we can sustain leads to mistakes, rework, and slower progress overall. Experience shows time and time again, that the worst technical mistakes happen when we push through late-evening and frantic over-work. Projects are marathons, not sprints, so it’s important to maintain a Sustainable Pace. When teams preserve steady, focused effort, the code quality and morale stay high. If a manager pressures the team to speed up, the team must push back thoughtfully. The team’s endurance and the long-term health must be protected. ...

Eric Evans’ idea of Ubiquitous Language is simple but powerful: the team needs a shared model and vocabulary for the problem domain. That model should be understandable to everyone: the builders, managers, operations, and the customers. So that the conversations, designs, and tests all line up. Maintain a living “data dictionary” with concise terms that describe the data and the processes that change it. Discussions for your team Do we currently have names for the core domain concepts that make sense to everyone? Where can we capture and store terms in a shared glossary? Do we use this language in our acceptance tests?

Years ago it was the norm for teams to work together in the same office. In close proximity. These days, teams work remotely, or partially remote. The idea of “On‑Site Customer” was simple: put the right product owner or customer or end-user in proximity of the builders. Close enough so they could quickly shoot questions/answers and get clarity on things, ad-hoc. This resulted in questions getting answered in seconds, and potential misunderstandings caught early. ...