There’s an old saying that has been applied and mis-applied. I learned the saying as “the whole is greater than the sum of its parts.” Judging from the Google fact-checking machine, that is not an accurate quote. I’m sure this is to the chagrin of many makers of motivational posters, like these ones that turned up in an image search.
Look at that last one, though. It is quoted differently by whoever translated Kurt Koffka as “the whole is other than the sum of its parts.” This is probably the most accurate in terms of conveying what a system is, and it implies an inherent impartiality in judging the outcome of the combination, like: “I’m not saying the system is good or bad, I’m saying that it is not the same thing as all of the individual pieces.” But that does not make for a great motivational poster.
So instead, we use the word greater, not other. When the word is employed in this sense, it isn’t spoken in terms of mathematical summation, obviously. Instead, we’re placing a value judgement that the combination of the parts has yielded something better than the fullest capacity of the parts acting individually. This is what we’re talking about when we’re using the saying in reference to a team. Everybody together has accomplished something more or better than what they could on their own.
But I don’t think it is controversial to say that many teams don’t reach this level of coordinated achievement. The reasons why not are as varied as the people on the teams. But to reach that state, each member of the team must continually operate at their potential. Alternatively, they must at least perform well enough to complete the work the project requires. They must be motivated to perform well at this work.
Company leaders will often lean upon incentives to keep engineers and developers motivated. But there’s a big problem with that; it’s easier said than done. Incentives come in many forms, and this is because the definition of “incentive” is intrinsically individualistic. What serves as incentive for one person might not be much of an incentive for another. And this serves as the chief dilemma for someone leading engineers on a technological effort—engineers often do not want to be lead. They want to pursue the activities that they want to pursue.
That’s repetitive and tautological, but it is the simple truth. What makes the dilemma a dilemma is that individuals’ incentives aren’t stagnant, nor are they necessarily apparent. Few people are introspective enough be able to articulate what it is that they actually want, that is, the deeper desires that form their requests. Usually they can instead only articulate first-order desires—their actual requests.
That is, at least, when they are comfortable and encouraged to speak them. And it’s not a given, that managers are encouraging their reports to speak on their desires.
My experience is that companies and their managers generally accept that they do not have a strong grasp on how to motivate engineers. These are really different levels of granularity, though—companies can’t offer the same types of incentives that managers can. Companies can offer cash bonuses, equity, education, and other non-financial benefits as incentives. When managers rely on these incentives as the incentives that can be offered, they become an extension of the company itself and that sense of granularity is lost. In turn, managers lose the ability to help motivate developers.
I can’t say that the leadership in most companies I have worked have understood this. Most managers I’ve had also did not understand it, but some did. On the whole, I’ve had three types of managers:
- The yellers.
- The aloof.
- The invested.
The Yellers
The “yellers” have one common type of incentive to offer, but they will lean on cash bonuses or other nice things to dull the message a bit: do what I want, and you’ll save yourself a lecture or being berated. On the plus side, they are typically pretty deeply informed and involved in the project and day-to-day progress.
Of course, this is because they have to be. In their minds, if the engineers aren’t approaching the problem the manager’s way, then it is the wrong way, and that can’t be left to chance since the manager hasn’t taken the time (sometimes due to circumstances beyond their control) to build trust in the engineers to let them drive the technological specifics of the effort.
The Aloof
The “aloof” don’t really take part in the incentive process. They don’t actually do much managing at all. They’ll walk through the steps required to meet the minimal bar of proof that they’re working, but they don’t invest themselves in the people that report to them. They generally treat their reports fairly in reviews, but they don’t really help their reports when there are mismatched expectations in performance or responsibilities. Engineers are more or less on their own, and the managers only exist to fill a spot in the hierarchy and to fill out reports so that engineers don’t need to.
The Invested
The “invested” managers are keen to find out about the people under them. Software Engineering, Software Development, and related fields are inherently creative ventures. It takes a large level of creativity to find solutions to interesting problems, especially solutions that require consideration of longer-term goals. Engineers are at their best when they feel that they are applying their unique creativity to solve problems. The invested managers learn the people they are managing, and learn their desires, how to best apply their creativity. The invested managers are able to build lasting incentives to keep engineers engaged.
What incentives keep engineers engaged? It isn’t solely more money or promotions.
A company can’t promote the same engineer year after year. Eventually they’re paying the engineer far more than the going rate (which is unsustainable for most companies), and worse, title dilution becomes a real problem. Paying an engineer more money each year might have undesired consequences—a company might be giving an engineer who dislikes their daily work and spreads negativity to remain at the company, miserable and spreading negativity. It’s also possible that a monetary incentive does not have the desired retention outcome anyway. They are pretty effective at lower pay scales but become pretty useless as a developer is paid more in their career and they realize that they can likely get a permanent increase the size of their normal bonus by just switching companies—and have a bonus on top of this, too! I have seen many people leave a company the week after annual bonuses are paid out. It’s like they’re thinking
“Well, if I wait two months longer, I’ll get a nice bonus, but I won’t wait any longer than that; I want to be out of here…”
– Average Engineer, wanting to leave a company around bonus time
More money might be necessary and welcomed for a developer at a time, and bonuses make one feel good when they are received, but they usually only come once a year. How many developers are motivated for 12 months for the promise that that there is a bonus coming? It has to be a ridiculously small number.
This is even worse for companies where bonuses are calculated from profit sharing. An engineer thinks “so not only is my performance a contribution to the bonus, but so is every one else’s, and maybe I don’t think that others are pulling their weight.” Typically, the people who have no control over the success or failure of a project or product are the largest group in a company, and these are the ones who get no bonus.
So the typical incentives suffer from the same problem: their novelty doesn’t last. It’s always one-and-done, and now we can no longer use that incentive, at least not for some prolonged period. And now what? What’s left, if an engineer is not motivated to work their best? There’s nothing, at least not without continual, prolonged investment from managers.
Some companies actively encourage a culture where developers are left to determine their own future. It becomes very “sink or swim.” According to the culture, developers are either able to prove their worth, or they aren’t. This clearly favors aggressive, outgoing personalities more than it does more temperate and reserved people.
It also causes some very talented people to leave.
Everybody needs a niche to fill. Everybody needs to feel that they’re filling their niche, and that if it isn’t filled well for someone, they suffer commensurately with the emotional feelings they have for their own perceived exertion of effort, compared to the value they think they are providing. The longer people have worked in their career, the higher a title they have, the more education they have, the more autonomy they expect to have, and the more autonomy they will attempt to employ in their work. A company’s lower and middle management gets to decide if they want to work in concert with such ambition, or if instead it will be a constant source of friction, because that desire for autonomy will not cease.
This is something to consider when hiring, and when contemplating a technical ladder for promotions. If you want to give someone wide latitude to solve big, ambiguous problems with only broad constraints, then hire a senior candidate. If you have specific goals in mind that you want to see acted upon in a specific way, hire an experienced junior candidate at a higher salary than they’d get otherwise. Or, don’t hire at all.
But don’t hire a senior candidate and let them languish as they try to find their niche in the company. If you optimize your hiring process to incentivize strong, senior candidates, be prepared to get them. Know how you intend to use them—keep in mind that if you hire senior candidates to put out a fire, they will need something else, bigger and better, to work on after that fire is put out. If you hire half a dozen senior candidates, do you have enough big projects for each of them to lead next year?
Consider instead hiring enough junior candidates to keep one or two senior engineers busy as they design the system or subsystem for the junior engineers. Or give the senior engineers opportunity to solve the most critical problems and have the junior engineers provide supporting modules that aren’t as critical. Fred Brooks likened such a situation to a surgeon with assistants.
Managers, use your unique position to help your developers find their niche. Hear their ideas regularly. Refrain from making value assessments of their ideas. Firstly, they might understand something that you do not. Secondly, they’re telling you what will motivate them. Discuss the project needs. See where there is alignment. See what can be done on the side, to determine if an idea is worth pursuing. Be invested in arriving at a workable solution with them.
Developers, think on what is best for your own long-term interests. You probably wouldn’t be as excited as you may first think to get to work on whatever you want to work on at any time—watch your productivity sink as you can’t decide what to work on next, or are constantly distracted by new, fun problems and can’t demonstrate follow-through. You’ll have never done such a magnitude of great work that amounted to so little! Or, instead, help your manager by finding the things in the company needs that interest you. Speak up about your interests—otherwise your manager does not know! Work with your manager to arrive at a plan where you can engage your interests to serve the project needs, or an effective way to kick off a new project and to be set up for success in view of the team’s resources and commitments.
Trevor Kemp 