Note: the canonical version of this document is published at https://github.com/joey-coleman/manager-readme/blob/master/README.md.
Hi! I'm Joey Coleman, and this document is about me, how I work, how I hope others will work, and how I hope to interact with people. I work at Kira Systems as a "Kira Fellow" — this is a Director-level, Staff+ position. I don't presently have a team, as such, but I am the line manager for a few people. Previously at Kira Systems I was "Director, Systems", and I built the Systems Team up from myself and one other to a team of about a dozen people (then I handed it off). The commentary about engineering versus management tracks at Engineering Management: the Pendulum or the Ladder resonates with me — I've now done more than two years on the management-focussed side, and I'm now focussing on tech and tech strategy; I suspect that I'll inevitably drift back towards management over time (but not right now).
This is the third version, updated October 2020.
I originally heard about this type of document from the Rands in Repose blog, particularly How To Rands; it seemed like a good idea, so I shamelessly followed. Later, Kira Systems started strongly suggesting that our employees create an "Owner's Manual" for themselves; that's just a worse name for this document.
This document is a guide to me — if you're working with me, it might help. Of course, it's probably wrong in all kinds of interesting ways, but at least you get to call me on it.
My role has two major parts: technical and leadership, in that order, and they have a great deal of overlap.
I try to lead in line with the "Servant Leadership" philosophy, in that I want to provide others (those that report to me, and those that don't) the means and resources to get things done, and then get out of the way. Everyone I've hired I've done so with confidence that they are both able and willing to get things done. I also see myself as an imperfect model — while I'm sure that some of my behaviour is not worth emulating, and I'm sure that I could improve other behaviour, I do try to exhibit those the traits I wish to see in my coworkers.
Technically, I try to spend more than half my time "in the weeds", and as much of that as possible fitting together bits and pieces that either have a high ambiguity quotient, or a high (but maybe risky) payoff for the organization — my role is intended to figure out how to do things we're not doing yet. Sometimes I'm an oracle — I am responsible for the current architecture of our production system, and I know far too many arcane details of why and how it was put together.
-
Honesty — I am direct, often blunt, and I appreciate this in others, even when I don't like the message.
-
Humility — Not even sure how to express this; nobody likes a braggart is too simple, and too obvious. Being able to say "I don't know" and understand self-limitations is golden.
-
Confidence — This is not in paradoxical opposition to the last: my experience is that those that are insecure are often among the least humble folk I've met.
-
Competence — Beyond the obvious skill-based meaning, this includes the self-awareness of knowing what one is competent in.
-
Curiosity — This is foundational: personal growth in technical fields is driven by curiosity. Also, I find incurious people hell to work with.
-
Applied laziness — Put positively, the drive to automate away any and all manual work. Life is not well spent doing the same repetitive thing over and over again.
I like the "Directly Responsible Individual" idea — that, once a person takes or is given a task, it's incumbent on them to own it and not be chased to finish it. There's always an out — directly admitting that one cannot do a task (alone), and asking for help, or another to lead.
-
Evasiveness/Verbosity — If asked a question, come directly to the answer of the question (or its intended question); if explaining a situation, come directly to the relevant points; if the points being explalined don't seem relevant to me, then I need to know first why they matter.
-
"Having to be told twice/asking the same question twice/having to be told everything" — there are many things I expect people to already know, and I freely admit that, occasionally, my expectations are unfounded. That said, if your job is to know X, and you purport to have experience doing X, if you ask me how to do X, I'm going to be surprised.
-
"Just" minimization — Saying something is "just a bit of design", or "just a matter of Systems standing up the instance", belittles the hard-earned skills of the people that do the work, and shows a profound lack of respect towards them, and a profound lack of understanding of what they do. That said, I've been known to use "just", with the quotes, as a signal that I understand that a task is going to be a significant effort, but that I accept that it needs to happen.
-
"It didn't work"/"Tell me what you tried" — If you'd like my help, be prepared to explain what you already tried. Bringing me a problem without any evidence that you've made a good-faith effort to troubleshoot it is not a happy thing.
-
I hope to see some degree of the things I value, of course, though I am aware that those are my values, and not necessarily yours.
-
Fix problems where and when you see them. This necessarily must be tempered with an understanding of why the problem exists, and why it persists.
-
Sensitivity first to the confidential nature of the data we keep, then to the control regimes we operate under.
-
A certain esprit de corps — we're all ultimately on the same team, as part of the same organization. Work for the common good (and sometimes this means saying "no").
This is written mostly for those who report directly to me, but applies indirectly to everyone else, as well.
-
1:1 meetings — I believe these are important, but I'm flexible as to how we do them. Some people prefer a fixed cadence, others prefer an ad hoc/as-needed schedule, and depending on my load, I will accomodate as best I can. That said, you can expect me to insist on a meeting at least once per fortnight; and, if we haven't sat down to chat within the past fortnight, I should be putting a block in your calendar. These are for both of us — I may have updates from the organizational context that I want to discuss with you; you may have things you want to discuss with me.
-
Challenges — Related to the last, I will give you things that I think (or hope!) will stretch your skills. Sometimes I will ask beforehand about areas where you would like to grow and work on, but sometimes it will be based on overall team and organizational goals.
-
Trust — If I ask you to work on something, it's because I trust you can (learn how to) do it, and I trust that you will tell me if and when you need help. This is a vote of confidence in your ability to manage yourself, not necessarily the assumption that you already know how to do the task.
-
Communication
-
Silently giving up — If you're overwhelmed, ask for help. Being overwhelmed is not a mark against you, but rather a missed judgement call on my part. Giving up and not asking for help is a choice you control; I would rather help and recalibrate expectations than be upset that something didn't get done.
-
Failing to learn — While our infrastructure isn't bleeding edge, it's far from traditional, and we're actively working to make things better. Sitting and holding to what you've always done in the past, only because it's the way you've always done it, is not sufficient justification. (Genuine best practices are only best because we haven't yet figured out better, not because there is no better.)
- The biggest part of my background is academia, and I argue like many of the academics I've met: full of noise, passion, and vigour. And when we're done that session, the passion stays with the ideas and we go for beer.