This post is about developer’s productivity. I’ve been meaning to write this a while ago, but I guess it got stuck in a clogged synapse. I have an engineer brain, so my inclination is to think about people in very complex ways, but then I balance that by reading about psychology, behavior and marketing, and I realize people have some simpler needs that are more obvious than the engineer brain thinks. Although a software engineer will appreciate and relate to this post, I’m really talking direct to founders of startups, CIOs, CTOs and other managers of developers who aren’t developers themselves.
Twice as fast
There are just two pieces that you have to understand to get a developer to solve a problem twice as fast: his inner motivation and external factors. Like on any other thing on our life, if we don’t feel like doing something, we drag our feet. On top of that, there are possible impediments or obstacles that make it harder to actually do the work. Managers, leaders, founders and developers themselves should be aware of those, address it and clear the path.
Intrinsic Motivators: 5 Ways to improve it
Which project do you think would get done faster? Project A: a simple dentist website as a school project for a hypothetical dentist with hypothetical requirements and deadlines, which you’ll get a grade at the end; or, Project B: a simple dentist website for a dentist, who you met at a party and you have an amazing crush on her/him, and he/she didn’t know how to do a website for themselves and you jumped right in and volunteered to do it? If you answered Project A, this blog post is wrong for you.
That’s the power of really wanted to do it. Of course, the example above uses an “extrinsic” force (i.e., the probability of getting a date) as a driving force, but still, that doesn’t take away the fact that you really, really wanted to do it.
Here are 5 tips to improve intrinsic motivation in no particular order:
Motivator #1: Build something cool
Nothing, absolutely nothing will get a developer more excited than building something cool. Cool by their standards, not yours, not the business, not the sales team. But what’s cool? It depends. It depends on the developer, on what they want to learn next, how they want to evaluate success, etc. The easiest way is to learn what each developer care the most, inside of the boundaries of what needs to be done, and give it to them. Yes, I absolutely get that component A needs to get done, before component B, but forcing a developer to build something they are not 100% into it will cost you 30%, 50% or 100% more time to get it done.
Motivator #2: Autonomy
The more time someone lives without autonomy on their day-to-day job, the more babysitting they need to get their work done. The more a manager schedule a developers daily bugs, or the details of the features that need to be done, or the meetings a person should attend, the more the manager will need to do it, to the point where the manager thinks he’s surrounded by dependent child-like developers who are incapable of taking any initiative. You get whose fault this it, don’t you? The converse is also true! The more independence and autonomy you give to developers the better they get at being independent self-driven contributors. The better they get at figuring out requirements, getting unblocked, chasing other folks to get their stuff done if there is a dependency, at testing their own code, and lo-and-behold, at understanding why they are building what they are building! Which leads me to...
Motivator #3: Know the Why!
Do you know who are some of the most overworked, underpaid and underappreciated workers of all? Non-profit organization volunteers! They work for free, sometimes under unsavory and unsafe conditions. They don’t do glamorous work and have very little autonomy on what they do. But they know exactly the purpose and meaning of their work! Making money is not a “Why”. Shipping software is not a “Why”. Whose lives is the software being built is going to make better? How is that piece of software connected to that? A developer who gets the “Why” will go further and faster than a developer who doesn’t.
Motivator #4: Newness
The majority of developers get excited like 5-year-old learning how to ride a bike without training wheels if they have to learn a new technology. It’s almost like they dare themselves to learn it and getting good at it. If you go to your average web developer and tell him he’ll have to learn a couple of new technologies to work on the next project, before you are done telling it he’s already thinking about friends who have been using that technology, about books that he’ll buy or online videos and courses he can use, and little side projects he can try with the new tech. That happens almost all the time, unless you have a non-developer pretending to be a developer on your team.
Motivator #5: Impact
For developers, size matters. That’s the market size. When Google, Microsoft or Facebook tell a candidate he’ll be working on a project that will be used by 700 million users, it's a hard selling proposition to beat. OK, not all projects will ever reach that scale, but make sure people feel like either it could reach that scale or, indirectly is reaching a massive scale. Writing software for real estate agents might touch just tens of thousands of people, but once you multiple that by the number of people those real estate agents are helping, you start to talk about the impact of your work in a much larger scale.
The five core motivators that I listed above are critical at getting developers waking up in the morning, excited to go to work and working long and hard to get things done. Part 2 of this post talks about "Boosters" for developers, small things that make a big difference.