I want to be an Imagineer

Before you think I am off to Disney to design rides or other attractions – which would be a very cool job, by the way - I am not referring to Disney’s coining of the term, re their designers needing to be able to engineer what they are coming up with in the latest amazing customer or digital experience (interesting side note, whilst Disney own the trademark to Imagineering, it was not the first to use this term[1]). I am instead talking about how this concept is now moving into mainstream digital businesses as they seek to compete in an ever-changing world.

The drive toward Digital is changing our business culture and our business resourcing needs like never before. The era of Digital businesses has provided opportunities to create and evolve internal and external facing business capabilities to improve efficiencies, whilst at the same time as the need for businesses to establish digital capability has become a necessity to compete. Simply outsourcing or partnering the development of digital capabilities is no longer a viable option because the ability for businesses to adapt and evolve within  dynamic market(s) at a cost they can afford means the profile of roles within and equally those outsourced is shifting.

The era of having roles that are specifically shaped as those who define their requirements (business users) and those who implement those requirements (IT) is coming to an end. With rogue IT being greater than ever (Business units looking to establish their own IT capability), the need for the model to shift couldn’t be more important. Why? Well simply put, when each part of a business looks to do its own thing we lose sight of who is accountable for stitching the various components together. Not to mention the impact of competing priorities, insular or siloed benefit realisation and the misalignment of resources not working together to achieve the greater good.

Enter the Imagineer, a new species of employee who not only has a clear vision for the business that he/she works in but also has an understanding of the tools/platforms/software that their business uses now and in the future. This new role profile will not only help to reimagine what a particular part of the business looks like, they will also have an understanding and an accountability to ensure that whatever they create actually works with a business’s broader organisation. For example in this role they make it possible for  marketing tools to work with a Customer management platform, or an ordering system to communicate with billing. This may seem obvious but history tells us our traditional ways of working have created extensive human glue as we seek to create the best widget to solve a particular problem instead of seeking to understand the broader business implications of decisions we may make in isolation from other parts of the business.

The Imagineer has a “T” shaped understanding of the business, an understanding of the end-to-end architecture and business flows combined with an in-depth knowledge on a particular domain with both the business requirements   and expertise on how the software they will use works. The result being a common understanding of how teams can succeed together and realise ownership and innovation in their part of the business at the same time.

I see this in my current role where we are exposing business people to the systems that will form the future of our business with an ask of them to know and manage those systems/tools in the future. It is not as easy a transition as having a traditional define and deliver model (Business vs. IT) for many years and then hope we will change the model overnight. It just doesn’t happen that easily, changing the model requires mindsets and behaviours of those involved to also change. The exciting aspect of this is the journey, partnering with our business owners who are keen to embrace this change and also become Imagineers themselves as we seek to redefine the customer, partner and employee experience in a newly imagined digital world.

Being an Imagineer is merely an example of where the collision of worlds from business and IT will create new opportunities.  These new roles are merely a representation of the shift that all businesses have made, where items are increasingly less about hardware and more about software, where services are no longer bought they are leased. The traditional barrier of business and IT is dissolving rapidly; I am not talking about start-ups but mainstream businesses where those who are going to be successful will need to have a blend of expertise

Imagineers will become a new role in our Digital Era, a role where people are needing to not only understand the technology and tools they are leveraging but also to have the vision of what the future can hold when we reimagine a digital world, a world where the limitations are only defined by our imaginations. It is this world I am excited to work in and bring an understanding to business leaders on the art of the possible through Imagineering^TM, where the knowledge of system and tool capabilities combined with a vision for what the future can hold will empower business to disrupt themselves and remain relevant for the future.

To that end, I will sign off.

Nathan Bell

Dreamer, Technology enthusiast, Digital Imagineer.

---

[1] https://en.wikipedia.org/wiki/Imagineering

When failure takes too long

In a digital world, new ways of working are becoming increasingly common. One of these is Agile, which broadly refers to how we deliver solutions in an iterative and incremental manner, through collaboration between self-organising, cross-functional teams.

This can seem very exciting – an opportunity for rapid development, co-creation and evolving requirements, as the business adapts to learning's and change.

With Agile fast becoming mainstream, this may not be new for those of us already on-board. Nonetheless, where businesses tend to struggle with the introduction of this new way of working is the cultural change that it needs to represent as well.

Now, when I talk about culture here, I’m referring to our fear of failure. In a society that celebrates success, it’s human nature for us to not want to fail.  Failure suggests we didn’t plan, didn’t consider the options and ultimately let down our colleagues, managers, customers or even family.

