Organizations often accumulate technical debt as the pressure to deliver customer value quickly increases, systems grow, and extending functionality the *right* way becomes more difficult.
The Inverse Conway Manoeuvre is unlikely to work in existing sociotechnical systems of a certain size and stability. It is even less likely to work in remote companies and distributed teams.
Mapping the architecture of the system that you are building in your company, is a worthwhile activity. With a bit of preparation you can run successful architecture workshops in a remote setup.
Is not to deploy on Fridays really that wise advice, that it used to be in the past? I would say “No”!
Developer experience engineering is a pretty new discipline. However, there are numerous parallels to user experience engineering. Therefore, DX engineers can learn from the teachings of UX engineering.
DRY is one of the most misunderstood and abused principles. Copy more, reuse less!
Code ownership on a team-level can not only help to identify the team that has knowledge in a certain area, it also can serve as a signal for a mismatch between architecture and team structures.
Code ownership is an important topic when it comes to enabling your teams and allowing developers to improve the system while keeping the overhead of changes low. While today, most companies would (hopefully) agree, that individual code ownership is bad because it creates knowledge silos and makes the organisation dependent on individuals, code ownership still is essential on a larger scale.
Blameless post-mortems are an effective tool to facilitate learning from failures, to share knowledge and to significantly improve the entire system, including software, infrastructure, and processes.
Are you interested in creating high-performing teams and organizations without carrots-and-sticks leadership? Subscribe and get inspiration directly to your inbox.
