This has come up in enough conversations that I thought I should write it down.
A few weeks ago, my bro said to me
If you can’t make an economic case for an engineering decision/initiative, you might wanna leave it alone.
And while I agree, consideration should also be given to the opposing perspective.
Don’t neglect the human side
Software development is a human
process. We are humans with human needs. Sometimes I just don’t have the
energy to tackle a new feature, but I want to work. Picking an item off
the Fun List and tidying it brings me joy. Don’t underestimate how much
better you are as a programmer when you’re happy . Kent Beck, in “Tidy, First?”
I’ve routinely seen team morale at its highest when everyone is focused on the same goal. One task, one feature
For an extended period of time
Extended period of time allows people to learn each others’ rhythms. That’s not something you can speed run unless you have very self aware, or very experienced people who can also communicate well
The shared context makes for reduced overheads of coordination & communication cross teams
This also goes hand in hand with autonomy. It drives autonomy and ownership, but it needs you to be trusted with autonomy in the first place, before you can start reaping those benefits
Having a shared problem & collaborating your way to a solution can also strengthen your relationships with the collaborators. “Something something trauma bond” 😂.
But if we give teams too much autonomy, there’ll be too much variance in our codebases
A way to mitigate this is to have those responsible for architecture & platform to define what the constraints are
Ie: which areas can we innovate on, and which areas are standardised