The Engineering Leader

The Engineering Leader is a brand new podcast that I launched today with my first guest Adam Rush, Technical Director at Stream talking about Developing for iOS. The podcast is aimed at helping the Engineering community to collectively raise the bar by sharing best practices that have been implemented by leaders working in some of the worlds most successful engineering organisations.

Click Here to listen to the Podcast

So why me? I am the Global Head of Engineering at Glaxo Smith Kline Consumer Healthcare; prior to this I headed up software engineering at Boots working predominantly across the customer channels including and the Boots Mobile App.

I have been leading software engineering teams for more than 14 years and have worked for both small start-up and large enterprise. Throughout my career I’ve got to know people who know how to build software really well and I’ve also encountered people and organisations who make choices that really limit the potential of their engineering teams. Seeing the mistakes that organisations make has really inspired me to want to help the industry collectively do better; and its important because the software that we are building today is going to shape the technology landscape for the next decade.

I want to use this podcast as an opportunity to help us as an industry get better at building software. We are all still learning the best ways to develop software primarily because software engineering as a career is still less than a generation old! Charles Babbage may have invented the first computer in 1822 and Apple and Microsoft may have been founded in the 1970’s but our modern popular understanding of software engineering as a serious career choice didn’t really come about until the 1990’s when we entered the age of the internet.

Software Engineers working with modern programming languages have learnt everything they know within the last 40 years; that’s within my life time. I am 35 years old and I can remember not having a computer in my house. Compare this to other industries; King Edward the 1st created the first modern lawyers more than 800 years. The first double entry book system was used by accountants in 1494 and the industrial age that modernised factories started in 1760. It is therefore not surprising that we are still learning the best ways to build software because the digital age has, relatively speaking literally just started.

With this podcast I am going to be talking to people who are working right at the top of their professional game; people working within organisations who truly understand how to build great software product and change agents who are successfully helping their organisations to digitally transform. The podcast is totally unscripted, its just me having a conversation focussed around current topics that are relevant today within the Software Engineering Community.

In the coming weeks I’ll be talking to leaders like:

  • Michelle Kearns Head of IT for Boots Ireland who will be sharing her experience of working with Healthcare Tech.
  • Dario Incalza who will be sharing his insight into DevSecOps and how he goes about ensuring that security is at the heart of his Engineering Squads.
  • Alex Karp who will be reflecting on the role of the Engineering Manager and how he goes about building high performing teams at Twitter.

I really hope you find it useful, if you do please reach out to me on twitter @stevewestgarth or search Steve Westgarth on LinkedIn.

I’m also actively looking for people who would like to contribute to the podcast, if you have something interesting to say please don’t hesitate to reach out.

A Great Place to Work

January 2022 brings with it mixed emotions for me as I prepare to leave my role as Head of Engineering at Boots and move onto pastures new (more on that very soon). Over Christmas I’ve been contemplating the experience I’ve gained at Boots and how much I’ve enjoyed working within the organisation over the last 3 years.

I very much saw joining Boots as a career defining moment and I will be forever greatful to Joe Elevathingal and Sarah Marsh for bringing me to the organisation — the opportunity to work with one of the UKs most loved brands was, and has been an absolute privilege and I know I will look back on as a highlight of my career. If you stop and think for a moment, how many people get to work with an organisation that literally touches the lives of millions of people everyday?

Over the last 3 years I have had the privilege of helping the organisation to change in ways that simply were not even imaginable when I joined. As a retailer we need to respond to the needs of our customer ever more quickly in order to stay ahead of the competition. I’ve helped Boots to embrace a more agile mindset, setting our teams up for greater success by developing SAFe agile release trains and forming cross functional delivery squads that are moving towards a CI/CD mindset based around a modern cloud native technology stack.

From an Engineering perspective it is fair to say that Boots still has a long way to go to achieve its ambition of being a truly modern engineering organisation but the passion and enthusiasm of the people within the organisation to change and adopt new ways of working really is infectious.

