Open IT

Original graphic © Can Stock Photo / KevDraws

“How to do IT in the 21st Century”

© Copyright Two Hills Ltd 2023, Creative Commons Attribution-ShareAlike 3.0 Unported License

The basic principles that Teal Unicorn works with, the better ways of managing and working, apply anywhere within an organisation, including within Information Technology (IT). Likewise, the globally-emerging practices that we identified around these better ways, which we call Open Work and Open Management, can be applied to IT. We call that Open IT, of course.

This page is under development
Watch this area grow through 2023-2025 as we develop it.

At Teal Unicorn, we have used our version of Open Work and Open Management to make work better for many organisations, large and small: better results, better lives, better society.  The results are spectacular. We wrote 5-star books. We got on national TV. Clients make videos about us. People laugh and cry. We all have a good time. We’ve made lifelong friends. This stuff works. We are passionate about sharing it.

In 2023, we launched an initiative to bring Teal Unicorn’s successful Open concepts to the Information Technology context. 

In 2025, we hope to turn it into another book, and a course for the Open Management Academy.

Click on the “+”  to expand the headings:

About Open IT

Here is a brief introduction to Open IT in booklet form:

Intro to Open IT

Every organisation follows a different path to different places on their journey of advancement in Open IT – there is no easy roadmap. The only thing that is common across them all is the principles they apply to help guide them.  That’s the “way” but it’s not a defined road.

That picture kinda implies that it is a process: “first do Empowered IT  then Adaptive IT, then Continuous IT”.  But that’s not the intention. They are together the way out of the gridlock, the prison, the cubes of conventional IT bureaucracy and inhumanity. It suggests their relative importance, not their sequence. In those three areas of Open IT, there are principles to guide us in our decisions. 

This is the opening webinar of the Open IT Project:

Here is a mindmap of Open IT

Philosophy of Open IT

The word ‘open’ now underpins everything we do at Teal Unicorn. We believe the words ‘agile’ and ‘agility’ are overworked, over-stretched to cover more than the words actually mean. What do we mean by ‘open’?

Open Work, Open Management, open architecture, open systems design, open source, open access, open door, open space, open communication, open discussion, open leadership, open innovation, open for business, open ended, open up, open book, open eyes, open minded, open hearted.

We must be open: open society to higher consciousness; open organisations to greater transparency and inclusion; open teams to collaboration; open individuals to self-examination, honesty, and vulnerability.

To open up to better work, we are opening up the organisation like a flower, letting light and air in, making room to move and grow, exposing the workings, inviting others in, welcoming, creating possibilities, allowing pollination, letting the value out, letting us thrive.

The key to advancing work is the manager. We must open up management to be invitational, inclusive, serving, and transparent. Better ways of managing enable better ways of working.

This is an appeal to our better selves to advance work and society to greater humanity and a better world – better ways of being.

We call Information Technology the “Epicentre” of Open, because IT has emerged as the thought leader in Human Systems Adaptability. It has taken over the baton from manufacturing. In most organisations, IT is leading the way. More and more, the wider organisation is asking IT to lead or at least provide expertise in advancing to new ways. IT has strong allies and sometimes other domains take the lead: corporate change, strategy, or personnel/HR can be sources of Human Systems Adaptability thinking.

Conversely, social change is impacting IT, as organisations embrace the new ways of thinking, which we capture in an organisational governance context as “values over value”.

We mapped this trajectory of the advances in IT thinking just like the technology advances:

When considering IT, these new ways have specific implications locally for IT (blue), and for the organisational functions IT engages with (green):

Here is our vision of what an Open IT “manifesto” might look like

Open IT Manifesto

More philosophy: why we can't tell you how

I hear some of you saying “So what? This is all theoretical. Tell me how!”

Two things:

Firstly, everyone is on their own journey. What you use and what you get will be unique to you. The state of the organisation at any moment will be unlike any other organisation, and the path to that point will be equally distinctive. There is no defined pathway, no magic formula. Attempts to convince us otherwise are religion.

Secondly, how doesn’t matter. It’s all noise. Why is more important. Vision, values, principles, and aspirations (not what or where we want to be, but who) – these are things we can know, believe, and have in common, as a group and across organisations. For example, the Agile movement was wise in rejecting all formalised methods and sticking to the underlying values and principles of its Manifesto.

