The Engineering Manager

Building people and technology

When your company is at an early stage, hard graft, rather than complexity, is the focus. Communication doesn’t require careful thought or organization because you’re either sitting next to each other or there are few enough of you to make decisions over video calls, emails or IMs. If there’s friction or disagreement amongst key people, then often the fight to keep afloat takes precedence anyway, dampening the urge to keep negotiating. Instead, you just do.

For the lucky few, dreams of success at those early stages can become a reality. That reality can be one playing out in fast-forward. Your company could attract funding and grow aggressively, expanding into many geographical locations and in turn create multiple products that each generate their own revenue streams. That’s all brilliant. But success and scale also cause drag: communication gets harder, collaboration becomes trickier and decisions require much more lobbying and consensus. Trying to continually adapt how the department works as it grows and matures is a continual iterative process that you’ll get wrong more than you get right.

From a technical viewpoint, as a product and company grows, so does the complexity of adding new features. In the early days where only a handful of developers were required to build the whole thing, decisions and progress were fast. But now building innovative new features often requires a multi-team effort: provisioning of new hardware or infrastructure, plenty of data science to prove concepts, new APIs and services built with future reuse in mind, and sweeping changes to the UI.

It becomes harder for each team to cleanly and completely own an area of the application. Dependencies begin to occur between different areas of the department and communication becomes more complex. You could argue that the hardest part of having a successful technology company is solving the technical challenges, but when it comes to doing this at scale it’s more often than not a people problem. How can everyone remain productive as the department steadily grows? Are there set processes and techniques that we can use to make this all predictable and frictionless?

Process isn’t always the answer

Being engineers at heart, we often try to solve all of our problems in the same way that we try to solve the problems that we have with technology. Surely, if we can streamline algorithms and build processes we should be able to apply the same logic to problems in the domain of communication and productivity, right?

Well, sometimes.

If we’re not careful then we can end up layering more and more complexity on top of what are essentially people problems and then inadvertently create even more people problems as a result. It’s a vicious circle.

It is sometimes necessary to take difficulties in the department and assess them as people problems rather than process problems to see if there are far simpler ways that they can be fixed. Let’s have a look at an example that we worked through in many iterations at Brandwatch. We still don’t have a right answer, but I feel that it highlights how we incorrectly identified a people problem as something that could be solved with even more process when the solution was in fact far simpler.

Pull requests

For many years I’ve been involved in reviewing code. This example covers how we worked through some issues with scaling backend code review as the department grew.

If you’re not familiar with them, pull requests are a method for submitting modifications to a codebase via Github so that others can review them before they are merged in. We’ve been using them for many years, and they’re great. However, when we first adopted them it took a number of adaptations to the way we used them before frustrations went away.

Let’s start with some history.

A very long time ago, in a pre-Github era, there weren’t many developers in the company. Typically people would ask for a quick in-person code review before pushing their work into the testing environment. Although an imperfect process, it encouraged people to seek review themselves before their code went any further. However, as we grew, and as the pull request functionality in Github became a lot better, we migrated to that system because it made it much easier to organize detailed reviews, especially when the number of developers in disparate geographic locations began to increase.

However, the pull request process highlighted a multitude of ambiguities in how we got things done:

• How many people were required to review a given change before it could be merged in?
• How senior did the reviewer need to be so that the review could be trusted?
• Who was allowed to click the “merge” button once the reviews were complete?
• How were conflicts resolved if the reviewers didn’t agree or if the submitter disagreed with the reviewers?

Mergers

In order to answer these questions, we added another layer of process: a group of senior and trusted developers called mergers, who had the authority to decide the fate of a pull request and ultimately were the ones that were allowed to click the “merge” button. Our new mergers enjoyed the initial responsibility and spent much more time carefully reviewing code. Two reviews were required: one from the merger and another from any other developer.

However, with time this additional layer of process created more people problems:

