5 ms·
In the following paragraph: > Do a bit more “Showing”, so you can release some of the pressure in your development pipeline. Then focus your efforts on activit
by jt2190 5y ago
In the following paragraph:
> Do a bit more “Showing”, so you can release some of the pressure in your development pipeline. Then focus your efforts on activities that build trust, such as training, team discussions, or ensemble programming. Every time a developer “Shows” rather than “Asks” is an opportunity for them to build trust with their team.
A team that builds trust is inviting the second pair of eyes. A team with no trust requires it.
- ljm 5y agoIt's not really a simple matter of trust, though. To take the example of the 'poka yoke' system that was posted here last week: is it because of a lack of trust that equipment operators are required to visually signal to themselves the action they will perform? Or is it because it's a simple and easy way to avoid basic operator error? "We trust our engineers to merge code and not break production," is not the same as "we require peer review of changes to production, and/or QA, to mitigate human error." Or more simply, trust but verify. Not every team will have a CI/CD pipeline that can effectively automate the 'verify' step. Nobody on my team, for example, is worried about being required to have n approving reviews. If nothing else, it's a relief if it means we're not paged at 3am to fix something we deployed without fully checking.