Happy Friday,

Last week I took a small snapshot into the practicality and economics of testing, and thank you to everyone who responded and even shared it. Moments like that keep me writing.

I was thinking about teams and motivation this week, and a thought occurred to me that I thought to share this week.

Quite often, technical leaders are picked from development teams. Now, these leaders may not code anymore, but its where they started. It is almost universal that when I talk with them they'll share the same sentiment.

They miss the joy and simplicity of coding.

When I probe further into this, it's mainly that the job today is just a lot more complex and often less satisfying than knocking out some code and calling it a day. To take it further the excitement around coding isn't different from them as it is for almost every developer I've talked with.

They were excited at the idea of building something people will use.

This is the same, primary motivator for most technical teams I work with as well. There is certainly joy in the act of creation, but the real motivation is connected to the purpose of their work.

Maybe an analogy here is something like woodworking. For reference I don't have any background here, so I apologize. I suspect many woodworkers find a lot of motivation in building a beautiful piece but get lost in the craft itself as they work with the wood. In this regard, developers are the same.

So if this makes sense that the act of creation brings joy, but our real motivation is connected to a purpose then it would follow that highly motivated teams have a deep connection to an underlying purpose.

Yet, time and time again I see technical leaders organize teams, information, and communication to keep their teams focused only on tech and view the rest as a distraction.

That means teams everywhere only have the act of creation and are left to find their own sense of motivation. Would it be hard to believe that this leads to higher employee turnover, lower satisfaction, and an accumulation of technical risk?

Companies everywhere are organizing software development groups that exist without purpose. How could they navigate risk when they don't know why they are there? How can they come up with valid options or help the business?

My challenge to every leader I work with is to be transparent and honest about what the real purpose of the group is, let them know what is at stake, what the goals are. When teams connect with that purpose and find a deeper set of motivation, then the joy in the craft has a direction, and you have teams ready to accomplish anything instead of requiring lots of coordination.

Sincerely,

Ryan