Throughout the observed history, human motivation has adapted to demands and economies of the current age. The first establishment, Motivation 1.0, provided us with the tools for surviving in a harsh and dangerous environment – why care about anything else than obtaining food and not being eaten by predators? During the industrialization era, Motivation 2.0 enabled considerable leaps in manufacturing and productivity with its system of rewards and punishments ultimately paving the way for modern digital work. However, to develop as a creative craftsman instead of a wage slave, we need Motivation 3.0.
Effectively, Motivation 3.0 replaced the carrots and sticks of extrinsic if-then-else stimulants with autonomy, mastery, and purpose. The three branches – or suffice to say a framework – for intrinsic motivation laid out by author Daniel H. Pink in their book Drive: The Surprising Truth About What Motivates Us (spoiler: it wasn't that surprising).
The AMP framework – as I call it – has been my professional companion for long. In this post, I share what the framework is made of, and how it might help you to become the best version of yourself.
You might get more out of this post by reading the book first. Nevertheless, I try to explain the terminology used in the book in the common tongue.
Baselines
According to Pink, before diving deeper into the AMP framework, we need to understand the very building blocks of motivation: our baseline. For developers, they are the pre-requisites for even signing a contract, which includes competent salary, functional equipment, IT budget, ability to work remotely, and other benefits. Granted, these examples are slightly biased towards my own preferences, but it doesn't make them less important.
It's worth emphasizing – especially to recruiters – that proper baseline can attract people to start working with you while successful adoption of the AMP framework will make them continue the work without fear of notice.
Keep on reading if you want to increase employee retention. Before publishing that new rockstar position in your company, get your baselines straight.
Autonomy
🧠 Assume the command of your work and career.
As a developer, I need to have freedom over task (what I do), time (when I do it), team (who I do it with), and technique (how I do it).
The work we do is usually formed around customer needs which can feel inflexible until we come up with a solution: a big task eventually split into smaller tasks. As long as we don't procrastinate, it's all right to work on those tasks whenever we feel a surge of productivity. These are the most accessible parts of developer autonomy. However, we often can't decide the team we belong to or the techniques such as programming languages, frameworks, and platforms we work with unless we land in a new project.
Some companies have strict guidelines on who can do what. Product owners define what is done, and architects plan how it's done without asking for second opinions. Remote work may be banned, and unmotivated people are crammed into cubicles from 8 to 16 every day. Team compositions are homogenous, and developers are permitted only to work on the part of the project lifecycle. There's only one way of developing software set in stone years ago.
Real autonomy can only be achieved by running things on your own, which often means running your own business. Fortunately, for those unwilling to sacrifice the comfortability of a stable payroll, many companies help to boost autonomy by offering a selection of viable projects, flexible working styles, diverse teams and trust their developers pick the right tool for the right situation.
Mastery
📚 Through autonomy, we direct ourselves towards mastery.
To create engaging software, developers need to feel engaged in their work. Some of us are familiar with Mihaly Csikszentmihalyi's concept of flow: the state of mind where our skills meet the level of challenge, and we sink into the task with an outcome of deep satisfaction. You've probably experienced it quite often.
The topic of learning and improving skills is tricky since every one of us has a unique approach to it. Some read books, others listen to podcasts. Some might see the light in a couple of videos, while some need to work on real projects. Therefore, people should be given ample time to hone their skills the way they see fit. It's sad to witness the "features first, learning second" mentality many companies suffer from.
My previous employer had a concept of Freestyle Fridays where the developers spent a whole Friday working on their own projects and presenting them to others. Some companies allocate 20 % of developers' time for non-billable work which is a sweet spot for learning.
Extreme programming practices such as test-driven development (a great source of flow) and pairing – ideally in junior-senior pairs – provide significant results when learning occurs mostly in projects.
As I wrote in my previous post, mastery is an asymptote, and we should not fool ourselves, thinking we can reach the peak. Our abilities are always infinitely improvable.
Make sure you can block time off for improving skills, and your management supports it. Participate in projects where your skills accumulate fastest. Learn things just-in-time to preserve sanity. Focus on fundamental skills and use them to solve problems in more specialized domains.
Purpose
📣 Through mastery, we can contribute better to a broader vision and leave a lasting impact.
Nearly every company claims to have a vision, mission, and a strategy to fulfil those. Many of these companies exhibit visually breathtaking landing pages yet in meetings speak only of the last quarters turnover.
Ideally, our first priority as developers is to satisfy the customer, which enables us to keep our job, but it's not a purpose as such. The purpose lies beyond our work, and it can be anything from reducing the effects of climate change, helping people in the developing countries, or ensuring the local theatre can more easily offer a dose of culture.
The older we grow, the more concrete the handprint we wish to leave behind. Our careers should not be a necessary evil to pass by before we can write that groundbreaking novel during our retirement years. We should do it now, while on top of our game. If your work doesn't fulfil any purpose in your life, stop wasting your time and quit.
Finding Your Drive
The AMP framework unlocks a path to a promising career, but to fully reap its benefits, you also need to study the path of software craftsmanship. A direction opposed to the production line and factory worker attitude with professionalism, pragmatism, and pride as motivators.
It's best to seek motivation from your current job, but in case it's not possible, there are alternatives for developers. A well-researched application of the AMP framework is open-source development. Developing and maintaining open-source projects, especially your own, offers a world of highest autonomy where everything can be harnessed for mastery, and nothing thwarts the journey to a glorious purpose.
Then again, you may find your drive elsewhere, but science has shown that, wherever it may be, the AMP framework is often the culprit. Even a construction worker can feel motivated by building a children's hospital with their chosen tools in a flow state of mind.
Maintaining the Drive
After finding your drive, you should make regular checks regarding the level of autonomy, mastery, and purpose at your work. Have the levels increased or decreased during the past six months?
To close, here are a couple of questions for your next feedback and development session.
- What has changed in your work regarding the task, time, team, and technique? Has the change been for better, or for worse?
- Have you noticed any new obstacles preventing your autonomy? How can you finish your work without hanging onto dependencies?
- When was the last time you learned a new skill? Were you able to apply it to a particular problem?
- Have you got better in any of the skills? To what extent?
- How often have you experienced a flowing state of mind? How can you form regular habits of those moments?
- When was the last time you made an impact on someone or something (colleague, manager, client, society, etc.)?
- What purposes are you serving through your current projects? Do they align with your views of the world?
Feel free to answer in the comments as well!
Photo by Max Duzij on Unsplash.
Top comments (1)
Great book, all IT leaders/managers should read it I think.