I’ve come to firmly believe that Engineering Leadership has a 3-2-1 principle to create Engineer happiness, which is a key prerequisite for high performance Engineering teams.
Engineer Happiness Leads to High Performance Teams
Good Engineers are like most people: they want to be happy at work. Unlike some people though Engineers get a significant amount of overall happiness FROM work, so it can be a dis-proportionally big factor in their overall happiness in life. It’s not just because Engineering can mean long hours. Many Engineers are also makers, folks compelled to make. Many really want to do a great job, and crave the recognition of other smart Engineers that their work is good and valuable. I believe this is a key part of what drives Open Source.
Over the years I have observed that there’s a set of things that need to be in place for an Engineer to be happy in his or her job. These have nothing to do with which technology or platform is being used. It has to do with the overall environment.
Happy Engineers are productive Engineers. Happy Engineers invent amazing new things. Happy Engineers deliver products and solve problems. Happy Engineers are the key to having a high performance Engineering team.
Three Factors of Motivation
I think Engineers are pretty simple when it comes to what motivates them. I think it boils down to three things:
- Engineers want to BUILD things
- Things that help people somehow
- Things that actually get used
This is trickier than you think. Lots of projects and companies are actually not all that helpful - they are just an excuse to play with a technology. If you want to really tap into the core of an Engineer you cannot do better than to have something that really makes a difference for other folks.
And of course, it has to “ship.” Making something that never sees the “market” (however you define that) is a sure way to undermine the motivation of an Engineer. It saps the energy almost as if it were a thousand leeches. There’s nothing quite like the rush for an Engineer who can point out what they built to other people and say “see that? I helped build that.” It’s just so powerful. Once you taste that as an Engineer you want more. What you build needs to be used to really fuel that core motivation.
In my experience teams need at least two of these to be a functional team. Less than that and the team motivation hits the basement and you’ll find yourself in a deep hole.
Team Environment
Many Engineers like to work alone, especially on tasks like design and coding. But I’ve only really known a few that were really loners. Most Engineers want a team “around” them, even if it’s virtual. Teams that are scattered remotely can definitely work just as well (or better) than teams that are co-located - if the communication is there, and if the right team environment exists. In my experience the two factors most important to this are:
- Working with smart people
- In an environment that prioritizes learning
Engineering teams are complex, living things. There’s way more to team dynamics than two points, but I’ve found that if these are missing you simply cannot make a high performance Engineering team.
Smart People
Good Engineers want to work with other smart Engineers. It’s a key attractor for getting great folks to join your team. If you have smart Engineers and they are not part of your interview process you are missing the boat! Engineers want peers who they can count on, and that they can learn from. They want folks that they can bounce ideas off. They want folks that can bring new ideas. They want folks that are not just additive to the team but multiplicative.
Learning Environment
Which brings us to perhaps the more important of the two: a genuine learning environment. Pointy heads say that all the time so why am I too? Show me a good Engineer and I’ll show you someone who constantly learns. New languages, new open source projects, new technologies. Take away learning from a good Engineer is like taking away their oxygen. It’s needed for them to live. Good Engineers will do learning whether it’s at work or not. Good Engineers seem to always be making things on the side, learning and testing and making. But if those Engineers can do it at work it’s a force magnifier. Google does “20% time” specifically to embrace this. You can do that but there’s other ways too. Let them buy books! They are so cheap and it’s surprising how some companies deny those expenses. Send folks to conferences! That checks several of the boxes on this list. Organize brown bag lunch meetings and bring in speakers. Actively encourage experiments with new technology. You’ll find that it’s like making a feast: all your Engineers will eat and everyone will be happier.
The Final One Thing
Finally, there is one thing that over time matters more than anything else. It’s not something that has immediate effect but over time it becomes either a core foundation or a corrosive agent that can disolve the entire team.
Trust.
Trust in the team. Trust in the company. Trust in the team leader/manager. Especially trust in the manager. To most Engineers the company is nebulous - it’s suits and pointy heads and bean counters and sales-folk. The team manager is the face of the company. If that person is not trusted then the value of all the stuff above may not matter. But trust is a fickle thing. In my experience Engineers are often initially skeptical but cautiously optimisitc. That optimism can be whittled away until the skepticism turns into hostility. When that happens all hope is lost.
Conversely, when Engineers trust that their management has their back then all things are possible. A key part of building that trust is ensuring that folks know that it’s OK to make mistakes. You learn from mistakes. Mistakes can guide you towards better solutions. If there’s trust that the process for handling mistakes is fair and impartial then progress happens. If that process is arbitrary, or biased, or cherry-picked, then trust erodes. Those processes are embodied in the team manager (whether it’s their process or not).
This leads me to the observation that the MOST IMPORTANT single factor of Engineering leadership is making sure that the team (line) managers are doing a good job, that you picked the right ones, that you are mentoring them and paying attention. Doing this is visible. The teams will see that their more senior leaders care about how the team managers are doing - and more trust is built. Conversely, in my experience, once a good Engineer decides that he or she does not trust their boss it’s only a matter of time before they’ll find a new boss.
Conclusion
It’s easy really, as easy as 3-2-1. I wish. Getting all this right to build a high performance Engineering team is far from easy. It takes constant effort, deep caring and a lot of work. But hard work alone cannot be successful. Just like you cannot code high performance software by just working a lot of hours - you need to understand and correctly use the right algorithms and technolgies. Similarly, building a team requires that you understand what makes teams tick. I don’t pretend to completely understand these dynamics but I have learned these lessons over the years. I hope they are of some value to you all.