• Our mergers became a single point of failure and if any of them got busy or sick then the throughput of teams suffered.
• This also increased the amount of pressure that our most senior developers had on their job: they were now slowing up the rest of the department if they were busy with their own work!
• Those that were not mergers felt like they had diminished responsibility. Not only did this make them feel like they were not trusted enough, it also dramatically reduced the amount of time that they spent reviewing code because they felt that a merger would need to do it anyway, so why bother?

SLAs

Of course, to solve this problem, more process was added! We implemented an SLA for pull request review which mergers needed to stick to.

This made things worse:

• More pressure was being put on the mergers to review quicker.
• The SLA was being observed regardless of the size, complexity or impact of the pull request. Some bug fixes take 30 seconds to review, and some architectural pieces can take multiple days.
• Our delivery managers would chase pull requests that weren’t meeting SLAs, causing even more stress for our mergers. They started to really hate the responsibility.

Easing the grip

After a while, it was clear that our issues with code review were people problems. I reached a point where I felt I was spending too much time in the week addressing problems that the code review system had caused: stalemates due to disagreement, pressure from the business about things being “too slow”, angry staff who felt powerless to get their changes through, endless cyclic arguments from code style to personality clashes.

It was time for change. Fundamentally, regardless of process, we wanted to aim for the following:

1. Everyone should feel empowered to make changes to the codebase.
2. It should be in the best interest of the submitter to get their changes reviewed and merged. They have ultimate responsibility for the progress of their review.
3. We trust that each engineer would submit their best work for review and would not want to do anything destructive or malicious.
4. We trust everyone to give suitable constructive criticism, no matter their seniority, and to do their best to prevent bugs or odd patterns making their way into the code.
5. Regardless of what happens, it’s just code after all. If something causes a bug when it gets merged into the codebase, we can just fix it or back it out. No big deal.
6. Two positive reviews and it merges. No specific mergers required. The submitter should feel empowered to nominate reviewers if there are specialist concerns.

We’ve operated with this model since. It still has its flaws, but for the size we are now it makes do, and requires very little policing or intervention. It allows most review to happen within teams, too.

Redefining what we wanted to fix as a people problem showed that none of these ambitions required monitored implementations of particular processes. Instead, we just needed to encourage people to feel empowered to get on with their jobs to the best of their ability. And best of all, it had entirely positive effects. More people became empowered to get involved in reviewing because they could affect the outcome. Teams felt like they could take more control of their destiny by reviewing the code of their teammates rather than relying on nominated engineers in other teams and locations. And, when very complex or controversial pull requests were opened, people actively sought reviews from the right people themselves because it was in their best interest to do so.

In summary

Before you add another process or piece of technology to solve an issue, stop and think: is this a people problem?

Although it can be tempting to use one’s engineering brain to solve issues as if they were an algorithm, often that isn’t what needs fixing. In our example, an increase in trust and autonomy of individuals made people work more efficiently, rather than trying to layer on more process. We are just humans after all.

How things get done

We’ve all heard about workplace politics. What are they? Are they good or bad? Can we prevent them or should we get involved? Let’s spend some time exploring them.

Work, as in life, is filled with many independent actors in a complex system. Each actor is motivated by differing interests, passions and values. Each is working independently towards the greater good of the company, and politics are what arise from the continual negotiation, persuasion and debate of ideas.

The term workplace politics has often been used to describe purely negative situations such as those being taken advantage of, proverbial backstabbing, or people being poorly treated and taken advantage of. I would say that is a subset of workplace politics: it can potentially happen, and it does, but it’s not the wave that you should be looking to ride. You can use politics for good.

Politics in the workplace are always going to happen. You can’t choose to not engage with them, because if you do not, then you will find that your career suffers as a result, especially as you spend more time in management. Instead, the art is to understand these politics to see how you can navigate them and use them to your advantage whilst at the same time being an open and transparent individual. Ego, power, unwritten rules and implicit culture unmask themselves at higher levels of an organization, and you need to be able to harness them with a clean reputation.

Let’s dig deeper into what they mean.

How do politics arise?

