People Hacks for Technical Leads

Lately I’ve been thinking about, doing a lot of research on and experimenting with management strategy. As a technologist I’m inclined to look for a structured approach — a process with which to automate teams. But as a student of anthropology I tend to reject frameworks so structured they become blind to context and nuance. I’m hopelessly attracted to large, complex systems. Generally the thorniest of those involve people rather than machines.

Still, I also believe that people themselves are not terribly complex. I’m very attracted to the Westworldian idea that human beings as individual pieces are actually very simple. The complexity comes from reactions and sub-reactions to interacting with each other.

Management, for that reason, has always been something I find fascinating. How does one leverage that simplicity to navigate its complexity? I wanted a way to hack people the same way I could hack machines.

Becoming Multichannel

About fifteen years ago I took a job that changed my life: I started teaching.

It changed my life because it turns out good teachers have to develop all these fundamental communication and organizational skills that are applicable in virtually every other profession. Or, in other words, what you cannot survive without as a teacher you can use to dominate in the business world.

One of the most interesting lessons from that period was learning to anticipate and leverage learning styles. The concept of learning styles is simple: some people are visual thinkers, some people are logical (math) thinkers, some people are kinetic thinkers. If you present information in a way that aligns with that person’s learning style they will learn it much faster and easier than if you presented it in a way that is inconsistent with their style.

The challenge for a teacher is that you are not always working one on one. You have a classroom of students and a mix of learning styles. So good teachers learn how to present the same information in multiple styles at once. A simple example of this might be talking through a concept, while drawing a representation of it on the whiteboard, then following that up with an exercise where students go through the process described to them.

The fun thing about learning styles is that it’s about optimization. If you are a visual thinker, it’s not that you cannot understand something explained to you verbally. It’s just easier when you can see it. What this means is that by talking and drawing you are creating two channels of information — visual and verbal. The brain will process both regardless of the individual’s learning style: receiving an optimized version and another version that then reinforces the information by presenting it in an alternative (suboptimal) way.

In other words, even though the number of kinetic thinkers is statistically very low that follow up exercise where you leverage movement and interaction to demonstrate a concept is not a waste of time for all the other students. Those with kinetic styles might have an ah-ha! moment, but everyone else develops a stronger understanding.

Xerox PARC had a term for this concept: they called it being multichannel. In the late 80ties they began experimenting with how to use this concept to make meetings more effective (the resulting project was called Colab in a clever play on words). Meetings are awful because they tend to force all productivity on to one channel (usually verbal). One person speaks, everyone else listens. Even if a meeting is interactive or discussion based it’s still usually only one channel. If someone brings along a Powerpoint, well now you have two channels.

Programmers like to talk a lot about how much they hate meetings, but pair programming is a meeting. Whiteboarding is a meeting. Lots of things that provide value and are enjoyable in the software development process are technically meetings … just with a slightly different format. Both pair programming and whiteboarding are multichannel in nature. When you whiteboard out a solution you are usually talking through your assumptions while also drawing or writing out the corresponding solution. The visual part of the exercise generally communicates a different level of detail that is complimentary to the verbal part. When you pair program you’re watching the implementation develop live. This frees up the verbal channel to discuss broader architectural issues.

We don’t talk about these things as meetings because they don’t feel like meetings. They feel like productive work. Meetings in engineering environments suffer because they force people from activities that are usually multichannel in nature to activities that are monochannel.

Even when I program alone I’m usually feeding complimentary inputs into multiple channels. For example, like many programmers I like to listen to music while I program. It helps me establish a rhythm and improves my focus. Also like many other programmers I have toys and puzzles on my desk, when I’m stuck on a program I’ll pick them up and play with them or I might go for a walk. Both options activate the kinetic channel.

And it’s not just programmers: a 2006 study of medical students found that most of them did not test with one clear learning style but rather a mixed mode state in which they performed best receiving information on multiple channels.

So how do you convert monochannel structures (like meetings) into multichannel ones? First understand broadly what different types of learning styles there are:

• Visual : pictures, images, and displays.
• Aural : sound and music.
• Verbal : can be listening, but don’t underestimate the power of speaking. Having to think through how to explain something can dramatic improve your understanding of it.
• Physical (kinesthetic): using your body, hands and sense of touch.
• Logical (mathematical): logic, formulas, systems/processes.
• Social (interpersonal): group work.

