Lessons from trying to be Agile in a Waterfall industry

Nine months ago my journey led me back into R&D in the life sciences industry, working with (amongst other things) software in a medical setting. The healthcare industry is clearly heavily regulated. Moving from releasing web products several times a week to software that’s released a few times a year (if you’re lucky) has been an eye opener. 

Tasked to bring in a new process, it would have been easy to slip into the wrong mindset – long spells of developer work, followed by copious manual documentation and a throw over the fence to a testing team for a few months. A few post-deadline back-and-forths between testers and developers thrown in at the end for good measure, obviously. I’ve seen it happen with installed software in far less regulated industries, and frankly, there’s rarely an excuse for it. Seven months later, we gained our ISO 13485 certification using the agile process we created. 

If you work where you don’t need to worry about your software telling someone they’re ill or not, and the thought of deploying anything less than daily horrifies you, this post might not be for you. It is interesting however that many of the fundamental principles and practices still (or should) apply even in a regulated industry. How did we steer clear of the waterfall trap? Here are the lessons we learned:

1. Get the right quality team

It would be easy for a quality team to force a process upon a new software team because that’s the way that they validate everything else – usually by using a hideously inefficient and burdensome quality software. Whilst that definitely exists, we were lucky enough to have a quality manager working with us that saw the need for agility, and how the systems that we implemented (in this case Azure DevOps) were a better match for compliance in an agile software development process. Having a quality team with this flexible mentality is crucial, and may require a lot of dialog upfront before anything new is implemented.

2. Get help from subject matter experts

Just to make sure we were on the right track, we consulted an external embedded software house that had experience implementing agile processes in the medical industry. There’s no way I was going to wave the Agile card if what we were proposing wouldn’t actually meet regulatory requirements. Luckily, there is a highly respected set of guidelines that offers some fantastic direction on the use of Agile practices in the medical industry (though the fact they felt the need to capitalise AGILE still drives me crazy).

3. Use DevOps practices

Turns out that if you follow the same good DevOps practices that high performing teams do, you’re most of the way to being compliant anyway. I was confronted with the unfortunate reality that most of our instrumentation products shared the same code repository, and relied on a gatekeeper to manually build the code in the correct configuration to produce the right product. The first task was to create a “master” build in Gradle that would take parameters based on which flavour software we wanted to build. Then, a separate build pipeline was built for each software flavour that built their respective installers and artefacts. We could then connect this to release pipelines for each flavour and have a record of all work items, pull requests and artefacts linked to a particular release was given to the validation team (and yes, there are rare occasions where a separate testing team makes sense – like when developers can’t use a pipette and people’s lives depend on it).

If you want to learn more about how good DevOps practices lead to high software delivery optimisation, read Accelerate or the latest State of DevOps report at the time of writing.

Start measuring your shippable work items so you at least know you’re moving the needle on deployment frequency. While a 10 day average isn’t ideal from start to ‘done’, it’s better than 60, and it’s getting more consistent.

4. If you don’t store your documentation in your QMS, you’re not going to burn.

Living, accessible documentation is essential for software teams to be agile. It’s no good gathering cobwebs in a quality system that takes an age to find anything (or worse, no one has access to). If you want to change your branching strategy slightly, you don’t want to be spending weeks getting a change approved by a QA who knows nothing about branching strategies.

Here is a blog by the consultancy I mentioned previously on the topic of living documentation for software teams in regulated industries. The idea is that your wikis / repos / markdown files are absolutely fine, as long as they’re kept up to date and go through a robust, audited pull request procedure and you’re able to produce them in an auditor-friendly format. This can all be automated, and in my experience, most modern software lifecycle systems are more secure and auditable than many quality systems on the market anyway.

5. Definition of Release

In healthcare, you’re not going to be releasing a product to a customer multiple times a day. At least not one that’s locally installed in a public sector environment. You generally have little control over the appetite for change of the various governing bodies and indeed individual sites. So then how can we conceivably aim to be an elite performing team according to the widely accepted DORA metrics? You aim to use all the previous steps to create validated, tested, shippable increments anyway. I mean everything – review lifecycle, packaging, deployment to an immutable release pipeline and signed off – preferably with automated documentation and release notes. If there’s a regulatory blocker, or the customer is simply reluctant to update their procedures with a new software module (even if it has features in it they’ve requested and want!), you’re still safe in the knowledge that those releases have gone through a complete release process in isolation and are ready to go. For us, that’s “production”. Just don’t let it end up like this:


In summary

In the time that we’ve had I’m pretty proud of my small team taking a 12 year old codebase that had no automation to speak of into a cloud-first, DevOps driven compliant process. Not only that, but we’ve learned a ton going through this process that will help us build our next generation of digital products. 

