# Roger nolan's Manager Readme

**CTO at Infogrid **

_After having a pending task to write a manager readme for about a year, I’ve taken the opportunity of a new role to actually write one. This should be considered a work in progress. The intended audience is anyone who reports in to me, though it's hopefully useful for anyone who works with me. Please treat it as a reference and promise on how I will conduct myself as a manager, and where it makes sense how I expect you to behave. It's also full of inaccuracies and, because I wrote it, **bias**. Please point out the mistakes and hold me to the correct parts._

# **Why am I here?**

A manager’s job in a company like this is to help people get their job done. Whenever possible I will try to push responsibility and decisions down the organisation so they are made by people with the most understanding and who are most affected by any decision.

## **General beliefs.**

I assume positive intent. In general, people who don’t appear to have positive intent have a different goal to you or one of you knows something the other doesn't. People are very rarely evil and poorly intentioned.

I try\*\* to practice **servant leadership**. To quote [Greenleaf](https://www.greenleaf.org/what-is-servant-leadership/): “The servant leader shares power, puts the needs of others first and helps people develop and perform as highly as possible."

I strongly prefer data driven decisions. I like data and information in general. I will try and make every part of our team and our dependencies data driven and free from bias.

I encourage experimentation and risk taking. We should be bold and have a bias to action hence:

## **Openness, honesty**

Admit mistakes, problems and errors. Communicate them clearly and openly. It’s a cliche but we learn from our mistakes and we can’t fix problems we don’t know about. I fully subscribe to the findings of Google’s [project Aristotle](https://rework.withgoogle.com/blog/five-keys-to-a-successful-google-team/). In particular the most important factor in building a successful team is psychological safety.

If I or the company are doing something that makes you likely to leave, tell me. Don’t bottle it up. I'm here to fix things. If I'm one of those problems, tell me and if you don't feel able to do that, tell my manager.

I will also try to be very open and honest with you.

# **Practicalities**

## **1:1**

We will have a **weekly 1:1**. It's not compulsory, nor do we have to use all of the scheduled time but I want it to be useful for you.  The 1:1 is Confidential unless explicitly stated.

The 1:1 is not a time to list everything you’ve done.

It will always start with the same question: “How are you?” This is intentionally general. I can offer support, help and advice. I might sometimes challenge you on your approach or assumptions but I won't tell you how to do your job.

I would like you to create a shared document where we can keep notes and items for discussion in our next 1:1

I will also occasionally have 1:1s with people in your team - this is just to keep me grounded and give them a chance to speak directly. It’s not a way of checking up on you.

## **Team meeting**

I will (eventually\*) hold a team meeting for all my direct reports. Again, this isn’t a scrum of scrums or a status update meeting. The team meeting is a chance for us to work on issues of note affecting the whole team. It’s also a channel for me to cascade information to the rest of the team.

## **Rituals**

I’m still looking for the **perfect reporting tool** so expect some experiments. If we find one that works for us, we’ll stick with it until something better comes along. The goals for reporting are that it’s clear and open and doesn’t take more than 15 minutes of anyone’s time each week.

I like all traditional **agile rituals** but I prefer us to not accept dogma and build our own versions that work for us - note that this does not mean “our own versions that sacrifice impact for expediency”

I will try\*\* to make meetings I'm involved in more formal than they probably are. I expect meetings to start on time, and to have an agenda and produce actions. If you invite me to a meeting which repeatedly doesn't have these things I'll start to skip them or take over.

# **Things I like**

**Automate all the things.**  Leave humans to solve the problems, not write management reports, test software or do admin. I don’t believe in “10x engineers” but I do think a single engineer removing toil can make a 10x difference.

I’ll occasionally declare [Chatham House rules](https://en.m.wikipedia.org/wiki/Chatham_House_Rule). Please respect it.

I’m a fan of the ideas in Accelerate from the DevOps institute - there's a good summary [here](https://medium.com/slashdeploy/book-review-accelerate-92ebc00f4354) but you should really read the book. I believe this kind of operational thinking applies throughout engineering, not just DevOps. Ditto Google’s views on SRE. The Google books on SRE are both [available for free](https://landing.google.com/sre/books/).

I value intellectual integrity and like to debate. I believe writing things down forces you to fully think things through so I like product requirements documents, design documents and so on - but I also understand they are not needed at all stages of a project or by all teams.

# **Things I’m bad at**

I occasionally work at **weird hours** and weekends when it isn’t needed. It’s a bad habit and you should not take it as an example you need to follow. If we occasionally need action outside normal work hours, I'll make it very clear.

**Office politics**. Working here isn’t a zero sum game. We can all win and if we try to win together it’s more likely to lead to success. If there are office politics here, assume I’m going to fail to navigate them well.

**Calendar management.**  I’m bad at saying no to requests on my time. Unless I’m the one who’s new here, My calendar will be rammed. I will try and help you book some time - I can cancel meetings if something is urgent. Note the corollary here - I may cancel or skip meetings if something urgent comes along.

\* The timing of this depends on us having enough substantive issues we get through in ad-hoc discussions.

\*\* as with all of this type of document I’m presenting an idealised version of myself, my working practices and views. When I stray from them, you should call me out.