Consider for a moment the last time you failed, what did that feel like? How much were you willing to share that failure with others? Announce it to the world?

Some brave souls would have stood up straight away and said, “Well got that one wrong, let’s have another go!” Now, think about the idea of failing on a regular basis. No – I don’t mean every day, but how you may have to keep changing directions while working on a project, as you become more knowledgeable on the pertinent challenges, to meet a projects objectives. How long would it take before your manager or even other senior leaders start to question what you’re doing, and wonder whether you’re the right person to be leading the project?

I’ve had some spectacular failures in my career as we sought to try new ways of working, introducing new capabilities or launching new offerings into the market place. However, I’ve also been fortunate enough to have some amazing support from my managers as I sought to pivot, recover or simply stop what we were trying to do and take a different approach (You know who you are and thank you for your belief!).

The biggest thing I have learned from these failures is simply to find my courage and highlight the risk or failure early, however uncomfortable this is, and no matter what the consequence might be. Unfortunately, not everyone has been as fortunate as I have in having some amazing managers – who understand that in the pursuit of some exciting goals, sometimes we get it completely right and other times spectacularly wrong!

It’s not uncommon that when a risk emerges within the business, an early view may be to classify it as “Amber” or even “Green” on the wishful basis that it will probably sort itself out before it becomes an issue. Unfortunately, it’s equally likely that with the passage of time, that initiative may not recover and in fact results in the risk becoming compounded due to collateral impacts.

These compounded risks can reach the point that they start to jeopardise the entire project. Given people’s natural tendency to want to show a project is performing well in its early stage, flagging this as an issue can make many folks nervous. Then one of two things will happen: either they will call out the bigger risk and wait for the bombshell of a response, with everything put on hold while a post-mortem takes place; or break down the main risk into smaller components, with the goal to resolve them individually and show that it is being managed.

I’m sure many managers who read this will say that they’re always supportive of their teams – and that all the team needs to do is raise the concern for the manager to help them solve it.

Now put yourself in your team’s shoe: when you wanted to be successful and prove that you could solve things on your own, how willing were you to call out issues on a regular basis without being seen as incapable of delivering on the outcomes?

At this point, I can anticipate the question many will be asking: what in the world does this have to do with Agile ways of working? Simply put, failure is a core aspect of Agile. In fact, you will meet many Agile coaches who say that the Agile methodology cannot be truly successful without failure.

Agile methodologies can let you achieve outcomes faster, by breaking deliverables down to their smallest component or feature you’re looking to develop. The Agile way of working requires teams to be empowered to define what they should prioritise to build first, to realise new and exciting outcomes without being encumbered by a fear of failure.

Two words leap off the page for me now – empower and failure.  Both are important and intrinsically linked to each other. What level of decision making would you be prepared to cede to someone in your team, who is leading a development project? How often would you insist on them checking in with you?

Insisting that failure is necessary for Agile to work doesn’t mean we simply sit back and watch teams continuously fail. Sometimes, intervention or a change of team member is required. Even as we empower our teams, it’s equally important that they know the standards expected of them –  whether it’s the performance of individuals or the overall team.

In setting the expectations and standards while providing the right coaching, we enable the teams to grow in the direction the business needs. I like to refer to these as the guardrails – giving people the reassurance and sense of security they need in the early days of Agile, that early failure is acceptable in the development of new capabilities. As those teams mature, these guardrails become less necessary as the team knows what is expected, and more importantly start to set their own expectations of the business as well.

To be clear though, giving greater flexibility and autonomy to teams doesn’t mean development paths look more like a bowl of spaghetti, with new capabilities created all over the place. Development teams still work to a roadmap and continue to have a prioritised view of what the sequence should be in the development of features. This lets them achieve an end goal, whether it is a new offer to market, a new system deployment or even customer deployments.

In a nutshell, Agile can be an exciting path for businesses to embark on, but it is merely a set of instructions for business leaders to follow. Simply following the said instructions doesn’t always translate to the desired business changes or accelerated outcome. For this way of working to thrive, it is imperative for business leaders to change their culture by providing the bandwidth for teams to learn, iterate and grow, without the fear of failure.

We need to recognise that without taking on the responsibility ourselves in driving this change in business culture, we will be left with teams that have been asked to embrace a new way of working that will ultimately lead to failure. This comes about when teams try to manage every risk scenario themselves, avoid the “bad news” conversation and try to be all things to all stakeholders. The result?  A workplace fixated on risk avoidance, which eventually leads to demotivated teams, increased cost of change and missed objectives – all because failure took too long.