How can i say it’s all noise? I am reading yet another systems thinking book, this time it is Seeing the Forest for the Trees by Dennis Sherwood, a book primarily about causal diagrams illustrated from some of the author’s work experiences. I realised as i read it that I don’t care much about the details of creating and analysing such charts. We use them to communicate, but causal diagrams don’t produce The Answer. They don’t Make Work Better. They’re just YAFTT, Yet Another Thinking Tool. They help illustrate, convince, and illuminate. What did turn a light on for me in the book was a reference to “Soft Systems Methodology” by Peter Checkland, where Sherwood says

In almost every real situation, people are intrinsically [or explicitly] part of the system of interest. Since people often have multiple, different, competing, or simply unclear objectives, SSM asserts that the most beneficial approach is one of enriching all the participants’ knowledge and understanding of the situation, rather than a “scientific” search for the “best” answer.

Oh the irony of finding such a concept in a book about causal diagrams as the solution to real-world complexity. (To be fair, Sherwood doesn’t think they produce The Answer, they are his prefered tool to illuminate thinking. But he did say they “tame complexity”. They certainly drive holistic thinking and surface issues for everyone to see. We like them too.)

I love the point SSM is making. All our methods and tools serve only to illuminate our thinking, not to do it for us.  Teal Unicorn has determined that the effective way to make work better is for all the stakeholders in the system to think as a group.

The answers lie within the group. Consultants and bosses are midwives, there to provide advice and help deliver it, not to impose their own brain-farts.

The bigger the group the better the answers. There is a game where people arriving at a venue guess how many jellybeans are in a huge jar.  It seems an impossible task, and for any one individual they are unlikely to get it right.  But the average of a big group shows a spooky ability to trend towards the correct answer as the number of guesses grows. Together our thinking is powerful.

The human brain is the most complicated structure known in the entire universe. Not even the internet or a galactic cluster exceeds it. Now consider that they are all connected by language, and connected with all past brains by accrued culture and knowledge. You can’t model its thinking processes with any tool or method – they are all tiny approximations. The hubris of those who think they can do so, or to replicate it in a machine, is hilarious. Get as many brains  together as you can and let them do what they do: think. (Certainly “group-think” in its negative sense is a trap to be wary of, but that shouldn’t put us off the activity in general).

No matter how awesome a thinking force you assemble, the future – and the present – remain unknown and unknowable.  You aren’t going to come up with The Answer. At best, you’ll come up with something that a super-majority at least consent to try, and a majority want to try, that is likely to be as close to optimal – for current known conditions and constraints – as anyone else could dream up.

It is counter-intuitive for 20th Century minds, those steeped in the scientific method, to hear that this is in fact the optimal strategy, which will most closely follow the wandering needs of the organisation (which is only apparent in hindsight). All of the plans, strategies, goals, bets, budgets, designs, and architectures are there to comfort us, to make us feel like we know where we are going Their two real contributions are that they provide safety barriers – along with policies and rules –  to keep individuals and smaller groups from going too far off  the page; and the process of creating them is another tool for illuminating our thinking.  So they’re not a waste, until we over-invest.

Open IT doesn’t much care how you make your work better, only that you do. It’s not that Teal Unicorn rejects all methods and tools, like some naked sadhu washing in dust. Peppered throughout, we mention a number that can help. 

They’re great, they’re just not the most important building blocks of better ways of doing IT. They’re hammers not carpenters.

We talked about this in our book Open Management

All intellectual frameworks are just planks we use to keep us out of the mud. They’re useful but they don’t need to be polished to a shine. We have a higher purpose than the constructs themselves.

As we have discussed, work is human. It is as much about ethics and aesthetics as it is about science and intellectual abstract models. At Teal Unicorn, I work with the mind and the heart. It is not only about what’s correct, but also what is right and appealing.

As your thinking rises above, the specifics of frameworks and models fall away as operational noise, and we open up to more important things, like humanity and thriving.

I don’t recall where I first read about the three “transcendentals” of Truth, Beauty, and Goodness. I’m not a religious person so it wasn’t there.  They do have religious connotations but that’s not how we are using them here.  They are universal aspects of what humanity considers – or should consider – philosophically important, and Open IT is an example, like Agile, of Philosophy of Work, so they should be at the heart. It turned another light on for me to realise how “truthy” my life had been, especially my work. 20th Century business theory systematically eliminated beauty and goodness from work. If the numbers are up, then it’s all good, it’s “just business” if we consequently do bad or ugly work. Greed is good. People are human capital stock. Organisations are not part of society. 

