What Is Digital?

If I had been given a pound for every time I’ve been asked ”what is digital?”, I probably wouldn’t be able to afford the latest iPhone, but I might be able to afford a decent case.

I’m lucky to work in a digital team, but where does that leave my non-digital colleagues? Someone made a good point recently that just because they are not the digital team doesn’t mean they are analogue! Very true. When did any of us deliver an analogue solution in our career?

So, What Exactly Is Digital?

There is much debate in the industry about what digital actually is.

For some it’s all about a new style of technology, scripting language or tooling. For others it’s about how we work and the processes and techniques. For some it’s about how business is conducted, in particular using online channels to buy and sell.

All of these and more are correct. For me, it’s all about

  • the type of work we do,
  • doing things differently and
  • creating an environment and culture to enable everyone to be their best.

A Different Type Of Work Takes A Different Type Of Person

The technologies we use now are certainly different to a few years ago. When I started in IT, Cobol was still the language of choice and Java was just starting to make a difference. We have evolved so much in the last 20 years.

Most of our work is cloud hosted and it’s a rare occasion that on premise is the first choice. Dev Ops, Agile, automation, robotics, platforms, containers, microservices amongst other buzz words are talked about and worked on in the team.

Open source software and tooling are positively encouraged and names like Gherkin, Cucumber, Chef, Puppet, Ansible, Chocolatey, Balsamic, Hadoop, Python, UX and Service Design can be overhead in discussions around the teams.

We have been so fortunate to realise early on, that things were changing and we recognised the need to evolve and re-invent our programmers into multi-skilled engineers, where tooling rather than native code is king.

Previously the type of person who would have made a good programmer might not be the ideal candidate today as an engineer. I’ve had many CVs on my desk that would have ticked every box a few years ago, but now the first thing we look at is will they fit into the team and do they have a high level of learnability.

The autocratic management style that was so familiar a few short years ago, can no longer be found in my team. I see myself as an enabler of the teams rather than managing them. As Steve Jobs said (not exactly verbatim, but you get the picture) ”We don’t hire clever people to tell them what to do, we expect them to tell us what to do”. When the team make suggestions, I take them seriously and try to make things happen for them whether that is training, having a relationship with a technology partner, getting licenses for a particular tool or giving them time to work on some innovation outside of their regular work.

The New Team Mindset

One of the first things we did as part of our cultural shift was to remove the hierarchies. We rationalised the roles within the teams. Everything is delivered using an Agile approach. We now have scrum masters and team members which includes everyone from apprentice engineers to architects.

Our people and their team have a number of attributes and characteristics…

  • No hierarchy – badges are left at the door
  • Everyone is equal
  • Everyone mentors and coaches each other
  • Transparency is a given – we don’t want secrets or hidden agendas
  • We don’t fail, we learn lessons
  • We share our blockers and issues and resolve them together
  • We solve problems
  • We have time to innovate, learn and develop
  • We remember and nurture our passion for IT
  • We celebrate and recognise achievements and successes
  • We have fun!

Speedboats over Supertankers

Working in a mega corporation the deals that previously were common were the multi billion 15 year outsourcing deals. This does seem to be changing and rather than the huge mega deal, clients seem very interested in breaking down their big challenges into smaller discreet problems. From which we develop a minimum viable product or do some digital experimentation. Using agile techniques of constant feedback loops means we can very easily change direction where we need to. Starting small or ”not boiling the ocean” has allowed us to reinvent our reputation as an innovative, digital partner to our clients. Where we have started small with maybe 2 or 3 people, inevitably turns into 2 or 3 scrum team’s solving more and more problems.

Digital Is Binary

There are many definitions of what digital is. Everything from cutting edge technologies, online business transactions, even legacy mainframe application development using agile, dev ops and automation.

One thing that can’t be debated, every digital application whether it is written in Cobol or any of today’s tools, it is still only 1s and 0s.

The Essence Of A Digital Culture Part 2

