To really progress in developing software and build anything at a scale, you have to examine your blind spots and learn to deal with people (you are people so this includes you). The culture we build is as important as the technology we use; the difference between a high-performing engineering team and a low-performing one is orders of magnitude in terms of productivity and quality. Focusing on how we do things is as important as what we’re doing.
Andy Walker, engineering manager at Google, spoke about his experience with developing and coaching teams at Google at QCon London 2018. InfoQ is covering this conference with Q&As, presentations, summaries, and articles.
InfoQ interviewed Walker about building high-performing teams and establishing conditions that make engineering thrive.
InfoQ: What’s the main challenge you see in building high-performing teams?
Andy Walker: We have this whole thing in a world where everyone wants to be a hero. And in reality successful working code won’t get you far; you can only write so much code before it stops being the best use of your time. The more people involved, the more attention you need to put into HOW you do things rather than just WHAT you’re doing.
If you’re really going to progress, particularly if you’re working in a larger company with other people, then learn to deal with people. Nobody ever teaches you how to deal with other people. We just kind of expected to figure it out how as we go along. If you’re going to invest time in something then I think it was Dale Carnegie who said that in any technical career 85 percent of your success is going to be down to your ability to deal with people and only 15 percent is going to be down to the technical skills. Boy, that’s kind of scary.
I realized that I actually have to learn all the skills and I have to figure out systems which are working for me. Otherwise I’m not really going to be able to do a job with it. It’s just not enough anymore. I spend a pretty large amount of my time with Google just getting people to talk to each other.
There are some things and some behaviors which we do because it’s convenient which really aren’t good for us in the long run. Things like the fact that we would rather send somebody a text message or e-mail than actually talk to them face to face, which is not a good way of actually communicating. Language is not very effective when it comes to getting ideas across - particularly in a world where we communicate via text rather than face to face.
Then there’s how our fight-flight can be triggered. Which frequently comes down to scripting which is how behavior is habituated throughout our lives. These are the hardest behavioural loops to unpick because we’re not even aware we’re following scripts.
There are blind spots where the wiring in your head that you think works really well but just doesn’t. And once you start examining where your blind spots are you can actually come up with much better responses to other people and also understand people’s responses back to you and how to get the better of them.
InfoQ: How can we deal with this broken human machine?
Walker: Begin to learn about some blind spots. Learn models for understanding why we have those blind spots and become aware that there are parts of your brain where they have a very strong ability to influence your thinking but you’ve got no conscious control on.
One useful model is called the Triune Brain which is a model for how our consciousness might have evolved. Below the conscious part of our brain sit two animal layers which are roughly equivalent to a crocodile and a horse. The animal parts of our brains have particular motivations. For example, the lizard brain cares about things like food, safety, warmth and making little crocodiles. The horse cares about things like social acceptance and popularity. Blood flows through the animal parts of our brain to our conscious part. And the animal parts of the brain have the power of veto over unsatisfactory thoughts as well as the ability to boost ones which line up with their objectives. Therefore we wind up contextualising things in terms of our animal brains without realising it. Advertisers also know this.
For example, as a 45 year old man who is in a Ferrari dealership, it doesn’t matter how beautiful the car is if I tell the lizard that if we buy this car we have the opportunity to make many more little crocodiles. Then suddenly I have lots of approval for that chain of thought. If on the other hand I walk up to the edge of a tall building and think about jumping off, then the crocodile objects to this and cuts off the flow of blood to that part of the brain. This also happens during a fight flight reaction as the crocodile diverts blood to muscles which it considers more pertinent in a survival situation. This, in effect, stops your rational brain in its tracks. If you want healthy relationships then you need to not put people into situations where they go into fight-flight.
InfoQ: How can we establish conditions that make engineering thrive?
Walker: We need to accept that the culture we build is as important as the technology we use. Everyone needs to be able to contribute so we can take the best solutions from a wide diversity of ideas and perspectives. To do that we need to understand the big picture - to seek out the skills and knowledge we don’t come pre-equipped with. Starting with ourselves and understanding of our own fallibility as a gateway to understanding both our peers and our users. Then understanding how we can make collections of people be a multiple of the sum of their parts rather than a fraction. This is where the role of a leader becomes important as you adopt a servant leader model where you are facilitating your teams rather than telling them what to do. Your job is to help people understand why they’re doing things. Then helping everyone improve how we operate. It’s rare I tell someone how to write a piece of code.
And it’s more than just writing software at play here. It’s the environment we work in, our ability to make decisions, to delegate, to learn from our mistakes and to share and develop our ideas. The difference between a high-performing engineering team and a low-performing one is orders of magnitude in terms of productivity and quality. If we want to build anything at a scale beyond ourselves this is a journey we need to take.
Examples:
- One thing which worked really well was helping people understand how poor a tool email is. Having a rule to never respond when you were tired, grumpy or felt an emotional response to an email is tremendously powerful. We can write very abrupt prose which has the potential to be misinterpreted. Better to go talk to the person and understand what they meant than responding straight away. It’s unlikely they meant what you perceived anyway.
- Encouraging people to have more face to face interactions. The rapport you build when you’re in the same room makes it easier to emphasise with the person on the other end of the email.
- Encouraging people to publicly recognise positive behaviours. Research shows people are twice as likely to help you in future if you say thank you or appreciate the effort. The more you recognise positive behaviours the more positive behaviour you see.
- Telling people to disagree with me and each other. Everyone should know why we’re doing things and what problems we’re trying to solve. And if I can’t explain why then we’re probably doing the wrong things. Also, I can be wrong. Being willing to admit that in front of people.
- Focus on what’s important. I’ve told people that they choose how they spend their own time. If a meeting brings no value - don’t attend it. Frequently the number of meetings grows to become the dominant drain on resources. Have fewer meetings - do more useful things.
- Reduce interruptions. So you can get into a state of flow. Inspired many many years ago by the Joel Spolsky post on context switching.
- Everyone has to be able to succeed / grow. I use Dan Pink’s talk on motivation here as a simple litmus test for people - if people don’t feel a sense of autonomy, opportunity to learn/grow or purpose then they’re not going to be engaged.
- Focus on outcomes - not deliverables. Frequently we get lost in a world of feature lists and bugs which stops people looking at the big picture. You want to create an environment where anyone in the team can have the epiphany that enables you to build something remarkable. If success looks like "ship feature x" then you lose sight of the problem you’re trying to solve.
- Focus on outcomes - not the one true way. There are many ways to skin a cat. We get caught up in holy wars on frameworks, languages, design patterns… You name it. But the energy we spend arguing about that detracts from the actual real world problems we’re trying to solve. At the end of the day - software engineering should be useful and if it’s useful then people will find it easy to have a sense of purpose.
Additional information of Andy Walker's QCon talk "It's People, Stupid (People Are Stupid?)" can be found on the conference website.