Most models and frameworks I’ve seen are heavy on objectivity, logic, and abstraction. Let’s have some subjectivity, empathy, and realism. More beauty and goodness. 

Sure Google can take DoD money to develop AI for killing machines, but is that what their staff want to be part of? BP can use GIS and AI to map potential new oilfields, but what do their staff’s kids think about that? Were Snowden and Manning heroes or villains? At what point could Fujitsu have stopped the UK Post Office from destroying the lives of their postmasters?  What was more important during COVID, profitability or retaining employees? If somebody is sick or going through a rough time, should the team carry them? Are ESG and DEI bullshit?

Is it a waste of money to make a website cool? Is a messy desk bad? Is it OK to joke around at work? How can we make the workplace a more pleasing place to be? How does our branding and marketing contribute to the urban landscape? How do our buildings and industries affect the visual environment?

And so on.

At Teal Unicorn, we are fans of Laloux’s version of the Spiral Dynamics model – it’s in our name.  In fact we tweaked it again ourselves.

Like all models it’s just a tool to illuminate thinking. It shines a light on how to really “make work better: better results, better lives, better society” (That’s our Teal Unicorn motto).

Where is all this leading? To get back to Open IT, it is based on Teal Unicorn’s Open approach, our word for all the ideas we are learning about that make the world better. When we apply it to work, Open Work is summed up as three aspects: Human Systems Adaptability. Last year and this, Rob has been thinking about how those concepts apply to IT work. The first one comes first. it’s a human approach to IT.

(That uses the same colour code as the above Laloux graphic).

Liberate those doing the work. Allow them to get their jobs done as easily, efficiently, and effectively as possible.

Then think holistically, in systems.  It is the only way to understand and deal with complexity. Once you truly grasp the implications, you can find the best ways to work. You realise that conventional optimisation is a local effort that is often counterproductive. The primary activity should be adaptation, adjusting constantly to a VUCA world.

Finally, think of flow in those systems. More than many organisational sectors, IT is flow-centric. Flow is more important to us than in e.g. marketing, HR, finance, or data. We make stuff. We work in value streams. Let the work flow free.

These are the three core principles of Open IT: Liberation, Adaptability, and Flow.  As you know, none of these are Teal Unicorn’s inventions. We encapsulate what we have learned, experienced, and proven.

So no, there isn’t going to be much method or procedure in Open IT . Just “liberate the people, allow the work to be adaptable, and get out of the way of the flow”.  Get the values and the culture right, embrace the principles, and the rest will follow…

Slides of our presentation to the Pink24 conference

Alright! Alright! We will tell you how

How do we get there? With two key methodologies, mostly. Those are our own Open Management, and the industry practice DevOps.

Open Management contributes mostly to Liberating the work and the workers, and then to supporting the other areas of Adaptability and Flow – by understanding them and making them possible. The workers will take care of the rest. Open Management is Invitational, Inverted, Inclusive, and Transparent – i.e. it is about freedom, collaboration, and visibility. 

Most people would assume DevOps is all about the Flow part of Open IT, but it contributes a lot to creating Adaptability by making fast iterative change possible, and to Liberating teams to get the job done by giving them control over the lifecycle – it contributes to all of it. Recall that DevOps is about Culture, Automation, Lean, Measurement, and Sharing – not just technology.

To change how you work, you must first change how you manage the work, to unlock change in the work.

So apply Open Management.

People don’t resist their own ideas. Resistance to change only happens when it is done TO people not BY people.

So use DevOps to collaborate with everyone to make work better.

These are the main tools we use to help the advancement to better ways of working…

Some of those you will be familiar with, some will need explaining.

Of course IT folks lose their minds if we can’t talk about software, so we relented and mapped a few tech tools that come in useful around  Open IT:

There. Happy now? 

With all these tools and techniques to hand, we use our general methods of organisational change, which are described here

Liberation

 Liberation of the work, giving people the capacity and authority to do their jobs.  

Liberation is a better word than “empowerment”, which still implies something gifted from above and potentially rescinded.

Adaptability

 Adaptability of the work, continuously adjusting and improving what we do, to track the changing world and to grow our resilience to its impacts.  

Adaptability is the survival strategy for the 21st Century.

Adaptability = agility + resilience.

Flow

 Flow of the work, smoothing and accelerating the delivery of value in a sustainable way.  