Politics typically arise because of tension between different types of social structures:

• The org chart. The most obvious place where politics can occur. Debate between you and your boss about your own interests, or conflict between your and your direct reports. This also manifests in individuals reaching down or up through the org chart in order to spread their influence.
• Close-knit informal groups. There will always be groups of people who are close to each other and protect each other through friendship, camaraderie or shared interests. They have no formal power structure in the org chart, but they lobby and work together.
• Influential people. Singular influential people, who may have much more say than others because of their tenure, celebrity or bargaining power can make situations political or difficult to navigate because of the difficulty of building consensus without them.

As you spend more time in a managerial role, you will see how decision-making is rarely an easy task. You have to navigate the structures and people demonstrated above in order to make sure that things move forward in a constructive manner.

Like in real politics, all political situations and negotiations involve an element of risk. How should you conduct yourself? After all, getting politics wrong can be humiliating: you can find yourself looking very stupid, uninformed or unpopular in opinion. Getting involved in the wrong type of politics can be harmful, so you need to be able to protect yourself from the kinds of interactions that are toxic and only exist for those involved to be cliquey, spiteful and malicious. However, getting politics right builds your authority, influence and ability to get things done, opening up further doors in your career.

Positive politic patterns

Let’s explore ways that you should use politics to your advantage.

Learning teams and networks

Who makes decisions in your organization? Who is influential? Who are the close groups of individuals that think similarly, and who are the rival factions? Identifying this up front allows you to navigate sensibly through the political landscape and gives you the best chance of knowing who to go to in order to build consensus on particular issues, and who to approach differently or even avoid.

Take note of the different teams and divisions. What are their priorities? What motivates them? What do they care about and what are they knowledgable about? Which individuals have sizable influence and why? Is it because of their tenure or their technical prowess? By mapping out the organization and learning how it currently works, you can identify which groups and individuals you can collaborate with on different issues with the least amount of friction.

Winning hearts and minds

Remember that in order to have influence and to make an impact, you will need to win hearts and minds rather than just telling people what to do. Being a manager and therefore having authority to issue instructions and directives does not function well when the only delivery mechanism is executive order. You need to be able to make sure that the people you are leading really buy into what you want to propose; whether that is a critical decision on a project, a decision not to hire somebody, or a refusal to take some architectural work in a particular direction.

You need to be able to understand what motivates and drives people and to have the confidence to explain to them why their work matters as well as just what it is. Those that aren’t immediately receptive are those that you should spend time with in order to reinforce your view.

Building consensus

As companies grow in size, projects and initiatives move forward through collective effort, rather than just the force of will of an individual. When working, you will need to understand that consensus – at least as much as you can get – is important. In small companies and start-ups you can just take the proverbial bull by the horns and do whatever you want alone with little repercussions, but larger companies are different.

You can start small and informal. Let’s use an example. If your team wants to do something dramatically different to the codebase for their next project, then it is important to take as many people as you can along for the journey at the same time. It’s likely that your team won’t be the first that have thought of doing something like you’re proposing, so start by having some informal conversations with those that are senior, influential and close to the matters at hand.

Assuming that informal conversations have been successful, then you can announce more widely that you’d like to try a proof of concept pull request, or even just write an idea paper for circulation. It’s important that those you initially talked to are able to sponsor your efforts and offer their support, and that any work that you propose is just that: a proposal. Build consensus by making others feel like they always have the opportunity to contribute to what you are suggesting rather than it appearing to be a mandate. It will unlock the ability to make wider reaching decisions.

Being your best self consistently

Appearances and interactions are very important. You need to be your best self in a consistent manner in order to ensure that you are able to engage correctly in workplace politics and represent your teams correctly and respectfully.

Always be open, transparent, respectfully critical and absolutely clear on where you stand. Have the confidence to be open to being proved wrong and to be fine if you are. Be open to disagree and commit to initiatives. Never push agendas for the sake of serving only one’s self. Fundamentally your means of conduct comes down to the Golden Rule: treat others how you would wish to be treated yourself, and set the bar high.

