Over Christmas I’ve been reading a fascinating book called The Chimp Paradox by Professor Steve Peters. The book introduces the concept that we all have two brains:
You (The Human) — this brain is responsible for intelligent, rationale and logical thought.
The Chimp — this brain is completely independent of you and not under your control. This brain thinks emotionally and is led by feelings and impressions.
The book argues that throughout life our two brains battle continuously in response to situations. The stronger Chimpbrain often wins, particularly in the moment as You, the human brain takes time to process information and to construct an intelligent and rationale response that considers all of the information available.
I am guilty (as I guess we all are) of not always thinking through the consequences of my actions and in particular not always considering how others might respond. Sometimes it is necessary to take an action which provokes an emotional response from another individual but strong emotional intelligence requires that we are cognizant when such a reaction is being provoked and what the outcome is likely to be.
I have been reflecting on my own approach both in my personal and work life. Sometimes I want to provoke a reaction. The question I have been asking myself is which brain has the response to the actions I take has come from and is it possible to tailor my approach in order to specifically target someone else’s human or chimp brain.
Experience tells me that sometimes in order to make someone sit up and take notice it is necessary to provoke an emotional response. The chimp paradox has reminded me that I need to have a game plan — when deliberately provoking an emotional response it is always helpful to consider how I will subsequently engage the respondents human brain; and how I will subsequently help the respondent to fight their inner chimp and logically rationalise my intention.
Learning from the Chimp Paradox in 2021 I am going to make an effort to get to know my inner chimp; both before and after I take action. I am going to carve time into my day to reflect on situations that have occurred and to evaluate which brain I engaged. I will also take time to consider which brain others around me are using and proactively consider how I can get to know the inner chimp of those around me.
My hope is that by taking time to understand how my inner chimp, and the inner chimp of those around me thinks, I can use this information to build my own emotional intelligence which in turn will help me to achieve my own goals and objectives.
My challenge to you in in 2021 is to take some time out and get to know the inner chimp of a friend or colleague. Taking this time might help you to tame your own inner chimp and focus more on positive human intentions and less on uncontrolled emotional responses that detract from your goals and objectives.
Above all when you are faced with an emotional reaction recognise that this is the response of an inner chimp and remember the words of Maxime Lagacé
“The most important thing is to look ahead. The past is your anchor.“
Now go find your inner chimp and ask your chimp if you can work together this year.
On a daily basis our organisation makes choices about what features can be released and what features are not yet ready to be put into the wild — sometimes this means that we allow functionality to go into production with known bugs and occasionally defects enter production without being noticed.
I strongly believe that we have a duty of care to our customers to make sure that our software is fit for purpose and to ensure that our software does not have any negative impact on our customers lives. Unfortunately sometimes the most innocuous bugs can have wide ranging unintended consequences that would surprise the most diligent development teams.
I am not ashamed to admit that I practice good sexual health by ensuring I have regular check-ups at my local sexual health clinic. After a check-up the clinic advises you that the results will take 4 days to process and they give you a number to call.
Going to the clinic is never a pleasant experience — but going to the clinic when you suspect that something may be wrong is a particularly unpleasant thing to do. Unfortunately that is the position I found myself in last year.
I’d be been tested and I was waiting for the results — as you can imagine it was a long wait but eventually 4 days had passed so I called up the number.
The automated voice asked me to enter my unique ID which I did and then pleasantly asked me to “Please wait while I look up your results”.
Now having used this service before the next step is normally that the automated voice informs you that your test is negative — on this occasion after nearly 60 seconds of silence the system said
“Please hold while I transfer you to an operator”
Now at this point my anxiety levels were going through the roof — I’d already spent four days fearing this test result and I’d absolutely convinced myself that I’d contracted something hideous — by the time the system told me to please hold I knew that there was something wrong — as a software developer I understood that you should never deliver bad news using an automated system — the reason I was now being transferred to an operator was so that I could be told the bad news by an actual human.
“You are now 12th in the queue and we will connect you as soon as possible”
So I waited — the system kept me in the queue for 35 minutes and I can honestly say it was one of the worst 35 minutes of my life.
Eventually — I am connected to Marie:
“Good morning, you’re speaking with Marie, please can I have your unique ID”
Now not withstanding the fact that I’d already entered my unique ID and I couldn’t understand why the system hadn’t been designed to automatically pass it to Marie — I gave it to her and a few seconds later she said
“Your results are negative”
At this point a wave of absolute relief spread through me — I was absolutely convinced this was going to be bad news and suddenly all of my fears were unfounded — this was good news, I was eurphoric — I spluttered back at her
“Why did the system put me through to you if the results were negative?”
and she replied
“It just does that sometimes”
Read that again …. “It just does that sometimes” — Now this makes me angry — I have many problems with this on many different levels.
First, this isn’t Marie’s fault, she’s working in a call centre — my problem with that statement is what it represents. This means that the failure is not a one off, it means that it has happened before and not only has it happened before its happened often enough that Marie, who is one of what I assume are hundreds of call centre operators working with this system, has been able to normalise it to such an extent that she can say “It just does that sometimes”.
That means it happens A LOT. Often enough for Marie to not think of it as an unusual circumstance. How many people are put through the agony of having to wait to be connected to an operator to be told that their results are negative?
Let’s explore what has gone wrong. Maybe the database lookup failed? Maybe there was a timeout error? As an end user I don’t care — what does matter to me is the emotional trauma that I went through prior to getting my results.
Now you can argue that I’m making a big deal out of this; does it actually matter? Or, is this just another 1st world problem?
From my perspective, I genuinely thought I had a hideous disease — and some of those diseases could be life threatening — so forgive me — but I think it is a big deal!
I can’t imagine for a second that the product owner set out to create such a poor experience for the end user. I don’t believe the developer intended the code he put into the wild to have such a negative unintended consequence and I’m sure the CEO of the organisation responsible for this experience would be devastated that his organisation was responsible for the emotional trauma that his system had caused.
Working in delivery for a large corporate organisation I am ashamed to say that I can see exactly how this experience has been allowed into production. It is all to easy to understand that this system had a date on which it had to go live — that date would likely have been attached to a business case which released funding and as a result I am quite sure that those delivering the system were under pressure to get it out of the door on a specific date in order to meet the business objectives.
The developer may have even noticed that the database query occasionally failed — perhaps it only happened one in every 1000 times and maybe the business took an active decision that fixing the issue was to costly at that moment in time.
The wider issue is that once code goes into the wild it is often in production for years, with little or no funding available to go back and remediate minor issues — once the system is live unless there is a big security problem or other regulatory issue it becomes very challenging for businesses to justify the money to do further work — and a database query which fails 0.1% of the time is unlikely to meet the threshold required for further investment.
Is that ok? Is it morally acceptable for me to have been put through this psychological trauma — does the money which was saved by not testing these edge cases justify the experience I had when I called to get my results?
Now you might say that this is an extreme example — that very few systems would have unintended consequences that would have such a direct impact on people’s lives — and that might be true — but all systems can have unseen consequences and those consequences by their very nature will affect users in unexpected and often undesirable ways.
I believe that within our industry there is no higher purpose than finding ways to surprise and delight our users. Yes, sometimes compromises are needed, and yes sometimes systems won’t be perfect — but as a community and as an industry we need to make sure that we do everything in our power to make sure that we don’t adversely affect the lives of our customers.
As Software Engineers our reputations are on the line — a bad experience here, and a poor experience there will lead customers to talk about those experiences and this will lead to negative press.
You never know, someone might just write a blog post and tell everyone how bad the experience is or maybe the experience will slip under the radar silent and unnoticed. The question we must ask ourselves:
“Is this morally acceptable?”
We often find ourselves morally challenged — There is a climate emergency; parts of the world are starving, it is still illegal to be gay in more than 70 countries. These are big problems and we must do our part to help improve our planet.
And yet as technology professionals we find ourselves in a unique position where we are able to directly affect and change the lives of thousands and in some cases millions of people.
In the grand scheme of things having to wait 35 minutes to get my test results might not seem like a big deal — but the software team that created this product had an opportunity to make a direct improvement to my life and to the lives of thousands of others calling up to receive their results — was it morally acceptable for this opportunity to missed?
Have you ever come across a system that had a negative impact on your life? If you work within a development team do you always consider the negative and often unseen impact an unresolved bug might have on your customers?
Please reach out to me on Twitter and share your own experiences and explore which bugs you consider to be morally acceptable.
I have often pondered what makes a Senior Developer “Senior” and what makes a Junior Developer “Junior”. Invariable such titles are bestowed upon software developers based upon where they are in their career and how many years of experience they have.
The idea that the number of years you have been doing a job is in my view quite an old fashioned idea. In some industries this may be valid; clearly I would prefer to be operated on by a heart surgeon with 15 years experience as opposed to a surgeon who is newly qualified – that said even in this context the newly qualified Dr may be versed in more modern techniques that the seasoned surgeon may not have knowledge.
I’m not suggesting that experience shouldn’t be considered but I would suggest that we are more interested in the skills that an individual has. Experience means that the individual has had longer to gain those skills but it in no way guarantees that the individual has used the time wisely.
With this in mind recently I’ve been giving some thought to how we should measure the performance of our developers and how to support them in building skills that benefit us as a company.
One of the tools that I have developed to help with this is a Developer Skills Matrix. The concept is really simple – across the top I list all of the skills that I want my developers to have and down the side I specify levels of knowledge (No Knowledge, Basic, Good, Great, Superstar).
When specifying the skills its important to drill down to a granular level of knowledge; being to broad brush doesn’t give you enough detail. In the example above you might be tempted to group all of the skills under the heading “React” – this would limit the benefit of the matrix as it is perfectly feasible for a developer to have no-knowledge of Redux and still be a great developer.
The idea is to create headings which cover areas that a developer might have knowledge or could be expected to have knowledge in order to effectively do their job.
In order to make best use of the ratings its important to provide clarity on what level of knowledge you would expect an individual to have in order to achieve the rating.
I use the following guidance but it can be adjusted to suit your own context.
You might have heard of the technology but you’ve never used it.
You have a working understanding and are able to make basic use of the concept or technology. You would usually ask a lot of questions and rely heavily on others to support you in any implementation work.
You are comfortable using the concept or technology as part of your everyday work but struggle with some of the advanced concepts. Sometimes its good to get help from someone who has more experience than you.
You are really comfortable with the concept / technology and feel you have a great working knowledge of most of the more advanced concepts. You can identify when people are incorrectly using the concept or technology and will offer support to assist them.
You know this concept / technology inside out and are a subject matter expert. You are able to support, help and teach others at all levels. If a stack overflow question were asked related to this area you would jump right in and answer confidently.
Once you’ve set up your matrix ask your Developers to complete it. I like to ask Engineers to justify their ratings in each area – this in turn leads to good 1:1 conversations and also helps normalise ratings across the development team.
Scoring the Matrix
When the matrix has been completed by the whole development team I like to score the matrix. No Knowledge = 0, Basic = 1, Good = 2, Great = 3, Superstar = 4.
When view across the whole of the development team this scoring allows you to identify areas of team weakness, where perhaps you have limited knowledge as a company in a particular area. This can then inform your recruitment strategy by identifying the areas you want to particular focus on when interviewing potential new joins.
The scoring can also be used to identify weaker team members or to help inform performance conversations. I would caution that this is not a silver bullet and should not be used as the only way to measure an individuals performance but it does open up some opportunities to recognise your staff and to inform clear and quantifiable objectives.
Ways to use the data
There are many ways to use the data to help your teams with continuous improvement such as:
Identify 3 skill areas where a developer has no knowledge. Set an objective that by the next performance review the developer will have basic knowledge in all 3 areas and ask the individual to provide evidence of their achievement.
The knowledge can be gained in a variety of ways such as independent research, an online course or pair programming. The method isn’t important but the commitment to improvement will benefit both the individual and your company. You know this concept / technology inside out and are a subject matter expert. You are able to support, help and teach others at all levels. If a stack overflow question were asked related to this area you would jump right in and answer confidently.
Company / Team OKRs
If you use Objective Key Results within your organisation then this data can be used as a quantifiable measure of performance improvement.
Objective: As an Engineering Team we will continually improve the skills required to build our products:
Key Result: The average score for every skill should improve each quarter.
The skills Matrix is not a silver bullet – it can be used as one tool to help with your overall performance management strategy.
When I first considered introducing this tool into my team I discussed with other Engineering Managers in my network and I heard horror stories of similar frameworks being abused – in one case engineers had nicknamed the tools “The redundancy framework”.
Like all tools its success is very much dependent upon its implementation – if implemented well as part of a wider performance strategy the framework can help identify areas of weakness within the team and help guide areas of focus for improvement over time.
Have you used a framework like this in your organisation? If you have I would be really keen to hear from you – please comment below or reach out to me on Twitter @stevewestgarth.
In this day and age it is almost inconceivable to imagine a world without “the car” or other motorised transport. It is hard to believe that the car was only invented in the late 1880’s and even harder to accept that motorised transport has only been common place for the last 80 years.
During this time, society has moved at a tremendous pace, which has led to the introduction of health and safety legislation that now controls all aspects of our day to day lives. It is therefore interesting to ponder what would happen if the car had been invented today.
Let’s imagine that the automobile did not exist and that an inventor puts forward a proposal, suggesting that it would be a good idea to create a machine that has four wheels, controlled manually by someone, who for the purposes of this article will be referred to as the driver.
In order for the machine to work a large (typically 40 litre) tank of highly flammable liquid would be strapped to the underside of the vehicle and this liquid would then be ignited and pumped through an engine placed in front of the driver, in order to propel the machine forward.
The proposal would need to suggest that the flow of flammable liquid would be controlled at the whim of the driver via a pedal mechanism allowing the speed of the vehicle to be increased or decreased as required.
In order to mitigate the risks associated with the idea the proposal would suggest that rules would be put in place stating that the maximum speed that the machine would be permitted to travel and guidelines would need to be developed stating safe speed limits on each stretch of tarmac (roads) that the vehicle used.
In reality, however, nothing but the power of the engine would prevent the vehicle going far faster potentially reaching speeds of over 130 miles per hour in standard automobiles, but potentially far faster in some models.
Assuming this concept, by some miracle, was approved and allowed to go ahead, consider if you will how an inventor could sell the concept of producing 30 million of these machines and then allowing them to be used on roads travelling at these high speeds in opposite directions.
To push the boundary further is it conceivable that the idea of a motorway would be accepted; a road which is specifically designed to allow these machines to travel at high speeds and facilitate the concept of vehicles overtaking one another when a driver feels another driver isn’t travelling fast enough.
This description sounds almost farcical given that in today’s society it is necessary to do a risk assessment for the most mundane task. It seems ludicrous that such a dangerous proposition would ever be permitted to go further than planning stages, if indeed it was ever given any serious consideration.
This opens up a related debate as to whether modern health and safety principles are stifling innovation and creativity. Had the car first been proposed post millennium it is unlikely that it would have ever been allowed to go ahead; it is therefore conceivable that great inventions that could revolutionise the human race are being prevented due to bureaucracy, which, is not proportionate to the potential risks of the task, problem, or idea.
The argument can be applied in principle to many innovations that have allowed man kind to develop over the millennia, including electricity, nuclear power, and coal mining.
This article serves as a warning to society that our history is based on innovation and growth and in the modern world it would appear there is a real danger of stifling that innovation which could jeopardise progression and lead to a society that forgets how to innovate.
Those of you who know me will know that I really value conferences. The opportunity to take some time out to learn, develop and grow is so important in order to contribute to our community, to network and to share ideas.
This week I have been privileged to join Lead Dev London at the Barbican Centre. The conference itself has been hugely well organised and I think Meri Williams needs huge kudos for being an excellent host.
On a personal note it is also hugely refreshing to see diversity and inclusion at the heart of an event. June often sees companies and events go all rainbow coloured but so often this is simply a token gesture – Lead Dev have really thought about how to ensure that everyone can participate fully in the event – from rainbow lanyards, to pronoun stickers, to live captioning, to free childcare this event has done a great job and I would encourage other events to follow their example!
So lets take a look at my best bits of the conference! It really has been an amazing two days!
This was a great opening keynote for the conference. Its so important to understand the phases that teams go through and to find ways to allow the team to progress naturally through the phases of team development. Lara succinctly summarised what to expect during team development and reinforced the idea that the forming, storming, norming and performing cycle really is a cycle. She has also written a book on Resilient Management I haven’t read it yet but its totally on my reading list.
If you have ever used Objectives and Key Results this talk radically challenge the way you’ve written and thought about them. The biggest takeaway from this talk was to stop setting OKR’s for individuals, focus on the teams and rather controversially remove the numbers from the goals – I totally agree that nine times out of ten such numeric goals are Scientific Wild Ass Guesses (SWAG) – and thank you for the new term to quantify what I already knew!
Building Security Culture on Infrastructure Teams – Franklin Hu
How long is a piece of string: the key to solving the conundrum of software estimation. – Jonathan Rigby
This is a problem that I have grappled with in every role I have undertaken – Jonathan argued that the true resolution to this problem is all about trust that expectations will be effectively set with stakeholders by team members. We need to trust that developers will give honest estimates that truly reflect the work that they think is involved and trust on the part of the product owner that they will not make hard and fast promises to the business based upon those estimates. Alternatively, if all else fails we could always join the #NoEstimates movement – getting more work done in the time you would have spent producing inaccurate estimations – GREAT CONCEPT!
So many other talks deserved a mention in this post – videos are apparently on their way soon so you can check them out yourself and I’ll post a link when it becomes available! A huge thank you to everyone for a great two days and hope to see you all again next year!
Joining any organisation in a management position is challenging; you will likely have people reporting directly to you (directs) and you will also be reporting into a more senior manager yourself.
Prior to your arrival in the role it is likely your new directs will have been told that they are about to get a new boss. This can be incredibly nerve racking for the individuals concerned and will have likely been asking themselves questions like “What is s/he going to be like?”, “will we get on?”, “what if they don’t like me?” and “how can I make a good first impression?”.
What is often forgotten is that the new manager is likely to be feeling the exact same feelings but from an alternative perspective and within this lies an opportunity for a meeting of minds.
My approach when joining an organisation is not to immediately force the relationship; meet your new directs as soon as you can and start with the principle of just being a nice person. Try to find out something about them and try to find common ground both inside and outside of work.
As I started my new role at Boots one of the key strategies I have adopted is to ask everyone that I have met about the challenges they are currently facing within their role and the challenges that they feel are currently being faced by faced by (in my case) the Digital Portfolio within the organisation. My intention in focussing on this question is:
To understand where there are common themes. Are different people reporting the same challenges from different perspectives.
To evaluate where I need to focus my attention most urgently and the areas that I might be able to have a positive impact.
To open up a dialogue where I am clear from the outset that I am here to help and that I will work with the individual to help them to remove their pain points.
The same is true of my directs. In asking these questions it immediately sets a tone that I want to help them to succeed. Where challenges exist I can then work with the individual concerned to help them to overcome the obstacle.
I’ve recently been reading some very interesting articles about the difference between a Boss and a Leader (more posts on this soon). My belief is that from the very first conversation you have with a new direct report you need to ensure you are displaying leadership attributes as this sets the tone for all future conversations that you have with the individual. If you’ve missed this opportunity and haven’t been able to set the right tone from the outset don’t panic – its definitely not to late to change the dynamic but it becomes a little harder to do so.
In my experience making the first impression count is incredibly important; you only get one chance to create a first impression and if you get the relationship off to good start you can remove the mutual nervousness that you and your new direct are feeling. It is your responsibility as the new manager to own this first impression.
If you have any thoughts on how to approach meeting new direct reports please comment below to continue the conversation.
In the last few months there has been a huge amount of change in my life which has culminated in me being appointed as the Engineering Manager for Boots UK in Nottingham.
Digital at Boots is in a really interesting position; you only have to look at the climate on the high street to realise that retailers need to adapt or die. Boots have clearly expressed a vision to enhance digital and focus on in store experiences.
In September a new CEO was appointed for Boots UK – Sebastian James comes from a strong retail background having previously been CEO of Dixons Carphone. In his role at Boots is opening stating that digital transformation must be at the heart of the business.
Joining Boots as the Engineering Manager provides me with a unique opportunity to shape the development of digital platforms across the business focussing on Design Driven Development to drive our customers digital experiences.
Having previously worked in small business environments this change is a radical shift in my own career progression. Taking some of the ideas and initiatives I have introduced on a much smaller scale and providing me with the opportunity to see how these models can scale for use in a large corporate environment.
Over the coming weeks I intend to document my journey and the journey of Boots UK here on WestgarthsWeb as we reinvent the digital experience of one of the UK’s best known retailers!
If you have any comments, feed back or questions please feel free to reach out on Twitter.
Recently I’ve been giving a lot of thought to design patterns within .NET Projects. I was invited in February to give a talk at DotNetNotts and I explored the Unit of Work Design Pattern which is often selected as a valid design pattern by developers due to the way it conforms to the requirements for separation of concerns.
The approach does however break several of the SOLID principles and this has lead many to favour other patterns and approaches.
Below is a recording of the talk given in February 2018. Would love to hear your feedback