man and woman looking at man standing near window
Photo by rawpixel.com on Pexels.com

In this second part of the blog, I want to explore how we have created a high performing, multi skilled team where training, collaborative working, innovation and  mentoring have become real enablers for our people and for our projects.

No More Silos

It is a standard concept in Agile teams to have T shaped resources that have a deep specialism as well as more breadth to a person’s skills e.g. an engineer can also have automation and testing skills.  This allows for relatively small scrum teams to be able to deliver whatever is needed within the confines of their own team without having to find skills from other areas.  When more traditional siloed teams are used, it often results in a bun fight for people’s time and managers or accounts wrapping their arms around resources.  This is no good for project delivery or for individuals who don’t get the opportunity to develop and upskill or multi skill.

Taking our people from ‘I’ shaped to ‘T’ shaped was one of the first steps in having a higher performing team.  However, we very quickly realised we needed more from our people and could give them more in return.

A number of the team are influencers and leaders and these people need to have more stronger strings to their bows.  So, we started to develop our ‘X’ shaped people.  These are our natural leaders, both business or technical who are the influencers and agents of change in our team.  The ‘X’ shapers talk to key client decision makers, influence technical and delivery direction and are the thought leaders amongst their peers.

We recognised we were taking our people on a journey from ‘I to T to X’.

ITX Picture

To develop the path for an individuals journey, everyone in the team was mapped as either an I, T or X as their starting points on their individual development plan.

To support the development of X shaped people, we have a range of soft skills and leadership training and coaching covering Influencing skills, being an agent of change, coaching and mentoring, communication, prioritisation and  solutioning.

Technical Training Team Triangle – AKA  The T4

The next dimension to multi skilling is also about addressing some very common problems …

  • Removing single points of failure
  • Attrition and retention of individuals with strong skills who were regularly being headhunted
  • No clear career paths for our new to corporation roles of scrum master, product owner, coach, Dev Ops engineer and automation engineer
  • Ever changing IT
  • No time to innovate
  • No fun and forgetting the passion for IT


Scrum Team Alignment :

We cut down and across our labour pyramid when pulling together our scrum teams.  This enables us to identify not only the next layer of top talent, but the next 4 layers.  This model facilitates mentoring and coaching across all layers of a team.  The coaching and mentoring doesn’t just head down the pyramid from the experts at the top, but heads in all directions especially where we have some of our early career people bringing new perspectives, experiences and a passion for learning and sharing new ideas or technologies.  We like to promote an environment where everybody learns something new every day.

There can be a fine balance between delivering on our project commitments and providing good development opportunities for our teams.  To make sure nothing dropped with our deliveries, we provided partial assignments for our team members.  They were still at least 50% assigned on their original project  (we provided a partial backfill to keep delivery on track), but we also gave them another assignment on a project that was using new technologies and approaches which meant when their current role was completed, they were 100% ready to move onto the next role.


To restore the passion for technology and bring some fun back to the teams, we gave them the time and freedom to innovate.  Listening to their ideas for innovating either for our client’s benefit or our internal benefit reinvigorated the team’s passion.  They were excited to produce some amazing results and get their hands on world class tools that previously might not have been used in our work.  The results were amazing!  People were looking forward to coming into work!  We did this with very little cash investment – we provided 3 Raspberry Pi’s and some RFID tokens and a reader – the rest came from the team’s inspiration.


One innovation project that is currently active is to get the teams to develop a mentoring app, similar to Tinder where both mentors and mentees enter their skills profile and there is a data matching process which makes suggestions for mentors covering both technical and personal / career mentoring.

The team are learning so much from this exercise.  I am acting as the Product Owner and we have assigned a Scrum Master and Engineering Team.  So far, they have captured the requirements and produced a wire frame using Balsamic software – it looks amazing.   We are planning an innovation evening where the team can take this to the coding stage which promotes some fun social collaboration in the team – I provide the pizzas and they produce the magic!

