Yet another Joel Test

An addendum related to the engineering culture I’d like to add is the evaluation of the reliability of the tests and the infrastructure (e.g. the build server). It’s easy to setup CI/CD to work a few times, but if the result is not almost perfectly reliable, what’s the point of CI/CD?!

There are too many Dark Matter Developers. They focus on getting things done. Obviously, that’s good. But they also don’t read many blogs, attend conferences, or local meetups. This keeps them trapped in their bubble forever. That’s why I want to have at least some explorative minds in your team.

Equally important as exchanging with the world outside your organization is to learn from each other. You can do traditional talks or present interesting content in the format of Dailies. You can also watch recorded talks and discuss the implications on your work. It can be as simple as ordering pizza and drinks for everybody and hosting a lunch & learn.

Code reviews sometimes are used to ensure quality. I prefer to think of code reviews primarily as an exchange of knowledge. The reviewers learn what has changed recently, and the author learns possible improvements suggested by the reviewers. I believe reviews are crucial to avoid knowledge silos.

Almost every organization has a vision and/or mission statement. Sometimes the vision & mission perfectly matches what you would like to do. Other times they look artificial. In any case it should be interesting to ask blue collar workers about their opinion on the organization’s vision & mission.

According to Measure What Matters by John Doerr: "Contributors are most engaged when they can actually see how their work contributes to the company’s success." If your work feels meaningful, if your contribution clearly has a purpose, your intrinsic motivation raises. The interesting question is whether the team vision & mission is explicitly articulated and whether everybody agrees on it.

Setting goals (e.g. as OKRs) is not easy but also not impossible. The next step is even harder: to measure outcome. Multiple organization I worked with did bi-annual performance evaluations, where you just had to provide convincing arguments why you didn’t do what you planned to do a year ago. So it was highly subjective. I prefer less hand-wavy ways to evaluate whether goals are met. It’s not the end of the world to not fully achieve a goal (see below). So let’s be honest about it.

Nobody is perfect. That’s why no one in his right mind expects constant success. But how do you deal with failures? Do you play the blame game, do you begin to sandbag and underpromise? Are you put under increasing pressure, because the delivery date must be held?

Or are you perfectly allowed to fail? Are you encouraged to risk something? Do you keep risks managable by running small experiments? And do you learn from failures?