> By far the biggest lesson that you can verify even on this thread, is that the biggest tech problems are actually people problems.
The opposite lesson is also useful: sometimes you can turn people problems into tech problems, and that's how you can 'solve' them.
Slightly hypothetical scenario: assume your team keeps all the source code on a shared drive. You are supposed to coordinate with your coworkers before touching any code. Sometimes that goes wrong, and looks like a people problem.
If you introduce eg git and automated-tests-before-merging, you can turn that into a technical problem.
My thesis is that organisations (and people in those organisations) can only solve so many people problems. If you lighten the load by automating some of the problems into tech problems, you have more levity on the remaining people problems.
(This happy state of affairs isn't always possible. And sometimes it can backfire.)
The opposite lesson is also useful: sometimes you can turn people problems into tech problems, and that's how you can 'solve' them.
Slightly hypothetical scenario: assume your team keeps all the source code on a shared drive. You are supposed to coordinate with your coworkers before touching any code. Sometimes that goes wrong, and looks like a people problem.
If you introduce eg git and automated-tests-before-merging, you can turn that into a technical problem.
My thesis is that organisations (and people in those organisations) can only solve so many people problems. If you lighten the load by automating some of the problems into tech problems, you have more levity on the remaining people problems.
(This happy state of affairs isn't always possible. And sometimes it can backfire.)