I recently spoke to a group of early career engineers at one of our resourcing partners who were just coming to the end of their digital training programme and asked them  what was important to them in deciding to join a company.  Every single person whom I spoke with said the same thing … they were looking for a company where they had the opportunity to learn from and be mentored by more experienced staff.  Salary and job perks were surprisingly much lower down their criteria for their future employer.  This reinforced how we were enabling the collaborative mentoring culture within our scrum teams.  We might not always  be offering the highest salaries in this competitive market, but we were providing the mentoring and opportunity to apply learnings and technical training alongside some very experienced techies.


For quite some time our employee engagement feedback was either there was no training or there was no time for training.  The training budgets hadn’t been distributed and we couldn’t wait, so we started to get creative…

We contacted many of our technology partners including Redhat, Amazon, Microsoft, CA Technology, Github amongst others and most of them gave us access to their free training, free software and with some free onsite expertise and detailed technology training.  Our corporation also has a deep pool of trainings available to anyone in the company and we invested some time to figure out what was good and applicable.  We also tapped into so much free training online including the power of a good YouTube video!

We also took advantage of the UK Apprentice levy and have 23 of our team on a Digital Technology Degree programme.  This acts as a great retention incentive for our people.  We are truly investing in our people with this and giving them an amazing development path.   We are now looking at the Apprentice Master Degree programmes now to try and take this even further.

For anyone new to digital either new to company or new to the team, we produced a curriculum called the “Digi-Dojo”.  This is digital enablement training which allows everyone to speak the same digital language, introduces concepts around Agile, Kanban, Cloud Computing, Automation amongst other hot topics and gives anyone a great foundation before looking at their more detailed career paths and training plans.

The Enviable Workplace Culture

There are many factors in creating an effective digital culture.  If you get this right you can deliver some incredible projects, have a highly engaged team where people love coming to work and are developing at the same time.

My aim is creating an enviable workplace where anyone who sees what we do, wants to work here.

It is incredible to see this happen – when you see people come alive and energetic to doing things differently.   I recently gave a tour of our centre to a number of engineers from a different part of the business – they were literally based in the building next door and had never been in our space.  By the end of the tour, their energy and enthusiasm was obvious to see.  As soon as they got back to their desks, I started receiving emails from them asking when they could move their things over and get a desk with us.  They commented on how they understood the theory of digital and agile before they visited us, but now it was made real to them and they were now completely on board with the changes that were needed in their part of the business.

In the next part of the Essence of Digital blog, I’ll cover collaboration and digital leadership.

The Essence Of A Digital Culture Part 1


We were incredibly lucky to host a Buildathon earlier this year in our Digital Transformation Centre.  One of our visitors (a global senior exec in the company) described our Centre as walking into a ‘Digital Disneyland’.

I took this as a great compliment !

We have been working over the last few years to really understand what it  means to have a digital culture and I think we’re very close to having nailed it.

It hasn’t been easy to get where we are today, especially when we have been part of a much bigger corporate machine, but there are a few key things that have made it possible.  I’ll explore a couple of ideas and principles we used to build amsuccessful Essence of  a Digital Culture…

Think Small, But Be Big …

Despite being part of one of the biggest IT companies in the globe, we started to think and behave as though we were a start up.  We were very insular, looking within the team to really figure out what we were trying to be. Even though we are part of a mega corporation, in today’s Digital IT market our competitors are more than likely to be a small software house than one of our traditional rivals as we started to think and behave like a start up.

This approach helped us go for some of the work that in the past our sales organisation would have turned their noses up to.  We didn’t mind going for a small 6 week project as we knew that when our clients saw what we could do they would want some more.  We needed to build our reputation as a digital company as our traditional market was in large scale infrastructure programmes and mega deals. One of our first projects started as 2 people looking at some blockers and now we have grown to 4 scrum teams for that client and have been delivering on new and exciting opportunities for them ever since.  They now consider us their partner in developing their digital road map and have absolute confidence in what we can do to support the transformation of their business.

