management

What makes a good manager?

Cody Redmond

• 4 min read

I was recently asked this question by a friend considering a move into engineering management. It's been a few years since I've asked myself this question, and I find it interesting how my perspective on this has changed over the years.

Before I begin, I'd like to note that I won't address the manager's responsibilities, which are frequently framed as delivering value to the organization, often by achieving operational objectives while retaining and growing reports. Instead, I'll focus on the qualities that make for a great manager within the context of a team.

Consistent Practices and Behaviours

A manager creates a stable and productive environment by establishing a repeatable set of practices and behaviours. When team members know what to expect, they can focus their energy on solving problems rather than worrying about unpredictability. Practices can (and should) evolve, but there ought to be a core stability that reinforces a psychologically safe environment for work to get done.

For example, I have a weekly team meeting with an agenda that acts as a checklist of our most important responsibilities and allows the team to discuss significant issues that may have come up. I also have 1:1 meetings every two weeks and a monthly retrospective to uncover better ways of working.

I also have a standard method for feedback (both praise and constructive) that I incorporate into my onboarding of any new direct report.

Regulated and Open

Software Development can evoke contrasting opinions, perspectives, and dynamics. Managers who successfully manage their own temperaments are far more effective when collaborating with others during times of increased tension.

Managers must effectively work with people not just on their team but throughout the organization. No matter the context, an effective manager leads from a place of responsibility, curiosity, and openness. The Conscious Leadership Group refers to this place as "above the line."   Conversely, being "below the line" means being closed off, defensive, and reactive.

Reliable and Effective

A manager is responsible for the standard of quality across their teams. This means modelling professionalism and follow-through. It doesn't mean that you need to be stuffy or uptight; it just means that you know which qualities are most important to build trust and an effective team and work to push that standard higher. Sometimes, I refer to this as "setting the tone."

For example, if I say I will do something, I do it and report back to the team. I use proper spelling, grammar, and full sentences, and I expect that folks come to meetings prepared. I use agendas for meetings, keep them on topic, and end them early instead of running down the clock.

  • In his book The Art of Leadership: Small Things, Done Well, Michael Lopp highlights that managers must set the highest standard for follow-through, which is crucial in building a high-trust team.
  • The central lesson of the book The Score Takes Care of Itself is that leaders who set, model, and maintain a high standard will create an environment where success is a natural outcome.
  • Another fun read that covers this ground is Turn the Ship Around! by David Marquet. I liked this one, too. It goes a little deeper into how shifting language can be a powerful tool in shifting behaviours.

Ambitious

A line manager often links the CEO or VP and the staff, ensuring effective alignment of organizational goals. With clear understanding and articulation, aligning the organizational vision with the personal drivers of your direct reports is possible, which can result in a powerful source of motivation.

In addition to responding to top-down objectives, a great manager will also work from the bottom up, looking for opportunities or innovations that could generate new revenue streams or unlock untapped organizational value.

Lastly, a great manager understands that engineers love hard problems and that setting high targets is a precursor to achieving exceptional outcomes. But just as important is understanding that making unachievable commitments on someone else's behalf is a source of demotivation. In this regard, it's important to maintain awareness of the technical environment in which your team is operating and to collaborate with your team to identify ambitious targets that are also achievable.  

  • The book Drive: The Surprising Truth About What Motivates Us does a great job of unpacking how different people are motivated by different factors. It's worthwhile to check in regularly with your direct reports on the most important factors and then find ways to align those drivers with operational objectives or growth goals.  

Risk-Adverse

Lastly, I don't often see this aspect come up in discussions as frequently—perhaps because it's often relegated to project management, a separate area. But from my own experience, I've noticed that a process that identifies and manages risk early enables far greater delivery and fewer surprises.

I like starting with a risk mitigation activity with my team that uncovers the assumptions, dependencies, and bets. Then, to raise our confidence, we validate assumptions and spike in the areas where we are least confident. We then move to system design diagramming and technical designs for significant areas.

If you can do this quickly and repeatably, you will often avoid working on the wrong thing for too long or seeing a project go drastically off-track. A direct report might occasionally feel unfamiliar with the "design up front" approach. They come around when they see that the entire thing can be accomplished within hours, that it generally yields better results, and that it's fun, too.

  • In the book "Righting Software," Juval Löwy emphasizes the importance of addressing areas of volatility in a codebase and the critical role of project design in software architecture. In particular, he states that complex software benefits from considered design, scoping, and sequencing. The design involves defining the architecture, components and interactions; the scoping ensures the functional and nonfunctional requirements are met and communicated, and the sequencing ensures that the development workflow is optimal for the team, which I often interpret as "allowing for the maximum number of iterations on running code".
  • The Pragmatic Engineer has lots of content about how engineering managers should be familiar with project management and risk management.