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.
Why should you listen to what I say?
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.
Lessons Learned
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
What do I value?
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 co-located, 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 a manager 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:
- Adding automated unit test coverage thresholds to every build.
- Upgrading dependencies and picking tools that have quicker build times to remove downtime for developers.
- Staying on top of blockers and distractions that take developers out of their flow. This translates to scheduling meetings in blocks instead of throughout the day and responding to questions or feedback from QA, product, or upper management so that developers don't have to.
- Streamlining CI/CD integration.
- Adding automatic error tracking (Sentry), type checking (TypeScript), and style guide enforcement (ESLint).
- Facilitating mob programming (like pair programming, except with the entire team).
How do I deal with different levels of experience?
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.
Do I still still code?
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).
Follow me on Twitter if you want to hear more thoughts on management and working in software development.