A readme on my management philosophies
This document is an introduction to me and an overview of my philosophies on managing software engineers. This document, like my philosophies and practices are subject to change and growth. In fact, I would be disappointed in myself if my views did not change and grow as I receive feedback, recognize patterns and try new things.
I have been coding in some form or another for 20+ years. I have been working with software engineers — pairing, thought-partnering, managing — in some capacity or another since 2008.
I love self-teaching and improving my skill in crafts, including: software, woodworking, home renovation, gardening, cooking, bicycle tuning, beading, macraméing, knitting, script writing and acting.
I get major nostalgia for 1990s video games. I love commuter-cycling and I think every major metropolitan city should focus on better cycling infrastructure. More about me and my interests here.
I believe that users matter. I believe that bottom lines matter, be they net income or some non-conventional measure. However, I believe that the people and teams building the product matter most.
I believe that focusing on people and helping them find meaning and fulfillment in their work promotes business success. That is, happy and fulfilled workers performing meaningful work play an incredibly large part in happy users and healthy bottom lines.
My job as your manager is to help you define success and then actualize it.
I value you having ownership of and autonomy over your work. It's my job to thought partner with you and provide you with feedback. It's your job to do your job (and not have me telling you how to do your job).
I believe that employees' personal fulfillment and self actualization leads to business success. Learning, growth and feedback are key parts of this. This is one of the reasons why I value intellectual curiosity as a trait. Intellectual curiosity intrinsically motivates people to learn, grow and realize their potential. People also perform better when they are intrinsically motivated by their work.
More here on fulfillment and Maslow's hierarchy of needs.
Helping catalyze your intellectual curiosity is an important part of my job. Think of me as your champion towards self-actualization. I will encourage you to approach your goals and challenges with a growth mindset.
When I check in with you about your progress towards your learning and growth goals, I will often refer to the categories from Bloom's taxonomy. As an example, as one of the junior developers I managed was learning React, we set goals around analysis of current opinions of React best practices. The broader objective was get to a point where the developer could evaluate the existing diverse opinions and contribute to the dialog by creating his own opinion on React best practices.
More on experiential learning, growth mindset and reflection here.
Integrity is a value that I hope goes without saying. Performing your duties morally, sincerely, and transparently is foundational to our relationship. A relationship of trust between us is incredibly important for us to work together well. Acting with integrity is a great way to build that trust; acting out of integrity is a quick way to break down the trust.
I will always be transparent with you when I can. If there are things I cannot share, I will tell you why. If you ever feel that I am acting out of integrity, I want you to call me out on it.
I am an avid protector of your personal time. I expect you to work the hours you have specifically designated for work. I explicitly expect you not to work on work-related tasks outside of those hours.
Having time and space to "turn off" work pressures is important to your personal wellbeing and your productivity when you are working.
I always expect you to prioritize your family and your health (mental and physical) above your work.
I want to spend one-on-one time with you at least once a fortnight. I'm totally happy with a weekly cadence if you prefer it.
Our one-on-one sessions are a great time for you to:
- ask questions
- give me feedback
- brainstorm your personal goals with me
- report progress towards your goals
- communicate any frustrations you have
- ask me for things/actions that will make you happier and more fulfilled
...and for me to:
- listen
- give you answers
- ask you questions
- give you feedback
- brainstorm your personal goals with you
- help you unpack your frustrations and strategize on how to solve them
- write a list of takeaway tasks for me to do
- challenge you to grow
It's easy for software engineers to get frustrated with pressure coming from product managers and business stakeholders ("this features needs to be delivered yesterday!"). It's easy for product managers and business stakeholders to get frustrated by pushback from software engineers ("it's not as easy as 'just putting a new button there'...").
Building empathy between these stakeholders helps them understand each other's roles, pressures, frustrations and constraints.
For more on this topic, check out the presentation I gave to Flatiron School.
First and foremost, if you are on a maker's schedule, I will do everything I can to respect it. I encourage you to turn off Slack notifications when you are planning on getting into flow state.
I prefer face-to-face communication, whether in person or over video chat. However, asynchronous comms can be more efficient and less disruptive. For collaborative technical tasks, whether it's domain modeling or pair programming, I much prefer to be in the same physical space as my colleagues.
If a question or discussion merits a short response or a brief dialog between several people on different schedules, I prefer a medium like Slack (DM or group DM). In this medium, for folks on a maker's schedule, I expect a ~4 hour response time. For folks on a manager's schedule, I expect a <1 hour response time.
For questions, discussions or announcements that are a) more important or b) require more thought and a more thorough response, I prefer email. Depending on the email, I generally expect a response time of between 12-36 hours. However, I find it's a good practice to clearly set out the expectation of whether and when to expect a response.
Particularly for longer forms of written communication, I aspire to write in plain language, with sections clearly labeled and the most important topics at the top.
Feedback can be hard to give and receive. But it is well worth the effort. I think it is perfectly natural for a receiver of feedback to feel defensive (particularly initially) in some cases.
My framework for feedback is as follows:
- Build inter-team and inter-personal trust alongside a culture of feedback.
- Train people to ask for feedback and be open and vulnerable to that feedback for their own benefit and growth.
- Only ever give feedback for the genuine benefit and growth of the recipient (kindness).
- Give feedback that the recipient can act on (specific and actionable).
- Recommend that people take time and space to digest and reflect on feedback. Reflect seriously, honestly and vulnerably on feedback, with a growth mindset.
- Given genuine reflection, self-parse the useful feedback from the rest. Be slow to dismiss feedback about which you feel defensive. This often provides the biggest avenue for growth.
- Work actively to integrate the useful feedback into your daily life and habits. (That is, grow!)
I invite you to give me regular actionable, specific and kind feedback to help me in my own growth.
There are many issues within software engineering upon which I am interested in iterating.
Software engineers love releasing features. (Product people and business people love feature releases, too!) I'm a big advocate of optimizing for makers' schedules for software engineers. That can involve shielding engineers against other stakeholders or staunchly defending process. While it would be nice for every chunk of the working day to allow for engineers to get into the flow on feature implementation, there is often work unrelated to implementation.
As an example, if engineering team members present technical presentations to each other on a recurring basis, how do you balance preparation for presentations against implementation goals in the current sprint or work cycle?
Various types of debt can be the bane of a developer's existence — it can grind development velocity to a trudge and decrease morale. There are various approaches to paying down debt, from greenfield rewrites to feature freezes to slow-and-steady pay downs.
After watching Sarah Mei's keynote at RailsConf 2018, I've grown fond the analogy of software development being like furnishing and maintaining a home. In that vein, I like the idea of taking a very messy home and creating plans, rules and habits to be tidy rather than dramatically decluttering. (Replace "home" with "codebase" or "product feature set" or "domain model".)
I haven't come across a silver bullet for debt (there likely isn't one). I am interested in iterating on creative ways to manage and pay down debt.