In any organization, you will find two types of people, those who work to be part of a mission, and those who work for a paycheck. Ideally, you want to skew your developers towards the former.
This can be challenging owing to the nature of work developers do. You wouldn’t be able to tell if your developer is seriously churning code or trolling people on Reddit. Especially, if you don’t have a technical background yourself.
Thankfully, you can bank on people wanting to be part of something greater than themselves. You can tap into this intrinsic motivation to get great results both for your organization and your team.
In this entry, I will be discussing what I have found to work in my own practice.
Jointly come up with stories
The ideal requirements are out there to be gathered is a truly misleading one.
I believe the act of story writing is a creative one. Out there what you will find is a problematic situation, your job with your team is to interpret the situations as problems and come up with stories which can then solve these problems.
By being involved in this initial problem setting, your team is able to see the meaning to the work they do.
As Fred Brooks put it:
The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures
By allowing the whole team to participate in this process, you get creations which are in line with the complexities of the business.
Regularly reflect on purpose
Kieran Setiya in his article on How Schopenhauer’s thought can illuminate a midlife crisis starts with this phrase:
Having jumped the hurdles of the academic career track, I knew I was lucky to be a tenured professor of philosophy. Yet stepping back from the busyness of life, the rush of things to do, I found myself wondering, what now? I felt a sense of repetition and futility, of projects completed just to be replaced by more. I would finish this article, teach this class, and then I would do it all again. It was not that everything seemed worthless. Even at my lowest ebb, I didn’t feel there was no point in what I was doing. Yet somehow the succession of activities, each one rational in itself, fell short.
You don’t need to be approaching midlife to get this sense, write-commit-push-deploy can feel as grinding.
Your best developers joined your organization for why you do what you do. It is easy to assume this sense will always remain there after all the company has not changed right?
I would posit you need to regularly remind your people why they do what they do. At iHub we built communities, it was always satisfying to see the uber successes in the industry trace their roots back to our organization. At Twiga, we are helping bring food security to the country. From this perspective, each commit matters that much more.
Identify and manage freeloaders
I came across this interesting video showing monkeys understand the concept of fairness
Unfortunately, in any team, there will be those who will be looking to do the least amount of work possible. Even if they never mention it, the other teammates notice and I assure you they don’t like it.
Ben Horowitz called it the law of crappy people:
For any title in an organization the talent in that level will eventually converge to the crappiest person with the title. Everyone at the lower level will naturally benchmark themselves against the crappiest person at the next level.
Present growth opportunities
If you did your interviews right, your people are smart motivated and ambitious. The last thing they want to feel is stuck. Paradoxically, your best devs will resist promotion to management. This is no excuse to give up on them. Instead, provide them with opportunities to grow within their interests.
This means actively monitoring what they are working on and scanning for new opportunities to challenge them even more.
How do you grow commitment within your own team?
This article was first posted here.