Being an engineering manager and a coach

TLDR: Listen to people and have good intentions. Read time ~ 6 mins

For anyone who’s spent five minutes trying to understand me, they know that my purpose is to grow myself to grow others. My path in the last few years seems to have been driven by a deep need to understand how to be a better coach, so I’ve captured some of my thoughts from that journey from both successes and failures. I’m not expecting any of this to be ground-breaking, but hopefully it does encourage a few managers particularly in the digital sector to have better coaching conversations with your team (If you want to find out the fundamentals about being a coach as an engineering manager from a better writer than me, check this out).

I’ve written this post from the perspective of an engineering manager, but most of these observations could easily relate to any manager who wants to be more of a coach.

Start with understanding your coachee’s values and purpose

I’m assuming here that you’ve already built up some basic rapport with your team member, the next step is truly understanding their values and purpose. I’ve already written about this in a previous post with a good practical exercise to do this. If you haven’t figured out your own values, do this exercise yourself first. Understanding others’ values and intrinsic motivations leads to empathy, a key skill in coaching. Empathy leads to objectivity, trust, and a quicker path to goal resolution.

I notice that engineers in my experience are reluctant to spend a lot of time digging into themselves like this. This may be because of more common analytical and logical thought processes that go on in engineers. During a team building exercise, I once heard an engineer interrogate the facilitator’s fundamental understanding of neuroscience, missing the irony that the psychometric test proposed that overanalysis was a team weakness.

Whatever the reason, persist with good intentions. Performance, behaviour and beliefs usually stem from these values and builds a solid base for the following points.

Coaching only works if people want to be coached

That’s not an excuse to avoid coaching conversations. If you’ve done the work to discover what people value, most of them can be coached – even if it’s to save their job. But hire for a growth mindset and coachability and it will be so much easier. I’m not a fan of hiring top tech talent if they’re not able to handle feedback.

With those team members that don’t want to be coached, your job then is to actively listen, with compassion, empathy, and consistency, to find out why that is. Do they feel like they’ve peaked and don’t need help? Are they sceptical of the process? Is there not enough trust there in the relationship? 

Dr Ron Westrum categorises organisational cultures into pathological, bureaucratic and generative, made popular in the digital industry by the book Accelerate and the work by DORA which discusses how important this is to create high trust, fast-flow environments. Thankfully I’ve not worked in a pathological culture, but what I can tell you having worked in bureaucratic ones is that engineers seem to be reluctant to accept their manager as a coach. This could be because their managers have climbed through the tech tree and found no other way to progress other than management (you don’t need me to tell you why this doesn’t always end well), or simply that the culture puts more emphasis on managers to favour product over people. Either way, the best way to break down that barrier is a consistent attitude to a coaching approach, trust, and time.

Westrum’s typology of organisational culture, “Accelerate: The Science of Lean Software and Devops: Building and Scaling High Performing Technology Organizations”, Nicole Forsgren, Jezz Humble

It’s worth mentioning that as a manager, you can’t solve everything with a coaching approach. Knowing when to make something a coaching conversation, and when not to, can be a tricky business.

Know when something is not a coaching conversation

It is a fine balance being both a coach and a manager. A good coaching relationship is based on a sense of equality, and as autonomous as I like to feel my teams are, being a manager means there’s a power dynamic there that makes equality tricky (this article has an interesting take on managing those power dynamics). You may find a scenario where you are helping someone on an improvement plan, which by design does not facilitate impartiality. Coaching techniques should still be used (active listening, empathy, evaluating options with pros and cons, accountability), but be very aware that sometimes the agenda is necessarily yours, not theirs.

There are times when it’s just not a good idea to try a coaching approach. 

  1. When you have the definitive answer, and they don’t. See, “How do I put a support ticket in to IT?”, “Where do we keep the project repositories?”. Trying a coaching approach here gets annoying very quickly.
  2. When they don’t have context, and you do. When I’m coaching someone outside of the work environment, a coachee definitely has more context about their problem than me. But employees will often not be able to come up with good solutions if they don’t have the same business context as you do as a manager. See, “What am I supposed to work on if I don’t know the roadmap?”, “What technology should I learn next?”.