Listen To The Teams

Although we had been operating under Agile and Dev Ops for a few years, we really started to crack the Digital Culture when we started to listen to our teams.

We held a deep dive focus group session and basically asked a number of our more vocal and opinionated team “what can I do for them to make them more effective in their role, happier at work and feel engaged within the team?”

There were the obvious salary, bonus responses, but we also obtained a wealth of valuable information from those sessions covering everything from training, tooling, creating an inspiring environment, innovation, technical and business partners, social and community, leadership and communications.

I took the output, categorised it into work streams with various actions in each work stream backlog relating to the feedback in the teams and created a programme called ‘Making The Digital Transformation Centre Real’.

Each action was given a RAG rating and reported on at each of the bi-monthly Centre Uber Scrum (large team cascades).  All of our successes, progresses and blockers were made visible to all of the team and they could see, very clearly that we were listening to them.

We had some quick and cost free wins …

  • set up a Kudos board
  • set up an ideas board
  • contact our teams preferred technology /tooling companies for free software and training – thus creating real technology partners verses the corporate strategic partners we didn’t have any contact with
  • develop and publish a comms plan and have regular ‘uber scrum’ meetings
  • give the team freedom to use best in class and often free software and tooling
  • run knowledge sharing lunch time sessions developed by our own in house experts
  • create a practical mentoring environment
  • engage with subject matter experts in our local ecosystem to support our lack of niche expertise
  • engage within the local community to support STEM activities in local schools, get involved in charity events, develop a relationship with all of the local colleges and universities in the area

We also made some small investments to allow innovation ideas that came from the team to be developed.  We spent around £500 on some Raspberry Pi’s, RFID readers and some virtual reality headsets.  The teams turned this into some amazing innovative projects which have either supported activities in the Centre or our clients.

We had transformed from a very unclear future into an environment where ideas were encouraged and supported and best of all, the team had some amazing ideas!

After 6 months of doing this we held a pulse survey of engagement indicators and found that over 85% of our team were either ‘happy or very happy at work’.

At this point it felt like we had found the team’s Mojo and we didn’t want to lose it, so our engagement activities turned into Project Mojo.


We are still running Project Mojo, issuing 6 monthly surveys, having Uber Scrums and running Mojo Workshops to keep the momentum going.

There are other aspects to our digital culture which I’ll go into more detail in subsequent blogs including collaboration, guilds, training amongst others.

We are still learning and continuing to get better every day.  Sometimes it’s amazing, sometimes it’s another learning opportunity.  I don’t know if it’s quite on the level of the Magic of Disney, but there is definitely a buzz, excitement and enthusiasm that I’ve never felt before in the air.

There are other aspects to our digital culture which I’ll go into more detail in subsequent blogs, including collaboration, guilds, mentoring, training amongst others and also, how we are looking to take what we have achieved and scale that out across the wider organisations.



Everyone Needs Their Own Lightbulb Moment

I’ve lost count the number of times I’ve been asked by sceptical clients and colleagues about using Agile and Dev Ops methods in software delivery.  This is usually followed by …

“We can’t use that because …”

“That won’t work for us because …”

“Our teams don’t want to change because …”

“Agile doesn’t really work”

… I think you can see a pattern.

In response, I usually find it is best to recount my team’s story of how we were very sceptical of change and happy with our waterfall status quo before we started using Agile and Dev Ops methods, but making the change and giving it a go was when the real fun started.  If you’re sitting comfortably, here goes with our story …

Like most IT Professionals over a certain age with a background of complex legacy public sector traditional waterfall projects that lasted more than 6 months, usually resulting in going over budget whilst running into impossibly tight testing windows where the requirements would change (usually late in the project) and defects were expensive to fix alongside a mounting technical debt, we thought we knew how to do things right.  The project managers blamed everyone, the business analysts blamed the client, the designers and architects blamed the business analysts, the developers blamed the testers.  Just writing that down now makes me embarrassed to admit our arrogance.

