In the book, “Drive“, author Daniel Pink talk about the primary underlying motivators of people based on research. He indicates that these are:
- Autonomy: The desire to direct our own lives
- Mastery: The urge to get better and better
- Purpose: The service of something larger than ourselves
Each one of these elements can then be decomposed even further such as:
- Autonomy – Giving an individual more control over where or how they work
- Mastery – Providing recurrent opportunities for investment into skill growth or activities that provide both stretch and deliver propositions for the individuals or teams.
- Purpose – Making the “why” of what they do highly visible or helping them see how their work contributes to the business as a whole or what impacts that they make through the work they do.
In my experience, these core ideals have always resonated me and they have been used within the culture we’ve built in my organization(although it could be more widely accepted):
Autonomy – We work hard to nurture the separation of the “what” and “how” of the work to be completed focusing the teams to have the freedom to have deeper ownership of the latter. We have balanced this by helping the culture find the value of conversation to find the best solution to meet the highest value. The best idea comes from where it comes from but no one has “carte blanche” to beat anyone into submission to follow their idea.
We utilize a remote work policy that is centered around being a professional and taking the work commitments seriously. Our teams are professional enough to understand that they have the ability to police themselves and have support from scrum masters and leaders in they see that someone is not pulling their weight or may bring it up for open discussion in a retrospective without fear. We expect notification as leaders so we can be responsible for knowing where our people are as a professional courteosy, that they have discussed it with their team and scrum master if they know they need to be offsite. We feel like this is polite notification as opposed to restrictive and teams seem to agree.
We use the general philosophy that “life happens”. I recall personally working jobs in which the expectation was that I took a vacation day for having an appliance delivered or having to take a sick day when I might be too unwell to make an hour commute but could have continued to contribute. By using this underlying idea, we communicate that we understand that people have life obligations that happen and we accept this and are willing to accomodate flexibility in where and when people work as long as we are still getting the work done in the best possible way and not degenerating into remote silos.
Always remember that if the tools and processes you are using carry so much overhead to ask a question, find an answer or interact effectively, an individual is more likely to make a decision in a vaccuum than take on the burder of the overhead of communication.
Mastery – We have realized this in several ways:
- We provide recurrent week long hackathons to allow teams to focus their creativity on thinking about interesting ways to solve a problem or extend a product. This is focused around exploration of an idea and focused skill work, not product deliverables.
- We provide to each and every member of our group a pluralsight account so that they can take advantage of learning within their schedule anytime.
- We have designed our 13 day sprint cycle with purpose to account for a single day each sprint dedicated towards self-learning, skill building and growth. This provides and opportunity of almost 3 weeks of self learning spread out through the year.
Purpose – This is one that I think we could work on more but we do try and nuture product owners to really explain the end value gain that the business receives from the work that the teams are doing. This has often been promoted by talking a field trip out to the field to meet the end recipients of the work and allow them to explain what they do, how they work today and where their pain points lie. This often creates a solid empathetic connection between the team and the stories that they meet. Sometimes just understanding the history of the work being done, why it is done and what it does for the end customers can help them find connections.
Finding opportunities to allow teams and team members to connect to the business as a whole to learn about what it does outside of the product work would be a solid long term goal and is being developed by our Human Resources team within a learning portal.
One of my goals this year is to determine how we can utilize some of Diana Larsen’s ideas suggested in “Liftoff” to connect teams as early as possible to create deeper understanding and allow them to be directly involved in shaping the work such as story maps and user story decomposition as well as using ideas to connect them better to how their work connects to the business.
How you can undermine your own agility
Often, I have observed that people will do wrong things for the right reasons and wonder what happened to the organization that they created. The group they once believed in starts becoming less agile over time. Please watch and mitigate these issues should you see them begin occurring.
Autonomy – You begin stifling ways of individual work. If you begin to lose focus of where people are, what they are doing (especially in being asked by executives) or “situational emergencies” are seen as only possible to be handled onsite. You begin to predict the schedule based on ideas of when and are not open to the conversation of what as part of that equation. Your actions start communicating that you have a level of distrust in the work of teams as expectations and delivery are misaligned. You develop a culture that wants to “see people” more than it values “the work that they accomplish”.
Focus on schedule begins to overshadow value. You set dates in the sand for features based on limited information and begin eroding the team’s ability to provide you input into complexity and delivery to make value based decisions.
Mastery – There is an old joke in which a CFO questions a CIO about the money being spent on training. The CFO states “what if we train them and they leave”. The CIO replies “what if we don’t and they stay”?
In a creative field, the ability to grow with the industry and get better at what you do is often a core part of your career. It helps you promote, it helps you move to know companies, it often refines or grows your ability to lead either technically or otherwise. Becoming better, is a core value to being a creative worker. Sure, you may eventually hit a pinnacle in which you either trade those technical skills for a new skills or you get to a point where the languages become secondary to the patterns upon which they are built. You see languages as tools and the patterns of how they work become more transitive. Basically a creative career without growth means at some point, you will get stuck. The industry will move away from you. It does not need to sleep or play with it’s kids or spend time with its family, people do. With this being said, I cannot see how any organization that seeks to achieve any longevity with employees would ever consider not investing into employees. It’s a fool’s bet if you do not.
But there is a significant cost to this investment if using conferences, learning sites, etc. Which in the grand scheme of budgets is far smaller than people think, in my opinion. But there is something you can use and that is opportunity. Sure, it has the cost of allowing someone the time and freedom to learn and grow. But the pay-off of staying relavent and having employees who are constantly honing their craft is a good thing. Often time, bottom lines of budget can drive these. Look for every opportunity to keep continual learning alive through peer to peer sharing, local developer talks at lunch and learns or even reducing a team member capacity during sprints to allow them to learn. Find opportunities to showcase what is learned to your group as well as the business.
Whatever you have to do, do not allow obstacles to cripple your team member’s approach to mastery.
Purpose – General George Patton was quoted to tell his troops “Better to fight for something than to die for nothing” in terms of his deep patriotism. Teams and team members want to know that they are doing things that are impacting someone.
I have often said that my affinity for public sector organizations has been because “I would rather create a product that helps a secretary do her job a little better than to make a 10% profitability increase for a board of shareholders I never see; even if they give me a bonus in the process”. Maybe it is because I started in the social work sector before I moved into IT in business or maybe it is because the work holds less meaning to me personally when the measureability is based on profit alone.
In general, people want to do good. I have never met an employee or a team member in my entire career that came to work and said “I am going to do the absolute worst job I can possibly do”. They may be incompetant, poorly trained, not a team player, above their head, etc. but they did not intend to do a bad job. I often remind teams that perform legacy work who complain about older code that many times the developers who wrote that code were doing the best that they could with the tools that they had and within the abilities they possessed. They were just trying to get a job done and help someone. They did not intend to write code that they expected anyone besides them would ever support, let alone, complain about.
I recall being part of a team building a system that at a certain point we began calling it the “Titanic” as we joked often heard the ribbets pop as we scraped along the iceberg. The project scope grew uncontrollably and it became death by committee with each person fighting for their individual wants and making it difficult to get any one thing of value completed. In the end it became a bloated system of 80% features.
The reason I mention this project is that it took the team a LONG time to become frustrated even after the chaos started because we believed in the underlying mission of what the system was going to do. It was targeted to help kids. And help those people helping kids. It was going to ensure that they had better care, they got connected more openly to services and community. The vision was amazing and each and every team member was on board. We watched videos showing vaporware and shed tears at the good we were setting out to accomplish. We were connected to something larger than what we did because we knew how it fit into the world that it would be released to. It inspired us, it elevated us, it pushed us, it connected us. That vision drove us even when we as technical professionals should have know that the end was near as we understood what the purpose of the work we were doing was.
Disconnecting your teams from that purpose is a mistake. Sure, we have systems that are like “hello, this is our accounting system. it handles our payroll and benefits”. But what is the purpose of that system. For a team, this is the system that ensures that people are paid in a timely manner, insurance benefits are kept up to date and vacation time is accurately stored. Without that system, we couldn’t pay people, people could not take vacation and if sick, people might not have insurance if inaccurate information is stored. It helps us apply raises and bonuses that pay for the needs of ourselves and our families. The people that use this system do not ever want to be the ones that have to email everyone to tell them they are not being paid and rent and mortgages are late, etc.
Sure, payroll is dull to me, but it has a purpose, a need, a vision and a connection to the business. If a team is being asked to do something on a payroll system, the “why” is important. Are we speeding up a process? Are we adding a new feature? Are we making a problem go away? Are we allowing people to do something easier or better? Understanding this, can create a better connection for the team to do the work. Reinforcing these things with personas, story maps, etc can even inspire them.
Don’t decouple the “why” from team work. Don’t reduce it to “cause Bob says they need this”. Understand the why. Help them understand it and form a connection with it. Taking the time to do this will allow you to continue to remain agile and continue to support a quest of purpose for teams and team members. It will allow they to understand the business terms, frame questions in business ideology and connect to d the end goal they are trying to achieve.
I decided to write this article as I reintroduced to the concepts of Drive in some reading I was doing lately and thought about how we apply or should apply these ideals in an organization. They are some good core concepts upon which to build an organization that resonates to the base needs for people (and remember those needs may be broadly unique as autonomy for one does not mean the same for others so think broadly about what avenues you support and what you reject.) and how these items can become corrupted as you introduce less agility or embraces practices that work against their nature. It’s not to say that experiement and reflection are not a great way to see the impact of things. Agile is all about, I am all about it. But be open to impacts of things in a organizational way and don;t be afraid to fail or be wrong. Be an organizational scrum master and protect the teams and team members by protecting those things that helps keep them focused and productive and meets the underlying needs. Remove impediments and reflect often. Be open but be vigilent…