# Alan Manos's Manager Readme

**Senior Engineering Manager, Platform at Dandy**

# Why are you reading this?

My intention is to introduce you to my management and leadership style and philosophy and set expectations to help guide the engineers I work with to be successful and productive both now and in the future.

This document is primarily intended to be read by anyone who reports to me, though feedback is welcome from anyone who reads it (a report, my manager, a complete stranger). I appreciate feedback and value the opportunity to implement it. 

I encourage you to hold me accountable to the concepts and promises herein.

# My role

As a manager, my job is to enable the engineers I work with to be the best, most productive and happy versions of themselves. I do this by:

- Mentoring and coaching engineers on professional, technical and business matters
- Planning work out in the open and ensuring that engineers on the team have direct input
- Fostering healthy, collaborative discussions in team meetings and cross-team planing sessions
- Reducing and removing blockers
- Shielding the team from turmoil/whiplash
- Being a technical resource
- Encouraging growth and pushing you out of your comfort zone to learn and explore new things
- Providing or seeking out clarification to remove confusion

You won't hear me talk about the "engineers that work for me". I work \_with\_ the engineers on my teams. We are all human beings with different skills and passions, serving different roles, none inherently better than the other.

# What do I value most?

Work to live, do not live to work.

I will not ask you to do something that I would not do myself (unless I am incapable of doing it).

I've had managers who've said "if you're not making mistakes, you're not working hard enough". While I don't endorse that mentality, I don't view mistakes in a negative light. Mistakes are usually the result of a technical or procedural failure, not a failure of a human being. I believe in and practice blamelessness and encourage all my teams to do the same. Mistakes are opportunities to learn and improve, not only for the engineer that made them, but for the whole team and organization.

Teammates who bring others along. Building proprietary knowledge around a domain is not job security, it's insecurity. By bringing others along with you, it demonstrates strength, confidence and your ability as a teacher. Helping the team get strong as a whole is a net gain for the team and the company. It also enables you to move forward to new and exciting topics.

# Expectations

- Ask questions of me and the team; do NOT suffer in silence
- You will tell me if you think I am mishandling something or could be doing it better
- Be the change you want to see (in the repo) - don't ask others to make changes to the codebase that you can make; if you don't feel comfortable making them, ask for a hand
- Engineers should spend 5-10% of their time on documentation (aspirational)
- Engineers should work to expand domain knowledge and sphere of influence
- Communication is fundamental; speak up if you don't agree with a decision, or if you do
- Let the team and me know when you're available and when you're not (Slack statuses are fine)

# 1:1s

I aim to meet with each report on a weekly or bi-weekly basis for 30 minutes. The time and topics are largely yours. Want to talk about your weekend or your pet? Need advice on a technical blocker or an interpersonal issue with someone on another team? This is your time.

When I bring topics, they are typically about:

- Professional development and growth
- How am I doing and how can I better support you?
- Opportunities for improvement
- Performance management - I believe in (near) immediate feedback. You will never get blindsided during an annual or semi-annual review.

# Where to focus on your first 90 days?

Meet your teammates. These are the engineers you're going to be working with for the foreseeable future. Your ability to work together is crucial to the success of the team.

Come hungry. Learn about the environment (both technologically and from the business perspective). Read the documentation. Don't make assumptions, ask lots of questions.

Early work will largely be shadowing and learning. Be patient, more responsibility and bigger contributions are coming your way soon.

Contribute to documentation where you see gaps.