All posts filed under “management

Listening for the Real Challenge

A situation that often comes up in meetings is that someone will raise an issue, using a recent situation as an example of what’s going on, but the discussion switches into being about the recent situation rather than the original issue itself. For example:

Person A: We really need to think about re-architecting Project X. Just last week, the team’s changes had a significant performance impact on the production site. What could we do differently to make the system more scalable?

Person B: Marketing were the ones to ask for the changes {insert long back story about the feature and Marketing} …

Person C: Marketing are always putting pressure on us to deliver features that make little sense. Can’t we push back on them?

Person A: Well, the problem with Marketing is…

The discussion went from trying to address issues with the system to be about Marketing. It’s easy to get sucked into carrying on the thread because it feels productive, but the original point is forgotten, then the meeting runs out of time.

When a discussion veers off course, I try to remind people what the original challenge was to get things back on track. But often, precious time has already been lost. It can be difficult to rein a discussion back in if strong characters are involved or from not wanting to be rude and interrupt the flow of the conversation.

For everyone taking part, listening to understand, rather than listening to respond, is an important skill to ensuring discussions stay on point. One question I learnt during my coach training is, “What is the real challenge here?”. I often say that to myself while listening to ensure that I’m paying attention to what’s being discussed and when a problem is being described, resisting the urge to latch onto something that’s related but isn’t the real challenge.

Team Health > Team Output

The majority of my time so far as Head of Engineering has been spent looking at the team’s health. Team health is a broad term, as it encompasses more than “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 practising 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.

Unseen Work

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 is knowing what technologies to use, it is knowing what techniques, data structures and algorithms to use, and it is knowing how to put it all together into building a functioning product.

There is No Debugger For Leadership

There are many mechanisms for understanding the issue and creating a fix when there are bugs in your code. 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 effects 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.

The Other Side of the Fence

As I have gotten older and my career has grown, many 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 many 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. I used to hate meetings, and now I value the high bandwidth communication and alignment they can give when run properly.

A big factor is a 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 they 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.