I'm incredibly excited to start working together. I am quite excited you are a part of the team! While this document is not intended to replace personal interactions and developing mutual understandings as we work together. I do hope that it is helpful in giving you an idea about how I think, prefer to work, and my hope(s) for you. I intend for this document to evolve as I do. That does mean it may get out of date. If something seems off or different let me know or open a pull request. I did write this after all, so it can't be perfect. Lastly, these types of READMEs have received some criticism. I think the criticisms are valid, but incomplete. I do not intend to ask you to do all of the work to make our relationship successful, nor adjust your core beliefs to align with mine. My only intent is to put myself out in the open and spark conversation.
We will always have a weekly one on one meeting at the same time, unless there is a P0 issue or one of us is on vacation, for at least 30 minutes. This meeting will serve as time to go over topics deeper than standup or a flyby in the kitchen or slack. I intend to talk about things of substance during these conversations such as career goals, things you may want done differently, or comments and concerns about the team. All of that being said, this is your time and we can spend it how you see fit! It is as much up to you as it is to me to have topics ready for these meetings because I do not plan on canceling or skipping them. Let's make sure to hold each other accountable to this goal.
- People first - I believe that an organization is only as strong as its people. My highest priority will always be to invest in you and the team. You will do your best work when you are happy, safe, and challenged. The most rewarding parts of my job is to understand your "hoodie" plus your "cave" and provide it. I believe investing in space for people to thrive ultimately results in positive business outcomes, therefore it is of the utmost importance. I truly believe in the people over the process as the right approach
- Everyone is important - This can be taken many ways. Our customers matter, and they should be our guiding star. Our teammates matter, and we should strive to learn from them as well as show up for them. The rest of the company matters, and we should always be aware of how our decisions may affect them. Lastly, you matter. Always make sure to take time for yourself. That can mean personal development initiatives, time off, or a walk around the park on a beautiful day.
- Trust - When I think of trust at work, I think of a team member taking on a piece of work and I know it can be done thoughtfully and delivered on time. This will be different for each individual relationship. You may hear me talk about task relevant maturity (a lot). Additionally, this trust is a two way street. I want you to feel that I trust you and feel that you have the autonomy to explore the problem and achieve the result in a way you see fit without needing to seek my approval or validation. You are always welcome to ask for help or a second set of eyes, but I want you to know that I trust you to accomplish the goal. It also means psychological safety for you and our team. You need to feel that you can trust the space we have created to speak your mind.
- Honesty - There is no trust without honesty. We will not be able to achieve that relationship without first being completely honest with each other. This can be about what is going on in your life, what is happening in the company, or just the timeline of a project. I intend to be as transparent as possible with all things, and ask that you try the same.
- Always be shipping - I think there is compounding value in constantly shipping incremental improvements to our codebase. This can be refactors, optimizations, feature work, or bug fixes. Without shipping constantly, the team loses perceived momentum. This can lead to low morale and creativity.
- Challenge the Status Quo - I hope to never accept a pattern or do something "because that is the way we do things". I expect myself and our team to always be asking "why?". Sometimes the answer is sound and apparent, but this approach will help uncover the times it is not and we will all be better for it. This applies to our code, our team processes, and also organizational structure.
- This should be fun - Like I said before, we do our best work when we are happy and engaged. If you are not enjoying your work we should talk about how we can enjoy your work again. Sometimes this could be a new project, new direction, or more learning. It could also be more work from home time or time and space to exercise. Let's figure out what it is for you! I am all about enjoying the journey over the destination. Said a different way, I want to prioritize the process over the results. We will all learn along the way no matter the result. That type of mindset makes a huge difference in my opinion.
- Do the hard thing - Difficult things are difficult for a reason. Something I have learned from my mistakes and successes is that when presented with a difficult decision, the hardest option is usually the correct one. It will be the most impactful in the long term even if it's painful in the short term. It is up to me to ensure it is clear why the decision is being made at the time. If you do understand why I am making a decision, please ask me.
A successful member of our team exhibits the above qualities but also proactively challenges themselves and others. They feel ownership of their code, domain, and company. Therefore, they strive to leave things better than they found them and are constantly learning to improve themselves and those around them through mentorship and communication. Their curiosity leads to contributions throughout the company in whichever domains they're interested in. Curiosity helps drive individual growth, for example, curiosity can be followed to new responsibility. For example, if there is something that you see me doing that you are interested in - ask about it! I would be happy to explain what I am doing and if it makes sense transfer that responsibility to you!
Lastly, but most importantly, our team members are kind and caring for those on the team.
- I like to start early. However, it is not as early as a few years ago. I have a toddler who requires me to hand them off to a caregiver at 9 pm. I start my day after that. By the way, this preference does not mean I am a morning person by any means but it is usually time I find myself uninterrupted. I cherish my time before 10 am every day and try to keep it free if possible. It also does not mean you have to be online early to match my hours.
- Additionally, I sign off at 5:30 pm every day to get home for my daughter's bedtime. I really enjoy that part of my day and prioritize keeping it clear, but am flexible to stay later for a good reason. Because of my family's schedule, I may work late or on weekends infrequently. I expect you to set your own hours without feeling like you need to work mine. Furthermore, I trust you will get your work done, and can set your own schedule accordingly. The ask I have is to prioritize overlap with the rest of the team.
- Take vacation, even if it is a day here or there, or an hour in the middle of the day to go for a walk, a run, or get a coffee.
- Take time at work to pursue things that are interesting to you that may be off our critical path. Let's find time to talk about finding those opportunities for you and the space to pursue them.
- Please, please, please take vacation.
My calendar is always up to date. Please add time to it if you would like, I am always happy to meet formally or informally. I attempt to block all my meetings together. This is usually a double edged sword as it provides more time to focus, but can leave me fatigued by the end of the day. Lately, my calendar has become pretty full. If I do not respond within 2-3 hours on slack please start pestering me however you feel comfortable. This can a strongly worded note, a stern look, or just a slack message. If you are in the office and I have my headphones in please just give me a heads up and I can come right over.
When communicating I prefer to use the following mediums in this order:
- In person/over video - but let's make sure the time is convenient for both of us. If it is not convenient for you I will make sure to find time that fits your schedule or workload.
- Over slack - I think long slack threads can be helpful for future context, but in the moment decision making or collaboration is best served via a video call or in person discussion (to be documented later).
I will do my best to never slack/email you after working hours or over the weekend. If I do, please do not feel pressure to respond. I know that is a tall ask, because I would feel that pressure. However, I do mean it and will give an honest attempt at not putting you in that situation.
I prefer to communicate directly and clearly (but have a hard time doing it through writing). Our time is precious so I prefer to "get to the point". Talking in buzz words is painful so I appreciate being able to speak candidly.
I am always hungry for feedback on what I can do better. I also enjoy praise, but because I don't know how to accept it well - and want to be better for the team - I appreciate hearing about ways I can improve even more. Delivery of this feedback in public or private is fine by me, the only thing I ask is that it is done sooner rather than later!
One of my managers once asked me if I thought my reports could be as hungry for constructive feedback as I am with them. I thought about it for a while, and the answer was, "most likely". Over time I have done my best to improve how I give constructive feedback in both frequency and content. This means more than when something goes wrong, but also coaching and explaining the why behind requests I make.
When I deliver feedback I will make sure to understand your preferred method of receiving it. With those preferences in mind, I will also strive to deliver feedback frequently and rapidly after an event that merits comment. Lastly, I will be honest about how I think you are doing, and I only ask that you trust that what I say is always with your best interest in mind.
- I find great joy in brainstorming a solution together. It can be exhilarating to come to a realization at the same time or watch the light bulb go on for someone else. However, when the lightbulb goes on for me, I may get lost in my thoughts. Ask me to come back to Earth, slow down, and explain.
- I always want to pair program more, and am happy to drive or come along for the ride. I also love pairing with different levels of engineers. I always find I learn something when I am pairing no matter if the person is more senior or more junior. It can be new syntax, a workflow technique, a tool or application, something about them, or a software pattern I haven't encountered before.
- Code review as an educational tool. Similarly to pair programming, I believe code review should be done by all levels of engineers and always results in leveling up both parties. These areas of learning are not always code, it can be mentorship, communication, and leadership as well!
- I want to understand the problems you are facing before we start talking about solutions. This means I will ask a fair amount of questions to start so please hang in there with me.
I like to make everyone happy. This can be difficult when making decisions. I understand that I cannot make everyone happy at all times, and in attempting to do so this can do more harm than good. That being said I do try to ensure that I weigh the costs and benefits to all parties involved. It can also lead to me taking a little bit longer to make decisions, it is also something I am working on.
Most of my decisions are informed by data. I choose the word "informed" intentionally because I don't want all my decisions to be solely driven by data. Context matters. It is important to use qualitative data to inform how you process qualitative observations.
Things will go wrong. That is a fact and while unfortunate it is okay. When something does go south, all I ask is that we quickly diagnose what happened, and find a solution. This can be a fix, a rollback, a status page, or a tough conversation with a teammate. Only afterwards should we retro what happened, then find ways to ensure it doesn't happen again. At no point should we assign blame, there is absolutely no benefit in doing that. My only other ask is that you appraise me of the situation at the appropriate time. That can be during an incident, or afterwards if it makes sense. I too will never assign blame, only look at ways to improve in the future.
- I prefer action to talking. I've been in too many meetings that do not provide value. There is a time and a place to debate potential directions or approaches but I bias towards figuring something out by doing.
- Complacency. To use a tired analogy - I look at growth like a shark. Most sharks cannot continue to live without continuing to swim (Except for a few. If you're interested we should talk about buccal pumping sometime). Similarly, without pushing your boundaries and constantly making yourself uncomfortable you will not grow. It is my job to help you with this, but I also expect it to be largely driven by you, too.
- Negative comments or body language. If something or someone is bothering you let's talk about it. If there is something going on outside of work that is okay! Let's figure out how to balance it with your current responsibilities.
- Inequity in a team setting.
- An old coach in high school once told our team to "stop going palms up". Meaning stop blaming the referee or anyone but yourself when something went wrong. What it really means is accountability. I want to ensure our team has a culture that allows you to feel comfortable admitting mistakes. They are teaching tools and make us better in the long term. If something goes wrong - we should understand and feel comfortable to admit that we made incorrect assumptions or decisions and improve on them.
- Additionally, if you see something wrong, I want you to feel empowered to fix it. Bring me solutions as opposed to problems. If you want to discuss a problem, be prepared to brainstorm how to solve it once we have time to process it.
- Once you get to know me, you will call me a liar when I say I am an introvert. However, in larger groups or with people I am not as familiar with I can be quiet and shy. I am doing my best to be more comfortable in these types of situations. If you notice I am quiet in a larger group I am most likely trying to gather my bearings, I would always appreciate a lifeline in those settings.
- I am constantly struggling with an imposter syndrome that is perpetually moving my set of goal posts. While I don't know if this will go away, it is getting better.
- My typing skills. My school district growing up voted for budget cuts and the typing program went. I'm working on it I promise.
- Use of the words "obviously" and "just". Not everything is obvious to everyone and the word "just" can belittle the significance of an action or event for someone.
- Not eating as many skittles.
- Making the difficult decisions decisively.
- Prioritizing my workload with limited focus time.
- Organizational leadership.
- I grew up outside of Boston, went to school in central PA (where I wanted to be a doctor and we can see how that worked out 😬), worked in the Northeast Kingdom of New Hampshire, and now live in New York. My family is usually in Rhode Island and my wife's family is from New Jersey. Hopefully this explains something about me, though I'm not sure what it might be.
- I like to use vim but also VS Code.
- More often than not I'd like to be surfing.
- I have a 1.5 year old daughter named Winfred aka Winnie aka Freddie aka Squishy. I am also the supporting character in our almost 2 year old Portuguese Water Dog's story. His name is Obie and is the epitome of controlled chaos. I love them dearly and be careful if you ask me about them or want to see photos. You will get what you asked for in full.