Other than these, try to look everywhere for the opportunity to make interactions with your team a coaching conversation, and provide early and candid feedback as often as possible (see Kim Scott’s excellent book Radical Candor).

Ensure actions and accountability

This goes for any coaching programme, but it’s so easy to slip out of the habit as a manager. Any good coaching conversation, particularly in a structured format (such as a 121 or an appraisal) must result in actions for the employee, accountable to the employee, and preferably set wholly by the employee.

A trigger for me is when someone says “Yeah, I should actually do X about that.” Especially if there’s a strong degree of trust, it’s all too easy for both parties to be satisfied that this is the end of it, both genuinely believing that this will happen at some point in the future when the dust settles and the next big feature’s over the line. Well, there are always more features, and expecting the dust to settle is like expecting a magic supercoding ninja to swoop in and clear all your technical debt for you. 

Try creating a new habit. When you hear the “I should”, instead of assuming it will happen, create accountability by asking questions like “Will you?”, “When will you?”, “Is that all you need to do?”, “How would you feel if you completed that sooner rather than later?”.

Coaching the individual by coaching the team

If coaching an individual isn’t getting the desired outcomes, coaching the team as a whole can encourage a positive attitude in the individual and reach the same outcomes. Human beings are social animals, and desire acceptance and validation from the troop (“The Chimp Paradox” is a really fun book that explores tribe mentality and is essential reading for coaches). If you coach the behaviours in others, eliminating the validation of negative behaviours from the rest of the team, you instantly create an environment where the undesired behaviour is not accepted within this troop and thus seek other forms of acceptance. Or, of course, they find another troop.

Summary

The key in trying the coaching approach as a manager is persistence. Sure – adapt, learn, try new things, ask different questions – but the gold comes only after a long period of truly trying to understand others and genuinely wanting them to be their best self. The proudest stories I have in my career are seeing people excel as a result of the actions they have set themselves from coaching conversations. Sometimes the eureka moment with a coachee just happens, when you least expect it, way down the line when something just clicks. It’s a culmination of the small things, the small iterations of listening, questions and actions, that deliver people to greatness.

Resources:

6 lessons I’ve learned from working with Agile Ninjas

TLDR; Eliminate waste.
Read Time ~ 5 minutes

Boy has it been an odd year. A year of volatility, uncertainty, complexity and ambiguity (VUCA), and having an agile mindset has never been more important.  Despite the sombre backdrop of 2020, good leaders have definitely learned, grown and adapted to the challenge during this time. Thankfully, one of the things that got me through this year was working with a team of awesome engineers, ScrumMasters, coaches and managers trying their best to adapt to change and lead in uncertain times. In the last 9 months, I’ve had the privilege of working with some of the most experienced agile coaches I’ve ever met. A pang of guilt rushes through me as I write this blog, as the contents are primarily a reflection of observations made possible by these awesome people. 

Whilst I’ve been on my own personal journey of growth and discovery, I thought I’d share with you some of my takeaways from those colleagues with an agile mindset so that others can take away something good, however small, from this otherwise sucky year.

1. The value of a good Product Owner

In the past I’ve worked in places where there was no clear product function, and found myself subsequently explaining to each new company-volunteered product ‘champion’ what their role should be, and why they should be passionate about it. So, it came as a nice surprise once I started working for companies who had product owners, where their job title was actually ‘Product Owner’. They not only showed up on time, but actually owned the product backlog and were held accountable for ensuring that the right thing was being delivered. Companies trying Scrum “because it’s Agile” often fail at the first hurdle because there is simply no representation of the customer in the work that engineers do. The benefit of having that PO role embedded on value aligned teams potentially saves months of wasted effort.

2. The team retrospective is the most important ceremony

The only ceremony that’s actually mentioned in the agile manifesto, at regular intervals teams should reflect on how to become more effective. I’m not going to cover well trodden ground about why they’re important (here is a great dedicated article to it) but it’s amazing how many teams either don’t do it or don’t find it useful. The reasons seem to be either:

  1. “We don’t have time with all the other meetings”. Answer – skip the other meetings. How can you possibly expect things to get better if you’re not taking dedicated time to figure out how?
  2. “They’re pointless”. Answer – give them a point. Make sure that actions are actionable, within the team’s control, written up and executed. Keep track of these. Don’t write an action that only “the company” can solve – this is the time to be accountable for your own team’s improvement.