This is not a strict framework. Different academic philosophies will break things down differently, but it’s a good place to start in order to get some ideas.

The next thing to do is define what you want to be communicated in your meeting. You cannot design how to integrate multiple channels if you do not know what message you are trying to reinforce with each channel.

The last thing to remember is that channels should compliment each other but they do not have to be carbon copies of one another. You should not be putting your message into song form in order to activate the aural channel (that’s a little insane), instead you should pick background music that fits the mood and energy level you want to encourage. You need not put an exact copy of what you’re saying on PowerPoint slides to activate the visual channel, far better to use imagery that fills in nuance the words cannot capture.

When this works really well the various channels are actually broadcasting different levels of information. Some are very high level, some are very low level and detailed. Let’s take a look at the pair programming example again:

• Visual: Code displayed on a screen in front of both programmers. High detail, communicates exact implementation
• Aural: N/A
• Verbal: Programmers discussing architecture, coding style, assumptions and/or potential problems. Lower level of detail, communicates broader more general strategy that informs implementation.
• Kinetic: N/A. Although some people naturally use hand signals to supplement their verbal communication when explaining something.
• Logical: N/A but could be present depending on the algorithms involved.
• Social: Programmers are working together. Lowest level of detail, communicates trust, respect, shifts in tone and mood reinforce verbal instructions about style and approach.

Learn to Embed

If going multichannel can be thought of as making meetings feel more like productive work, this next section of people hacking involves turning productive work into meetings.

Wait, wait, don’t run away! Trust me.

Just as I learned a lot about leverage learning styles to improve communication while I was teaching. I’ve learned a lot about management while trying to fix legacy technology. USDS pushes people to “go where the work is” or in other words embed directly with the teams who are in charge of the system you’re trying to fix.

People push back on this for a variety of reasons. Embedding is a difficult thing. You are frequently treated either covertly or overtly like a spy, a saboteur, or an idiot. People are dismissive of your opinion and also worried that you will get them fired. It’s far more comfortable to sit in your own office, surrounded by people from your own organization and send people emails. However, that is also a pretty ineffective way to run a team.

USDS uses a variety of social engineering techniques to nudge people out the door — for example, our office space is hilariously small for a 200 person org.

The benefits of actually just sitting in the same space as teams cannot be overstated. A lot of the things I would normally schedule a meeting to be briefed on I learn on a much deeper level through normal office chatter.

Though I’m not fond of the implicit value judgements in Paul Graham’s Maker’s Schedule, Manager’s Schedule he makes a good point: not all work is structured the same. There are some types of work that one can start and stop easily. Meanwhile most programming work has pronounced ramp up and cold down periods. One can’t simply sit down and write good code for an hour, then stop and do something else. You need time to really dig in and focus on the task.

Minimizing the number of meetings does optimize the effectiveness of programmers (or anyone with a similar ramp-up/cool-down work structure) and the best way to eliminate a huge number of meetings is by absorbing as much information passively from an environment as possible.

One of the changes I made to the first team I led at USDS was getting our engineers to program without headphones. It’s fine for normal programmers to wear headphones as they work, but our people aren’t being deployed to write code, they’re being deployed to advise, train, and coordinate other teams of engineers. When you’re wearing headphones you’re not present in your environment. You miss so much about who’s working on what, what the challenges are, what the internal politics are, who works well with whom. All of this is valuable information.

And in circumstances where you’re leading a team that might not be 100% comfortable with you (for whatever reason) wearing headphones says to them don’t bother me . If your team is insecure it will heighten their anxiety around you.

There’s a lot you can learn about how a team works, how a project is going and who works well with whom just by being strategic with small interactions. Traditional one-on-ones are great but there are a wide variety of ways of having mini-meetings that blend seamlessly with the work patterns of the day so that your engineers do not think they are having meetings but you get the same benefit.

Here are some things I’ve done in the past:

• Walking the floor. Sometimes I’ll leave my office and just walk around the building (or among the cubicles) like I’m heading to the bathroom or something similar. I’ll stick my head into the cubes/offices of key people just to say hello (seriously, just a wave and hello). A lot of times something as simple as saying hello to someone as you pass them is enough to get them to stop you with a question, a complaint or to report a problem.
• Travel with your team. Short trips, long trips, walking to and from meetings. If you have the opportunity to coordinate be it a car pool or a conference don’t pass it up. People tend to be more expressive when they’re processing an experience so travel to and from is not wasted space, it’s prime time to share information and bond.
• Design natural intersections. The traditional water cooler is a perfect example of a intersection, a place where people just naturally (and spontaneously) gather throughout the day. Part of managing a team isn’t just facilitating how they communicate with you, it’s also about facilitating how they communicate with each other. Natural intersections can be kitchenettes, a bit of dead space by the bathrooms, common area couches, or staircases. Observe the natural traffic patterns of your office environment and figure out how you can encourage people to stop and briefly say hi to one another.