Choosing the company that you want to work for is a very difficult decision; for me its important that the organisation I work for is making a difference. During the pandemic I have unwittingly found myself on the front line of the UK’s response supporting our stores, team members, patients and customers in ways that I would never have imagined. The community spirit within Boots is palpable and the joy of being part of a team who truly want to impact peoples lives in a positive way has driven me to realise how privileged I am to have been able to support this amazing organisation.

There have been so many achievements during my tenure at Boots, almost to many to mention. For me the launch of Adobe AEM which now serves the Homepage, Brand, Article and Category pages is probably the greatest success and technical accomplishment; we cannot however diminish some of the other great success stories such as launch of Algolia search, replacement of our customer identity and access management solution and where would we be without our cloud native customer engagement platform that is rapidly becoming the future for

Each of these achievements, and many others have been made possible due to the passion and enthusiasm of the people that work at Boots. It is the people that make Boots an amazing place to work and the people that have enabled all of these phenomenal success stories that I have been proud to be a part of. I have never worked within a more dedicated and inspiring team and for that I thank all the colleagues that I have worked with for giving me a reason to want to come to work each day.

While I can’t name everyone at Boots that I am going to miss dearly I do need to give a special shout out to all of my direct reports — during the last 3 years you have helped me to grow as a leader and I hope I have provided opportunities for you to also grow, learn and develop your own careers — it has been a pleasure managing each and every one of you and I really hope that we have the opportunity to work together again in the future.

Leaving Boots has been a big decision for me; I am focussed on developing my own career and the opportunity to have an impact within an organisation on a more global scale is simply to good to turn down. I can honestly say I have loved every moment of working for Boots and I wish the organisation every success in the future — it would be an honour if our paths did cross again; for the right opportunity I wouldn’t hesitate to return.

Why Agency Agile Is Broken

Countless books have talked about why organisations need to adopt an agile way of working; the promise of delivering value faster and ensuring that the customer ultimately gets what they want because they can change their mind and reprioritise requirements is an alluring prospect.

Unfortunately introducing an Agile way of working within an agency often results in unmet expectations and a feeling that Agile didn’t deliver everything that was promised.

Let us explore a typical “Agile Project” within an Agency.

Meet Chris (the sales person). Chris is really pleased that he has a lead from a new company and feels confident the agency can deliver the work required.

The project starts well — the client comes into the office and explains their requirements. Chris invites Joe (Technical Expert) into the room to assist with the sales process; Joe listens carefully to what the client says and articulates confidence that he understands exactly what the client is looking for.

In some agencies a project discovery phase may be sold to the client — this is usually a meeting or series of meetings which allow Joe and his friends to drill into what it is the client actually wants and ensure that they have a really good grasp of the requirements for the project.

At some stage during the sales process Chris will explain to the client how the project process works and the client is introduced to the concept of an Agile delivery. Invariably the conversation will go one of two ways:

Time and Materials

The agency explains to the client that they work in an Agile way and as a result the client can change their mind and re-prioritise requirements as the project progresses. For this reason the agency can’t give a fixed price and instead will estimate each of the requirements based upon the number of days required to complete the work.

The client is asked to place a work order for a fixed number of days to be used to deliver the highest priority requirements. If the client adds additional requirements they will be estimated and then prioritised accordingly. This might mean that lower priority requirements can’t be done because the client hasn’t purchased enough days — the client can either forego the requirement or purchase additional days to get the work done.

The client signs up to this approach confident that they are in control and that they effectively have a fixed price because they know that they won’t add or change any of the requirements during the project.

Team Velocity

The agency explains to the client that they work in an agile way. The agency has a SCRUM team available to complete work and the team is able to deliver x points of value per sprint.

Each requirement will be estimated according to size and this will be converted into a numerical value using the Fibonacci sequence (a significant amount of the meeting is spent explaining this concept to the client). It is agreed that requirements will be prioritised by the client and will be grouped together into a sprints worth of value.

The client is asked to place an order for a set number of sprints worth of work. If the client adds additional requirements they will be prioritised outside of the current sprint. This protects the work currently being done by the agency and ensures that the entirety of the clients budget isn’t wasted by going down one particular route without checking in with the client.

The client signs up to this approach confident that they are in control and that the overall project budget is protected. The project is effectively fixed price because the client knows they won’t add any further requirements and there are milestones in place at the end of each sprint that can be used by the client to check progress.

