With less hierarchy and governance, companies want to become more agile. The goal is to tear down internal borders, encourage collaboration and be one step ahead of market and competition. Modern digital work tools are supposed to support and nurture this borderless way of working and thinking.
Start-ups get all of this engrained in their DNA from the beginning. Existing businesses have to reverse engineer the process and re-invent themselves. In this, the idea of “agile” often gets misinterpreted and people are left without framework, ground rules and the True North for wherever they are heading.
In this article I want to share my experience from my work in the triangle of leadership, organisational development and technology.
Flat hierarchies & agile development. An attempt to break with old norms.
An increasing amount of companies are experimenting with flat (or no) hierarchies and decision models. They are inspired by agile development in the software industry or lean management in industrial manufacturing. Sociocracy or Holocracy are examples for those models.
Short iteration cycles, lean decision making and cross-competence collaboration are at the core of all of those models. Temporary strike teams formed of the right people, are supposed to address operational or strategic challenges. Well –informed decisions aren’t subject to endless meeting cycles and line management approvals but are made in SCRUM –like events, in which all required competences are in the room.
The overarching goal is to move more decision power into the organisation and reduce formality. With this, companies hope to be more aptsuited to an increasingly globalised economy and the Millennial generation of workers.
So far for the theory…
The power of agility can only be unleashed with a strong foundation
In my career I have been part of many website, intranet and business productivity solutions projects. During that time software development moved from “waterfall” to “agile” methods (e.g. SCRUM).
Too often, “agile” is interpreted as “the short-cut from vision and idea level to creating source code”. A solid product definition, proper scoping, specifications or an underlying technical strategy are suddenly “old school“. The team needs to be “more agile and not waste time with theoretical work“.
As a result, none of these short-cut style projects are a pleasant experience. Eventually, an engaged and committed team might deliver a product that would pass user acceptance tests and perform well. However, severe budget deviations, postponed launch dates and a stressed out project team are usually the price that has to be paid, though.
That’s because agile doesn’t stand for “wittingly cutting corners”. Agile actually means “professional freedom within clearly defined borders of a solid and communicated framework”. The short cut version, however, seems to to be the most common misinterpretation of the idea of agility when it comes to organisational design.
A misinterpretation as a foundation for “new leadership”
To cut a long story short: if something new is established on the foundation of a misinterpretation, not much good can come from it. Unless, when you are really, really lucky. But that’s not how the business world works. Luck is often part of it, but never really the deciding factor.
The common, unfortunately wrong, understanding of “agile” tempts companies into the implementation of organisational models, teams or projects, that lack one essential success factor: a leadership framework.
“Leadership” isn’t blind trust in the existence of intrinsically motivated heroes in the organisation. Fully self organised structures, in which teams, goals and methods are unregulated choice, cannot be the alternative to companies that suffocate themselves with processes and micro management.
If organisational models draw inspiration from the success of modern software development, it has to go all the way, though. The more freedom is given to the process, the more explicit the common denominator has to be.
Any kind of team needs a purpose (the “why“), clear objectives, their defined zone of freedom and a common way of working in which they can function together. None of this can be left to the organisation to just “go and figure it out along the way”, and none of it is “micro management” either – seemingly the most feared action in the modern business world.
I am not saying that what is defined in the first place will be set in stone forever. But if you give yourself the option be flexible along the way, then there should at least be an initial plan, you can deviate from.
Leadership is guidance towards a True North
To quote the Scrum Alliance: “Every Scrum project needs a product vision that acts as the project’s true north, sets the direction and guides the Scrum team. It is the overarching goal everyone must share – Product Owner, ScrumMaster, team, management, customers and other stakeholders.” (Source: thescrumalliance.org)
It doesn’t matter if a team works towards a new website, a digital workplace or the design of a new career management model. The scope of what is to be delivered by a certain deadline needs to be defined and commonly understood, which are actually two different aspects of the same thing.
Driven by a shared purpose that team will then operate in a zone of freedom. Along predefined checkpoints, well informed decisions will be made to stay on track.
Agile is about the journey, not the destination
The misinterpretation of “agile” I am talking about is caused by the adoption of a new model, without having fully understood it. Agility isn’t the concept of end-to-end corporate democracy. Agility is about how a group of aligned people can reach a shared goal through multiple iterations that allow for adjustment and refinement along the way.
Knowledge work and business process automation don’t go together very well. I guess we can all agree on that. The modern workforce strives for more personal freedom. People want to be part of the creative process and jointly figure out the best way of solving a challenge – at least the high performers and talents at work do.
For that people need five distinct pieces of a puzzle that form a solid foundation for the agile journey:
- A clear vision, a true north
- A clear scope, to manage expectations towards a deliverable
- A defined team that provides all the necessary competence to take well informed decisions
- A shared work format, that turns multiple teams into a well oiled engine
- Guidance along checkpoints to allow for sparring and coaching
Why I have written this article…
Almost 10 years ago I started to specialise in internal digitalisation with a focus on information work and business productivity. At the time, the field was primarily driven from two angles:
- War for talent: There was (and still is) a strong belief that substantial change is necessary to attract the new generation of (digital) high performers. HR departments actually feared the new wave of Millennial generation information workers with their set of personal values and emphasis on freedom and work life balance.
- Social Media at the Workplace: IT and communication departments, wanted to win the battle against e-mail and support the idea of a networked and knowledge driven organisation. Tech companies have responded to this trend with a new breed of collaboration and communication tools.
I started my work in the field as an evangelist and adviser for the digital side of things and quickly learned about the organisational challenges and hidden pitfalls involved in those initiatives. Over the years I have refined my approach, evolved my role and now focus on the people and change process itself.
In many of my projects, companies had attempted to introduce a less hierarchical organisational model. Sometimes implicitly through methods of working and project set up, sometimes explicitly through the actual organisational model of the company.
My experience in these projects has fuelled my opinions. Time and again I’ve seen talented people get lost in an environment intended to work “for” the people but which in fact confuses them more than anything else.
Guest post by Philipp Rosenthal.