Management Area 4: People — Managing to Motivations

Why optimizing for business value is not the right thing for the business

(Part Four, subpart two, of The Seven Areas Of Software Management)

Introduction

The last post introduced why understanding your team’s motivations was fundamental to people management. That turns to the next problem, which is what motivates your team members is sometimes/usually different to what business needs would immediately have them do. Handling this is what separates great people managers from mediocre ones who churn team members every 1–2 years — realizing that when you disregard motivation, and just optimize for the business in the short term, then the business will not have the optimal outcome in the long term, as unmotivated people will move on, taking their hard acquired knowledge and experience with them.

The easiest way to talk about this topic is to focus on one area of motivation, and I will focus on Flow. The reason is as someone who has 8 years managing teams of ~75% software engineers, it seems to be most software engineers primary motivation. The reminder though is that not everyone’s motivations is the same, and managers need to be able to appreciate and manage team members with other motivations.

What is Flow?

The idea was studied and popularized by Mihaly Csikszentmihaly, in particular in his book, Flow. Straight from Wikipedia: “flow state is an optimal state of intrinsic motivation, where the person is fully immersed in what they are doing. This is a feeling everyone has at times, characterized by a feeling of great absorption, engagement, fulfillment, and skill — and during which temporal concerns (time, food, ego-self, etc.) are typically ignored.”

Csikszentmihal has 9 conditions needed to achieve “Flow” state, which a lot of computer-centered work innately brings as long as the environment is well managed. However, the hardest of the nine is that the work must have the right amount of difficulty balanced against each individual’s skill. “To achieve a flow state, a balance must be struck between the challenge of the task and the skill of the performer. If the task is too easy or too difficult, flow cannot occur. Both skill level and challenge level must be matched and high; if skill and challenge are low and matched, then apathy results.”

Diagrammatically:

The challenge is that software development is high acquired-skill work — in solving problems and writing code engineers are acquiring more skills that makes the same problem less hard in the future.Thus, seen from the viewpoint of productivity, our best optimization is to have engineers work where they are most highly skilled. However, from the view of getting flow, once an engineer is highly skilled in a certain domain, it is less likely there are enough challenges left for them to hit a state of flow. And so long term thinking managers have to balance.

Software Developers and Flow

Stating what you need to do here is easy: to the extent you are reliant on deep acquired skills to get the right business things done effectively, then sometimes you need to let your team do things which are highly motivating to them, whether or not that is strictly the top immediate priority for the business. The way I visualize this is:

That is: good managers walk a curved line between balancing what the business says it immediately wants, and what each engineer wants to do. Importantly: on the picture, that the final point reached isn’t the original business ask is deliberate. The hope is by giving engineers some freedom you will end up with something better for the business than what it asked for. But it might also be worse. But it will never be the same, particularly in software systems where you often have the following dynamic of work needing skill (i.e. presenting challenge)challenge falling over its age:

i.e. Experienced developers will want to work on new systems much more than the business strictly needs. Now, just following that strategy can go awry — anyone who has worked in software development for a while can point to whole teams where they seem to deliver the bare minimal business value while concentrating on what motivates them — rewriting a system that does not need to be rewritten. That is a management problem, but it is foolish to think none of us will ever be part of doing it. The next section has the step by step to get the balance right.

Step by Step Managing to Motivation

1. Know what the business wants from your team. This is not as easy as it sounds, particularly for early managers who think “what the business wants” is just “what my manager wants”. The problem is, your manager might have the same misaligned motivation problem as you and your team. To get on top of this involves working with your Peers/Partners, and putting time into strategic Product Management, which are parts 5 and 6 of this series, so I won’t dive here. An important part is the need to get some sense of tiering of importance/value of the asks. Another early manager mistake is taking over a team which has been mismanaged, with a massive backlog of unmotivating work for very important and vocal stakeholders, and the manager feels their only option is to get their team to spend 100% of time on, even if it’s going to take years to address them all. They are then surprised 12 months in when their whole team starts quitting.

2. Know your team member’s motivations and if they are being hit. The main mechanism is 1:1s, covered by the last post. What the outcome of those should be is for everyone in your team, you should have an always up to date mental tally of what they have done the last 6 months, how motivating it was, and what they want in the future. Importantly, this is an area where following the squeaky wheel getting the grease proverb, leads to disaster. You need to watch for the motivation of your full team, not just the outspoken ones asking for more motivating work.

3. The tally applies to senior engineers. Some leeway can be given to extremely distinguished engineers who have a lot of mentoring taking up their time, and a track record of having done unmotivating work in the past. Here I am thinking people with at least 15 years who would be Senior Staff/Principal Engineer level at the FAANMG companies. But especially for those in the middle (8–15 years), I can think of nothing which demotivates junior to mid engineers more than having a supposed lead engineer who is unengaged with the day to day toil that they have to deal with.

4. Recognize when people are doing the unmotivating work. Sometimes this is verbal praise, sometimes it’s a prize, for some types of work (e.g. toil from the Operations section) you may want to measure and track. Failing public recognition, even private recognition (“I know this isn’t going to be fun for you for the next month, but the business really needs it”) works better than just “you need to do this as its the right thing for the business”.

5. Start scheduling opportunities. My magic number is someone should get a decent amount of time to do something motivating an ideal of every 3 months, and at least every 6. While for some type of people and motivations, you may be able to duplex the motivating work with the unmotivating (e.g. if they want to go to a training course, etc), often the motivating work will need close to 100% of someone’s time. Thus, assuming the business needs things continuously delivered, you need to treat “motivating work” as something you explicitly schedule for.

6. Start working on projects and their justifications. “Person X has done some great but super-unmotivating work and this project is to let them have some fun”, never works as a story to sell a project, not to your team, not to your manager, not to your peers. You need to find a match between what the person finds motivating and something that does have sufficient business value. Sometimes this is just pulling a future priority forward, at which point as long as its scope is not too big, you won’t get many questions. Usually what I end up doing is either that, or finding something that even if the expected business value is not a top priority, it has high value:

• In the first order as a potential outcome. I.e. “this probably won’t work, but if it does it will be game changing”.
• As information. I.e. “Even if this doesn’t work out, it will answer a whole bunch of longer term strategic questions”.

The main thing is finding the right project for each person is an iterative process, because as much as the subtext of needing more motivating work is there, all work your team does needs a story that your team, peers and leadership all can see that it is adding some business value.

7. Time box, and beware silver bullets. From the last section, as value of a project gets more probabilistic, you need to limit potential downside. This can be done by putting hard limits of time (i.e. time boxing), cutting all fat in features, and insisting on incremental delivery. This is particularly important as there is a tendency for these types of projects to be around using/evaluating a new technology, often as part of a rewrite of an existing system (i.e. resetting the timeline in the diagram above). Beyond rewrites taking much longer than expected to capture all existing functionality, you also have the problem that the new technology is only not a silver bullet to the inherent complexity in the existing system, but also brings as many long tail negative downside as benefits. So you end up not meeting any business requirements for much longer than you expected, particularly when you do multiple new technologies at once.

Thus my rule here is any team of ~7 gets to choose one new technology a year to trial, but thats it. As a manager, that may mean you have to pick and choose between your team members most-motivating projects, finding something for the others which while still motivating, does not carry as much ongoing cost. But that is part of the art here, of picking the right motivating projects, and convincing everyone you are doing the right thing for the business.