I originally wrote this when I first joined the ebay Software Engineering team, as an ice-breaker and conversation starter with my new reports. I thought I had lost it once I left ebay, but happily found a copy of it while going through some old files. It is also available on GitHub at https://github.com/adrianlebar/manager-README.
Welcome to the team! I’m really glad you’ve joined us!
First, a little about this document. I have seen dozens of similar documents by Engineering Managers, and I think they're pretty great ideas. This one borrows from many of them I have read over the years, but it's applicable to me, and reflects my values as an Engineering Manager (and human). It originally appeared on an internal wiki page when I worked for eBay as a manager working with the Engineering team at the Canadian classified site Kijiji. It has been significantly updated since then.
I initially wrote it because I once read a quote that stuck with me. At first it stuck with me because it seemed a little absurd, but as I thought about it more and more (and I thought about it a lot), because it spoke to me on a an intuitive level. That quote is likely apocryphal, and also likely misattributed, but apparently President Eisenhower said it. That quote is:
‘I have always found that plans are useless, but planning is indispensable.’
It speaks to the fact that the value of a plan is not in informing us what to do, but in the act of answering all the questions required to come up with a plan in the first place. Since (another apocryphal quote) 'no plan survives contact with the enemy', having all the information that was gathered in the planning phase suddenly becomes very valuable when we're making decisions by the collective seat of our pants.
This document is among other things, a work in progress. I wrote it, and continue to refine it (occasionally), because it helps me identify and refine my thoughts and values, and hopefully it will help you understand me a little better while we’re working together.
Consider this an exercise in planning.
What this is and also what it isn’t
This document is a quick(?) introduction to who I am, what it might be like working with me, and some insight into why I might make the sorts of decisions I do.
What this document isn’t is a list of my expectations of you, or my plans for our team.
Stuff to know
I’m a musician by training, a graphic designer by education, and a software engineer by accident. But I am a manager deliberately.
I have five children (five sons and a daughter smack in the middle). I have two cats and one brilliant wife who is a lot smarter than me. She has a PhD in something I cannot even pronounce.
I am a Slovenian citizen, despite being born in Canada and also being a Canadian citizen
My hobbies include photography, writing, travelling and reading. I make espresso drinks and latte art. I like long walks in the rain. I also like quoting old songs and movies.
My role here
My job is to attract and retain great talent. Since you're here, we're off to a good start!
The most important part of my job is the people who work here, whether they report to me or not, engineers or not. My calendar is always visible, and you are free to take up any available space in it if you have something you need to say to me. Don't ask permission.
That said, my calendar is also totally full. So don't wait for an empty space in my calendar. Slack me. Or email me. Or phone me. I do a lot of things here, but very few of them are likely to be more important than talking to you if you have something to say. Again, don't ask permission.
The other part of my job is to set context. This is sometimes easier than the other part.
I expect us to disagree. This is a good thing, so long as we do it respectfully. Let's stick to the facts. Data wins arguments, I've heard it said, and we should both bring data to back up our positions. That said, if something's really wrong but you haven't figured out the metrics to describe that, don't hesitate to say so. We will figure it out together.
Teams that don't disagree and talk about it are weaker than teams where everyone feels they can speak their mind.
Density of communication
I have a theory of communication that looks something like this:
'The denser the communication format, the better.'
What that means is that face-to-face talking > video conferencing > telephone > messaging (Slack, etc.) > email. Choose the most dense form of communication available to you.
Butts where they create value
As far as I'm concerned, you aren't payed to sit at a desk. You're paid to create value. I don't care if you're sitting at your desk in the office doing that, or sitting at home doing it, or even sitting in a coffee shop or on a beach. Create value.
That said, there are times when the best way to work together might be face to face, or via video conferencing or something (see Density fo Communication, above). Work out with your team the best way for all of you to work together and get to it.
Afraid of being fired?
There's a good chance that at some point - especially in your first few months here - that you're going to feel like you're about to be fired. Happens to us all.
If you were to ask any three engineers on our team if they felt like that in their first three months, chances are two of them will answer yes. The other one will likely be engaging in some revisionist history in their own minds. It's completely natural to feel this way. It takes a while to really grok what we're doing here and how we're doing it, and its really important that you know that I know that.
Unless I (or your manager, if your manager reports to me) has explicitly said to you that you're in danger of losing your job, or very specific and clear words to that effect, then you're incredibly unlikely to get fired in your first three months. Or at all, really.
My track record on firing people
I've been managing people for a long time. I've had hundreds of people reporting to me in that time, in a variety of roles at a variety of companies. I have had to fire a few people, but in all that time - almost 15 years as of this writing - the number of people I have terminated is precisely five. None of them were surprised when this happened. Some were angry, but none of them were surprised.
For example, one of those people dropped a production database. After electing to not make a backup. Twice. He was angry that I fired him. The only valid criticism I am willing to accept here is around the question of why that engineer had access to the production database. And that's a valid question. The answer is not good. Mistakes were made. I learned.
The upshot is that you probably aren't going to get fired. So don’t hide your light because you’re afraid you might get canned. Fortune favours the bold.
Wherever possible, I default to open. I will tell you stuff if you ask. I will tell you stuff if you don't. I won't lie.
If I can tell you something, I will. If, for whatever reason (privacy comes to mind, there might be others. Stock market stuff, perhaps), I will tell you I cannot tell you.
When it comes to performance or discussions about your career, I will be equally transparent and honest. Sometimes the best thing for both of us is for me to take off my manager hat and just put on my listening hat. I can do that, when it's the best thing to do.
I'd like the same from you.
What I think I'm good at
I think I'm good at giving feedback, both positive and negative. Sometimes I might ramble on a bit on this front, but I consider it part of my role to share my perspective on your performance, your work, and just about anything else.
I think I’m good at helping people understand their own performance. If I’ve done it correctly, any year-end evaluation process will not come as a surprise to you. You’ll already know because we will have been talking about it all year, and you’d be able to measure your own progress toward the goals we set together.
I also like to think I'm good at acting in a way that is consistent with my stated values. If I'm not doing so, then I also think I'm good at being called out for it. If you catch me being inconsistent, call me out.
What I think I'm not so good at
I tend to tell people what the objective is, while maybe not always providing enough direction on how to achieve that objective. There are reasons I do this, and it is on purpose, but I should be more sensitive to which situations might require more personal attention and provide it. I'm definitely getting better at it, but it's still a known failure mode, and you should be aware of it. A good mitigating strategy is to have a candid discussion about it with me if you feel I should.
I'm also not good with people who express opinions without being able to back them up. Double so if they're a jerk about it. Possibly triply so, in fact.
Also, the number of years you’ve done something is a really terrible data point to back up an argument. If you have to resort to ‘I’ve been doing this for ten years and...’ then you don’t have a case. I’m not discounting your experience - in fact I really value that experience! - but I will not accept it as a sole reason we should do something. And neither should you.
My philosophy on 1:1s is that they are not for me, they are for you. They are not an opportunity for me to tell you things, they are not an opportunity for me to try to understand how your work is going. If I feel we need to do this, I'll do it outside of a 1:1. Face-to-face if possible.
1:1s are also not for status updates. That's literally something that is best relegated to stand-ups or email or something. Repeat: not for status updates.
1:1s are for you. To cover the topics you feel we should cover. To ask the questions you feel you should ask. To learn the things you want to know. The agenda is yours. Topics can include how to grow your team, how you're doing, your own career growth, anything YOU want to talk about. This is your meeting, not mine. If you don't have an agenda, we can reschedule, or you can invite suggestions for a topic from me, but this one is all about you. You’re the star of this 1:1 show.
We'll start off with frequent, long meetings, and gradually pull them back to whatever cadence makes the most sense. 60 minutes every other week often seems to be that cadence, but whatever works best.
Dos and don'ts
A short list of things to do and not do. Neither inclusive nor exhaustive.
- Do communicate effectively, using data to back up your position.
- Do be bold. Fortune favours the bold.
- Do send an agenda with your meeting invitations. I have been known to decline meeting invites without agendas.
- Do tell me if there's a better way. Be prepared with data. Data wins arguments, remember?
- Do adopt a learning mentality. This is a trait I value above almost all others (Honesty is another one).
- Do own your own career growth. I am here to coach, I am here to help. But it's your career and you have to live it.
- Do guard your time preciously. You don’t get it back, so make sure you’re using it wisely.
- Do have a life outside work. This is so critical I cannot stress it enough.
- Do lead from the front. This means being the change you want to see.
- Don't ask permission. Tell me what you intend to do, bring data to the discussion, and convince me you’ve thought it through.
- Don't assume I know the answer, even if I sound convincing.
- Don't be afraid to ask why. More than once if needed.
- Don't be afraid to make mistakes. We all do. If we're not making mistakes we're not learning. And if we're not learning, we're doing it wrong.
- Don't make excuses. Things happen, mistakes are made (see access to production databases above). That's okay. But own them if they're yours. I'll own them if they're mine. In fact, I’ll own them if they’re yours too, because that’s part of my job. So we’ll both learn.
- Don't do something just because I told you to. Data, remember? It's a two way street.
- Don’t check email or Slack on weekends. That’s your time to recharge and bring your best self to work on weekdays. If we can’t take time off on weekends because we are worried about our systems, we’re not monitoring properly and don’t have a good strategy in place for operating our products, and that’s a problem we should fix.