The Engineering Manager

OK, so I tried. I really did try to write one. Multiple times.

But for some reason, they all came out trite.

Whenever I had a spare moment during the long Bank Holiday weekend, I would open up my laptop and begin to make notes on the definition of my role, on what I expect from those that report into me, how I like to communicate, the intricacies of my personality, and so on.

Each time I completed a further round of edits on it, I would step away from the computer. Upon returning later on, I’d reopen what I wrote previously, but I was always disappointed with what I read.

Although the purpose of a manager README is to help a relationship between a manager and their direct report get off on the right foot, I was unsure as to whether I was even getting the right impression of myself.

A thought repeatedly entered my mind.

“Who on Earth is this person that needs to write a document to tell me how to work with them? Is this really me?”

Maybe my view was not the opinion of the majority, as the idea of manager READMEs has gained some traction. But, regardless of how others may feel, here’s my personal take on it.

Some background

In recent months, a number of articles have been shared about manager READMEs, predominantly by those that work in software development. The document is written by a manager, typically for a new direct report, and outlines subjects such as the following:

• The manager’s role and responsibilities
• How they like to work and communicate
• Expectations that the manager has from their direct reports
• Their management style and default mode of operation
• Any personality quirks they may have

Some managers would share their README document before their new member of staff arrived for their first day at work; consider it homework, if you will. Some shared it before their first 1 to 1 during induction week. Some had it publicly available online.

It’s a neat idea that stirred my curiosity. Should I have one of these? Are my staff putting up with some of my personality traits because I’ve never made them explicitly clear? Have I had any clashes, unbeknownst to myself, with my staff because I hadn’t clearly outlined our relationship?

. . .

Now, if you’re interested in reading some of these documents for yourself, then there are plenty available for you to digest. Hacker Noon published a collection of READMEs from some prominent engineering managers, and Katie Womersley of Buffer wrote about how to use them and shared her own. There are also many more examples dotted around the web, typically findable by typing “manager README” into your favorite search engine.

But, let’s return to my struggles when writing my own.

It’s worth mentioning that I never suffered from not knowing what to write. Over years of managing teams I have become comfortable and confident with how I work and I’ve had a decent amount of feedback that others are happy with this as well; both from those that report to me and those that I have reported into.

I was able to specify quite precisely what I felt the core aspects of my role were, what I expected from myself and from those that work with me, and I was able to state my communication preferences quite succinctly. I didn’t even think I had that many quirks, on reflection.

However, each time I read it, something didn’t sit right. I couldn’t quite work it out at first. Was it that the content wasn’t truthful? Was it that I was describing an idealized version of myself that I would feel wasn’t entirely truthful if I published it?

Not exactly.

Observations from others

After some thought, I took myself back to the comments sections of the articles that I had originally read, and also spent some additional time searching on Twitter and the Web for what others had been saying about the concept.

A few observations stood out.

The first was by Margaret Heffernan in reply to the original article on Hacker Noon:

Wow, these are all so similar it’s uncanny. I started wondering if actually they were all written by the same person. Everyone wants to be excellent. Everyone is here for you, not themselves. Everyone wants to be responsive but not intrusive. Did they all read the same management book? Sadly what these don’t show up are the differences that make people interesting.

This was congruent with the feeling that I experienced reading my own words: they felt like the words of others.

Every sentence that I was able to commit to (digital) paper felt like plagiarism of something that I’d already read elsewhere. Is management done well, in technology or otherwise, effectively the same core principles that we’ve all read from umpteen management books and learned from our own mentors? Have we reached technology management homogeneity?

Then, I uncovered a further observation.

Whilst reading through related conversation on Twitter, I came across an opinion stating that the concept itself could be flawed.