Thinking about flow is possible in IT because the system is highly bounded and controlled. The simple linear models of manufacturing are a good approximation for the well-behaved Require-to-Deploy value stream.

More to come…

Principles of Open IT

Every organisation follows a different path to different places on their journey of advancement in Open IT or anything else – there is no easy roadmap. The only things that are  common across them all are the values, principles, and aspirations (not what or where we want to be, but who) – these are things we can know, believe, and have in common, as a group and across organisations.

The principles of Open IT that are specific to IT include:

Quality 

  • It is time we restored self-respect, and lifted our IT culture to aspire to noble goals of quality and value contribution. 
  • You will never ever get good quality code until those who write the code are those who fix it. The “warranty period” should extend forever.
  • If you want the best code, let those who build it be the same people who run it in production. Let Dev own Prod.
  • the major cause of unplanned work is poor quality.
  • The only way to sustainable higher velocity is higher quality. We have to stop pushing defects. Commit to no known defects. Prioritise defects over new.
  •  the “customer” of IT is seen as the organization itself, not the end consumer of services.
  • Plan tests before we write any code.
  • Automate tests so that they can be performed immediately.
  • Engineer to allow testing in parallel with development, including performance and compliance
  • Test as much and as often as resources allow
  • Once CD is fast enough, all changes, regardless of the urgency, should go through the normal full “gauntlet”. No emergency change process.
  • Give build teams an error budget: a certain level of failure is permitted without violating SLA.
  • An incident is an unplanned investment in your systems.

Teams:

  • long-lived teams who own the code through multiple iterations of its lifecycle. Application Support teams stop trying to fix defects and instead triage them and quickly pass them to the owning team
  • Self organising teams, doing the work, designing the work, and managing the work.
  • Agile teams should organise around capabilities, not designated roles like programmer or tester.
  • give high status to technical masters. Leadership should be a meritocracy.
  • Formalise some of that influence in whatever you call groups based on common expertise: guilds, chapters, communities of practice
  • Those with a common skillset should get together regularly (rule of thumb: monthly)
  • The team assess their peers
  •  Reward performance mostly at the organisational level, in some contexts at the group level, a little at the team level, and almost never at the individual level.
  • work with maximum transparency, making all work visible, so everybody can coordinate and synchronise.

Structure

  • IT work is a network of co-creation, including with the customer.
  • Break down Build/Run divisions.
  • The linear flow model is appropriate within IT for the development-to-production delivery value stream (hence DevOps), but it is not a good model for design and build
  • Operational Readiness operates broadly, from Architecture to Design to Build to Test to Release to Evaluation, a holistic approach to making sure the systems are alive and healthy when Operations get them
  • Innovative ways of working need buffering from the conventional parts of the organisation.
  • There is a need for a management methodology to “manage, integrate, govern, and coordinate the delivery of services from multiple service providers” to ensure quality and continuity of service.
  • Outsource commodities, and keep everything that matters. Any time you have an outsource service provider, the relationship is contractual not collegial.
  • build a higher trust relationship with our suppliers so that they trust us to go outside the contract and we trust them to deliver outside the contract, so that we enable each other to experiment until the contract can change.
  • Governance is not done within the IT function, it is done to the IT function, by the governance functions of the wider organisation
  • IT must grow to get a “seat at the table”: representation in executive leadership and a voice in the direction and decisions of the organisation.

Flow

  • Shift from project management  to product management, from project-centred to product-centred ways of working.
  • Bring the Work to the Team …not the team to the work.
  • Get the governance, management, gatekeepers, and controls out of the way.
  • One backlog. A team should work to a single merged stream of work, prioritised for them by those who are accountable for the value produced by the team.
  • All teams should work at a sustainable rate, without overburden, with headroom, with slack.
  • Constrain the rate at which work flows into the team: set expectations, provide feedback on workloads, and constrain work generation
  •  the improvement of flow must never reduce our capacity for agility
  • projects are a transitory wave which passes through the product structure. A project is a surge in work
  • IT value streams flow into the customer value streams, contributing components, i.e. flowing orthogonal to them.
  • while the stream paradigm is useful in IT for its efficiency and structure in a constrained pipeline like DevOps, it can be misleading in dynamic, complex, and innovation-driven environments where flexibility and adaptability are key, where a network paradigm is better
  • Cut through bureaucracy and siloes: using swarming, the right people come together as quickly as possible to cut through all the process and just fix it.
  • Once have automated configuration and orchestration software, the information is in the automation. We don’t need to be collecting it anywhere else, we can inspect when we need to know.
  • When your lead time is measured in days or weeks, manual “change control” is impossible.

