Manager Readme

April 1, 2019

Hello hello. I created this document for the people who work with me, new and old, to describe what I stand for as an engineering manager. Similar to a software readme, this doc should help you read me as a manager, understand how to interact with me (inputs) and what to expect in return (outputs). There are probably some bugs too. In the spirit of continuous improvement I always aim to acknowledge my flaws and improve on them.

What to expect from me


I strive to always tell you what I think and know. You can ask me anything. There are no stupid questions. I will ask for the same from you. One of my biggest dislikes are deception, misdirection or just straight dishonesty. I don’t believe we can effectively work together where this exists.


I’m here to help you. That really is my only job. Often I’ll encourage you to try and solve a problem yourself. That doesn’t mean I’m not there to provide guidance or that I don’t have an opinion. It’s just that if you solve a problem you are then armed with the skills and knowledge to solve that same problem again in the future. You might even come up with a better solution than I could have thought of. Even better you can then go on and support others with that knowledge, leading to more self sufficient teams.


We hired you for a reason and that’s to do your best for our company and it’s users. I trust that you’re invested in good outcomes for the company.

My Focus


I’m a manager of humans and so I will treat you as such. I don’t expect perfection. I try not to cast blame. I’m curious and ask lots of questions to learn from you. I’ll work to motivate and encourage you so you can learn and grow as much as you can while working with me. If you ever feel like I’m not showing trust please call me out on it.


I believe that empowering directly responsible teams that can deliver on their goals is key to building a successful organisation. The sum is greater than the parts. While I work with people, I’m usually aiming to encourage teamwork, collaboration and systems thinking to help build high performing teams that work well together.

Engineers Not Coders

I consider that software engineering differs from the task of coding. Engineers are deeper thinkers, look outside of the box of a single bit of software and strive to solve hard problems. They take these problems and turn them into working solutions for people. They hold themselves responsible for their work, which includes their communication and teamwork, any issues that come up, delays or missed expectations. They push the limits of what can be done. My expectation is that all the engineers I work with are engineers not coders.

Working with Me

Open By Default

I’d like you to try to be open as a rule not an exception. This could be in choosing your communication channels (slack public vs private), sharing your work (foggled on for the office vs available only to developers) or how your give feedback (to your team in your retro or privately to someone at Friday drinks).

Base Expectations

Some things that are baseline expectations, you need to do without being shown how or explained why, are:

  • Be Respectful - to people at work regardless of how you are feeling
  • Be Attentive - turn off your laptop and put down your phone when someone is talking to you
  • Be Timely - show up to meetings on time, I’m not going to teach you how to do this. Give me and your peers plenty of notice about leave, time off, change of plans etc