Manager README 2021
It has been a while since I wrote my first manager README. The idea is simple: help people who are going to be reporting to you understand the way you think, what you believe, and what you expect. For this one, I’m going to write it without looking at my previous attempt to see how my worldview has changed in the intervening three years.
Team
The primary responsibility of an engineering manager is to be accountable for the engineering delivery of the team. That output must be high quality, timely, and delivered in a way that is sustainable. This is achieved by focusing on three elements at the team level.
Delivery
Customers do not pay for software, they pay for solved problems. Similar to how programmers say all programming languages are bad, but some are useful, likewise, the same can be said of software. If you do not focus on your primary responsibility to solve customer problems, you will not be part of a successful team. Note also that software is never final. Do not think of versions of software as done, but rather everything is a temporary solution. Every processing pathway has a scaling bottleneck, every user experience has a level of tolerable pain. Every feature has a shelf life; if it always makes the engineers feel completely at ease, the team could probably go faster. Write software that delivers optimum value. Sometimes the horizon is days out, sometimes years. For developing perfect systems, seek academia.
Automation
Code is automation. Automation is code. Go slow to go fast. Manual tasks are boring for most humans, and error prone. It takes time to automate manual processes, but it’s a skill that programmers should spend all their time practicing. They should look for opportunities to automate tasks anywhere they drag team performance down. Automation is not just the code for the software that solves users’ problems, it’s just as much a part of provisioning systems that run the code, and how it gets to those systems. Designing, implementing, documenting, and reviewing are inherently slow, cerebral, collaborative, and manual; everything else can be automated.
Truth
Truth is about recognising what you’re doing and how, and a great deal of this truth can be found from automated monitoring. Time is the only valuable commodity that any of us have so when we come together we must work in the most honest way. Shine a bright light on what you choose to be the most important thing to work on. Use operational telemetry, logs, release stats, WIP, task throughput, service level indicators/objectives/availability (SLAs), key performance indicators (KPIs), analytics, BI data. Discuss as a group why you chose to solve the problem in the way you did. Do not hold back from stating your assumptions or clarifying a disagreement. A team of individuals will always disagree, that’s perfectly natural. Share how to proceed when this happens and be consistent. Honest teams are not afraid of transparency.
Individual
Individuals are unique and the engineering manager has to change style to help them grow and realise their potential. The foundations are the same for all.
Trust
The relationship between manager and engineer cannot be successful without trust. This is a long journey that is earned in small steps every day. Respect and truth are constants that must always be upheld. There is a balance of psychological safety and psychological resilience. The manager must offer safety for their direct reports because as their manager, they hold the foundations of whether the day-to-day job is pleasant, exciting, fulfilling, and self actualising, or a miserable grind of boredom, frustration, fear, stress, and pain. The manager cannot lose their temper and lash out. If the engineer conducts themselves in a manner directed by their manager, they must be protected at all times by them. If trust is ever lost, confront the issue and sever ties if need be. The engineer in turn is resilient — they know the manager supports them so does not shy away from delivering bad news or admitting mistakes.
Path
We are all a work in progress. Whether we aspire to be a CxO, or have reached a comfortable career plateau, there is always a way forward to how to work differently tomorrow. The manager should have the experience to see where that tomorrow could be, and has the wisdom to describe the path to be taken. Sometimes the approach is mentoring, sometimes it’s coaching, sometimes it’s knowing that the lesson needs to be taught by someone else. Regardless how it’s done, the manager knows what the engineer’s goal is and shares a plotted path to that goal.
Obstacles
As important as showing the direction to walk in, is pointing out the blockers in the road ahead. Knowledge and skills can be learned, but behaviours are deeply ingrained. Some ways of thinking or behaving take a long time to deconstruct and reassemble, while some should simply be acknowledged and mitigated. Offering radical candour, sometimes the most painful feedback is the best to hear from your manager.