My current theory of leading software teams and projects has four keywords:
- Trust: I assume everyone is working to get the job done. They assume I will help them get the job done. This starts off more like faith and grows into trust as teams coalesce.
- Autonomy: each person on the team is independently productive for a significant chunk of their day. When they make assumptions to stay unblocked, they are adept at collaborating asynchronously to verify them or correct course.
- Agency: each person solves the task they’re working on in a way they see fit, within the conventions shared by the team. If an interesting idea comes up outside of the those norms, anyone can pursue it such that they maintain the trust/faith of their colleagues.
- Support: each person knows that the team, particularly yours truly, is there to help each other. This most often manifests as pairing on troubleshooting, designing, coding, etc. Most importantly, sometimes it is sharing the load when one person is feeling overwhelmed.
Support is a recent addition. I had previously thought that autonomy and agency were the things enabled by trust. But I’m starting to think1 support is a crucial part of the equation too.
Without support, you’re just throwing people into the pool and telling them they can stay a-float however they like. It omits the “get good enough to swim” part, which is pretty crucial!
This kind of support is most obvious when you’re bringing someone new onto a team. But you need it throughout an individual’s tenure on your team. The people with years of deep experience and history in their head need support of a different variety.
Teaser: I’m on the fence about adding 2-3 more words to my repertoire. There’s a lot of moving parts to leadership!
- Largely due to onboarding people to a team/system/organization with a long history. This doesn’t happen without a larger-than-normal support effort. Perhaps that effort is amortizable over time (i.e. writing docs), but it’s still a big lift. ↩
