This is my personal implementation of the "manager readme". It's basically a cheatsheet for dealing with me. Like real software, it's a permanent work in progress and full of defects + inconsistencies.
I like the model of servant-leadership. It's not necessarily the the best approach in all situations, but I like those ideas and that framework a lot; and I strive to be that kind of leader.
To that end, I see my role primarily as a facilitator + enabler. I'm here to help the team and org figure out where to go; and then remove any roadblocks and obstacles that might prevent us from realizing those goals. For the same reason, I also try to act as the lightning rod + general whipping-boy for our team, in order to shield everyone else from those distractions.
I'll typically stay out of most deep technical arguments at this point and defer to the team's expertise instead. My place is to create an environment where the team can be successful, not to dictate technical decisions.
At a high-level, I want our team to be awesome; for everyone on the team to feel challenged, productive, engaged and happy; and I'm willing to take on the dreary chores and scutwork to make all that happen.
- As a general policy: if you ever have a question, complaint or concern, please just say so. Don't suffer in silence. Don't fail alone. Need help? Missing a deadline? Have a better idea? I'm acting like an idiot? Just say so. In particular, if you're unhappy with me or something I'm doing, please tell me.
- I tend to ask a lot of questions, especially when we're discussing some large topic with the team. Why do we do XXX? If we were building YYY from scratch, today, is this the design we would choose? Can we do this faster/better/simpler? Please don't interpret these questions as skepticism or disagreement. I'm likely trying to (a) confirm my understanding or (b) deliberately provoke a longer discussion to find edge-cases and draw out other opinions.
- I tend to be a visual learner. Diagrams and figures help me to understand new topics or ideas. I will sometimes start drawing on the whiteboard prematurely as way of clarifying/explaining some idea, even to myself. Or I'll ask: can you draw me a picture of XXX?
- I'm more of think-to-talk person, but IMHO talk-to-think is a better mode for team discussions and I may deliberately steer debates in that direction. I struggle with this sometimes: I want to move quickly, sometimes before I've really had a chance to internalize some topic, and may circle back after a discussion to confirm or discuss in further depth.
- By default, an hour once a week, until we agree otherwise. Once we find a good cadence, I will try to never cancel them. In the event of an unavoidable conflict, PTO, travel, natural disaster, war, etc, etc, I'll reschedule instead of canceling.
- In general this is your meeting to discuss whatever questions or concerns you'd like: big strategic topics, small tactical details, scary issues, career path, technical minutiae, etc. I will typically bring topics for discussion, but will always defer to your agenda over mine.
- If I want to discuss something "big" at a 1:1, like career planning, I'll warn you in advance. Mostly so you're not blindsided and have time to reflect or review before we meet.
- For urgent tactical issues, please escalate or reach out immediately. Please don't wait for a 1:1.
- My calendar is public by default, with both work- and non-work commitments on it. If my calendar says I'm available, then feel free to schedule over it. Don't wait for an invitation.
- If some topic is urgent or time-sensitive, tell me. I'll make time regardless of what the calendar says.
These topics and expectations are personally important to me; and tend to color my expectations of the team and the larger org.
- A bias for action and results. When in doubt, let's act, not wait. If we're blocked, I expect us to look for alternative options or other ways to make progress. If we're not sure of the path forward, let's gather the best data we can, make an educated decision, and keep moving. Corollary: Never wait on me. If some issue needs an urgent response or action, make the best decision with the data we have and then move ahead. Never wait on me or my input.
- Quality. A high quality bar is important to me personally. I expect us to take our internal quality and internal process seriously; and I prefer fixing issues over deferring or punting them. No broken windows. The hard problems can be fun to fix; but the little ankle-biters are just annoying and slow us down as a team. Let's fix those little issues once, not workaround them repeatedly.
- Ownership. I expect us to own our own problems + solutions. If there's a bug in our code or one of our components, I expect us to fix it in a timely fashion. For this reason, I dislike fuzziness and ambiguity at the edges: if there's a problem "near" something that we own, I'll assume that it's our responsibility until proven otherwise.
- I routinely work evenings and weekends. Therefore, I will sometimes email/slack/etc you at weird hours of the night, on Sunday afternoons, etc. This is my own personal process: I'm catching up from today; getting ahead for tomorrow; or possibly not-sleeping (see below). Regardless, this is my process, not yours. I'm not expecting an immediate response. Don't feel obligated to respond until your normal working hours.
- I suffer from raging insomnia, frequently. Sometimes it's seasonal (June, July, August, when there's lots of daylight in this part of the world). Other times it's self-inflicted (stress, usually). Regardless, if it's late in the day and I seem punchy, disinterested or quieter than usual -- it's nothing personal. Odds are that I'm working on 3-4 hours of sleep, and my caffeine has worn off.