Shift left

  • baking it in, making it part of the workflow, done by those doing the value work. Quality and compliance are built in, and assurance is done as we go.
  • Those outside the value work need to come to the work.
  • Integration happens early. Integrate continuously.
  • peer review and self-certification of change over CABs or Change Managers approving changes
  • security is a fundamental part of the software development and deployment process, rather than being an isolated phase or afterthought.
  • In order for tests to not be a bottleneck, and to enable high-frequency deploys, they must be automated and embedded in the workflow
  • Ensure there is line of sight to the organisation’s customer: everybody can see them, see what they experience and what they need.

Engineering

  • Automation is non-negotiable as it is essential for maintaining or improving quality while accelerating processes and building resilience
  • Be a toolmaker: share automation
  • Engineer for resilience. Agility means embracing failure, but first we have to survive it gracefully.
  • a resilient system should learn from impacts and restore itself to be stronger than before
  • Build resilience into IT systems also means considering human factors: design for human error
  • Build Continuous Delivery as “rapid, incremental delivery of high quality, valuable new functionality to users through automation of the build, deployment, and testing process, and improved collaboration between developers, testers, and operations”
  • Maintain a single source repository
  • integrate security (and other compliance) into the DevOps pipeline through automation and codification – “Continuous Compliance”. Create a system where compliance is part of the process.
  • Strive for self-healing systems
  • Strive for zero-touch scaling
  • Use chaos engineering to test for weakness and to generate innovative solutions
  • there is a tension between centralised shared tools and locally chosen team tools. Resolve the polarity case by case.
  • Implement continuous monitoring of the health of environments (from Dev to Prod)
  • You can only automate that which you can standardise, i.e. make known: described, predictable, and repeatable. Only some of the world can be standardised.
  • achieve greater resilience, reliability, and efficiency in IT operations through automation, monitoring, and continuous improvement.

Adaptability

  •  IT is a complex adaptive system within the larger organisational body
  • Complex systems have an endless capacity to surprise us.
  • Complexity (uncertainty and ambiguity) and change make it impossible to maintain a complete and accurate understanding of the system. (e.g. CMDB)
  • Agile principles offer a way of thinking for rapid development and deployment, enabling IT to respond to customer needs or market changes
  • adaptability = agility + resilience
  • think beyond known risks and prepare for “unknown unknowns” or  “plan for the unplanned”. 
  • Decentralisation and redundancy can provide better resilience 
  • There is more failure than success, so learning mostly comes from correction, adjustment, and recovery.
  • Expert opinions are just opinion, until proven right here right now in this context.
  • Objectives can be clear early, but requirements should evolve as development uncovers new information.
  • An organisational learning culture within IT absorbs the rapidly evolving technological landscape and translates it into actionable strategies.
  •  internal feedback mechanisms ensure that IT remains balanced and optimised. It’s only feedback if it is acted upon.
  • never make decisions or do work until the last responsible moment.
  • maximise the work not done.
  • When selecting tools or methods, experiment and explore, to find what works best for your people in your organisation at this time
  • transform IT Service Management (ITSM) into a fluid, highly adaptive discipline (“Continuous Service”)

That’s definitely a first-cut draft.  There are too many principles, and some of them aren’t really IT-specific.  It will do for now, to be continuously improved.

About the author

The only way you can cope with any deluge of knowledge is to find a trusted curator to filter and organise for you. I hope you will see me that way and follow along. I’ve been immersing in this stuff since last millennium – learning, writing, and consulting. I’ve made small contributions to the bodies of knowledge for DevOps and ITSM:
– The Phoenix Project reviewer
– The DevOps handbook contributor
– ITIL 2011 contributor
– ITIL 4 contributor
– VeriSM lead author
and author of:
– Basic Service Management
– Standard+Case
– Owning ITIL
In recent years, I’ve worked mostly in Vietnam with Dr. Cherry Vu, branding as Teal Unicorn, helping create content to fuel her spectacular success with clients transforming their work to unlock value and joy, including:
The agile Manager (small a) book
Open Management book
The Open Management Academy

Now I’m producing Open IT.

I hope you find it useful

Rob England