The Engineering Manager

Not the best mix

You get all sorts of personalities working in technology. Let’s start with a story.

There are two meeting rooms, side by side. The camera pans over to the first of them, on the left. The wall of the meeting room is glass, and through the pane there are three suited individuals in their mid-forties, having what looks like a very heated argument.

We are now inside the room.

“I just refuse to believe that. I know I’m right. We should go with the offer, and that’s that.”

“Nonsense. I’ve been in this industry longer and I’ve seen this go wrong. We shouldn’t proceed. You’re mad for thinking we should.”

The third man chimes in, whilst looking quite red in the face. “We should do the deal.”

“Why? You’re clearly not thinking straight.”

“We just should. Don’t question me on this!”

We are outside the room again, looking in through the window. A fist bangs the table top. Hands go in the air in anger.

We’re now outside the second meeting room, looking in through the glass. Two people are sitting in there, dressed much more casually. One person is standing at a whiteboard, drawing a series of boxes connected with arrows.

“So, we know what we need to build, but first we need to work out what framework we’re going to use. Any thoughts, guys?”

“Dunno. Could try some out I guess?”

“Yeah.”

“Probably.”

“Not sure why we’re even bothering with this project.”

The person at the whiteboard is now staring out the window, frustrated. The conversation around the table continues.

“I know right? What’s the point? Surely there’s better uses of our time.”

“Yeah. Remember that project we did last year together? What a waste of CPU cycles. I doubt anyone even uses it.”

“Hah, exactly. These people know nothing about building software, do they?”

We are now back outside both rooms. Two meetings are going nowhere. Fade to black.

Working with different people

Technology companies, like most companies, have a wide array of different people and personalities working there. International offices are staffed with people from all genders and cultures: salespeople, engineers, data scientists, executives, researchers – you name it – all of them come together for this wonderful thing called work. Sometimes teams and meetings can be an eclectic mix of people who get along swimmingly and collaborate well. On other occasions they can be frustrating, one-sided and fruitless.

You’ll need to collaborate, debate and make decisions with all sorts of people throughout your career. Yet, despite our differences, the value you gain from interacting with your colleagues need not be purely up to chance. You can consciously adapt your style to improve your individual conversations and even intentionally ameliorate differences in a whole group.

I’d say that there are two levels that you can operate at in order to work well with your colleagues:

1. Understanding the personality types of others. This allows you to have better quality interactions where you can engage on the right wavelength with people. You can appeal to a fast-paced directive mind with one approach, but you can equally pitch something in a differing style to a deeply analytical person so that it lands right with them.
2. Playing a personality role in order to get the best out of a situation. Knowing the balance of a team, group, or selection of people in a meeting, you can put aside your natural personality (which may be, for example, analytical) and play a different role to improve discussion and decision (e.g. a brash and directive viewpoint). Your natural way of being describes you, yet it doesn’t define how you should always be.

Understanding personality types

Techniques

There are a variety of methods for categorizing personalities. You may be familiar with the Myers-Briggs test, which after answering a number of questions, assigns you a strange-sounding acronym such as ISFP, ISFJ and INTJ; the latter being mine, for the curious reader.

Additionally, you may have been subject to some training at your company that used the Insights Discovery toolkit, which is based on the psychological theory of Carl Jung. Again, after answering some questions, a written report is generated that assigns you a color on personality wheel that represents the predominant characteristics that you exhibit. Typically this exercise is followed by training on how to work with people’s personality traits.

Here’s what the Insights Discovery wheel looks like. Where do you think you naturally reside?

We did the Insights Discovery training at work and although I approached it with skepticism, the outcome was very positive. I was able to explore traits that make me who I am, but more importantly, to become much more sensitive to others that have divergent personalities. If you’re offered any kind of related training then approach it with an open mind: it stimulated some really interesting discussion between us. Just don’t assume red means angry. That’s not true.

The basics

But, I digress. Less chat about psychological models. Let’s keep it simple. Some people are loud, some are quiet, some are rambunctious, others are shy, some are deeply cerebral with their decisions, and some trust their gut instinct instantly.