If "how to work with me README's" must exist (and I don't take it as a given than they must), then they should be given by direct reports to their managers, not the other way around.

— EricaJoy (@EricaJoy) May 9, 2018

As Robert MacCloy points out in the same thread, surely, shouldn’t the burden of adaptability be on the manager? After all, isn’t it the duty of the manager to facilitate their direct reports, and in doing so, the manager should not expect their staff to change how they work to suit them? Do we not all possess different relationships depending on who we are?

. . .

I’d hit writer’s block.

At this point, I’d closed my laptop and leaned it up against the sofa. I’d jumped into the car to head into Lewes with Rebecca on an unexpectedly warm spring Sunday. I was sitting in the passenger seat of our car while she was driving down the A27.

As we passed the contour line between the Amex Stadium and the University of Sussex campus, I was trying to articulate why I had found writing my manager README difficult, and how that was now at odds with my original idea for this article.

I began: “You know, it just didn’t feel right producing a page of A4 detailing traits that somebody should know about me. They’re the sort of things that I typically discuss with my staff anyway.”

“Right,” she replied.

“Also, after reading a number of other people’s, they’re all really similar. Am I really just like everyone else?”

“Well, maybe you’re quite comfortable with how you work, but you’ve been doing it for a while. The process of writing it down could be a useful exercise to a new manager who hasn’t spent the time thinking about how they operate – it doesn’t have to be published and shared.”

A very good point.

“Not everyone is the same as you, either. There may be other managers who feel comfortable writing it down and communicating it in that way rather than going through it all in person.”

Also true. Discussing personality traits can still be an awkward conversation for many.

I replied: “Yeah. I’d much rather talk about this in person rather than have to document it all. That’s just how I work, I guess.”

And so it was.

Cmd-A, Del

When we got home at the end of the afternoon, I opened up my laptop again. It seems that my own manager README ended up being really short:

I’m here to help you succeed. Let’s talk about anything on your mind at any time.

And look: it’s even on Github.

I prefer to go through how we should best work together face to face, as we begin to get to know one another. You’re still welcome to write your own one for me to read if you like. It’s totally up to you.

Your mileage may vary.

Our psychology

Taking a first step into management from an individual contributor background can be tough. Not only is the role a step up in terms of accountability and responsibility, it also widens the interfaces in which one operates: increased debate and discussion, more exposure to opposing views both inside and outside of the team, and deeper emotional connections, tensions and breakthroughs.

An engineering manager can find themselves as a conduit and chair for all sorts of situations: debates about scope and priority with Product, dealing with clashes of ideals about which framework should be used for a new application, through to fallout in the team after missing a deadline, ongoing performance issues, and believe me, I could go on.

In addition to continuing to utilize your technical strength, you also need to also develop a strong mindset that can identify and work with the psychology of those on your team. Having worked with a great number of people over the years, I have seen that conflict can manifest in so many ways beyond the prescribed roles that people work in.

Yes, of course, there is a natural tension between Commercial, Product, and Engineering. But even those with the same skillset can find themselves clashing with each other due to the psychologies that frame the way that they think about the world.

Let’s look at the play between pessimism, optimism, realism and idealism. We face this more than we might think; both within ourselves and in the disposition of others that we work with. How does it manifest and what can we do about it to help our teams succeed?

The outlook matrix

Now, before I go any further, I must admit that the matrix I am about to present to you is not my original work. I stumbled across it on a quiz website aimed at what I can only assume to be schoolchildren, given that some of the questions were asking my reaction to someone telling me that my crush likes me, or whether the teacher has yelled at me for being late to class. Sometimes inspiration comes from the strangest places. Don’t worry, though: the actual origin of the image differs.

But anyway, to the matrix. It represents the tension between optimism and pessimism contrasted with the tension between idealism and realism.

Both you and your team will naturally gravitate to a default position on this matrix: our natural mindset. Yet, that default is not fixed. Often we will find ourselves temporarily at other positions on the matrix in reaction to particular situations. When faced with the planning stage of a project we may inhabit a mindset of optimism and idealism, inspired by the CEO’s vision of how the feature is going to completely revolutionize the application. During the tail end of a death march project we may find ourselves channelling a combination of pessimism and realism.

Let’s explore the nuances of the two axes with respect to managing software teams. We’ll discover that the extremes of the psychologies can actually drive both positive and negative behavior. There is no perfect place to be for all situations.

Optimism and pessimism

Some basic terminology that you’ll already know: optimism is the general tendency to expect positive outcomes, and pessimism is the general tendency to expect negative outcomes. Initial categorization of these traits could lead to thoughts that optimism is entirely beneficial and that pessimism should be entirely avoided. There is some truth in this, however there are subtleties between optimism and pessimism and two related traits – credulity and skepticism – that are important to understand and separate.

Pessimism, of course, can drive a lot of negative behaviors. A pessimist can shut down conversation and throw water on to the fire of a great idea before it is fully formed. A pessimistic team can sap the creativity from a product owner and lead to an aversion to try anything innovative and challenging. Pessimism can make estimating work a nightmare: you just wish you could change the team’s mind, but their psychology is defeating you.

Yet, it is important to recognize that pessimism is related to, but quite different from, skepticism. Whilst a pessimist will naysay ideas due to their mindset, a skeptic will apply questioning to the idea to ensure that it is as fully formed and correct as it can be. Pessimism comes from the wrong place, but skepticism comes from the right place. Don’t get them mixed up, as a healthy skeptic can inject more rigor into your ideas and improve them as a result. Skepticism should be thoroughly encouraged and praised. It is essential for critical thinking.

Conversely, optimism can in many situations be extremely useful: a person with an optimistic outlook on life can drive many positive behaviors in themselves and others. An optimistic manager, especially in times of high stress and difficulty, can be a calming and balancing influence.

Optimism should be commended, but it is not to be confused with credulity, which is the tendency to be too ready to believe that something is real or true, without sufficient evidence. A credulous leader can make irreversible decisions based on false premises. A credulous team can make a poor technology framework choice without properly evaluating it. That same credulous team can underestimate the length of time it takes to complete a project and overpromise and repeatedly miss deadlines.

Drive towards optimism but watch out for credulity. Equally, reward and encourage skepticism, but don’t confuse it with pessimism. The subtleties are critical.

Idealism and realism

Idealists believe that reality is constructed from ideas: that reality is itself a mentally constructed concept. Realists believe they see the world objectively as it is. Without straying into the realm of early Greek philosophy, we can place idealism and realism at two ends of the vertical axis in our diagram.

Idealism and realism can both drive positive and negative behaviors. Both have their place and time. Idealism within a founder or leader can drive everybody towards a vision of the future, no matter how challenging it is to get there. Think of Steve Jobs and his reality distortion field.

Idealism can drive innovation; it can rally a team behind a cause much greater than themselves. However, idealism can also create issues – it can become radicalism. It can create standards that may be entirely unachievable. Radicalism can cause heated arguments over pull requests. It can cause deadlocks in thinking and endless arguments. Idealism should serve as a guide, but the path towards idealism can never be entirely pure: the fact that we are just humans and are trying to get stuff done to a deadline means that there will always be hacks, shortcuts and compromises. We must be pragmatic. A healthy pragmatism between idealism and realism means that things actually get done.

Too much realism, on the other hand, can have negative consequences. Extreme realists can judge idealists as uninformed, irrational or biased, which can kill innovation. Someone has to come up with that crazy moonshot after all. Extreme realism may prevent a department with a crumbling legacy technology stack from ever trying to modernize because it is seen as too difficult, which could ultimately be the death of that company.

Your team will likely have a combination of idealists and realists. Harness the vision of the idealists to see where the team should move towards, but use the realists to help create the steps needed to get to that destination. A pragmatic balance of idealism and realism creates an actionable plan that moves in the right direction over time.

A balancing act

We need optimism without credulity, skepticism without pessimism, and a balance of idealism and realism. Where do you naturally sit in the matrix? What about the individuals in your team? What about the team as a whole? Is the group dynamic different to the sum of the individuals? Why do you think that is?

Are you able to change your position to counter-balance extreme opinions within the team, even if that mindset is not the natural one in which you reside? Also, are you able to notice when your own default position can cause biases in your own judgement?

Personally, I tend towards optimism but I can recognize my pessimism which can be higher on days that I am stressed. I sometimes suffer from credulity when talking to someone very persuasive or senior. In these situations I tend to have to remind myself to apply more skepticism. I would like to think that I have a good balance between idealism and realism, but try asking me that when I’m in a pinch near a deadline!

How about you?