# Keith Peters's Manager Readme

**Director of Engineering at Notarize**

# Motivation for this document

This document describes what I&nbsp;see as my role and how I&nbsp;work at Notarize. I'll try to express what you should expect of me as an engineering manager and director of the engineering team, and what I&nbsp;expect from the engineers and managers I&nbsp;work with.

This is not meant to establish or imply any new process or policy at Notarize or the engineering team. It just describes how I&nbsp;do my job.

# My role

I have two roles - Engineer Manager for the RGB (Retail, Growth, Business) team, and Director of Engineering for Notarize.

As an engineer manager my work is measured by the productivity of the RGB team. Are we completing valuable projects on time with quality work that results in improved business?

As Director of Engineering, I&nbsp;oversee the other three engineer managers for Core, Real Estate and QA. Here I&nbsp;see my role as improving the stability, growth, and productivity of the entire engineering department.

I schedule weekly, 30-minute 1:1 meetings with the managers, and bi-weekly 1:1s with the engineers I&nbsp;manage directly. I&nbsp;also do "skip 1:1s"&nbsp;with everyone in engineering roughly every other month.

My focus currently is inter-team communication and developer growth.

# What do I value most?

I&nbsp;put strong emphasis on professionalism and personal responsibility for your own job. I'm not interested in micromanaging you. You were hired for your skill and ability and professionalism and I&nbsp;trust that you will do good things. The ideal engineer or manager is one who is not just doing the minimum she or he can get away with, but is actively looking at how they can improve things for the company, help their fellow coworker, improve communication, define and enforce best practices, and grow themselves and their teams.

I&nbsp;don't value a contest of who can put in the most night and weekend hours. I'd much rather see engineers be 100+% productive on normal work hours.

# My Expectations

If you ever feel the need to talk to me outside of a scheduled 1:1, reach out via email or Slack and I'll meet with you as soon as I&nbsp;am free. I&nbsp;know that engineers like to work in the zone, so I&nbsp;will strive to use email to contact you on less urgent matters and Slack for more timely issues.

I&nbsp;don't expect anyone to be perfect. I&nbsp;do expect people to be professional, own up to mistakes or slips, let people know about them and have a plan for how to fix them.

I expect that our engineers are professional and adult enough to be able to work out conflicts between themselves. I am totally willing to help iron out disagreements, but I don't have a ton of tolerance for excess drama.

A tightly coordinated team knows where all of their team mates are at any given point, and what they are working on. We are pretty flexible here in terms of schedule and remote work. But people should strive to stick to a schedule that mostly aligns with the other members of the team. If a non-remote employee is not going to be in the office (taking a day off or working from home), their team should be aware of that in advance. Remote / WFH employees should be reachable on Slack and email.

# 1:1s

When I&nbsp;do a 1:1 with a you, the floor is yours for the first part of the meeting. It's great if you are able to come prepared with things that you'd like to talk about. I&nbsp;don't really need or expect a general project status update, but if that's what's on your mind, I'll listen. I'd love to hear about any struggles you might be having, ideas for improvements, or your goals. I'd also like to learn more about you as a person (and have you know me more), so we can talk about family, vacation, side projects, whatever you have going on - provided you are comfortable doing so.

I'll try to provide feedback in each meeting as well. This is an area that I need to get better at - thinking about and delivering timely feedback - so feel free to push me on this point. And if there is anything you think I&nbsp;can do better at, any way I&nbsp;can help you, any questions I&nbsp;can answer for you, this is the time for those.

I&nbsp;schedule 1:1s for 30 minute slots. Sometimes there isn't that much to talk about and we'll end early. Sometimes we might go long.&nbsp;

# Personality quirks

When I&nbsp;was younger, I was painfully shy. I've gotten over that completely. I'm still not what anyone would call an overly talkative person, but I&nbsp;don't have a problem talking to people in general. So if I'm not reaching out to you enough, feel free to reach out to me.

I have a very dry sense of humor and have a tendency toward understated sarcasm. So take anything like that with a grain of salt. If I'm actually providing you with critical feedback that I&nbsp;expect you to take to heart, it will be in a straight, non-sarcastic tone.

My tech career has mixed being an individual contributor with a lot of educational efforts. Writing tutorials, blog posts, books, speaking at conferences, teaching workshops, videos, etc. I&nbsp;love teaching and making complex subjects understandable. I've also found that the best way to learn something fully is to try teaching it to someone else.

My professional background is very heavily based on front end development, so in terms of back end and infrastructure, I&nbsp;lean very heavily on the other mangers who have stronger backgrounds there. One of my goals is to become, if not proficient, at least more conversant in that area.

# Where to focus on your first 90 days?

If you are just starting on the engineering team here at Notarize, you probably have a lot to learn. You should have a manager who will work with you closely and start you on an onboarding checklist. Working through that checklist and getting productive on small tasks while you build your knowledge is all that is expected at first. Err in the direction of asking for help sooner than later in the beginning. Of course, engineers want to figure things out for themselves, but don't spin your wheels too long.

Within your first few days or week as a software engineer, you should have your environment fully set up and have&nbsp; submitted and merged a pull request for some small feature or bug fix - ideally, a few of these. QA engineers should be set up and actively testing with a few tickets written. Automation engineers should have fixed some breaking tests or written one or more new tests.

Within the first 30 days you should be working mostly autonomously.

Within 90 days you should have a good grasp of a large part of the code base as a software engineer, or understand most of the functionality of the app as a QA or automation engineer and be able to originate improvements on your own.