Regardless of how you categorize your own personality and those that you work with, whether through a model like the above or just your own gut feeling, one thing is fairly clear: when working closely with others, you need to be tuned into everyone’s differences in order to have high quality interactions. Not everyone you work with will be the same as you, and it’s your responsibility to respect that and make others feel considered.

Sometimes you’ll clash with people. You have to understand that the way that you view the world and reason about it could be the opposite of how they do, but, importantly, both of your viewpoints and logical processes are just as valid as each other. The first step in being a great collaborator is using your emotional intelligence to be aware of these differences, and then focus on communicating in a way that resonates well with others. Ask questions. Consider. Probe if you sense that you’re causing discomfort. Speak out if you’re uncomfortable yourself.

Here are some examples of how people may be different to you.

• Quiet doesn’t mean indecisive: The quiet ones in meetings may just be deeply analytical about decisions. They prefer to go do their research and come to a reasoned conclusion later. It doesn’t mean they are indecisive. Respect that and let them do so. They’ll probably come back with a more balanced and well-researched opinion than yours! How about we go and do some research and get back together tomorrow to discuss what we’ve found?
• Loud doesn’t mean right: A very confident and loud personality may come across as the most persuasive, but remember that there are other opinions in the room. Allow space for others to speak by asking questions directly to them for the benefit of the room. A good point. I can tell that Bob’s been thinking a lot while you were speaking. What’s your current thoughts, Bob?
• Zooming out and zooming in: Depending on their role, some people will be detail-oriented while others prefer to take (excuse the cliché) the helicopter view. Both levels of abstraction are necessary, but allow each personality to express their feelings. Tie the opinions together into a wider narrative that considers the views of all. I understand that we need to ship this new product yesterday, but there are a lot of considerations that the group has raised. How can we drill into all of the detail and then come back to make a decision at the end of the week?
• Consensus: Some personalities are deeply uncomfortable at not getting consensus on decisions, whereas others couldn’t care less. Ask questions about how the group can arrive on the same page, and try to get those creating discord to understand that they need to persuade others, too. I totally agree with your position, but we all need to get there together. How can we do this without causing a rift with the other teams? What could potentially go wrong?

I’m sure there are many more examples, but group dynamics are tough. If you can develop a sensitivity to the personalities of others and understand what motivates them, you can begin to develop a feel for how to pitch controversial ideas or make difficult decisions while making them feel considered and respected.

Playing a role in meetings

As our introductory story showed, particular mixtures of people don’t work so well, and as a result some meetings can lack the balance required to move the discussion in the direction of a decision or action. So we’ll move on to a skill that is more advanced.

Here’s the question: regardless of your own personality type, are you able to play differing personality roles for the benefit of a discussion or debate? This requires a great deal of self-awareness about your default mode of operation (i.e. are you a snap decision maker, an analytical thinker, predominantly a listener or an orator?) and the ability to notice when a discussion lacks balance and to slot a counterweight into the missing gaps. It also requires a great deal of confidence to represent or debate viewpoints that you are naturally less comfortable with.

It can be useful to think what the ideal outcome of a particular meeting is. Are you trying to make a decision on something? Is it a chance to critique an idea? Are you trying to come up with new ideas? The purpose of the meeting acts as the North Star that you are all aiming towards. With that in mind, what is the balance of people in the room like and how likely are they to work together to get there effectively?

There are a number of techniques you can use to do this:

• Adopt an opposite stance for balance: If you spot that the conversation is getting stuck because people are being too analytical and not getting to a decision, or that the room is at risk of argument or a decision being made that is too rash, can you adopt an opposite position in order to pull the room towards the desired outcome? You can anchor a frantic room or invigorate a lethargic one. Can we run through what a different approach would look like to this? What if we did this in the backend instead? What would happen if we used our own infrastructure for this, rather than going straight into the cloud?
• Adopt a controversial stance to interrupt thinking patterns: If you feel that the debate is one-sided or at risk of not exploring all avenues before reaching a decision, can you be controversial for the sake of inspiring new discussion? What if we didn’t do this at all? Is this actually a bit of a silly idea? Is this really worth our time and money?
• Pretend you know less than you do to probe deeper: This technique is useful to get people to explain their thinking further for the purpose of critique and, often more importantly, if you spot that others in the room are not following but may be too embarrassed to ask, you can confidently feign lack of knowledge to bring others up to speed. I don’t quite follow that last step; can you elaborate? Why doesn’t that framework support that feature? Why wouldn’t our current system cope under that load? What do you mean by index
• Pretend you know more than you do in order to be proved wrong: If you feel that a given solution is worryingly complex, can you falsely posit that it’s actually much easier in order to force more explanation? Surely it’s just doing this, then that, right? Isn’t there open source software that just does this? Why isn’t this as easy as just adding this field to the database?

I’m sure that there are other techniques that can be equally useful. To use another cliché (that’s two now, sorry), careful playing of different roles can turn you from a musician in the orchestra to the conductor, steering collaboration in the direction of the greater good. It’s also fun.

In summary

We’re all different, and sometimes that makes for wonderful collaboration, but it also can result in conflict. As well as developing the emotional sensitivity to be able to work well with others by appealing to their own needs, you can work towards playing a role other than your natural one in order make collaboration faster, better and more interesting.

Hello?

Max has been working at his current company for about 9 months now. On the whole, he’s been having a really good time there: he’s building an interesting piece of infrastructure that will be a big deal for the upcoming product roadmap, he gets on swimmingly with his team, and he’s learning a lot. He’s even been convinced to change his IDE.

However, there are a bunch of things that have been bugging him recently. Firstly, he finds it really hard to find information; notably the documentation for the broad architecture of the platform doesn’t seem to exist, nor do any notes on best practice for the area he works on. How does he know if he’s building things the right way? Secondly, he’s been taking part in job interviews and he feels that the process is too drawn out compared to the speed at which he feels you need to secure good candidates before they accept offers elsewhere. Lastly, he has a feeling that the communication between the commercial side of the business and the engineering department could be a lot better. In fact, there have been a number of miscommunications recently which have made projects appear like they were late when they weren’t.

The problem that Max has is that he doesn’t really know where to raise these issues. He’s mentioned them a number of times to his line manager, but the department is pretty big; for these concerns to get up to the CTO requires four steps in the org chart. Is his message being relayed all of the way to the top where action can happen? He would go to the CTO directly, as he would in his previous job at a smaller company, but he doesn’t know her particularly well, and he can see how busy she seems to be all of the time. He’s nervous of being too pushy.

This feeling of inability to affect change is not something that is unique to Max. Most engineers in his department are smart folks, and they can see that a multitude of things could be a lot better, but they are not sure how they can make them happen. What can they do?

Management bugs

The idea

Last year at Brandwatch we rolled out a “management bugs” initiative, which was a slight adaptation of the concept written about in Radical Candor, a book that comes highly recommended. Kim Scott tells the story of a similar scheme that was implemented at eBay.

The idea was that as the company was growing via rapid expansion, the leadership were becoming increasingly distant from the staff on the ground. The CEO wanted to rectify this problem, and therefore installed a suggestion box in a busy area of the office. Anyone could drop a note into the box and at the all-hands meeting the box would be emptied. All questions and suggestions would be read out and answered in front of the whole company. This was a neat way of breaking down the typical barrier to leadership: all input is treated equally, no matter who it is from.

Our version

We really liked the suggestion box idea, however, there were some flaws:

• Box location: We’ve grown to the point that we have offices in a number of countries, so a physical suggestion box in HQ is only going to be seen and used by those that work in that location. Having a box in each office just makes the whole thing a bit of a pain to manage as well.
• Presence at at the meeting: Those that happen to be on vacation, ill, or visiting clients miss out on the Q&A.
• Tracking issues: Not all of the issues raised are going to be solved instantly. Some may require a lot of discussion, or may spin off into a working group before a solution is found. How can staff know the ongoing status of everything that’s been raised?

