Getting to know me

It’s been a long hiatus since my last post. Many thanks to all who are still tuned in. My last post was help me understand you, where I ask favors from new teammates to understand them better. This post is the mirror piece. I have found it useful to create a document for coworkers to understand me better. I call it the getting-to-know-yuan document.

Write for the audience

My primary audience of the document is my team. It would not be a terrible choice to name it help-you-understand-me, but the name deserves some considerations. Not everyone has asked me to help. What if they don’t need my help? For that reason, I settled on the name of getting-to-know-yuan.

As for the content, I find it helpful to cover my management philosophy and general operating approach. It is also beneficial to supplement with a management handbook which contains tactical advice on how to better work with me. A bonus section is how to tell I am grumpy and how to help me, although I am yet to created my own version of it.

It is super valuable for me to review it from time to time. To some extent, I think the document has provided more value to myself. It reminds me to follow the best practices I created for myself! It is also important to update the document as I learn new things.

Getting to know Yuan

Below is the latest version with confidential information removed. Feel free to tweak and reuse for your own benefits. I cannot claim credit either since mine is also based on many great examples I have seen at Stripe.

If you are reading this, I am really excited to be working with you.

Management Philosophy

My management philosophy is heavily influenced by systems thinking. To me, a manager’s performance is evaluated by the collective output of their team. Therefore, a manager needs to be flexible in doing whatever is needed from them to deliver the desired output. On a high level, to paraphrase Niels, I believe an engineering manager is responsible for creating healthy and well-executing teams:

• Well-executing means:
  • Understand what the business needs from the team, and set the right goals for the team
  • Know the execution status for the goals
  • Help the team unblock when they encounter hurdles
  • Ask for help from their own manager and/or the organization when necessary
• Healthy means:
  • Create an environment of trust so that
    • the manager and their reports can have difficult conversations
    • Disagreement and conflict can be surfaced in a constructive way
  • Make it sustainable so that people stay engaged and don’t burn out

To put it another way, my focus as an engineering manager is on projects and people. I would utilize tools like policies and processes to help with that, but the tools are a means to an end.

Here are a few books that played key roles in shaping my understanding of engineering management:

• High Output Management, Andrew Grove
• Only the Paranoid Survive, Andrew Grove
• An Elegant Puzzle, Will Larson
• The Manager’s Path, Camille Fournier
• The Making of a Manager, Julie Zhuo

Operating Approach

Team meetings

I recognize the value of regular team meetings, including sprint planning, standups, etc. I believe good processes are not designed but evolved, so I tend to rethink each meeting’s value from time to time. For example, here is a story of my previous team on adopting and getting rid of standups.

On a high level, I think the purpose of regular team meetings is to:

• Help with project execution
  • By broadcasting status updates and increasing awareness of each individual project among a larger group
  • By communicating blockers and asking for/offering help
  • By escalating issues and making decisions to address them
• Help the team members bond with each other
  • By checking in on each other and sharing joys and tears
  • By asking for and offering help on key blockers
  • By trusting and empowering each other on major challenges

On a new team, I would like to keep existing meetings running first. In the meantime, I will seek to slowly evolve them to increase the value we get out of the meetings as a team. I don’t think there are universally good processes for all teams, but there are great processes tailored to each individual team.

1:1s

I spend about half of my time preparing for and attending 1:1s. I prepare high-level agendas before 1:1s, and I expect my counterpart to also think about topics to discuss beforehand. I wrote about my learnings to effective 1:1s. For my team members, I also dedicate one 1:1 per month to career conversations.

Planning

I prefer to have long-term visions (e.g. two years) and short-to-medium-term roadmaps to guide execution. The quarterly planning cycle enables teams to be agile, while we also need to execute against a compelling long-term vision to avoid being trapped in local maxima. My usual plan is to refresh team charters yearly to provide long-term direction, and to track OKRs more regularly to drive short-term planning and execution.

Management Handbook

Equity

I believe in equal opportunities among team members. It includes driving team planning and owning projects. It also includes facilitating regular team meetings and participating in toilsome tasks.

Pair work by default

Each work stream should have at least two engineers by default. Exceptions can be made, but generally I find pair-working as an effective way to keep the team focused and to increase throughput. It also helps increase the bus factor over time.

Communications

I think more clearly when reading and writing than during meetings, so I prefer written communications especially when we are about to make important decisions. As an extension, I prefer meetings with written agendas and/or pre-reads. This is not intended to be a replacement for meetings, but rather a way to make meetings more efficient. I do enjoy a healthy dose of unscripted chit-chat too, but I can also ramble a lot - please stop me early!

Feedback

I welcome feedback, particularly constructive ones to help me grow. I prefer giving and receiving feedback in 1:1. Upon receiving feedback, I might need time to think and reflect. That does not mean I disagree with the feedback - I might just ask for some personal space to learn and grow :)

Goal setting

I believe in driving business outcomes via metrics / OKRs. I have a strong preference in democratizing access to metrics so that they are easier to review and to track against. That way we could have leading indicators to tell us when things need attention. Otherwise, we could fall into a trap where we scramble to find metrics after the fact to justify the impact of our work.

Execution

I usually take a hands-off approach for project execution. I will default trust individuals to make forward progress consistently. To gain some visibility into progress, I will usually ask project owners to break down projects into milestones with estimated dates, to send regular updates on progress, and to update estimates when necessary. This practice is to hold ourselves accountable, but more importantly it helps us get better at estimation and execution over time.