Additionally, remember that when you become a manager, whether it is right or not, your position in the org chart grants you more power and you must wield this power respectfully and wisely. In the game of politics you must make sure that your relationships with particular staff are never seen to be favorable or unfavorable for personal reasons, otherwise you can be seen to be cliquey or nepotistic and this will make you less trustworthy. This may require some difficult conversations between those you are friends with externally about how you can conduct yourself in the office, but you will thank yourself in the long run. You need to engage equally and fairly with all.

Building a network of peers

Previously we have talked about building a network of peers from different areas of the business in order to share information, get feedback and sound out your ideas. In workplace politics, your network of peers is important as it allows you to be more broadly informed about how the wider business feels about your own initiatives and priorities, and it also gives you a chance to trial ideas before taking them any further, allowing you to initially operate in a safe, cross-disciplinary setting.

Negative politic patterns

In contrast to the positives, there are many negative ways that you can engage in workplace politics that will at best result in conflict and at worst have a negative impact on your career.

Misuse of executive order

Whilst your seniority may allow you to just tell people what to do, without winning hearts and minds, you will erode your respect and ultimately your influence. I like to imagine each manager having an energy bar, like in a video game, that is depleted when a controversial override on a decision is made, or an unpopular direct order issued. You must use them tactically and sparingly. The bar replenishes when you move forward with your team in a congruent manner where they are motivated to go on the same journey as you.

Level-jumping

I’m sure we’ve all been guilty of going over someone’s head to their manager because it’s quicker and easier than going via the chain of command. I’m sure many of us also saw how much trouble Jimmy McNulty used to get into in The Wire for doing so (warning: very strong language).

Now, there may be times that this is quick, easy and convenient. However, the person being left out in the middle feels awful. There are things going on in their team or division that they are none-the-wiser about. Sometimes you may have a good relationship with your manager’s manager or even be friends outside of work, but you need to make sure that you go via the proper channels and bring your own manager along for the ride.

The same is also true for those who run a large organization with many layers of management. If you are going directly to the direct reports of your own direct reports about issues that should really involve the person in-between, then you are meddling and it shows disrespect for the person being left out. Could you not delegate this to them? Why not? Could you not coach them to do so?

Being unprofessional

I’m sure that this goes without saying. If you wish to be influential and effective as a manager, then you need to engage with others in a professional manner. This may be in contrast to your exact personality outside of work, but you owe it to all that you interact with to be open, honest, transparent and without motive. You need to operate for the greater good in order to be taken seriously.

Those who are unprofessional erode the trust that the organization has in them, and in higher levels of the org chart where trust is of utmost importance, those who cannot demonstrate it will find themselves unable of moving into these roles.

Going rogue

If you think that the best way to demonstrate how good your idea or initiative is by just doing it without anyone knowing, then it is likely to cause much more conflict down the line than if you had built consensus in the first place. Going rogue is similar to building up technical debt: it gets worse the longer that it continues and it is harder to back out from.

For example, if you thought the best way to make big architectural change in the codebase was to just do it silently rather than taking everyone else along for the ride, then you may find yourself unpopular when those controversial code changes end up being forced through because of an impending deadline for a feature, or even worse, blocking the whole deliverable.

If you are unable to build consensus, then maybe your idea or initiative is not as good as you originally thought it was.

Using politics for personal gain

The last negative area should come as no surprise: you should not use workplace politics for malicious personal gain. Bending ears to force through your recommended candidate so that you get the referral bonus is a terrible thing to do. Using your influence to force others into situations they do not want to be in for your own gain is also abhorrent. Abusing your position to make others feel small, powerless or marginalized is the worst form of politicking and will always catch up with you. Just don’t.

In summary

Workplace politics are very real and when understood and harnessed for the power of good, they give you the ability to move an organization forward in a positive manner. When used poorly or for malicious reasons, you can begin to build a snowball of mistrust that will always come back to bite you, and will limit your career. Engage wisely.