Tame the group chat

Confession: I hate Slack. I hate Hipchat. When the UN made me use Skype I hated that too. I know it’s blasphemy: but I hate group chats.

At the UN I was on a fully remote team. I was also the only person in the United States, which meant I woke up about the same time the other engineers were logging off for the day. My mornings consisted of wading through hours and hours of chat logs, side conversations about one guy’s kitesurfing hobby, or the latest Game of Thrones episode mixed seamlessly with vital technical discussions. And yes we had work and non-work channels; it never made a difference. We broke chats up by teams only to invite other team members for one-off conversations and then never remove them. So not only were channels off topic, but we had four or five channels with exactly the same people in them. Finding old information became a nightmare.

Group chats and all the features that frequently come with them can be productivity boosters. They can facilitate remote work, automation, inter-team collaboration, knowledge sharing, etc.

But they can also run completely wild and have the exact opposite effect.

Mostly by accident, I’ve developed some techniques for keeping group chats from poisoning team life. The first is putting off having one for as long as humanly possible. If you’re forming a new team, take a couple of weeks to observe people’s communication styles before launching a group chat. Some teams are very tightly bonded — they’re not just colleagues, they’re friends — those groups are far more likely to want to have distracting side conversations on the group chat.

For teams that are pretty social, try establishing a non-work group chat first. This is what ended up happening at USDS. Policy restrictions meant we’ve only just gotten a group chat for work, but we’ve had an active social chat for a years. As a result the work chat doesn’t really drift off topic that often. When people want social contact, they go to where they are likely to get the biggest and most engaged audience for that, which isn’t our work chat, it’s the old social chat.

Sometimes though the difference maker can be the way the tool is designed. Earlier this year I was introduced to Zulip and — Oh! I have never known such joy! Zulip is threaded, which forces people to sort things into their proper channels rather than just letting conversations drift. So it’s the group chat that works best for me.

Develop a back brief strategy

More people does not make a situation better. A sure sign a meeting will go off the rails is when people are being invited to it as an FYI. Some will say that those people should be invited as “optional” but I like to be stricter than that. There are two types of people who should be invited to meetings:

• People who need to make the decisions
• People who have direct knowledge or expertise on the thing being decided.

Otherwise, it’s hard to invite someone to a meeting and ask them not to participate in the discussion. What optional invitations do is increase the number of “Well actually…” comments a discussion is likely to have before the decision is made. People who need not be in the meeting in the first place are trying to find some sort of meaningful contribution to make to it, spinning the conversation off-topic or relitigating old dramas. Assume two digressions for every non-essential invite and give yourself a budget. How many digressions do you think you can handle before the situation becomes hopelessly confused? Decisions that are straight forward can survive a lot of nitpicking. Decisions that are riskier or more nuanced cannot.

If the decision is being made on a senior management level and the expertise is on the staff engineer level, this means the middle managers in between do not get invited. Meetings become more productive and more likely to result in good technical decisions but a back brief strategy becomes essential. The people in the middle might not need to contribute to the conversation but they certainly need to be made aware of the output of it.

Back briefing is filling in other parties about decisions after the fact. It can take many forms: emails, text messages, formal memos, quick conversations.

Ultimately, the best thing you can bring to a team is trust . Your back briefing strategy is a little bit about you keeping other people informed but it’s much more about you demonstrating that you trust your team to make decisions on their own and keep you informed.

Come Join My Team!

Hey you got to the end of this post! If this stuff is totally in your wheelhouse then you should nominate yourself for a Technical Response Unit Fellowship . For the last year I’ve been working with the Department of Commerce to design a program for technical people who want to get real experience building and managing high functioning teams. It’s a three month program that will embed you with large complex technical projects in even larger and more complex organizations. The fellowship includes a stipend, housing and travel, so if you’re interested in figuring out whether you could be a good manager you have no reason not to apply.