— management — 3 min read
This is the start of my Manager README. If you're just starting out in management, or looking for help managing a remote team, hopefully my experience can help.
I currently manage the Front-end and QA teams at Measurabl. I recently helped launch Kingston Lane while at Native Axis, a fully remote startup where I was the head of engineering for two and a half years. For over ten years I have been a Front-end Developer and at almost every position I have been the lead developer; responsible for mentoring junior developers, performing code review, defining the tech stack, establishing code design pattens based on best practices, etc.
During my career I have conducted hundreds of technical screens and interviews. I have helped design the hiring process at multiple startups. I have had regular 1:1s with direct reports on a weekly basis for the last three years. I've worked with great and terrible managers throughout my career and I've learned from all of them.
One of the most important lessons I have learned is that software development is 20% coding, 80% communication with other people. Even the code we write is mostly for other developers. The computers break it down into ones and zeros anyway. All of our organization, patterns, and variable names are only for our peers and future selves. The better you can be at communicating through code, pull requests, email, Slack, video chat, and in-person, the more successful you will be.
Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. ...[Therefore,] making it easy to read makes it easier to write. - Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship
When I started at Native Axis, I wanted to create a remote software development company that embraced flexibility and trust in it's employees to enable huge productivity gains. By removing the physical requirements of being colocated, everyone on the team was able focus on doing their best work instead of being distracted and stressed by commuting and sharing office space.
My philosophy on management aligns very well with how remote companies have to function: on trust. I want to work with people that I can trust.
[Y]ou need to learn to manage by expectations rather than by "butts in seat," so make sure you can show trust in those you hire. - Wade Foster, CEO of Zapier
My goal as am anager is to enable them to do their best work without micromanagement. I really like how Help Scout prioritizes "players" (relative to management "coaches") and follows "servant leadership". This aligns well with how I tend to manage my own teams. I believe it is my job to improve the health and productivity of their team through optimism, empathy, and leverage-based thinking.
Although clear communication is key for any company, I think it's the most important aspect of a remote company. Without the nuance and context of body language and tone of voice, it's easy to misread any Slack message. I always assume the best of intentions from everyone else and infuse my communication with optimism to avoid negative conclusions by anyone else.
Empathy is equally important for communication. With every pull request comment I use language like "what do you think about", "have you tried", and "you could also" instead of "you should" or "this is wrong". I think these simple techniques keep people open to receiving feedback.
Leverage-based thinking (thanks for the term Edmond Lau), means focusing on improvements to the development process that allow everyone on the team to iterate faster. These may or may not involve some actual coding. For example:
I have worked with and managed junior engineers fresh from code school, as well as senior engineers with over twenty years of experience. Engineers from either side of that spectrum can be overly confident and inflexible. I would prefer engineers more like myself that are positive, confident but humble, and willing to change their mind or their habits for the betterment of the team and company.
Sometimes I do miss being an individual contributor, but I believe that as a manager you have to give up on many of the "fun" projects to allow your team to enjoy their work and learn from those new experiences. I also do several things to stay close to the code. For one, I review every pull request, so that I'm up to date on the codebase and can share my knowledge with the rest of the team on a daily basis. When I do have time to code, I tend to focus on changes that will boost productivity for the entire team (see "leverage-based thinking" above).