May 7, 2016.
The first few years of management for me were a wild frenzy. Every situation was brand new, and I puzzled through each decision from the ground up. Over time I developed some rules of thumb and guidelines, but only the experience of managing managers has truly refined my thoughts on management.
When I started managing, my leadership philosophy was simple:
These have served well as a foundation, but by applying them repeatedly over time and circumstance, I've seen them fray on the edge cases. Learning forward, I've started to weave in a number of additional ideas in the vain quest for a unified theory of management.
At its core, I believe management is an ethical profession. To see ourselves, we don't look at the mirror, but rather at how we treat a member of the team who is not succeeding. Not at the mirror, but at our compensation philosophy. Not the mirror, but how we pitch the roles to candidates. Who we promote. How we assign raises. Providing growth opportunities. PTO requests. Working hours.
We have such a huge impact on the people we work with–and especially the people who work "for" us–and taking responsibility for that impact is fundamental to good management.
This doesn't always mean being your team's best friend. Sometimes it means asking them to make personal sacrifices, letting go of a popular member of the team, or canceling a project the team is excited about. It's remembering you leave a broad wake, and that your actions have a profound impact on those around you.
I believe almost every internal problem can be traced back to a missing or poor relationship, and that with great relationships it is possible to come together and solve almost anything.
Technical disagreements become learning opportunities to everyone.
Setbacks are now a shared experience to gel together as a team.
Even with great relationships, there are still real challenges! You have a limited budget for giving raises and can't satisfy everyone. If your customers don't love your product, camaraderie can't pay salary. Some technical problems are genuinely novel without obvious solution or where the obvious solution is cost prohibitive.
That said, I try to start debugging problems from the relationship angle, and find the technique pretty effective.
A few years back, one of the leaders I worked with (I think it was this guy), told me, "With the right people, any process works, and with the wrong people, no process works."
I've found this to be pretty accurate.
Process is a tool to make it easy to collaborate, and the process which the team enjoys is usually the right process. If your process is failing somehow, it's worth really digging into how it's failing before you start looking for another process to replace it.
As you start honing in on the problem (maybe it's you!), honestly ask yourself if a different process would address it, or if you're moving around the food on your plate. My experience is that a different process probably isn't the solution you're looking for.
Often in this profession we're asked to deal with difficult situations. No set of rules can guide you safely through every scenario, but I have found that postponement is never the best solution.
Instead of avoiding the hardest parts, double down on them.
If you have a poor relationship with your manager or a member of your team, spend even more time with them. Meet with them every day or have dinner with them. If two engineers are struggling to work together, before you separate them onto different teams, get them to spend more time together trying to understand each other's perspective (some obvious exceptions here, but if two people truly cannot work together, is there something else there you've been avoiding dealing with?).
As a leadership, you can't run from problems; engage 'em head on.
Lately, I've come to have something of a mantra for guiding decision making: do the right thing for the company, the right thing for the team, and the right thing for you, in that order. This is pretty obvious on some levels, but I've found it to be a useful thinking aid.
First, all thinking should start from a company perspective, and you should make sure that what you're doing is not creating negative externalities for the company or the other teams you work with. For example, you're really excited about trying out a new programming language in a project, but also make sure you've considered the additional maintenance cost for the rest of the company.
Next, make sure your choices are being made on behalf of your team, not on your own behalf. This might mean pushing back on a timeline which would force your team into a death march, even though it's uncomfortable to have that conversation with your manager or your product partner.
Last in the list is yourself, but while I do believe you should generally put yourself last, it's also a reminder to remember to "pay yourself." Burnout is endemic in our industry, and a burned out manager often leaks onto their team. Give as much as you can sustainably give, and draw the line there.
So much of what we take for granted is cargo-culted instead of done with intention. Early in your management career, you'll have to figure out how to approach common challenges: interviewing, performance management, promotions, raises. It's totally alright to start out by following what you see around you, learning from your peers is critical to success, but it's also important to be honest about which of your practices are truly best practices and which you're following on autopilot.
The recent focus on programming interviews is a great example. Most hiring managers, myself certainly included, are aware that they're conducting mediocre interviews, but over time it's easy to lose that perspective. You can't fix everything at once, so you'll often be doing something mediocre at any given point in time, but remember to come back and improve it when you can (e.g. paying down your management debt).
As a final thought, the best management philosophy never stands still, but–in the model of the hegelian dialectic–continues to evolve as it comes in contact with reality. The worst theory of management is to not have one at all, but the second worst is one that doesn't change.