I’ve been in software management roles for the past six years or so. As I prepare to take on a role that will shift my attention away from management for a while, here are a few things I’ve learned during that time about how to be a good manager.

I had initially hoped to summarize all of my major points of view on this topic in a single blog post, but I’m finding that I can’t be that concise and I will likely need to make additional posts in the future if I want to document my learnings comprehensively. It’s also probably an important caveat that my experience has mostly been of software development teams, and while I have had experience managing other types of teams and managing managers, I think the advice below is most applicable in a context where one is running a team of software developers.

Evaluate decisions based on inputs, not outputs

Your job as a manager is in large part to make decisions. It is important that you are prepared for some decisions to turn out to be incorrect, and also that you are working on your decision-making process constantly in order to minimize this.

Imagine you can place probabilities on a certain decision being correct at the time you make it. For example, an architectural decision may be correct assuming a certain amount of user growth over the coming year, and that user growth is a function of many factors, including true demand for your product, sales and marketing effectiveness, product quality as perceived by users, etc. You feel confident that there is demand for what your product has to offer, that your sales and marketing teams are competent, and that your engineering team can build a product that feels high-quality to users, but even given unlimited time to consider this question you would only be able to produce a range of outcomes for how each of these inputs will affect user growth. Furthermore, there may also be exonenous factors affecting your user growth that are hard to predict; for example, a sudden shift to work-from-home and teach-from-home for employers and educators could be caused by a global pandemic and result in skyrocketing demand for your video chat product. Through a combination of what is possible to know and what is reasonable to learn within the time you have to make the decision, maybe you can score your decision in terms such as “assuming user growth within a range of X over the next year, which I feel has a high likehood of being the case, my confidence is Z% that this architectural decision is correct”.

Let’s say that your product manages to become a viral hit during that time, though, and user growth dramatically outperforms your expectations. This is a wonderful development for you and your company, but your architecture is now struggling to keep up with the scale of demand. The design could now be seen as incorrect, but your decision remains correct; in order to make an architectural decision that would have served you well at this point, you would have needed to make that decision in a way that optimized for a much lower-probability outcome. If you adjust your future decision-making based on this outcome, you are likely to make worse decisions.

While others will judge the quality of your decision-making based on outputs, you must think of your decisions in aggregate and seek to improve your overall “hit rate” by focusing on inputs.

Manage expectations and “succeed”

This is one of the aspects of management that took me the most time to truly internalize. Your success will be judged by others in terms of their own expectations; they will care neither about whether your decision-making process was sound, nor whether the outcome of your decisions meets your own expectations, but merely whether the outcome of your decisions meets their expectations.

When you have the trust of your peers at work, you gain a great deal of productivity because you have to spend less time rationolizing your decisions to them. Thus, it is important to sharpen your decision-making for the current context as quickly as possible so that you can start delivering good results and your peers start to trust your (and your team’s) competence.

Since it takes time to tune your decision-making to a new context, you can build trust in the interim by communicating your confidence intervals around decisions. I find it is common for people to communicate their decisions in a binary manner and thus face much more blowback in the cases where their decisions turned out to be wrong. It builds much more trust to communicate a decision accompanied by the level of confidence you have in that decision and what goes into that confidence interval. This allows other stakeholders to plan around potential failure and not be surprised when something doesn’t go as planned.

Ultimately, success as a manager is very much in the eye of the beholder and this can be the source of career frustration for a lot of managers. Set expectations in such a way that you create resiliency to unexpected developments within projects and a sense that you and your team can be counted on by the organization for quality work. Furthermore, set expectations in such a way that you and your team also feel that you are doing good work.

At the individual level, focus on strengths

In equity investing, particularly venture capital, it’s often stated that one’s downside is capped and one’s upside is uncapped. That is, one can only lose as much money as they put into the investment if the company’s value goes to zero, but there’s no reason why a company couldn’t double or triple in value, with the same growth being realized in the value of the investment. Thus one should not put more money into a given investment than they can afford to lose, and they should understand the downside risks, but it is more possible for upside to affect one’s wealth positively than for downside to affect one’s wealth negatively. I believe a similar dynamic exists for individuals on a team; an individual’s upside can create much more growth for the team as a whole than their downside can detract, as long as the downside risk is appropriately quantified and managed.

