Chapter 3
Interfacing with Humans

You’re standing in the kitchen thinking about what to make this evening. You’re flicking through a recipe book full of bright pictures and sequential methods. Recipes are sort of like algorithms, aren’t they? You set up the environment, follow the steps, and out comes the result. They appeal to our minds as engineers: creativity, precision, methodology, and tastiness. As you think about algorithms, your mind drifts to when you were first learning to program. It wasn’t a passion that you already held, nor was it one that unfolded in an instant. It unfurled slowly with time. At first, you hated it. It was frustrating. You didn’t understand any of the concepts or familiar building blocks that underpin most programming languages: variables, methods, arguments, and loops. The compiler spat out incomprehensible error after incomprehensible error as you tinkered.

But gradually, and with effort, you learned how to interact with the computer. You remember the first program that you wrote on your own. It was part of a homework exercise. It asked the user to enter a number n and then it would print out the sum of 1 to n. You felt a wave of satisfaction when it worked, instantly outputting the result to the console.

You remember in the following years how you spent countless hours tinkering with programming projects, both inside and outside of school and university. You downloaded open source software and marveled at those humongous codebases written by other people. You poked around in them to see how they worked. Your final-year project on your degree was a compiler for a small, fun programming language that you invented. And then, the impossible seemed to happen: you got a job that allowed you to get paid for your hobby.

Yet, here you are, having made a drastic decision to stop being a humble programmer that writes code. You are now a manager. You feel like you did sitting in front of that blank text editor for the first time, wondering how on earth you were going to write a program. You didn’t know how to work with the computer, how to speak to the right language, how to issue instructions, and then make it execute and get the right result. What exactly is the language for running a team? How do you express what you need from them, and how do you get the output that you desire?

Starting a managerial role involves learning a new set of tools. You may have ended up working in technology by tinkering with the tools required to program a computer. These tools may have been programming languages, software for creating graphics, or commands for configuring servers and data centers. As your expertise in these tools increased, you became more effective, knowledgeable, and able to tackle larger and more complex problems. You were also able to teach others how to use these tools so that they were also able to become more proficient themselves. You were even able to get paid for doing so. As a manager, you may still incorporate your existing expertise into your new role, but now there’s a new set of tools to learn. These are the tools that allow you to be an expert manager, which involves doing your work effectively through others.

Let’s recall the equation that we outlined in Chapter 2, ​Manage Yourself First​. Your output as a manager is:

This chapter will introduce the tools that you need to supercharge your output. You’ll learn how to communicate candidly and concisely with your team and your manager and how to delegate work to your staff.

When first learning how to program computers, you’re faced with a number of unfamiliar tools. It takes a significant investment of time to learn enough to write a program that prints out “Hello, world!” to the console. For the experienced programmer, learning a new language is easier because they already understand the underlying concepts, and they can map what they have learned in one language to another and understand the differences and similarities.

When a programmer gets their first job, they will often have had experience in using the tools that they need to be productive. For example, a junior will have almost certainly done some programming before, either as a formal part of their education or through their own self-directed learning. The same is true of a programmer moving from one company to another. They will likely be working in an entirely different domain, but they’ll bring with them their expertise in their tools, which will allow them to hit the ground running and not have to learn everything all over again.

Managers in the technology industry have a tooling crisis. Typically, teams end up being run by engineers being promoted into management positions, and depending on the organization, they may get excellent mentorship and training or none at all. This results in a wild disparity in the skills of managers in our industry. Some are taught the tools that they need to become experts at their job, whereas many are metaphorically sat in front of the text editor with no idea what to type.

If we were to pick an arbitrary piece of software that we wanted to understand, we may ask:

• What is the language that the program is written in? How is it structured, and what syntax does the programmer use to express what they mean?

• What is the standard API for that language, and how should it be used to make the program do common tasks in a predictable and efficient way?

• How does the program run when it is written? Does it execute on a virtual machine, or is it compiled directly to run on the local operating system?

By using some artistic license, we could reason that you need some related concepts to be able to work with a team for the first time:

• What is the language and communication style you should use so you can discuss, debate, and deliver feedback both openly and candidly?

• What is delegation and how should you use it like an API for getting work done through others? How can you use delegation to get tasks done efficiently and to a high standard?

• How well does your team run and how is it doing in the context of the department and organization? We look at the tools for how to discover this in partnership with your own manager.

That’s exactly what this chapter will be about. Firstly, we’re going to learn all about communicating effectively with people. Then we’re going to learn about delegation, which is how you get your work done as a manager. Then we’re going to focus on the often-neglected relationship with your own manager, teaching you how you can get the best out of it to ensure that both you and your team are doing a good job in the context of the wider organization.