Motivation for this document

This document is a living document that changes for the better as I do. I aim to be as transparent as I can be to enable others to work with me and understand my motivations and intentions.

My role

My responsibility is split between the organization and my teams. My primary responsibility is the delivery of commitments by agreed upon timelines. I always look to implement ways to improve efficiency, performance, and reliability of the software delivery teams that I lead. The primary way I do this is by growing members of the team by giving them challenging projects with clear accountability and metrics. I also build the skills of teammates by making sure they have the skills and knowledge for our current state as well as our future goal state.

I make it clear that I’m always available for questions. Uncertainty should never block smart people from doing their best work. I strive to provide all context for work, so issues are a rare occurrence.

I evaluate the team’s performance based on quantitative and qualitative metrics. Quantitatively, I track defects caused by new work. I track metrics like code test coverage and performance benchmarks. I also follow the cycle time of work completed to uncover bottlenecks or areas ripe for improvement. Qualitatively, the team’s cohesion and engagement will be measured quarterly. Any engagement or team cohesion issues left untreated can spiral into dysfunction very quickly. My job is to stay connected to the team’s daily work so I can head off problems as promptly as possible.

I lead by example. I would never ask someone to do something I would not do myself. I’m a big believer in team communication. Teams need to spend time explaining their design decisions, their code clarity with comments, and onboarding materials for new team members. Clear and concise communication is a skill that will serve everyone for their entire career.

What do I value most?

I value high standards from my teammates. I strive to do the best that I can do for all of my work. I continually study and train to develop my skills and knowledge to further my impact. I also value automation because I know it’s a force multiplier for teams over time.

My Expectations

I’m available any time to help the team by any means. The only exception I have to this is during PTO from work. I need time to disconnect and recharge throughout the year.

I expect my team to give their best each day during work hours. I don’t expect after-hours work except in situations caused by our own mistakes. As a team, we committed, and we must deliver on that commitment as a professional software delivery team.

1:1s

At a minimum, I hold 1:1s with all of my direct reports every week for 30 minutes. The 1:1 is a chance for the IC to drive the conversation to whatever they feel is more pertinent to them. You own the 1:1, but that doesn’t mean you do all the work. A conversation is a partnership, and I will come prepared with content. However, sometimes, everything is going fine, and you might not have anything to discuss. I will always have something to talk about regarding team improvements and growth opportunities.

Personality quirks

I am passionate about my career and doing a great job. I’m always working on bettering myself. You might find me sneaking away to read on my Kindle during lunch or skimming through the latest news in my news feeds.

Some people might perceive me as negative because I’m always focused on what needs improvement. I’m not cynical or pessimistic; I’m very focused on continually improving myself and the things around me. I ask my teams and peers to help check me whenever they see this behavior.

Lastly, I keep a separation between home and work. I love company outings and socializing with my coworkers. My work relationships are critical to happiness in my career. However, when I go home, I devote myself entirely to my family. Generally, this means I don’t spend weekends hanging out with any coworkers on the weekends.

Where to focus on your first 90 days?

Whenever you join a team that I lead, you’ll find clear and concise onboarding documentation in Github written in Markdown. I create a team repository with team artifacts and working agreements. The artifacts include engineering best practices for the languages and frameworks that we use. The team and I continually iterate on how we operate for maximum effectiveness through issues and pull requests. Github is an excellent tool for this because it naturally facilitates discussions around changes to an idea via pull requests. Github Issues raise particular concerns with artifacts. Github is also a natural choice for an engineering team that uses Github on a daily basis.