In our minds there was nothing that we didn’t know about IT delivery.  With vast experience amongst us all (we once counted the IT experience in our team of 40+ people to be just over 1000 combined years!)  we all thought we knew what we were doing.

Then we were asked to deliver the impossible.  Everyone agreed we needed to do things differently and re-write our well-thumbed rule book.  So we made a plan with timelines and milestones and phases … in other words the same as before.  Then someone suggested that we try Agile.  Terms like scrum, sprint, standup, backlog, Kanban were thrown around and we all sighed, looked around at each other smugly, but agreed to give it a try – under our breathe we secretly thought it would never work.  We reluctantly agreed that as we were going to fail doing this in our legacy way, we might as well try Agile.

We trained scrum masters, set up white boards, agreed with our client who would be our product owners, trained our engineers in some Dev Ops tooling, introduced some automation and then it happened … OUR LIGHTBULB MOMENT.  We managed to achieve the impossible!

Collaboration with the client was seamless and they even integrated themselves into our scrum teams.  Our staff were learning new techniques and ways of working that broke down the barriers between ‘them and us’.  We removed the blame culture between the separate teams as our scrum teams were made up of designers, analysts, developers and testers – we were all in the same (scrum) team now.  All parties were working together with common goals, learning our lessons every sprint and taking ownership of our own areas of delivery whilst at the same time supporting our team wherever we could.  We recognised when we failed, but we failed fast and we failed together – so we fixed it without the need to produce and approve reams of paperwork to get changes agreed (working software over documentation for the Agile Manifesto purists).  We had the client product owner within our scrum teams and we were making decisions when they needed to be made.  Priorities actually made sense for once.

This was a few years ago now and we are still learning each and every day.  We now talk about how “it’s all common sense really and it’s just what we do”.  We have learned to be pragmatic with Agile.  We do what works for each and every project.  Sometimes we lean towards more purist Agile and other times we take what we need from a number of different schools of thought and adapt to fit the work.  The constant feedback loop is crucial to our success so we can learn and improve at every iteration.

We have happy staff – who have amazing relevant digital skills, who receive ongoing mentoring, training and development in Digital, Agile and Dev Ops.  Our team are now highly multi-skilled.

We have happy clients – who feel part of the process and don’t feel like we are trying to sell them something, but are trying to help them fix their business problems through amazing IT.

This has resulted in a very healthy pipeline of work as our reputation has grown and we are leading the way in how to effectively delivery digital solutions as well as a highly engaged workforce who actually enjoy coming to work.

The advice we usually give to our sceptical friends is …

  • Start small, maybe with one project – don’t try to boil the ocean.
  • Identify a problem and create a one problem statement, so you really understand what you are trying to solve and fix.
  • Use Agile techniques appropriate for your delivery – be pragmatic.
  • Up-skill and Multi-skill your teams, so they can work effectively.  Give them the autonomy to decide the best in class software and tools to use (unless the client has constraints we can’t move) – give your scrum team members a voice.
  • Make the scrum team own their delivery and equip the scrum master to be able to take away the blockers and have leadership who can support the scrum masters and team members.
  • Have a good product owner – we define this in it’s basic form as someone who knows stuff and can make a decision.
  • Have open, honest and transparent collaboration.  The quicker you acknowledge the problem, the quicker it can be resolved.
  • Create an environment of no blame.  If (when) there are failures and mistakes – learn from them and making them a learning opportunity, rather than turn them into an inquest over a failure.
  • Willingly and openly give and receive feedback – listen to your teams – who knows better than those who are doing the work?  I can’t emphasise enough – LISTEN TO YOUR TEAMS !!!!

This isn’t an exhaustive list, we have found it works for us and it might bring you a lightbulb moment too.

man and woman doing high five
Photo by rawpixel.com on Pexels.com