A great way to encourage people to just T-off with retros is making something the team look forward to. Make it fun, and encourage discussion. Some ideas I’ve seen over the years:

  • Ask everyone to bring a gif / movie / weather icon / picture / emoticon that they would use to describe the last sprint
  • Pictionary – draw the last sprint and let the others guess what you’ve drawn and why!
  • Have a theme for the retro – themes I’ve seen include Mario Brothers, The Beatles (with accompanying music), Avengers, video games etc.
“How would you describe this sprint in a GIF?”

3. Real actual deadlines exist

“If you’re really agile, you’ll get rid of deadlines”. I’ve heard this so many times. Try telling that to the people who write software based on government legislative deadlines. Or those that write education software based on a hard back-to-school date. Or ask those that write payroll software to ignore the constant stream of changes to job support schemes and tax changes this year. Product roadmaps in these cases are very useful things, and should even include other non-deadline features based on changing markets, customer demand and engineering improvements. This is not the same as the people that promise the customer a feature that hasn’t been built yet by next week, without talking to the developers. There is still a special place in Hell for those people.

4. It’s about the mindset, not the process

The ScrumLords are not going to cast you to eternal damnation for not having a backlog refinement session

I was (and still am) a massive fan of Scrum, having championed it as the way of delivering agile software. The cracks started appearing when I tried introducing it to mechanical engineering and chemistry teams – they just couldn’t practically work to a regular cadence. After learning a little more about Kanban this year, that really could have worked. 
The ScrumLords are not going to cast you to eternal damnation for not having a backlog refinement session. But you should be confident that you’ve tried it as a team, reflected on it as a team, and come up with an even better prioritisation process as a team.

5. Communities of practice rule

I mentioned in a previous blog about the value of talking to other teams to better reflect on how your own team can improve, and communities of practice are a great way to do this. The DORA 2019 State of DevOps report states that 57% of elite performers use a “Communities of Practice” model as a transformation strategy – more popular than any other strategy, including proof-of-concepts, grassroots and centres of excellence. The Agile and DevOps principles crossover sufficiently enough that we can apply the same logic.

“The best strategies for scaling DevOps in organizations focus on structural solutions that build community”

“State of DevOps REPORT 2019” DORA / Google


Even if you can’t see tangible progress from your community, the sense of belonging, psychological safety and oneness it creates in a large organisation will pay dividends down the line. It gives members a sense of purpose which in turn creates a positive attachment to the organisation. An excellent article on how to get your agile community of practice off the ground can be found here, and having read it in retrospect, I’m pleased to see we weren’t far off the mark.

The golden rule – eliminate waste

All Lean principles revolve around eliminating waste, and it is hard work finding where the waste might be for your team. The process of estimating, for instance, can necessitate a useful conversation around acceptance criteria, encourage a definition of ‘done’ and eliminate waste for the team by ensuring they’re building the right thing. The controversial #NoEstimates movement however argues why estimating may be waste in itself, where time could be better spent writing software and concentrate on making all stories small enough to fit in the sprint. The retrospective itself can be wasteful if not used correctly. 

“Simplicity–the art of maximizing the amount of work not done–is essential”

Agile Manifesto (Agile Principles), 2001

The agile principles state that “Simplicity–the art of maximizing the amount of work not done–is essential”. I have learned that regardless of whether or not your agile teams are software teams, getting value quicker to the customer involves frequently asking this question of your process – “Is this eliminating waste?”.

In conclusion…

Gratitude is the key to resilience. It is an indicator of high emotional intelligence (written about in my previous blog) and is an essential part of withstanding a VUCA world. In the horror-show that was 2020, we must reflect on the lessons we’ve learned and find gratitude in our journey through it. I can say with confidence that I am grateful for those that have shared these lessons with me.

Feature image taken from the book “Agile Samurai” by Jonathan Rasmusson

