# Ben Feldman's Manager Readme

**Engineering Manager at Square**

# Motivation for this document

I want an easy way for people who work with me to understand what I value, how I think about problems and how best to work with me. 

# My role

As an engineering manager I see my role as:

- Defining a vision for the team and impactful objectives
- Evangelizing the team and its members
- Hiring and growing great well-rounded engineers

# What do I value most?

**Taking ownership over problems, not implementations**

It is important to understand why we do our work. In taking on any project, no matter the size, I try hard to know the background story so that at the end of the day I have ownership not just over what the code but that the problem is solved. This often leads me to push myself and others to learn about customers, follow through on features after release and to think critically about the work they do. 

**Communication is a 30-way street**

For the people I work with it's just as important to me to understand how they communicate in addition to what they are trying to communicate. This is how we can put people in a situation where they have the best chance of success. Commonly I see this with group brainstorms or technical discussions where engineers are often called on to present technical ideas and defend them. Not everyone is eloquent or can recall information on the spot, many need time and space to present their position I believe if you want everyone to participate, you have to consider how everyone communicates. 

**Give ownership over painful and time consuming issues**

Similar to above, I believe that if there's a time consuming workflow or problem, the best way to fix it is to make it someone's problem. If the release tools are bad, and it takes days to release new code, I would make releases one person's job and tell them to engineer their way out of it.   
  
**Being a good engineer is more than the code you write**

Yes code quality and architecture design are important skills, but they'll fail you every time if you can't present technical ideas, convince others that you have a good vision, and mentor others to realize your vision. No one person excels at everything, but I value these other skills just as much as that great O(1)  line of code you wrote. 

# My Expectations

**Have bad news****? **

Tell me! If a project isn't going well, I want to know as soon as possible and without any spin. Often leadership and expertise are best demonstrated in handling situations that aren't going well. 

Have feedback for me that isn't positive? Tell me! I prefer feedback in emails or person and love accompanying examples of what I could be doing better.

**Need input on a decision? **

I love making decisions and getting involved in technical discussions, BUT, I'd rather you think through the problem and bring topics to me with a well informed decision. There's a time and place for brainstorming, but most of the time I want people to feel empowered to come up with suggestions and present their decisions. 

# Meetings

I rarely accept appointments, so please don't double book me. If I will not be free to attend an appointment, I will decline it. 

**Impromptu**

99% of the time, if you need to talk and you see me, i'd love for you to come talk to me. Headphones in? Come wave. Slack, email, phone, text are all great ways to find me if i'm hiding. I much prefer you come talk to me if I look free than schedule a meeting for a 5 minute discussion. If i'm preoccupied, i'll just tell you to come back later. 

**1 on 1s**

For our 1 on 1s I want to leave technical and specific project discussions aside as much as possible. Generally I feel more people would be in the conversation for these topics and it's not a good use of our time. A good 1 on 1 has us improving our relationship, helping talk through career or personal goals or expressing feedback about the team and company. 

For our first 1 on 1 I'm a big fan of [Lara Hogan's list](https://larahogan.me/blog/first-one-on-one-questions/) of questions.

**Agendas**

The person who calls the meeting should drive the meeting and have a clear agenda. I'm a big fan of ending early, and leaving the room with clear action items assigned to people. 

# Where to focus on your first 90 days?

People: You should have the beginning of a support network. You'll have identified people you can use for help in topics around engineering, culture and career progression within the organization. 

Technology: You should know the nomenclature of the team's codebase and can contribute and test code. You've pushed through several small projects and have taken the time to explore the codebase instead of just sped to complete tasks. You are participating in group technical discussions and contributing ideas to improve the codebase and team workflows. 

Product/Client: You have shadowed our partner non-engineering teams (sales, operations, etc) and understand the big initiatives of the team and how your project relates to it. 

# Personality

- I love puns of all shapes and sizes
- I love food, and my personality is affected strongly at the lack thereof
- I have a puppy and will show you pictures if you ask, or even if you don't