The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change

by Camille Fournier

If you want a team that feels comfortable taking risks and making mistakes, one of the core requirements is a sense of belonging and safety.

The culture of fear is pretty common in technology, and it survives best in environments where things are otherwise going well.

We don’t set up systems because structure and process have inherent value. We do it because we want to learn from our successes and our mistakes, and to share those successes and encode the lessons we learn from failures in a transparent way.

You don’t need to find the perfect solution; you need to find something that will get you through to the next milestone, whether that milestone is the next release, the next growth spurt, the next funding round, or the next hire.

the unstructured organization either displays characteristics that ultimately make it less self-directed than the members might wish to believe, or is run by hidden hierarchies and power dynamics.

It’s no surprise that we usually end up refactoring spaghetti code when we want to make it scalable, because refactoring usually involves identifying and explicitly drawing out structure in order to make the code base easier to read and work in.

A complex system that works is invariably found to have evolved from a simple system that worked.

Reach through the part of you that is shy about praising people or embarrassed to share your feelings, and go into the part of you that cares about the people you work with.

Without any process, your teams will struggle to scale. With the wrong process, they will be slowed down. Balancing the current size and risk tolerance of your team with the processes at hand is the essence of guiding good software development and operational guidelines.

The processes should have value even when they are not followed perfectly, and that value should largely lie in the act of socializing change or risk to the team as a whole.

There’s nothing more demoralizing than having someone from a completely unrelated area veto a project.

The most important lesson I’ve learned is that you have to be able to manage yourself if you want to be good at managing others.