We had a think about how we could do this. Was there already a system that allows people to raise issues, to specific people if required, non-confrontationally? Does this system enable these issues to contain discussion and be tracked through different workflow stages? Well, actually, it turns out we were already using one: JIRA.

Set up

We thought that we’d give our management bugs initiative a go for two weeks to see whether it gained any traction. Our pitch to the department was this: it’s fairly commonplace to have bug-fixing weeks in technology companies, where everyone downs their tools and attacks outstanding bugs that haven’t been prioritized. It tends to be fun as everyone can stop their regular work for a while and make a significant impact by their focussed effort elsewhere. Given it works for software bugs, why shouldn’t we try something like this for process and management issues?

We wanted to make sure that if anyone felt that there was something bugging them about the way that the department was being run, then they could create a ticket in the backlog, and the senior management would follow the following process:

1. The ticket would be picked up by one of us, which meant acknowledging it and dragging it into the “ready” column of a public kanban board.
2. Comments would then be solicited from anyone who was interested and actions would be decided.
3. When the ticket was eventually completed, a summary would be written of the issue and the actions that were taken and emailed out to the whole department.
4. The ticket would be moved to “done” and an archive of the summary email would also be created publicly in our company Google Drive.

We created a new JIRA project called “Management Bugs” and gave administrator access to the senior managers in our department. In our case this was the CTO and VPs. The premise is that anyone would be able to raise their bugs into the backlog where they would be seen, tracked, and worked on, out in the open for all to see. We also gave people the option to raise a bug anonymously if they wished by having one of the senior management submit it on their behalf.

After setting this up and announcing that the initiative existed, how did we do?

Reflections

We were initially concerned that nobody would engage so publicly, and after the first day there was only one fairly uncontroversial ticket raised. However, given time, and after others saw that the tone of discussion was friendly and constructive, many others took part. We’ve now been running the initiative for 6 months and we’ve had 37 management bugs raised from people in a multitude of roles in the department, and we’ve solved 29 of them. The subject of the bugs has been incredibly varied, and we’ve been impressed with how open and honest everyone has been in defining, discussing and solving issues.

Here are some example management bugs that were raised and their resolutions:

• The surprising difficulty of booking Airbnb instead of hotel rooms through the travel system, even though they’re usually much cheaper and more interesting to stay in (plus you can cook your own food!). It’s now really easy to do so. Our Finance team helped us out a lot here.
• Clarification on how perceived performance links to salary increases at the end of the year. The algorithm for how salary increases are calculated according to performance and budget is now documented and available for all to see.
• Interesting discussion about the perceived speed that we get work done and how that has changed over time as we’ve grown our headcount. The perception that more engineers and a larger company means faster work isn’t always true.
• Concerns about teams switching to new projects too quickly after their completed project has shipped, thus not getting the chance to iterate, bug fix and address technical debt. As well as being mindful of the issue, we now try to give each new feature defined time to soak in production before context-switching on to new endeavors.
• Observations on the current quality of communication between the engineering department and commercial teams. We now have weekly newsletters and our CTO has regular open Q&A sessions with those in the US since our HQ is in Brighton, UK.
• Whether our existing take-home technical task is still useful in hiring new engineers, and if so, whether we can make them better for candidates to complete and easier for us to review. Broadly speaking it’s OK, but could do with some improvements, and we also don’t need to give it to everyone if they have enough demonstrable proof of their programming skill (e.g. an active Github account).
• New roles in teams were being advertised externally on the company website, but people who already work for us sometimes didn’t realize that there exists an opportunity to apply for them. We now make sure we advertise internally too.
• Ensuring it’s clear on our careers page that part-time applicants are welcome for most positions.

In summary

We’ve been really surprised by how well the management bugs initiative has been received here, and I would definitely recommend giving it a try. Feedback from our staff has been positive, and we’ve been appreciative at how open and honest everyone has been in discussions. This is the culture we’re aiming for, after all.

If you do decide to give this a go, do make sure that there is enough engagement from those who are running the initiative to keep it active. Seeing bugs stagnate may make people think that management doesn’t care, so do set aside time every week to work on it.

What bugs do you reckon your staff would raise?