Most of your team members will want to be great, and if they achieve this, they will do so by turning their strengths into superpowers. One can often avoid complete failure by leveling up one’s weaknesses, but one never becomes great by doing this. Furthermore, your team will do much better work if they see a path ahead of them to becoming great at what they do, and it will help to set a bar for the team of the quality and integrity through which work should be approached.

“Focus on strengths” can sound like somewhat of a rose-colored management approach, but there are certainly harder decisions that come with running your team this way. Generally, you are accepting that you cannot change someone’s strengths or weaknesses, you can only grow their strengths and contain their weaknesses. In the latter case, the best thing to do is to put someone into a role such that their shortcomings don’t matter as much, but if no such opportunity exists, or they have a flaw whose negative impact is impossible to contain regardless of the individual’s role, you likely need to move them out of your team. Moving swiftly to make such a change is in everyone’s best interest.

For further reading, First, Break All the Rules explains this mindset much better than I could in a few paragraphs. As a slight aside, I also much prefer the StrengthsFinder test that’s associated with this book to other workplace personality tests, as I generally feel that the flaw in these tests is that they attempt to map every personality onto a rigid grid-like construct, and I much prefer the fluidity of the StrengthsFinder approach.

At the team level, focus on transparency and trust

Thanks to your strengths-focused approach to individuals on your team, you now have a team of contributors whose skill sets are well-balanced towards what is needed for the team’s goals, each of whom has the potential for greatness within their own niche, and none of whom have the potential to toxically drag the team down. At this point, it becomes your job to make sure your team has all the information and context they need to make their own good decisions and the trust in each other needed to work together well.

It’s hard to give blanket advice on how to do this, so I’ll cover this section in terms of a few broad rules and things to keep an eye out for (along with some links to further reading): * As a leader, you should always default to transparency. There is much more to write about this statement, and I’ll probably need to make it a post of its own at some point, but as a general rule of thumb if you find yourself wanting to withhold information from members of your team, you should interrogate this feeling and in most cases you are making a mistake. When defaulting to transparency, there is also the risk that you overload your team with information that lacks a narrative or context, though, so you do need to be cognizant at all times that you are not forcing to much synthesis work onto them or just making them confused by providing a lot of poorly-framed information. * All discussions should happen in public channnels. If you are using a lot of private Slack channels, this is a giant smell that likely indicates larger problems with the trust and knowledge-sharing function within your organization. For more on this, check out Julia Evans’ piece How do you make an awesome team?, which specifically addresses team members, not managers, but I think is great for managers to read as well since it basically describes the perspective that you want to encourage your team members to have towards their team. * Along similar lines, set up your team processes to produce a lot of feedback. Having operations be discussed in public group channels is a great example of this, but so is CI/CD and releasing small change sets frequently so that the team can see the effects of their changes quickly. The DevOps Handbook is a classic tome that describes the value of visible, continuous workflows with lots of mechanisms built in for feedback and learning opportunities. * Make sure no one works alone. Any project that is important enough to have someone focused on is important enough to have multiple people focused on it, and one-person “teams” almost always end in disaster as they create knowledge silos and limit growth of both the individual and the team. * Don’t make them come to you. Figure out ways to tell when team members are struggling and how to intervene in ways that build trust. In some cases, you may want to offer help in front of a group, in order to foster a sense that help is available between members of the team, but in other cases you may want to intervene more privately in order to avoid injuring a team member’s pride. Camille Fournier’s How do Individual Contributors Get Stuck is a classic on this topic. * When something goes wrong, always do a blameless postmortem. I love postmortems; there is no faster way for a team to learn and advance than when something goes wrong, but only if you take advantage of the opportunity to mine that incident for its rich lessons. The blameless bit is essential, though; your team will learn nothing if they are focused more on whether they are in trouble, and even if the incident did result from one individual’s mistake then you should treat this as an error of the system you have created (to allow one person to make a mistake large enough to cause a postmortem-able mistake). While I would caution most teams from taking too many process lessons from a behemoth like Google, I think their Example Postmortem doc is a great one to use as a template.