We’ve still got a long way to go. If anyone has any other insights in remaining agile in a medical setting, or you can see some hideous oversights in these lessons, please do let me know. Just don’t be mean.

It’s a cliché, but don’t accept the status quo or your environment as an excuse to abandon an agile mindset. Get the right people around you, make noise, and move the needle – one day at a time.

Why we should think before labelling someone as a millennial

My degree was in astrophysics. When I mentioned that I studied astronomy to people, the response, “can you read my horoscope?” was more common than I’d have liked. Why did that bother me? It wasn’t that people didn’t know what astrophysics was, or even that they were probably just trying to wind me up (success). It’s the idea that a huge swathe of the population can have the same characteristics based on when they were born. This perception is particularly bad news for Virgos in China applying for a job, for instance. So, when a seasoned manager described me as a “millennial” based on my wanting to understand the feelings of people, I set out to figure out why that evoked a similar response and why something so seemingly harmless could be a problem.

In the discussion, I was describing the Insights Discovery colour wheel (other personality profiling tools are available), explaining that I tend to align with the supporting-coordinator role. I explained that while this doesn’t define me, it indicates that I have strengths such as empathy, and taking a coach-first approach. I’m concerned with how people feel, myself included. The response was, “Oh, you’re definitely a millennial then”. They might as well have said, “Ah, got it. You’re a Taurus.” (I am, by the way).

There’s absolutely nothing inherently wrong with what the person did here. There was no call-out needed, no discriminatory slur, and to be crystal clear, I am not comparing this to any experience of marginalised or persecuted groups (based on race or gender for instance) who are still unfortunately attributed to dangerous labels on a daily basis. So why then in this “harmless” case can labelling still be damaging?

The story that I told myself I heard was, “Oh, you value people and care about how they feel? That’s a weird thing for a manager to do. It must be because you’re a millennial”. Far-fetched, I know (we’re all human, and we all fill in the blanks with stories). Even so, there were two implications here that didn’t sit well with me: One, that my generation could be branded so easily as all having the same characteristics (and controversial opinions abound as to why this could be). Two, that my values and purpose – the things that I’ve worked so hard for years to define and curate – have been given to me and my fellow snowflakes by the inevitable product of bad parenting, as Simon Sinek calls it a “bad hand”, and a series of unfortunate economic balls-ups.

millennial – noun – “a person reaching young adulthood in the early 21st century”

Google Dictionary

First of all, the definition of “millennial” from Google Dictionary (and many others concur) is “a person reaching young adulthood in the early 21st century”. So yep, objectively I am one. No argument there. If we’re looking at things the timeline can affect, I was raised by baby-boomers, in a time where I probably got a participation award at some point, thought I was entitled as a teenager (ever met one who didn’t?), and led a privileged, economically stable upbringing. I did go through the economic crash of 2008, losing tens of thousands in the housing market, and I did have crippling student debt. Whilst there’s evidence to suggest things are objectively harder for us as a generation, I question how any of this could have an effect on the values and characteristics of effectively an entire generation and why that would lead to a labelled generalisation.

At the end of my reflection, I think the issue was the implication that because I was an empathetic, coach-style, feel-first type personality, it must be because I was a millennial. I think it was the reduction of my self-awareness journey over the last few years to a label shared with an entire generation that made me contemplate how powerful labels can be. Lord knows I wasn’t always empathetic. I had some shameful experiences with junior developers early in my career. It’s taken some painful life events, some deep self-reflection, and learning how to support these values with resilience (not to mention a qualification in coaching) that I’ve defined and developed these values.

Here’s the reason why I try not to use labels. When you attribute a person’s individuality to an arbitrary group of people – when you reduce their life experiences to a label – you are dehumanising them. People’s lives are not just shades of grey, they’re rainbow coloured, an infinite spectrum filled with nuances and life experiences that shape them as humans. Don’t get me wrong, I like being labelled as a ‘coach’ – but I’d probably take issue if someone said “you’re a good coach, you must be a Taurus”.

When you attribute a person’s individuality to an arbitrary group of people – when you reduce their life experiences to a label – you are dehumanising them

When we’re about to label someone based on their characteristics, even if it’s just a subconscious bias in our head, it’s in our power to stop and think – is this label really a part of their identity that they’re proud of? Or are you taking away from their individualism as a beautiful, worthy and fallible human being?

Of course, my response in this case was not a 900 word essay. It was, “yeah, I don’t really like labels.” But then, that was a very millennial thing to say.

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.


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.


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”


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


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.


  • 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.


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.


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.


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.