Make the Right Thing the Easy Thing: Designing Processes Teams Will Actually Follow

[@krishnapatni]

the Know vs Feel is not discussed a lot by people. Glad you bought up this point. This is actually a very common scenario while leading teams. for yak shaving, we had a rule in one of the organizations I worked for earlier. It was to have 5 mandatory vacation days where you're not allowed to login. if you would, it would be flagged and you and your manager would have to explain to the senior management. this made teams less people dependent.

[@dariolm6965]

This guy nailed it

[@pohjoisenvanhus]

Write a replacement while keeping the current one running sounds great. However I've heard of cases where people need to do that with something that was never specced nor documented which makes understanding the old system and its code not an option.

[@pfeilspitze]

This is where you can do pinning and side-by-side. Use the process of writing something that does the same thing in order to deduce the requirements, and analyse all the situations where your new system gives a different answer.

[@mortenthorpe]

This case is super common, but more to new systems than to rewrites… in rewrite projects, the former project is often a really good prototype, where specifications can be derived. The case you’re mentioning sounds more like a communications and competences issue; the person communicating to the project owner (customer), knows too little of the customers’ requirements, the capabilities of their own engineers, or more likely (commonly), a combination of both. Underlying issues can of course be engineers not being qualified, or capable of communicating their own competences to the project manager, and ultimately making its way as mixed messages to the project owner.

[@teeaalarto532]

Book he mentions at 17:33 is heathbrothers.com/books/switch/