adamgotterer / manager-README

A quick start guide for how I think, work, and lead

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

My README

What on earth is a manager readme!? Think of it as a quick start guide for how I think, work, and how you and I will work together. It includes an overview of my personality, leadership philosophies, and expectations. It's not a replacement for actually getting to know each other but a way to accelerate our working relationship. However, I do look forward to actually getting to know you!

This document is a living breathing document and will be updated as my philosophies change, I learn things about myself, or feel like there's something you should know.

Disclaimer: This README is about me and me alone. It does not represent the views of anyone else at Common.

My Role

As the CTO of Common my responsibilities are:

  • Hire and retain top talent (that's you!)
  • Build a great engineering culture and organization
  • Disseminate information
  • Set and provide context
  • Define a long term road map and vision for how Common uses technology
  • Review and iterate on our process and technology
  • Mentor and help you be successful at your job

I'm here for you. I'll do what I can to provide opportunities for learning and personal growth. This is your career and I won't tell you what you should do, but I'm here to guide you and offer feedback and advice. I'm here to help you achieve your goals.

Since 2008, I've been managing and leading engineering teams and contributing varying amounts of code based on the role and stage of the company. I'm an engineer by trade and have been writing code and shipping software for a long time. I love coding and miss it at times. I do my best to stay relevant and close to the technology. These days, the closest I get to writing code in the critical path is contributing to architecture discussions, jumping into a PR/slack conversation to offer my 2 cents, or pair programming when someone on the team needs some partnership. I can provide an outside perspective but won't be working on your project day-to-day and may not know all the nuances. I can be a good sounding board and have informed thoughts.

At the moment, I'm not making many code contributions to Commons code base, I spend a small amount of time on the occasional side project and in the future hope to dedicate a small amount of time to experimenting with ideas, building tools, or making small improvements. I very rarely, if ever, will write code in the critical path.

One on One's

If you are one of my direct reports I've added a 30 minute weekly 1:1 to your calendar. This is your time. Feel free to reschedule it to a time that is best for you and adjust the length and frequency as you see fit. If you feel like an hour is what you need, lets meet for an hour. If you'd prefer to meet every two weeks for 30 minutes, let's do that. At a minimum we should try and meet for at least 30 minutes every two weeks.

If you report into one of my direct reports I've added a 30 minute monthly 1:1 to your calendar. This is your time. Feel free to reschedule it to a time that is best for you and adjust the length as you see fit. If you feel like an hour is what you need, lets meet for an hour.

Since this is your meeting, I expect you to drive the agenda and come to the meeting with topics to discuss. It can be difficult to come up with topics in the moment, so I encourage you to write down topics throughout the week and send them to me a few days/hours before we meet. The earlier I get them the more time I have to think about a response. Don't save time sensitive or important things for our 1:1, we should chat about that sooner.

The most productive 1:1's are where we talk about your goals, personal growth, the company, the vision, strategy, etc. Our 1:1 should not be a status update session. We should only talk about status if you feel like I need a status update. I'm happy to talk through the challenges you are having on a project, but you don't need to wait for our 1:1 to tap me for help.

I really enjoy getting out of the office and doing 1:1's outside on a bench, in a park, or over a walk. I have some 1:1's that are always a walk, some that are outside when the weather is right, and others that are always inside. I leave this choice up to you.

My preference is that we have our 1:1 in person, if possible. So, if you aren't in the office please reschedule it for an open slot on my calendar when you will be back in the office.

Lattice

You will receive an invite to Lattice, a platform we use company wide for managing feedback, reviews, and status updates. Please complete your Lattice each week on time. I prefer my direct reports to submit it at least a day before our 1:1 so that I have time to review it. It will ask you a few questions about what you are working on this week and last, if you have blockers, and a few other questions that are helpful for me.

Feedback

I believe in timely feedback. I won't always wait until our 1:1 to deliver it. I'm pretty blunt and don't shy away from a difficult conversation. I hope that you'll be comfortable giving feedback to me as well. I want to know when I make a mistake or screw up. Tell me so that I can learn from it and not do it again.

We won't always agree on everything. It's important the conversation remains productive and level headed. The sooner we learn how to disagree productively the sooner we will trust and respect each other. We don't make meaningful progress by always agreeing with one another.

If you want feedback on something specific, just ask.

If you can give me feedback in-person, I'd prefer that. If you're only comfortable starting a discussion through email or over Slack, I would rather you do that than not bring it up at all. If you're not comfortable giving me feedback yourself, please give it to someone above me who can anonymously relay it to me.

Similarly, if you have feedback for a team member, I encourage you to give it to them directly. If you're not comfortable doing so, please feel free to relay it to me to pass along. If you want to give direct feedback but aren't sure how, let me know and we can talk through it.

My Schedule

My calendar can be quite intimidating and is often a sea of meetings. Don't be afraid to book time or interrupt me. I'm very interruptible. If my calendar is full send me a message and I'll likely be able to move something around. If it's urgent let me know and I'll drop what I'm doing.

From time to time you'll see something marked with DNS (Do Not Schedule) on my calendar. This is reserved for times I have appointments, personal responsibilities, or small chunks of time I need to focus, prepare, or complete something.

I follow the headphone rules for engineers. If you are wearing headphones I won't bother you. That rule doesn't apply to me. If I have headphones on, it does not mean I am "in the zone" or expect to not be interrupted (I'm probably just enjoying some music). Feel free to get my attention. If I'm about to run off for a meeting I'll let you know and we can figure out a better time to chat.

Working Hours

I'm usually in the office around 9/9:15am and leave between 6pm and 7pm. The rest of the team starts their day at varying times ranging from 8:30am to 10:30am and leave at 6pm or later.

I'm more interested in output and impact than hours in the office. You're an adult and should decide what work life balance / integration looks like for you. With that said, you are working as a part of a team, so I ask that you have at least 4-5 hours a day of overlap with the rest of the team and that you clearly communicate your availability.

I love what I do and sometimes I work in the evenings or during the weekend. I don't expect you to. I don't mute slack notifications to my phone and I check email regularly. During off hours I filter incoming messages and will reply if it's important, I'm not busy, or if it only requires a quick response. Outside of working hours I often think of ideas, questions, or solutions. This might manifest itself in an email, comment, or slack message directed at you. I don't expect you to reply until the next business day unless I call it out as urgent.

Meetings

I value face to face discussion / debate and find meetings are sometimes the most effective way to disseminate information or to make a decision. I respect your time and try to be thoughtful about whether we actually need a meeting and when I schedule a one. My goal is to schedule meetings when they will be the least disruptive to your schedule. It's not always possible to find a good slot that works for all attendees. I apologize.

I use Clockwise to manage some of the meetings on my calendar. It's a tool that optimizes for stretches of focus time and automatically schedules / reschedules meetings to the time that is best for all attendees. The more people on the team who use it the smarter it gets for everyone. I recommend installing it and customizing it for your desired schedule.

If you find yourself in too many meetings come talk to me and we will figure out if they are all necessary. We try not to be too meeting heavy and I regularly review the recurring meetings on the teams schedule and I'm not afraid to kill unproductive or unnecessary meetings.

My Expectations of You

  • Default to: what is best for Common?

  • Do amazing work! But you shouldn't strive for perfection. I'd rather see something live and providing value to the business then stuck because a better algorithm/pattern/optimization/etc. was identified. That doesn't mean you shouldn't improve your code, it just means you can ship something that meets the definition of done and make additional improvements after it's released. Find the balance between good enough and perfect.

  • Constantly be asking yourself if you are using your time well. Are you working on the right things? Does it help the business and the departments objectives?

  • If you see something that doesn't make sense, call it out. Challenge architecture decisions, over engineering, user experience, and focus. Be constructive and be kind, but never hold back.

  • When people email you they expect you to read and reply within a day. When they send you a slack message or @mention they deserve a reply within a few hours.

  • I encourage the team to disagree and come to a consensus. When a consensus can't be reached I can be asked to step in to mediate or make a decision.

  • I love data. I prefer to make data driven decisions. When there is no data I go with my gut or try to make a calculated decision. I'm wrong and make mistakes sometimes. I don't expect you to always be right. I'd rather make a decision than not have a decision.

  • When I ask you to do something that feels poorly defined you should ask me for clarification and a call on importance. I might still be brainstorming. These questions can save everyone a lot of time.

  • I do my best to stay on top of things. But occasionally things fall through the cracks. Let me know if you are waiting on something from me.

  • Part of my job is being a router of information. I hear and see a lot of things. I do my best to disseminate information. If there's something you want to know about, just ask. If I don't know the answer I'll point you to someone who does or I'll find the answer for you.

  • If you make a mistake you won't be blamed. But please bring that mistake to my attention as soon as possible so we can address it. We will also discuss ways for you to learn from the incident.

  • Treat people right, I have a zero-tolerance policy for being rude, abusive, or bullying. If you are on the receiving end please let me know immediately so I can handle it.

  • If I'm moving too quickly ask me to slow down.

My Philosophies

  • I believe strongly in iterative development. Shipping small things and making incremental improvements. Stay away from big bang projects where you go off and develop something for weeks on end and then release it all at once.

  • Everything is a test. We test code, we test ideas, we test processes. Some will work and others will not. The things that work we will iterate on and the things that don't we will change or eliminate.

  • Nothing's sacred. Just because something was done a certain way before doesn't mean it's the way we should do it now. Don't be afraid to change things up. But first understand why it was done that way, there might be some context you need.

  • No owners, just maintainers. If you can make a worthwhile improvement or change to an area you aren't familiar with, you should.

  • Code was meant to be changed. Don't take it personally if someone changes yours.

  • Quality assurance is everyone's responsibility. I don't believe in hiring QA people as a dedicated role for engineers to throw work over the wall to.

  • I strive to hire people better and smarter than myself.

  • Code that doesn't reach production and provide value to customers or stake holders is waste.

  • I believe in the four pillars of happiness: having a purpose and meaning, feeling as though you are in control, feeling as though you are making progress, being connected to other like-minded people.

  • I prefer proven stable technology over the shiny new thing. I also believe in the right tool for the job.

  • I'm very transparent and open. I hope you can be as well.

Personal

I'm very open about my life. I enjoy telling personal stories and talking about my experiences. Your personal life is yours and you should share as much or as little of it as you like.

My wife Jessica and I have two boys, Nate and Cameron (we call him Baby Cam), and a Cavapoo named Sgt Pepper (we call him Sarge). I love strategy board games, Settlers of Catan is my favorite. I enjoy eating and trying new foods. I've eaten a bunch of weird things I can tell you about if you're interested. I enjoy traveling. The last 3 big trips I took were to Thailand, London, and Italy. I've been snowboarding for almost 20 years. When I'm at my desk I'm usually listening to music. I like classic rock, 90's/2000's punk/ska/rock, jam bands, indie electronic, and modern rock.

Some things you should know about me:

  • I try not to take life or myself too seriously. I like to joke and mess around. I try to make my presentations fun. Let's try to laugh, have a good time, and build something amazing together.

  • I try not to say "no" too often. I prefer "yes" or "yes, but not right now". Don't mistaken this for me over committing to things.

  • When I get excited or impassioned about a topic I'll start talking faster. Tell me to slow down if you can't understand me (my wife does!).

  • I like to optimize stuff. I optimize code, process, and myself. I'm always looking for ways to improve and make things better.

  • I think best by staying cool, calm, and collected. When we are in a crisis, you won't see me freaking out. Don't interpret this as me thinking the crisis isn't important.

  • I have an opinion about a lot of things. I try not to impose that on you too often. But if you ask I'll give you mine. I'm also always open to a discussion and hearing about alternatives.

  • I have high moral standards and strive to never ask you to do something that makes you feel uncomfortable. If I'm somehow in a gray area, please let me know.

  • A year or two ago, I look a personality test and was categorized as an ENTP. In the same way I don't believe someone can be defined by their astrology sign, I don't think someone's personality can be grouped that simply. With that said, I feel like a lot of what's been written about ENTP is accurate. So if you're curious about my personality type, google it.

--

Thanks for reading!

I'd love your feedback: Was reading this valuable? Did I miss anything critical? Anything that wasn't very useful?

About

A quick start guide for how I think, work, and lead