The majority of my time so far as Head of Engineering has been spent looking at the health of the team. Team health is a very broad term, as it encompasses more than just “is the team doing okay?”. At a minimum, it means, are people on the team engaged and happy, right through to, are there processes and documentation in place to support them in the day-to-day process of delivering software.
Managers tend to spend a lot of their time looking at just the output of their team. Are we delivering? How can we deliver faster? How can we write better code? etc. But unless you have your underlying team health in order, this is the wrong thing to be thinking about.
If you’re the coach of a football team, the aim of the team is to score goals and win matches. So you could spend all your time focusing on drills, improving core skills, and practicing shots. But what if all the players on the team are sick or injured? All the will in the world won’t win you the championship if no-one is in good shape. You need to let your players rest and recover before you focus on their skills and scoring. The health of the team underpins everything about the output of the team.
We often mistake the job we see managers doing with the job they are really doing. We’ve all asked, at one time or another, “What does my boss actually do?”. We see them go to countless meetings, ask questions, or send around documents. We then equate those activities with the actual job of being a manager. Until I was promoted into the role of my departing boss, the perception I had of what they did was totally different to what I found myself doing. There was all this unseen work going on behind the scenes that led to the countless meetings, that led to the questions and that led to all the shared documents. On-top of that, the un-seen time and thought that went into ensuring the right questions were being asked and the right documents were being created and shared. This is no different to equating Engineers to writing code. There is so much unseen work involved in writing the right code. It’s knowing what technologies to use, it’s knowing what techniques, data structures and algorithms to use, and it’s knowing how to put it all together into building a functioning product.
When there are bugs in your code, there are many mechanisms for understanding the issue and creating a fix. Your computer will tell you when you’ve made a mistake, give you feedback and await your next command. So as a developer you learn to live in this constant cycle of feedback. Constantly making mistakes, and constantly making changes. It becomes second nature. But it’s through these constant mistakes that we learn what does and doesn’t work. We learn to see patterns and spot errors sooner. These mistakes and what they teach us are what make us grow.
Moving into a leadership role can often feel like the total opposite. There is no fast feedback for your decisions. Sometimes it may take months to know you’ve failed, and sometimes you may never know at all. So you can end up doing everything you can to avoid making mistakes. But just like the developer, you need to make mistakes to grow. It’s uncomfortable, and it’s painful, but you have to make calls when afraid or in doubt. You have to learn to live in the cycle of mostly absent feedback. Sometimes you’ll pick up on the affects of the choices you made, sometimes that feedback will be faint, but it’s only in that faint feedback that you’ll find growth as a leader.
As I have gotten older and my career has grown, a lot of my thoughts and opinions on topics around software development, management and leadership have changed. Reading back through some of my posts from ten years ago, I see a lot of the same thoughts and ideas that come up in discussions with more junior team members. And it’s not that they are wrong, but how the effects of experience and having a different vantage point can drastically change your view of things.
Whereas I used to be all for building a custom solution, now I would favour buying off the shelf more. Whereas I used to hate meetings, now I value the high bandwidth communication and alignment they can give when run properly.
A big factor is the difference that being accountable can have on your opinions. Before my promotion I would often rant about how “we have to immediately stop doing X”, or that “we need to really start doing Y before it’s too late”. But now that I’m in the role, all the second-order effects I had not previously considered, start to raise their ugly heads. I had only seen things through the lens of my IC role, now I see them through the lens of someone responsible for the team and how that team can meet wider objectives.
I’m sure that as I grow older still and my career grows, a lot of the thoughts and opinions I have now on software delivery, management and leadership will change. And all the things I’m critical of will look very different when I’m on the other side of the fence.