Remote and distributed work is an unstoppable trend recently accelerated by five to ten years. It allows people to live where they want to live, and people who couldn’t move or regularly visit an office before can find better jobs.¹ Remote work is great for a more diverse workforce, and I’m glad this trend is here to stay. However, it’s much harder to build a shared sense of purpose and build empathy for colleagues. This post exists to help people and teams adapt better to this new era.

In a hurry? Jump straight ahead to the Recommendations.

A New Era

I expect many companies will operate with a hybrid model of partial work from an office and partial work from home. Even if you aren’t sure whether you’ll work from an office or elsewhere in the future, the age of a singular big headquarter per company with everyone in the same place has passed. The new norm will be multiple engineering hubs, fully remote companies, or a mix of headquarter, hubs, and remote work.

It’s been almost five years since I switched to engineering management. I am by no means an expert engineering manager and I’m always looking to improve. However, most managers will define their manager principles in the first couple of years of their management career. I think of this post as the “Nakazawa Management Starter Pack”, and I’m curious how it evolves over the years.¹

In a hurry? Skip straight ahead to the Priorities.

Why did I switch to management?

This question is one of my all-time favorite questions when I interview other managers for a position. Many people tell stories about how they found out that they were really good at helping others grow their careers.²

Welcome to the inaugural post in my new space, which I hope to keep fresh with insightful content. As a front-end engineer and engineering manager, I focused on building developer tools for open source projects such as React Native, Jest, or Metro for the past ten years.

In a hurry? Skip straight ahead to the Principles.

I am restless in searching for a better user experience, and I lose sleep over misaligned pixels. I deeply care about how people feel about the tools they are using every day. This experience informed how I think about building software, and the team I work with lives by several principles we defined together. I am sharing this manifest with you in hopes that it’ll be useful to shape your high-level thinking of developer tooling, too.

Developer Experience or “DevX” is the experience developers have when building, maintaining, testing, deploying, and analyzing software. Think about the tooling you use: Some of them are probably hard to use, slow, and there aren’t any plans to improve them.