Why emotional intelligence is increasingly required in software development

TLDR; Because AI can’t automate human emotion (yet).
Read time ~ 7 minutes

“emotional intelligence—the ability to, for instance, understand your effect on others and manage yourself accordingly—accounts for nearly 90 percent of what moves people up the ladder when IQ and technical skills are roughly similar”

https://blog.dce.harvard.edu/professional-development/emotional-intelligence-no-soft-skill

Emotional intelligence (sometimes referred to as EQ) is the ability to understand your own emotions and the emotions of others such that you are able to help, guide and influence situations based on those feelings and the expected consequences of them. There are countless articles, blogs and books on the subject (this being my favourite article), articulated in Daniel Goleman’s book “Emotional Intelligence” into the following model:

  1. Self-awareness
  2. Self-regulation
  3. Motivation
  4. Empathy
  5. Social skills

Using this framework, I’d like to explore why it’s relevant in the digital sector, with particular reference to software developers.You’d be forgiven for thinking that IQ is still the thing that matters in a technical landscape, and that how much you know about a certain domain or technology is still the dominating factor. Unless you’re able to navigate the model below, you’ll be limited to that 10% of development potential (by the way, this definitely applies to tech leads and managers too!).

In a 2011 Career Builder Survey of more than 2,600 hiring managers and human resource professionals, 71% stated they valued emotional intelligence in an employee over IQ; 75% said they were more likely to promote a highly emotionally intelligent worker; and 59% claimed they’d pass up a candidate with a high IQ but low emotional intelligence

http://press.careerbuilder.com/2011-08-18-Seventy-One-Percent-of-Employers-Say-They-Value-Emotional-Intelligence-Over-IQ-According-to-CareerBuilder-Survey

1. Self Awareness

I’ve had hundreds of one to ones with software developers, many of them centred around personal development. What I spend most of my time doing with early conversations (and in some cases continue to do so for a long time) is figure out why they do what they do. Is it money (rarely)? Is it cool tech? Is it that they want to build a reputation as an accountable deliverer, or do they like making people happy by giving them solutions to problems?

Knowing your values, your strengths and your weaknesses is the first step in understanding why you react the way you do to certain situations. For me, my values are at the absolute core of the decisions that I make, at the micro and macro level – without them I’d have no North Star guiding me and certainly wouldn’t be able to understand my feelings when I see an opportunity or a threat.

I would argue that without mastery of self-awareness, practising other items in the model becomes backbreaking work.

THINGS YOU CAN DO:

  • This values exercise helps you understand and prioritise your values. It has been invaluable for my professional development, and recommend it to others wherever I can
  • Seek out some 360 feedback. There are several popular frameworks and tools available, I would recommend the Emotional and Competency Inventory Survey. However, a simple start / stop / continue conversation with your peers and stakeholders would would be a good first step

2. Self Regulation

Self regulation is the ability to regulate your own emotions based on your awareness of the impact of them on your surroundings.

Let me highlight one example. In Marshall Goldsmith’s book “What got you here won’t get you there” he outlines 20 habits that hold you back. Number eight is negativity. “Let me explain why that won’t work”. And boy, do some developers like telling you why ideas won’t work. You know that teammate? When you’re in a meeting, firing ideas around with your colleagues, and they keep responding with “let me tell you why that won’t work”? Whilst massively useful for managers (the good ones anyway, the ones that listen), highlighting risks in a constructive and sensitive way (offering solutions, establishing fact etc) is a skill that needs to be honed. If you’re always that person, and of course you’re aware that you’re that person, have a chat with your manager or someone you trust about how to effectively convey that risk whilst still offering solutions and being part of the change.

Self regulation of course applies to many other aspects and behaviours that all employees / managers deal with – integrity, how we deal with our emotions verbally or physically, adaptability. Again, a good feedback mechanism will allow you to measure and notice this more frequently.

THINGS YOU CAN DO:

Changing personality habits takes time, with frequent short bursts of practise. “The Coaching Habit” describes a nice model to create new habits to replace old ones, and Box of Crayons (the company founded by the author) has a good short series on creating new habits starting with this one

