Win, Place and Show
Avoid competing against your team. You are not there to be a better coder or engineer. Your super power is helping them to be better and accomplish more amazing things on a regular basis.
Teams are odd and complex things. They’re fueled on the collective traits of the individuals who make them up, while somehow also exhibiting emergent properties which transcend the particular people involved. Honestly, I’m still learning how this dualistic team nature really works, but I’m convinced it revolves around the dynamics of raw ability, mutual comparison, sense of self, clarity of goals and the capacity for the manager to understand where each person stands in relation to the group (and ultimately, the product being worked on).
Like it or not, when you bring a set of humans together, you’re going to see hierarchies emerge. If you’re lucky, these form in ways which benefit everyone, organically, right out of the box. But most likely there’ll be bumps along the way which require a bit more thoughtfulness and attention to people’s needs and motivations.
The balance is tricky. As a manager, how are you supposed to create an environment of fairness and consistency, yet also show flexibility and adaptiveness when people seek to make changes that effect others on the team?
The classic tool of the manager is to blatantly assert hierarchical dominance. “Because I say so,” while a powerful motivator, should really be used as a last resort. If you really need to use it, do it. But understand it will cost you in the long run – particularly with a group of software engineers. If you’ve gotten to that point, you’ve probably done something wrong – and should be rethinking your managerial approach – or at the very least, change your area of focus on what exactly you’re trying to manage.
Take heart. In time, you’ll find the right approach. There are many pathways towards success here. Over the years I’ve seen dramatically different styles of engineering leadership which have worked equally well. Knowing which cultural contexts to gather your observations from can really help simplify things, and lead to better outcomes.
For example, let’s look at competition and how it can drive or stifle people’s ability to achieve and succeed. Some things to consider: are all people inherently competitive, even if they don’t identify as such? Is competition a nice to have, a requirement or something to be avoided? Are there good kinds and bad kinds of competitive spirit?
We have some data on this topic. Studies suggest that competitive pressures help improve outcomes for physical challenges, but tend to be counter-productive for tasks where memory and mental retention are required.
“If competition does indeed have an effect on attention, competition could have a varying effect depending on attentional load. In accordance with the Yerkes and Dodson law, one might expect that competition may improve performance in situations requiring a low attention load, but not in learning environments requiring high attentional load.” Brynne C. DiMenichi & Elizabeth Tricomi, The Power of Competition: Effects of Social Motivation on Attention, Sustained Physical Effort, and Learning (2015)
Originally devised in 1908, the Yerkes and Dodson law describes the relationship between arousal and performance. It shows how performance rises with increased psychological stimulation (“arousal”) – but only to a point. When too much stimulation is introduced, learning, cognition, and overall effectiveness start to decrease. As one might expect, this pattern tends to map cleanly against a familiar bell-shaped curve.
According to DiMenichi and Tricomi, this does not seem to hold true for tasks requiring deep attention and more complex thought processes. There are a few reasons suggested for this, one being the introduction of glucocorticoids (stress hormones) into subjects’ brains which not only serve to damped the Yerkes Dodson effect, but at times invert the gains seen with tasks requiring lower attentional loads.
Another explanation was described by Carol Dweck and Ellen Leggett. In their paper A Social-Cognitive Approach to Motivation and Personality, they describe two basic adaptation systems in children confronted with novel and difficult tasks. The subjects tended to split into one of two camps, each with their own major pattern of cognition-affect-behavior: the so-called “helpless” response and the “mastery-oriented” response.
Children who veer towards the helpless pattern experience a loss of belief in their abilities and engage in a defensive withdrawal of effort. Their attention becomes divided between formulating optimal strategies to solve goals while also worrying about how they appear and whether the outcome will match expectations. Those adopting the mastery oriented pattern exhibit a more durable belief in the efficacy of effort, care less about perceived outcome and are more apt to internalize an intrinsic reward for meeting the challenge in front of them.
What causes this division? Dweck and Leggett suggest this may be drawn from the child’s own theories of intelligence.
“Some children favor what we have termed an incremental theory of intelligence: They believe that intelligence is a malleable, increasable, controllable quality. Others lean more toward an entity theory of intelligence: They believe that intelligence is a fixed or uncontrollable trait. Our research consistently indicates that children who believe intelligence is increasable pursue the learning goal of increasing their competence, whereas those who believe intelligence is a fixed entity are more likely to pursue the performance goal of securing positive judgments of that entity or preventing negative judgments of it.” Carol Dweck and Ellen Leggett, A Social-Cognitive Approach to Motivation and Personality (1988)
Those with a more fixed view of cognition tended to focus more on negative ability judgments from others, leading to helplessness. In contrast those who see themselves as more malleable, tend to transform the challenge into a learning goal – with little regard to how they are being judged by others.
In a competitive context we can see how comparisons to one’s cohort might trigger this division, resulting in a shutting down of effort and concentration in some members of your team. Because of this, it’s probably best to play down competitive pressure within the team. It may improve outcomes for some, but will leave others miserable and stressed out.
Note: perhaps the most important and fascinating point in their study reveals that “… children who avoid the challenge and show impairment in the face of difficult circumstances are initially equal in ability to those who seek challenge and who persistence.” (Dweck & Leggett, 1988). In other words, there is no difference in raw potential for either group. It’s just that some have chosen a different coping mechanism than others.
So if you’re not relying on the hierarchy to bring focus and correct problems on the team, what should one do to keep things on track?
It’s helpful to remember that not every problem requires your direct involvement in finding a fix. One thing software engineers are great at is identifying and solving problems. Great leadership is usually about setting context and shaping focus, not directing tasks or uprooting people from their intentions. There are some things you can observe and understand along the way which can help with how and when to directly intervene, and when to step back and let the team work things out.
This can be a frustrating and disappointing thing to internalize, but your raw ability to convince the people you manage may vary greatly from team to team (or person to person). This isn’t always about trying harder, or manipulating people or even better understanding the circumstances you’re in. Sometimes the personal chemistry is such that you may not get through to the person in exactly the way you want. The advice here is to take small steps toward improvement, keep a sharp eye out for improvements, even minor ones – and iterate. Also, be patient. It could take months or even years to get where you’d like.
Have you examined your own need to compete against those your manage? It’s incredibly common in the software engineering world. Newer managers often feel compelled to know more than their team and exhibit this knowledge in stark and tactless ways. No doubt you had to work really hard to get where you are, but the skills needed to manage are different from those to do the execution of the engineering. Don’t outshine those around you. As long as the work is getting done and everyone is reasonably stress free, your job is basically done. Don’t turn things into a personality contest.
This said, there are times when the team has a need to see you compete for relevance. Being too eager to shy away from the same challenges they face can erode your credibility. This is why it’s important to stay on top of your engineering game. If you can’t write code or spin up solutions on your own, keep abreast of the latest coding patterns, tooling and frameworks.
Experience and a Culture of Learning
Teams will almost always have a wide array of skills and expertise. This diversity allows you to get more done and stay nimble, but can lead to balkanization of “smart kids” and everyone else. There will be other articles on this topic here, but the short response is to make it clear that those with extraordinary skills are required to pass them along to the rest of the team in some form or another (pair programming, tutorials, code reviews, etc). The ability to share and mentor are essential traits I always look for when hiring in the first place.
The Larger Organization
How does your team fit into the overall organization you work for? Are they at the core of the business with tons of visibility, heightened expectations, fast turnarounds and short notice? Or is their workstream more under the radar with more room for failure and recovery? It’s essential you understand the relationship to the rest of the business and plan things out accordingly. Are you staffed with firefighters or surgeons? If you find you have a mismatch, work with your company’s leadership to surface the gaps and either recalibrate expectations outside your team, or take on the resourcing needed to transform.
Finding the right way to motivate people is highly dependent on the particular blend of engineers on your team at any given moment. Circumstances matter. What appears natural and effective for one team will be completely inappropriate for another.
Like anything else you’re trying to get better at, leave yourself the time to observe, reflect and adapt your approach. Learn how to identify the team’s inherent abilities, working context, and the exact nature of your sphere of influence.