This is part two in a series on motivation. To recap the last post: rather than external motivations, what we actually need are internal motivations. This idea is from Dan Pink’s book Drive, and you can also watch an inspiring TED talk about it which I highly recommend. The three main ideas (which we will explore in three parts) are Autonomy, Mastery, and Purpose.
Let’s talk about Autonomy and what it means for software engineers. Autonomy means the engineer is in control of many aspects of their work. Aspects under his or her control might include when, where, and how to accomplish the work, and even what the specific work is.
When an engineer can choose when to work, they are empowered to work at what is their optimal time. Some people are morning birds and think best when their mind is fresh at 7AM. Others are night owls and would prefer to not show up at work until 11AM, and don’t really get warmed up until 3PM. To tell either of these people “company hours are 9-5, you have to be at your desk at that time” would be soul-crushing. Usually companies are fairly flexible with this aspect of autonomy, but we can do better: I’ve seen big corporations that gave the option of 4 day weeks (with 10 hour days), or schedules with every other friday off (with 9 hour days), which were wildly popular with employees.
Most employers offer very limited options for where to physically work. The single option is usually a single desk in an open floor plan. Open floor plans are very popular among managers and office planners, but among developers open floor plans are almost universally despised. As an engineer trying to get into the zone, the best option you can hope for (and it’s worth asking for) is easy access to a guess office or room with a closed door where you can go at will. Better yet, permanent semi/full time work-from-home arrangements are also incredibly popular and easily doable with the nature of work of the software engineer.
Being able to choose your actual work is the pinnacle of autonomy! But how can we accomplish that and still do what needs to get done for the business? In many cases, you may be able to choose the features or bugs that interest you (from those available) instead of all being dictated to you. Some people will naturally gravitate to certain parts of the system or certain kinds of features, giving them autonomy over their actual work. And if you are lucky, there are programs like Google’s 20% time or Atlassian’s shipit days where engineers truly have power over the “what” of the work and still push the business forward. Even if you don’t work for Google or Atlassian, it’s worth bringing up with management to see if it could benefit your company (and benefit you at the same time).
As an employer, you can provide these options of autonomy to increase the engagement of your engineers and the competitiveness of your company, while keeping in mind to find the balance between full autonomy and accomplishing business objectives. As a software engineer, you can ask for these things in your current job or look for them in your next job. With a bit more autonomy, developers can be happier and more motivated, and businesses can be faster and stronger!