3. Motivation

“For artists, scientists, inventors, schoolchildren, and the rest of us, intrinsic motivation—the drive do something because it is interesting, challenging, and absorbing—is essential for high levels of creativity.”

“Drive”, Dan Pink

If your motivation is money, security or control in this industry, you’re going to get burnt out pretty quickly. Dan Pink explains it in his book “Drive” that there are two types of motivation – intrinsic and extrinsic. He argues wonderfully that in our creative industry, this intrinsic motivation is crucial for us to innovate, design and craft ideas. Lastly, in our VUCA world, coupled with the compounding uncertainty of the current COVID-19 situation at the time of writing, intrinsic motivation develops the essential life-skill of resilience – to quote a colleague, “the ability to get yourself back up when life kicks the shit out of you”.

Managers take heed – if you do not find the ability to foster creativity in your engineers, you will have a demotivated team.

THINGS YOU CAN DO:

After finishing the values exercise above, make sure you’re doing activities in your day job (or life for that matter) that match with your values, so that you can draw from that spring when life gets you down.

4. Empathy

Aside from the obvious benefits of empathising with colleagues, I wanted to focus on the customer. I previously wrote a blog on why developers should talk to customers, and this is why. Empathising with the customer is fundamental to developing what the customers actually need, not what we think they want. There are entire processes and methodologies centred around design thinking, human centred design and service design that mandate that humans – in all their irrational and emotional glory – should be at the core (of course, “The Lean Startup” by Eric Ries is mandatory reading on this subject). And yet sadly, there are still engineers reluctant to step away from the 1s and 0s, relying on the vast corporate network of sales, marketing, product owners and directors to empathise for them. Great for the consultants, not so good for your company’s wallet.

THINGS YOU CAN DO:

I’ve tried to cover how developers can get closer to the customer in my previous blog, hint : it’s at the bottom

5. Social Skills

Something of course that we developers have in abundance. I once went to a ‘team-building’ event where the organisers completely mis-read the room. There was near mutiny when they announced to everyone’s surprise that there would be a 5 minute ‘skit’ that the vast majority of introverted scientific folk would have to perform. It was however team-bonding, in that we now unified in a single point of hatred, and I don’t regret the experience for a second.

And what is it with us creative types using Slack / Teams / Basecamp IM as our default mode of communication? The amount of times I’ve had to encourage engineers to pick up the phone to create a personal dialog with someone rather than relying on an electronic form of communication or ticketing system. It doesn’t develop the necessary discipline to form rapport with people, the fundamental requirement to reminding reminding yourself that the other party is a human being. Ever wondered why IT keep ignoring your requests, no matter how many times you put a ticket in or send them a very clever and strongly worded email? It’s because you don’t have a rapport built with the human being that has to deal with 100 other cleverly worded emails that are just words in one of their systems, devoid of context or empathy. This rapport is forged most effectively through face to face contact, one study citing a face to face request is 34 times more effective than an email. Kim Scott argues in her book “Radical Candor” that by caring personally about people, you are better able to empathise and understand the context of their position in any situation.

In conclusion…

This summarises my point nicely for all elements of this model: you cannot have emotional intelligence without creating relationships. Creating relationships and rapport is hard. It takes time and investment, and requires you to care about and empathise with other human beings.

One day, JavaScript will die. As long as there are humans, emotional intelligence will not.

The balance of people and product

TLDR; favour people.

dilbert.com

So a combination of finishing my new favourite book “The Infinite Game” by Simon Sinek, a change in career and some pretty heavy family events has led me to reflect a lot on this question. 

To clarify, when leaders favour people over products, they make a conscious decision to sacrifice the speed of product development in favour of supporting the team that are working on it. When leaders make decisions that favour products over people, they make decisions they have deemed to be for the good of the product, project or bottom line sometimes to the detriment of the team. Sinek also refers to this as “will over resources”. In the infinite game of business, he provides evidence (both anecdotal and empirical) that companies who make more of the decisions that invest in trust and psychological safety over profit stand the test of time. The DORA 2019 State of DevOps report (a benchmark guide for high performing software teams) suggests that elite performers in our industry have a culture of psychological safety as a building block for high software delivery performance. To build exceptional products, it requires an exceptional investment in people.

