Organizing your agile teams? Think about M.A.T (Mastery, Autonomy, Purpose)
Last updated: January 13, 2023 Read in fullscreen view
Recommended for you
- 02 Nov 2023
Differences between software walkthrough, review, and inspection - 02 Nov 2021 What is Terms of Reference (ToR)?
- 18 Oct 2021 Key Elements to Ramping Up a Large Team
- 15 Feb 2024 What is a Cut-Over in Software Development?
- 03 Apr 2022 Microsoft Solutions Framework (MSF)
We use teams all the time at work. When they can deliver by themselves, it’s a thing of beauty.
Too often, teams encounter big problems: it’s unclear how to collaborate with other teams to deliver the needed results; there’s still hierarchy that gets in the middle of problem-solving, and people on the team aren’t able to access the expertise across the rest of the organization.
How do we best organize the people for the work we need to accomplish?
There is no one right way to organize. That’s because people don’t work to make their teams successful first. They work to achieve autonomy, mastery, and purpose. Once they know they can satisfy themselves, the work for the betterment of the team.
First, we need to talk about personal satisfaction with work.
People work for Mastery, Autonomy, and Purpose (M.A.P)
Dan Pink, in his book, Drive, popularized the ideas of autonomy, mastery and purpose. He’s had plenty of company throughout the years. I recently read Under New Management: How Leading Organizations are Upending Business as Usual, by David Burkus. I’ve also read some of the agile management books, such as Joy Inc: How We Built a Workplace People Love, by Richard Sheridan.
M.A.P. as a Simple Framework
Agile makes the ideas of autonomy, mastery, and purpose transparent to everyone. But you don’t have to be agile to use those ideas, or even to provide a fulfilling work environment.
That’s because people don't work to be agile. People work for their satisfaction. Often, autonomy, mastery, and purpose will satisfy them. Keep people satisfied at the personal level and they will provide the results you want in their team.
You might think people work for money. Money is necessary, butnot sufficient.
You can see this in action when people select among multiple job offers. They do not always take the highest one. People say things such as, “I like the team (or my boss) and I think I would fit in well there.” Or “I can learn with or from other people there.” Or “I want to do work that means something to the customers of the product.”
These answers are all about autonomy, mastery, and purpose. The autonomy is about successfully using the culture to work. The mastery is about learning. And, the purpose is about what the product means to others.
Once each person knows that their personal satisfaction is possible, they can succeed as a team. And, the teams need autonomy, mastery, and purpose to deliver.
What happens when teams need other teams to deliver the results the organization needs?
Teams need other teams to deliver results
If you’ve ever been part of a large effort to deliver a product or service, you’ve seen teams collaborating—or trying to do so—with other teams. Sometimes, it’s great. At other times it’s a disaster. What’s different?
When all of the teams coordinate, as in a program, the teams know the purpose for the product or service, assuming someone has created a program charter that shows the value to everyone.
How can you create an environment that helps people see when they have interdependencies? I like program management with rolling wave deliverables. That’s where the program product owner value team (the product manager and the product owners) say, “Here are the results we need for the program, now and for the next few weeks. We’ll update those results as we see you deliver.”
This creates a loosely coupled environment with autonomous teams who understand how to deliver their chunks. If the program management creates rolling wave plans, the teams can adapt to the ever-changing environment and adapt their plans.
Not everyone understands how to do that.
If you don’t use program management, you can use holacracy, which says, “As teams, we have the responsibility to deliver. We will make our decisions and coordinate so we deliver the results.”
Teams take responsibilities. They might shift those responsibilities over time. And people might shift responsibilities over time, too. For example, if a team completes its designated work for a given product, it might help another team complete its work.
If a person sees a need somewhere else in the organization, that person can take that responsibility. He or she would explain, “I see the need for more build automation. I’m going to attack that for all of us, okay?”
In holacracy, each person’s role is fluid. The job description doesn’t drive the work. The work drives what people and teams deliver to the organization.
Notice how teams and people have authority to make their own decisions. The teams iterate rapidly, not just for the product, but for how the organization works.
Holacracy introduces the notion of circles, with a specific role of “cross-link.” This person has the responsibility to work across the organization in order to initiate the discussions with other teams and circles. Each team has the responsibility to deliver its results, and each has a responsibility to work across the organization as its members like, in a way that fits the organization.
Note how the teams take their responsibilities. That means the team has the autonomy to work the way its members like to work. They build mastery as a team, and take roles when needed to serve the higher purpose.
In holacracy, teams have no top-led decision making authority. That helps the hierarchy problem. But what if holacracy is not for you? Fortunately, you have other options to reduce hierarchy.
How to Motivate a Team of Software Developers
Motivation leads to higher performance and satisfaction in the job. But how can we motivate a team of software developers? Sadly, there are common misconceptions about motivation that do more harm than good. Fortunately, science has already discovered the motivators that work: autonomy, mastery, and purpose. This post presents these three pillars of motivation and concrete actions to implement them in software development environments.
- Contingent, expected, “if-then” rewards don’t work in creative, non-routine jobs like software development.
- They kill intrinsic motivation, reduce creativity, encourage short-term thinking, shortcuts, cheating, egoistic behavior, and lead to poor performance in the long run.
- Avoiding “if-then” rewards means that the reward should not be announced up front and therefore be expected: “If you do this, then you’ll get that”.
- The three pillars of intrinsic motivation are autonomy, mastery, and purpose.
- Autonomy: Ideally, the developer has the freedom to choose their tasks, the technique to solve the task, the time when to solve the task and the team in which they like to work. However, in reality, there should be some restrictions applied to avoid chaos.
- Mastery: The developer has the opportunity to learn something new and to constantly become better at something that matters.
- Purpose: The developer’s work has an impact and changes something for the better.
- For each pillar, there are many actions to implement them in a software development environment.
- Motivation is individual. Ask the developer about their motivation in one-on-one meetings.
Autonomy
Autonomy is the first pillar of motivation. First an foremost, people are motivated if they can choose their tasks and decide how to solve them. But autonomy has even more aspects. They are called the four T’s:
- Task. Decide on which task to work on.
- Technique. Decide how to solve a task.
- Time. Decide when to work on a task.
- Team. Decide with whom to work on a task.
So far so good. But how can we implement autonomy in a software development organization and team?
- Being in a self-organizing team. This term subsumes many very important team characteristics which also affect the motivation of each developer. Some are:
- Select one’s favorite tasks. Every developer can take the task from the task board that they like most. There is no assignment by the team lead. This leads to a sense of ownership and commitment.
- The team is empowered to work on all aspect of their application. This includes tests, build, delivery, releasing, operations and monitoring. This relates to DevOps.
- Freedom of Technique (including Technology).
- A developer should have a reasonable amount of freedom on how they solve a task. First and foremost, this can mean things on the code level (class design, algorithms) or some aspects of the UI. But this can also include the used libraries, frameworks and the language. For instance, I experienced a huge motivation boost when we decided to introduce Kotlin at Spreadshirt.
- BUT unrestricted freedom is dangerous. It can lead to a zoo of technologies and ecosystems that can’t be maintained anymore. Having a consistent technology stack improves the productivity, eases operations and employees can change the team more easily. In the end, it’s a trade-off between motivation/innovation/better solutions on the one side and productivity/maintainability/aligned operations on the other side. At Spreadshirt, we agreed on the following compromise: Each team can use their own libraries and frameworks as long as they stick to the JVM ecosystem. Greater changes in the technology stack (using a new language like Kotlin or a completely new ecosystem like Ruby, Go or Python) are possible but need to be discussed. Moreover, we run quarterly “Hacking and Innovation Days”, where the developers can try new things. This is important to satisfy everyone’s urge to try something new without affecting productive code.
- Finally, it’s important to highlight that technology decision should be team decisions. Everyone should commit to a certain decision because potentially everyone has to maintain it.
- No Micromanagement. The team lead should not try to control and check every detail. They should let go, delegate tasks and trust that every member will come up with good solutions on their own.
- Everyone is Involved in Design Decisions. Every team member should be involved when it comes to decisions about design and architecture. We usually hold a meeting when we have to come up with a database schema, architecture, design decisions or bigger refactorings in our software. After my experience, the outcome of those meetings is great and much better than the solution of a single developer. Swarm intelligence impresses me every time! Some important rules for the moderator of those meetings are:
- This meeting isn’t about the senior principal software architect presenting their solution while the others are listening reverentially. Architecture and design is everyone’s task and everyone can and should contribute.
- Asking questions instead of presenting your solution. It’s very interesting to hear other approaches and ideas that have not been influenced by your solution. At the end, you can still propose your solution.
- Introverts also have good and sometimes even better ideas. Ask them proactively about their opinion.
- Flexible working hours. Fortunately, this is already standard in most software development companies - for a good reason.
- Noncontrolling language. The phrasing is crucial. This applies not only for feedback in code reviews but also for the daily communication within a team. Try to avoid phrases that contain “must” or “should”. Instead, use “think about …” or “have you considered …”. Again, ask questions.
Mastery
Mastery is about getting better at something that matters.
There are several things an organization can do to support a developer’s mastery:
- Fixed Time for Hacking and Innovation. Many companies have different names for this. They call it “FedEx Day” (Atlassian), “20 % time” (Google, Atlassian), “4+1” (itemis, codecentric), “Hacking and Innovation Days” (Spreadshirt), but they mean the same: Giving the developers time to try new ideas and innovate without any restrictions. At Spreadshirt, those days are holy and much fun. We often came up with very cool ideas that make it into production. At Google, Gmail and Google News are outcomes of those hacking days. So it’s not only about mastery and motivation but can also generate great innovations with business value. The frequency of those hacking days varies from 20 % (one day of the week) to quarterly events. For the start, consider to start with two days each quarter and see how it works.
- Conferences. Allow your developers to go to conferences. At Spreadshirt, every developer is allowed to attend a conference once a year. Additionally, support them, if they like to hold a talk at a conference.
- Internships in other teams. At Spreadshirt, a developer can make an “internship” in other teams for one or two weeks. I can’t highlight enough the value of those internships: It’s so interesting to see how other teams work, what are their processes, what are their technologies and solutions and what are the social dynamics. And the knowledge exchange works in both directions. I also experienced an stronger social bond across the teams after such internships.
- Internal Conferences. Another instrument to knowledge exchange within the IT department are internal conferences. Our “conferences” are called “DevDay” and take about 5 hours and consist of 20 min talks in two parallel tracks. Every developer can contribute a talk. A collective lunch for “networking” closes the conference. Our experience is great: It’s so interesting to see what other teams are working on and what are their solutions and experience.
- Task-Shifting. Do the same stuff over and over again is boring. You stop to improve your skills. So it’s a good idea to let the task rotate within your team even if it takes longer at the beginning. Moreover, you keep capable of acting in case of absences of certain team members. An extreme form of this is shifting whole developers between the teams.
- Provide magazines and books.
- Allow attendance of online courses and webinars.
Purpose
Purpose is about working at something that matters and changes something (in the world, business, organization, community or team) for good. Doing meaningful work is motivating.
- Visibility of progress, success, and impact.
- Kanban Boards and Scrum Task Boards are great tools to visualize the progress of work. It’s a satisfying feeling to move a ticket from “In Progress” to “Done” and to see one’s contribution to the team’s work. It’s also a good feeling if all tasks are eventually end up in the “Done” column at the end of a sprint.
- A Burndown Chart is also a great tool to visualize progress and the impact of each team member’s work.
- Sprint Review. Presenting the development progress to the customer, stakeholders or users is also a good point where progress becomes visible.
- Metrics, Logs. A developer put a lot of effort into optimizing the performance of a remote call or an algorithm? It’s so rewarding if there are metrics (e.g. in Grafana) showing the improvement in terms of shorter response times and higher throughput. At Spreadshirt, we have Mini-PCs with multiple monitors showing Grafana dashboards in each office.
- Statistics, Reports, Live-Ticker. The same applies to domain-specific reports and statistics (conversion numbers, order reports, throughput). For instance, in our current project, we compare the decision quality of our application with the one of humans. It was so motivating for us to see the statistics of our applications becoming better and better over the time. Another example is our Live-Ticker, a small web app that shows the latest decisions of our application. It’s so cool to see our application doing its job.
- Appreciation. Usually, each developer is doing a good job and the team is recognizing it. But often, we don’t express our appreciation. That’s sad because praising doesn’t hurt you, but could mean a lot to the praised developer and improve the interpersonal relationships. I believe that appreciation is one of the most powerful instruments for motivation. But there are some gotchas:
- Be precise and personal in your feedback. Don’t: “You all did a good job”. Better: “Tim, your improvements to the algorithms significantly speeds up our response times; Well done!”
- Be situative. Give feedback right in the situation where the effort takes effect.
- Don’t praise inflationary. This weakens the effect.
- Don’t make praising become an award ceremony. This might lead to envy and frustrated developers. When in doubt, prefer giving feedback in private.
- Despite the daily working time in the office and one-on-one meetings, there are other possibilities to say when something went well like the sprint retrospective meeting or the daily standup.
- Everyone is Involved in Design Decisions. This point is important for autonomy, but also for supporting purpose. In a design meeting, every team members hopefully understand why the application is developed in this or the other way.
- Redirect positive feedback to the team. Positive feedback from stakeholders, customers, users or the C-level is often expressed to the product owner or the team lead. It’s very important to redirect this rewarding feedback to the whole team: Forward E-Mails, quote a user’s praise in the daily standup or copy it into the team chat. It’s so simple but powerful. In the past, I often saw team members proudly remembering those praise.
- User Story Mapping. At the start of a new application or functionality, we use User Story Mapping to discover the user’s journey through the application and to prioritize the features. This helps all developers to get a common understanding of what needs to be done and the benefit of each feature for the user.
- Direct Contact to Users and Stakeholders. That’s a tricky one. Having too much contact with users and stakeholders can be exhausting and too time-consuming for a developer. No developer likes endless meetings with stakeholders. Usually, this is the task of the product owner. However, talking to them directly from time to time makes the developer see that their work is really easing the user’s life and is making them happy. This is a rewarding experience.
- Highlight everyone’s contribution to the team success. Every developer is contributing to the success of a team. Giving expression to this contributions doesn’t hurt you but mean a lot to the developer. There are several opportunities for this: the daily standup, the sprint review, the sprint retro or just at any time. And don’t focus on the tasks with “impressive” output like frontend tasks. Automating the delivery pipeline, increasing the test coverage or improving the code quality via refactorings are valuable efforts that ease the life of the whole team and therefore deserve praise.
- Celebrate success. Reaching an important milestone, shipping a new feature or simply having an anniversary can be good opportunities to step back and look back at what the team has achieved. Celebrations increase the awareness of achievements. So take your time, write an e-mail to all colleagues and invite them to some popcorn, beer or ice cream in your office.
- Financial Safety. If you don’t pay a developer enough, he will question the reason for going to work every day. Mind, that the highest paid developers are not the most motivated ones. Money doesn’t motivate. But lacking money can demotivate. So it’s about creating a monetary baseline to get the topic “money” off the table.
- The definition of Product/Project Vision, Sprint Goals, Milestones are a good mean to express purpose explicitly.
- Open Source Contribution is motivating as it serves a higher purpose than fulfilling business requirements. It’s about giving something back to the community and helping others. If a developer has created something cool, suggest to open-source it on GitHub. This way, others can benefit, provide feedback and praise and may even contribute. This is motivating and can improve the company’s reputation as an attractive employer.
Sum Up
Explore more on these topics
Guest Blogging: The Definitive Guide