Following this initial meeting the company will undoubtedly want to produce a proposal. In this document the company will replay what they have been told by the client to provide confidence that the requirements have been understood. The client will sign on the dotted line and the project will begin.

Typically the project starts well; delivery seems to be on track and the developers make all of the right noises during daily stand-ups (The Agency has started doing these because that’s what Agile organisations do — in reality it is an opportunity for the Project Manager, Jim, to demand an update which can be given to the client).

The client is given regular updates by Jim (who may or may not have been involved in the discovery phase) and they are pleased things seem to be on track and progressing according to plan. As the project progresses things start to go wrong:

Something was under estimated

A specific requirement was estimated as a small task that should only take a day to do — this isn’t actually a small task and takes 8 days to complete. At the end of the sprint the client isn’t happy that everything which was promised hasn’t been delivered within the agreed timescale.

Jim explains to the client that the feature took longer to do than expected and advises that the work will be prioritised in the next sprint. The client asks who is paying for the next sprint and states that they shouldn’t have to because the estimation is at fault and states that Chris promised that the company were really good at estimating — in the clients view as the agency was responsible for estimation it is the agencies mistake and as a result the work that was not completed should now be finished for free.

In return the client will graciously accept that the deadline has slipped but advises it is now critical that no other deadlines are missed or their project will be severely impacted.

In case you hadn’t noticed — the concept of Agile is now forgotten and we are effectively working fixed price waterfall.

Another project is experiencing problems

The clients project is underway and progressing well. Another project is experiencing some issues (perhaps it is the project referred to above where something was under estimated) the developers are asked by Jim to help get the other project over the line and immediately stop work on the clients project.

At the end of the sprint everyone is surprised that the clients project hasn’t made as much progress as was expected; Jim explains the problem to the client and the agency agrees to continue working on the project at no extra cost to get the work over the line. The client accepts that the deadline has slipped but advises it is now critical that no other deadlines are missed or their project will be severely impacted.

Once again we have slipped into a fixed price waterfall mindset.

The scenarios described above may be repeated several times. By the end of the project the client is generally ‘happy’ that they have a deliverable that broadly meets the requirements that was originally outlined. It is likely they have a sense that they have had to compromise on some features but they accept this as they have worked in an agile way and this was explained to them at the outset. The project has taken longer to deliver than anyone thought it would but the client is happy because they have only had to pay for the work that they committed to so their budget remains intact.

If any additional money has been spent it is for something brand new that definitely wasn’t mentioned in the initial project meeting. We know this because even though the client was “absolutely sure” that it was mentioned in the meeting the agency has spent several hours going through the proposal internally and grilling everyone who was at the meeting asking them to remember what happened in the room several months ago just in case the client had mentioned the new thing in passing.

After much negotiation the client reluctantly accepts that it was not part of the original requirements and agrees to pay for the bare minimum amount of extra work in order to make sure the new thing gets done.

Sound familiar? I have seen the project process above repeated within countless agencies. The harsh truth is that although everyone involved in the process firmly believes that they are working in an agile way the process described above can at best be described as “fr-agile”.

The agency has taken the bits of agile that sound good to the client and have sold a dream of being able to change requirements and deliver things quickly without also ensuring that the client is subscribed to the reality that they are also working in a world of estimation uncertainty. As a result the agency has inadvertently taken on the uncertainty risk because when things go wrong the agency gives ground in order to make sure the client is a happy customer.

Fixing Project Variables isn’t Agile.

The starting point for fixing the problem is to understand why the approach outlined isn’t agile. Let us consider a waterfall project — in projects of this type organisations try to fix the 3 project variables:

  • Time
  • Scope
  • Budget

Agile methodologies recognise that in order to adapt to change all 3 of these variables cannot be fixed. In an agile approach typically budget and time will be fixed by virtue of the fact you have a set number of resources working for a given period of time, i.e. a sprint.

Agile methodologies recognise that in such circumstances it is not possible to fix scope because of the degree of uncertainty found within software development projects.

If we map this onto our typical “Agile Project” it becomes clear that the clients expectations were mis-set during the initial project meeting — estimating features in terms of days or story points allows the client to build a phycological bond between the money they are paying and the estimation that has been given — it is this phycological contract which is broken when a piece of work has been under-estimated and delivery therefore takes longer or when less work is delivered that was originally promised.

A better way ….

In order to move beyond fr-agile ways of working clients and agencies need to embrace the true essence of what it means to be Agile.

A good starting point is to review the Agile Manifesto. The first statement is that a truly agile organisation values

“Individual and Interactions over processes and tools.”

In my view the solution the agency agile problem requires agencies and clients to establish a close and trusting bond where both agency and client are incentivised to do the right thing and work together in order to meet the objectives of the engagement.

For an agile project to be successful the whole team need to work truly as one organisation. Both sharing in both the successes and failures of decisions that are taken.

Agencies must build a bond with a client where we move away from a traditional customer supplier relationship and move to a world where the everyone is aligned and incentivised to achieve the same goals and ambitions. This requires both parties to truly embrace moving beyond a fixed scope agreement and understanding at a deep and meaningful level what success really looks like.

The solution to the problems highlighted in this article are not easy or straightforward; but solving a problem begins by identifying that there is an underlying issue and agreeing that there is a problem which needs to be solved.

The premise of this article is that Agency Agile is broken; what are your views? Have you encountered an agency that faces the problems outlined in this article? Perhaps you have worked with an agency who has been able to move beyond the problem and create an environment where both client and agency successfully partner to create a shared outcome, shared risk and shared reward engagement?

Please reach out to me and share your experiences — @Steve Westgarth

Out with the old …

A little thing happened today …. I say it is a little thing but to me and my colleagues at Boots it is actually quite a big thing.

Today we launched the new homepage and our new CMS Adobe Experience Manager (AEM).

In the grand scheme of things this might not seem like much — websites go live everyday with varying degrees of fanfare but this particular release is a big thing for us and has been the all encompassing focus of my team for the last 12 months.

When I joined Boots there was a big ambition. The organisation had a very complex brown field technology estate and was very aware of the need to modernise the digital capability and embrace a composable commerce solution built on a modern cloud microservices stack.

The organisation had rationalised that the first step in making this transition was to create a headless front end; moving the user interface away from Websphere Commerce Suite (WCS) and building out a cloud native user interface (enabling faster speed to market for feature development) using a modern Javascript framework.

In the first days and weeks in my new role I considered that such a change would be relatively straight forward and a sensible first step; little did I know how difficult that journey would be and the problems we would encounter along the way.

For those of you who are interested here are some of the issues and challenges that we have overcome in the last 12 months:

The Concept of the Donut

This problem seems like it was encountered a lifetime ago, but its actually become fundamental to our approach. WCS is a huge monolithic application and everything is very tightly coupled. In considering how we might adopt Adobe AEM in a truly headless solution we were faced with a stark reality that there is a huge amount of functionality contained within the header and footer of our website:

User Login
Mini Basket
Site Navigation
Analytics / Tagging + a whole host of functionality (and tech debt) which makes the current site work today.

The desire to build out a headless front end required all of the functionality listed to be re-built in React. More than this though, it required all decisions related to these features to be known and agreed upon upfront.

Our strategy is to build a new composable commerce application using best of breed technology– we therefore needed to agree what technologies would be supporting each of these components and agree the target architecture of the site before the build could begin in anger. The analogy of knowing where you are going on holiday before you get on the plane never felt more real.

It quickly became clear that the timelines attached to this were going to be unacceptable and incredibly un-agile — we needed to break the problem down and deliver in an incremental way — the concept of Minimal Viable Product was discussed but in reality stakeholders (and our customers) didn’t want to loose functionality we already had on as part of our transformation journey.

Enter the concept of the donut. Our solution was to leave the header and footer of intact on WCS and read the existing HTML into our new microservices application. We then injected the new homepage content in between the header and footer — the homepage content effectively became the jam in our donut.

Taking this approach allowed us to kick the can down the road on a number of critical problems such as shared state, session management, integration of product data and a number of other issues. We focussed our attention firmly on what we believed would bring the highest customer value, a fresh responsive design built using a modern CMS and the ability to begin leveraging the power of the Adobe Marketing Cloud.

The solution isn’t perfect — the header and footer still contains a lot of technical debt and we haven’t been able to realise all of the site performance improvements that we want — but we have taken one very big step towards our end state! We also know that we will be able to incrementally address these issues over time and are confident in our approach.

This answers the key question that the eagle eyed amongst you will be asking:

“Why is the header on the old homepage and the new homepage the same?”

The simple answer – it is …. but not for long. We can now start to incrementally build out the header and footer components and also take those elements headless over the coming months.

Style Bleeding

Adopting the donut didn’t resolve all of our problems in fact it introduced a number of other issues that we have needed to overcome.

One of the key issues we encountered was the issue of style bleeding. This occurred because the WCS stylesheets hadn’t been written using BEM notation and therefore over-rode styles contained in the react application.

The solution was to create a template wrapper that performed a full CSS Reset on content held within it — this wrapper now encapsulates all of the AEM content making up the jam in our donut.

Shared Header / Footer

Although we took the decision not to build the new header and footer as part of the initial phase we did need to consider how our approach would scale as we continued to build out our headless front end.

To that end we explored the phased transition states that our header and footer would go through beyond the go live of our homepage.

The solution was to create a microservice to serve our header and footer to WCS and also any micro frontends that we might choose to create either now or in the future.

This service will be in our estate for a long time to come and provides the glue that will hold together our consistent user experience well into the future.

Routing — Content Served from WCS or AEM?

Today we have launched our new homepage, but over the coming weeks our business teams will be migrating all of our Department, Brand, Article and Category Pages onto Adobe Experience Manager which will bring our fresh new look to the whole of

This means we have now entered a hybrid state with some content served from WCS and other content served from our microservices application. The problem? How do we make sure that new AEM content is served to the customer (as opposed to WCS content) when it is available?

Our solution was to create a service which is known affectionately as the decider of destiny. This service now forms part of our digital edge services and directs traffic based upon what content is published in AEM — effectively maintaining a routing table that determines if the business have published AEM content and serves it to the customer if it is available.

AEM Preview

Editing and previewing content across the end to end customer journey was a critical requirement for our business teams. The issue we encountered was that as we move into our hybrid state we needed to enable the business to preview content across our microservices application and also the legacy WCS estate.

Our solution was to leverage the power of the Adobe Single Page App Editor and preview capability. Sitting here today this is a really obvious solution but 12 months ago when we embarked on this journey the SPA editor was still in beta and we really didn’t know if it would be able to handle all of our use cases.

It turns out our gamble paid off and the result provides an incredibly powerful way to scale our preview capability as we continue the development of our new customer experience.

Over the course of the last 12 months the team have resolved these issues and a whole host of other problems — turns out creating a headless front end does bring a lot of unexpected challenges particularly when facing into a brown field technology estate.

We still have a long way to go on our digital transformation as we gradually rebuild our website on a modern cloud technology stack. Each increment takes us a little closer to our target state which will enable us to leverage the true power of CI/CD and unlock agility and speed of delivery which will truly transform our ecommerce platforms across the Boots organisation.

Today is a big milestone, and a huge achievement! Today marks something that everyone on the team should be incredibly proud to have been a part of — I know I certainly am!

It is also heart warming to hear what our CIO Rich Corbridge thinks of today’s achievement.

“This change is one of so many big advances that happen to Boots over the next 3 to 4 months, an ambitious change that places the customer at the centre of every thing we can do for them on a digital platform.

Our customers love the Boots store, these changes begin to enable that same love to transition to the way we are reflected on line. Every part of Boots is involved in how we make this change, truly inspiring to see how the whole organisation understands and gets behind what so many others would describe as a technology change!”

I want to use this opportunity to thank everyone who has contributed towards this achievement from within my own team, our partner organisations (Including Adobe and IBM IX), other teams within Boots IT and the wider Boots business. What has collectively been achieved today is truly transformational, you all need to be congratulated on this success and on a job very well done!

To our customers, I really hope you like the new look and feel! Please take the time to reach out to us and let us know what you think, the team would love to hear your comments and we hope the new experience brings a little extra joy to your day.

As for me, I’m incredibly proud to work for Boots and to lead an incredibly talented engineering team of truly inspirational and very talented individuals. Thank you all for bringing your A game to work each and every day and giving me the opportunity to be part of a truly miraculous digital transformation journey.

Agile Tools: The Burn-Up Chart

Organisations are embracing agile delivery models at an unbelievable rate; a huge range of methodologies are being adopted in order to allow large corporations to make sense of doing things in a new and unfamiliar way.

All to often we see agile being interpreted as an “IT Thing”; as a result other parts of the organisation feel that they don’t need to adapt or change which introduces huge practical challenges in changing the culture.

Within my own organisation one of the biggest challenges we have faced is that stakeholders struggle with the concept of not being given a specific date when something will be delivered.

Stakeholders who are close to the delivery understand that we are prioritising feature developments according to business need. When a significant amount of money is being invested in a development which can’t go live until a critical mass of features are developed, it is often difficult to articulate a specific date on which that critical mass will be achieved.

The Burn-down Chart

The burn-down chart is one report which is commonly used to demonstrate and track team velocity. The burn-down chart is a great document for showing individual team progress, and for demonstrating how velocity improves over time. However, it does not help us visually present stakeholders with an indication of when work will be completed. To those who are not close to the work of the team the burn-down chart doesn’t give enough information because it only shows a snapshot of a single sprint which fails to show the whole picture.

The Burn-up Chart

One solution to the “When will it be delivered” problem that I have found effective is to create a Burn-Up Chart. The idea is simple:

  1. Estimate all stories in story points.
  2. Add up the total number of story points that need to be delivered in order to deliver the critical mass of work that people are interested in.
  3. Create a graph, the Y Axis should plot story points and the X axis should show sprint numbers (in our organisation stakeholders preferred the X — Axis to show dates).
  4. After each sprint plot the number of story points completed.
  5. Work out the average number of story points completed in each sprint and use this to forecast forward how many points will be completed during each future sprint.

The graph can now be presented to stakeholders and it clearly shows the estimated completion date based upon known velocity.

The burn-up chart can be used when you have a single team and also when you have multiple teams working on the same delivery. Just add all of the story points together and accurately plot the combined total achieved during each sprint.

I have also found that the burn-up chart is a great way to explain why a delivery date might change.

Scope Change

If scope changes part way through a delivery you can adjust the target line to reflect the point in time that the scope changed. This also gives an indication of how much extra work has been introduced.

Conversely it is straightforward to model what the delivery date might look like if scope were to be reduced.

Velocity Reduction

If velocity significantly reduces during a sprint it becomes immediately obvious to stakeholders. This should then inform a transparent conversation about what caused velocity to decrease at that point in time. Expectations can be managed at the earliest opportunity which ensures there are no surprises when a committed date isn’t achieved.

The burn-up chart is one tool which can be used to help organisations understand how delivery is progressing. It is particularly useful in businesses who are new to agile or have difficulty in breaking down work into small increments which can be fully delivered in a single sprint.

Have you used any alternate strategies to answer the question “When will the work be delivered”? If you have any ideas please reach out to me on twitter @stevewestgarth

Why I Actively Share My Pronouns

Someone asked me today why I put my pronouns in my e-mail signature and what it means.

As a cisgender man (a person whose gender is in alignment with the sex they were assigned at birth) there is little to no risk in sharing my pronouns. When you’ve never questioned what pronouns people use for you, or even thought about the idea of pronouns, sharing your pronouns is easy and costs you nothing. For a person who is transgender or nonbinary, sharing pronouns can be incredibly daunting and create huge barriers for the individual particularly in the workplace.

By sharing my pronouns in my e-mail signature I hope that it makes it easier for others who may be transgender or non binary to share their own pronouns

More information on why pronouns matter can be found at

If you don’t already actively share your own pronouns perhaps you might consider putting your pronouns into your e-mail signature – you never know who it might help.

Recognising the Chimp In You

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.

Which bugs are morally acceptable?

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.

Image for post

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.