Let your customer be your pilot.

I enjoy listening to Sting. One of his songs I am humming constantly (nowadays) wants me to ...

Let my soul, be my pilot
Let my soul guide me
He'll guide me well

(modified to fit lyrics for purpose)

A product's soul is its customer.

If your initial reaction at reading this title was 'duh, of course', hear me out.

There is a serious underlying problem, that I will frequently come up against - the inability to get past the Me, Me, Me syndrome (and I accept, with embarrassment, that I flitter in and out of this mentality, especially when I am mentally exhausted).

Up and down the ladder, there is always a subtle concern about 'having my voice heard', 'winning that argument with Jason', 'putting my design patterns above anyone else's without discussing them' and a myriad of other insecurities that are progressively bred in the traditional corporate culture.

These insecurities and anxieties often impose a cognitive load on team members and their focus becomes skewed, from thinking about what makes the customer happy (and a happy customer is more likely to be a happily paying customer) to how they can outshine others and stand out from the pack.

While this is great for a personal career (and I am all in favour of doing the right things to move the professional needle), it starts a cultural rot, that becomes putrid over time.

A Scrum Team is like a Sports Team.

Teams win or lose together and the only way Scrum teams can (and should) win is by delivering value to the people who have paid for it (and if you have to think twice before realizing the customer is the people who have paid, please speak with a counsellor).

Always assess how anything you do for a product or service impacts your customers before worrying about others.

A simple rule of thumb we used during my time in the Product Development teams for a healthcare organization was to consider how something we added or removed from a product or service would impact, in order of priority:

1. The patient (does the quality of care increase?)
2. The company (does the proposed change increase reputational risk ?)
3. The team (is the team going to suffer in any way?)

Of course, (1) and (2) took precedence and it is a testimony to the teams I worked with, that they were least concerned about personal gains.

I write to remember, and if, in the process, I can help someone learn about Containers, Orchestration (Docker Compose, Kubernetes), GitOps, DevSecOps, VR/AR, Architecture, and Data Management, that is just icing on the cake.