As he explains it so beautifully in this video, Sinek suggests that even if we can tip the balance of our priorities 51/49 in favour of people (will over resources), the rewards are obvious.

Many leaders have a bias towards people higher than this, not that I have any way to quantify it. This brings its own problems (lack of exposure to at C-level, perceived slower project delivery etc.) which I have personally encountered. This is not a strategy I recommend if you want to climb the corporate ladder quickly, but it is one that I recommend if you want to make a positive difference to people’s lives (and, as it happens, also delivers great products and brings in revenue to the business).

“If employees don’t feel cared for, they are statistically and significantly more likely to leave”

A study by Gallup that pops up time and again (first referenced in “First, Break All the Rules” – 1999, Buckingham & Coffman) asks over one million employees around the world to agree or disagree with the following statement : “My supervisor, or someone at work, seems to care about me as a person”. This Gallup defines as the The Fifth Element of Great Managing. The study finds that those teams that answered this question in the bottom quartile (that is, the teams that answered ‘no’ most often) had a 37% higher turnover rate than those in the top. If employees don’t feel cared for, they are statistically and significantly more likely to leave. For more reading, this post does a better job of explaining it than me.

In Summary

  • Psychological safety is the number one building block for creating elite performing teams in software delivery according to DORA
  • If employees don’t feel cared for, they are statistically and significantly more likely to leave

My personal argument for people over products like this: Investing in teams is like investing in a savings account. You use the capital in the account to ‘buy’ delivery of a high quality product. You cannot call on reserves when you have not invested, and you will pay for it later if you take out a loan to do so. 

Building rapport with humans and creating a culture of psychological safety requires heavy investment, and is hard work. However, Sinek reminds us that to favour ‘will’ over ‘resources’ and to build trusting teams is key to playing the infinite game of business, and ultimately delivers the best possible product for our customers.

A call to action for software companies – talk to each other!

“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly”

Agile Principles

So states the agile principle, but considering we’re all supposed to be finding new ways of improving, it sure is darn hard to talk to other teams about it.

Firstly, let me say networking events continue to be a fantastic source of knowledge transfer for our industry. In our region in Teesside for instance there’s Refresh Teesside and the Hainton meetups, but people tend to have their guard up at these events. The conversation leans towards the ‘this is what we’re doing right’ rather than ‘this is where we’re struggling’. I always find the latter conversation extracts more value, and I feel way more secure talking about this in my environment of work with the people and tools available.

I’ve been on a personal mission the last few years to try and invite developers from other companies to come on site to have a look around at our tools and processes, in exchange for an optional reciprocal tour. Both sides gain insights, understand where their strengths & weaknesses are and hopefully take something back into their retrospectives to make them more rounded teams. Reciprocation has been a challenge at best.

So taking a leaf out of the call centre handbook, I thought I’d share a script to counteract the most common reasons why companies are reluctant to share…

1. We’re too busy / don’t call us we’ll call you

Number one reason we get. I have a simple flowchart that helps in this situation:

Whilst it’s a bit tongue-in-cheek, the situation always reminds me of the following ‘too busy to improve’ graphic that hangs pride of place in our physics office:

2. All my stuff is secret

OK, so let’s sign an NDA. And let’s not look at your super secret project. In fact, let’s not have a look at any projects at all. We’re really just interested in how we can be better developers and improve our delivery, and we’d love to help you out too if we can.

3. Are you scoping me / my team out for a job with you?

Nope. No strings attached, no hidden agenda, we just want to be better, and if we can we want to help you be better too.

4. Do you want a job here?

Probably not. I’ve knowingly arranged for my team to go to companies where they’re interested in hiring them, on the understanding that they’ll come back with some valuable insights on where we can improve our processes (I could probably do a whole other post on why it’s not a good thing if you’re a manager and this scares you!).

So please do seize these opportunities to improve (drop me a line on LinkedIn if you want to arrange a no-strings-attached meetup!) and ask this question of yourself : “Am I the hairy guy with the square wheels?”