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.

You Don’t Gain Control with a Promotion

When I was a Senior Engineer, I thought if I moved into a Tech Lead role, I’d have more say and more control over what the team did. When I was a Tech Lead, I thought if I moved into a Head of Engineering role, I’d have more say and more control over what the department did. I’ve found myself to be wrong both times, and both times, it’s felt like I’ve had less say and less control than I thought I’d have.

As a Senior Engineer, I wanted things to be built and created a certain way, so moving into a Tech Lead position seemed like the logical way to do that. But once in that role, my problems became so much wider that I didn’t have the time to get into the details of how one thing was coded and created. Over time, as Tech Lead, I wanted things to be architectured and built a certain way, so moving into the Head of Engineering position seemed like the logical way to do that. But once in that role, my problems became so much wider than that I didn’t have the time to get into the details of how architectures were built or created.

The point is that you can influence and solve the problems you have, right now, in the role you’ve already got. Maybe you’ll need permission, but you can get that if you need it. Getting promoted into a role doesn’t give you any power to fix the problems you had before, because those are now someone else’s problems. When you’re promoted, you’ll be solving the problems of that role, not the role you’re in. You’ll be playing a different ballgame, in a whole other arena, that’ll make the problems of your previous role, pale in comparison.

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.

Stop Working In Your Team and Start Working On Your Team

As Engineering leaders, it’s easy to get swept up by the day-to-day grind of delivering software. Code quality, broken builds, deployments that didn’t go according to plan, 1:1s, conflicts, stakeholders, and all the other things that fight for attention as we try to satisfy the organisation’s needs. This is us, working in our teams. We’re getting into the weeds of what’s going on and helping firefight issues as they come up. But to be really effective in our role, we need to take a step back and think about how we can be working on our teams. To look for and cut through all the noise and waste. How can we improve our processes to build more robust software? How can we improve our ways of working to go faster? Where are we missing data that would allow us to make better decisions? If we’re not doing these things and just getting stuck in the details with the rest of the team, what are we really bringing to the table as leaders?

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.

Applying Your Leadership Style

When you have sports coaching, whether that be for martial arts or tennis etc, often the coach will look at your technique and say “you’re doing it all wrong!”. And then you find that each coach has their own theory on how it should be done, even claiming other coaches don’t know what they’re talking about. But when you look at all these different theories and techniques, and put them into practice, at that moment where it counts, whether it’s contact with your opponent, or with that tennis ball, they all generally put you in the same, correct position, ready to take your shot.

Leadership is like this. Whether you’re quiet and gentle, or you’re loud and angry. At the moment when it matters, no matter what your individual style is, you have to be in the correct position in terms of vision and trust, ready to lead your team to success.

Learning how to Learn

The best developers I have worked with have all been incredible in self-directed learning. And yet a common pattern that I see more junior developers get stuck on is not knowing what to learn to progress their skills as a developer.

I spend a lot of time reading, whether that be blog posts or books, watching talks or listening to podcasts, I have never found myself short of topics to look into more or things to try out. So when I try to picture how someone can feel stuck, I struggle to see where that obstacle is coming from. 

There could be many reasons at play here. A more benign reason being fear and uncertainty: “There are so many things I could learn, what if I pick the wrong one?”. To that, I say start anywhere and see where it takes you. This approach then takes you on a “just in time” approach to learning, where, as you get deeper down the rabbit hole, the topics you need to learn change depending on where you end up. Whereas a more serious reason would be that the individual feels it’s not their responsibility: “My manager should tell me what to learn”. I could see how this way of thinking could be born out of schooling or bootcamps where we are told what to learn. So the responsibility for one’s development has been abdicated. 

Self-directed learning is a skill, but an important one for anyone looking to get ahead. For those that struggle, my advice is to just jump in. Doesn’t matter where and it doesn’t matter how. Pick up a book. Watch a video. Listen to a podcast. But no matter what, put as much of it into action as you can and link the dots. Every step you take will lead to the next, and that next step may require you to change course, but that’s okay, as now you’re learning.

Spring Boot JAXB unable to marshal type error

Working with a SOAP API with Spring Boot WS. I was getting the following error trying to create the request.

I was originally directly using the JAXB generated classes to form my requests:

The correct way is to use the provided JAXB ObjectFactory:

But to prevent marshalling errors you need to wrap your object in a JAXBElement object:

No more computing books

One of my bad habits is constantly buying computing books. This wouldn’t be so bad if I read them, but I have amassed a huge backlog of books that will most probably never be read and which ends up being a waste of money.

A couple of posts I read recently have led me to the decision that I should stop, or at least drastically cut down on, buying computing books. The first post talked about “learning voyerism” where you are really more interested in the idea of learning new things instead of learning the thing itself and the second talked about spending time going deeper into topics instead of boucing lightly through many different ones.

It is very difficult to stay focused on one thing when there are so many things happening in the world of computing all the time. There are a tonne of new and exciting languages and frameworks being released all the time. And while it would be great to try them all, that can only mean that you’ll never actually become good at one of them.

I have always been a bit of a generalist and while knowing a bit about everything isn’t a bad thing, there is a fine line between knowing a bit of everything while being proficient at some things and knowing not quite enough of everything to be unable to do anything at all.

OpenSSL issues building Ruby 2.2.2 with ruby-install

Trying out chruby and ruby-install and installing Ruby 2.2.2 with ruby-install was giving be the error:

Setting the LDFLAGS env var solved this for me: