Management Philosophy

Posted June 16, 2017 by Gordon Radlein

A common question I get, since becoming a manager, is about my management philosophy.

I quickly learned when people ask they’re usually not looking to wax philosophical on the essence and meaning of management. Instead, they’re typically looking for a new perspective on the following definition of management philosophy: Sets of beliefs as used by an individual in a management position to guide the decision making process.

Since managers apparently need a philosophy it’s unsurprising that most of the people asking are other managers. So to help out my colleagues (and because I need execute on the blog post I’ve been promising since 2013) I’ve decided to share my current answer to the question of management philosophy. The five principles I rely on to help guide my decision making. If you’re a manager and haven’t yet thought about your approach to management, perhaps it’ll help get the juices flowing.

A brief disclaimer
I’m a big believer in the power of context and its influence over almost everything we do. This means the principles I’ll enumerate below are a reflection of my current thinking around management given my experience thus far and are certainly not set in stone (in fact, this list was only four things long till mid 2016). I retain the right to add, edit, or delete these tenets as I continue to learn and experience new things. Consider the permissions on what follows to be set to 755 (-rwxr-x-rx).

A little more on context
This set of principles was built mostly from my experience as a front line engineering manager. However, having worked with a variety of senior managers, I suspect they’re applicable to managers at all levels.

And now, without further ado, I present to you Gordon’s Five Tenets of Engineering Management.

Trust above all else

Everything starts with trust. In 2016 Google went public with their work on Project Aristotle, a multi year quest to discover what makes teams effective. Project Aristotle identified five key dynamics of successful teams and at the top of the list is the notion of psychological safety (when people feel safe taking risks in front of one another). Trust is a necessary precondition for psychological safety. In fact, I tend to think of psychological safety as the condition that arises when the graph of interpersonal trust on your team becomes fully connected.

Given the above, it’s hopefully obvious that trust is something you should be working to build from day one. If your reports don’t trust you, the human with (probably) the most direct impact on their immediate career growth, you can kiss that dream of psychological safety goodbye. Further, as a manager it’s your job to make good decisions with limited information. A lack of trust puts you at high risk of making those decisions with information that is stale or just plain wrong.

Never stop working on trust. People turn over and context and expectations change. And once acquired, if lost it can be almost impossible to recover. How to build and maintain trust is a post in itself and many have written on the topic. Find what works for you and get to it.

Feedback feedback feedback

Provide feedback early, often, and in all directions, and set the expectation that your reports do the same. A wise manager of mine once told me feedback will make or break you (please read that post if you haven’t already). Feedback is how people learn what works and what doesn’t (whether you’re getting it from a colleague or a computer). This is true in all dimensions of your life and is how you’ll build effective relationships with your managers, peers, and reports. Moreover, feedback is how you get early warning on potential problems, be they people, project, or organizational. It’s how we reduce the fog of war and and increase confidence in our situational awareness. Note that there’s a circular dependency between feedback and trust. How to improve one by leveraging the other is left as an exercise for the reader.

Give space to succeed (or fail)

If you give someone a script, they’ll follow the script. Handing your reports a script precludes them from innovative work and if they have no space to innovate they will only ever meet your expectations.

Actually, that’s not true. Eventually they’ll leave to save their sanity.

Generally, folks writing software for a living are doing it because they have some proclivity for designing and building things. Like all works that take shape in the mind, it’s a fundamentally creative endeavor. Removing the creativity from someone’s creative endeavor is not only a (terrible) accomplishment, but one that removes any reason they have to continue working on said endeavor.

Neither you nor your reports know what they’re capable of until they’re given the opportunity to find out. For that they need space and enough trust to take a risk.

A little structure goes a long way

Too much process is tedious and too little process is stressful. One of your tasks is finding the balance. Well understood mechanisms for communication, decision making, operations, and administration reduce cognitive overhead. Your team isn’t going to be putting together project proposals every day, but when they do they shouldn’t have to figure out what needs to be done from scratch each time. Same goes for reporting work, deciding which competing implementation to move forward with, how to interact with external customers, and a host of other common actions performed by engineering teams.

Having well defined processes for common ad-hoc tasks is like serving a read heavy workload via a client side write-through cache vs. forcing the client to make cross Atlantic trips to a poorly indexed database on each request. You should do it.

Always have a vision

A clear destination, or vision, provides purpose and incentive for your team’s work. Without one you’ll soon start to wonder why it never feels like you’re making any forward progress.

This is my most recent tenet. Your team is on a never ending journey. This journey never ends because as your (industry|market|customers|company) changes your team’s destination changes with it. I like to think of it as moving from waypoint to waypoint on an ever expanding map. Your responsibility is to make sure you and your team are clear on the coordinates of the next waypoint. How you choose the next waypoint and the exact route taken between where you are and where you’re going is something changes from team to team and organization to organization, but if anyone gets lost because they were working with the wrong coordinates, that’s on you.

And there you have it! What’s your management philosophy?