Overview
Early on we said we were not going to bore you with the low-level sh!t that went into creating ALEiGN. However, we know that a bunch of you will be interested, and we think that is great. Every tradesman wants to talk about tools and methods and whatnot. So here we go...
ALEiGN as a concept started in earnest in 2013 when David was working for the Lord Mayor of a large local government authority (LGA) and saw that the vision of their leader - the lord mayor, almost immediately fell apart when you got to the second level of management. That is, between the Lord Mayor - the chief stakeholder and the duly elected representative of the people in that area and the people reporting to the CEO, the aspirations of the council effectively disappeared. It's not like he hadn't seen disaffected people in organisations before, and it's not like he didn't understand why this happened, but this was the moment of inspiration - the call to action - if you can't fix it here...well, it's time to pack up and go home.
So that was the day the concept of ALEiGN was born, but the approaches, methods and so forth go back over a hundred years, and we are going to touch on those here.
Why do things fall apart?
At the most basic level, plans fall apart because people don't communicate with each other. In the example above, the CEO of the organisation didn't communicate with the Lord Mayor that, in his opinion, the vision could not be achieved. Write or wrong, that's not his call - what he could have done is sit down, work through the issues (generally a lack of people, skills and budget) and then reorganise the LGA. Better still, work with the people in the organisation to show why certain things couldn't get done. The CEO didn't do this - now he is gone.
The above is an example in an organisation of a few thousand people, managing projects worth billions of dollars. But you see the same thing in small projects, small business, and even small jobs. But why does this happen?
In the LGA example, the vast majority of people working there loved the Council - they were nearly all residents in the LGA so had a close affiliation with its aspirations. But they had a dim view of management's ability to execute a vision. Why? Because of two things, observation and word of mouth which becomes a self-fulfilling prophecy.
Observation
People we met in the LGA that were in positions of authority and had been there for some time (years) observed that "yeah, well, the Lord Mayors come and go, but the only constant is that we have to collect garbage, keep the street lighted, register dogs and ..." basically she was saying that the "keep the lights on" work that every LGA has to do take up 80% of the time. Meanwhile, a new council is elected every four years with promises to do a bunch of stuff. So how does the organisation orient itself to the new stuff when 80% of their activity is doing the old stuff?
They don't. They nod politely to the executive and then go off and do what they have always done. In the meantime middle management (and this went all the way to the CEO) tell the executive that everything is fine...until it's too late. What happens then is that the executive blame the people doing the work (and where did they get that impression from? could middle management be throwing them under the bus do you think dear reader?).
And what does this create...
Learned Helplessness
Back in the days when experimental scientists could do what they wanted with test subjects, some arsehole decided it would be interesting to see what happened when you put a dog in a metal cage and put an electric charge through the cage. At first the dog becomes frantic and tried to get out. Eventually, when it discovered it couldn't get out it just lay there, moaning. Wouldn't you? I like to think one of the lab assistants rescued the dogs and put the scientists in the cages and left the power on - Liam Neeson style.
The same thing happens in organisations - and more so in larger organisations for reasons we'll cover later. A new person is interviewed for a job, they are super keen, love the idea of working for this organisation and can't wait to start. They get the job, and within three to six months are forgotten. A year later they get in at 9, organise to have coffee with a few of the other inmates, kill time to lunch, move some papers around so their errant manager, if they do turn up, has something to see, then wander off home.
If they have a good manager - maybe they are getting interesting work and are in that few percent that get things done...(ever heard someone say that about 80% of the work is done by about 20% of the people).
If it is a bad manager - they'll probably leave if they ever get the energy to do so. There is a saying "people join organisations and leave managers." It's true.
ERG and thanks for Abraham
Maslow as you know talked about self-actualisation. In a nutshell, we go to work because in society now, that's how we get shelter, food the other things we need to survive. We would like to do interesting work that builds our self-esteem and get the odd "attaboy" from our peers and managers. Finally, in rare cases, our job is who we are - the person that loves piano and is a concert pianist.
Aldefer took Abraham's work a step further and said that humans have needs that fall into Existence, Recognition and Growth. In this hierarchy, we have to satisfy one before the other. You can't feel recognition if you haven't sorted out existence for example. And if you can't or are not getting a higher level set of needs satisfied, you then regress to the next lower one. So - let's look at that in the work context.
You have some people you hired to do something - they've been left to their own devices, they have little or no connection to the vision of the organisation so if asked "define yourself as a human", their response will be more oriented around their family, hobbies, interests, etc. They are unlikely to say "well, first off, I administrate a couple of grants for council and we helped 150 homeless people get jobs". In the public service, it is estimated that less than one third of people identify with the strategic objectives of the agency in which they work. Imagine an army where two thirds of the troops just were not up for the fight?
So - in ALEiGN, we've created an environment where everyone can see the relationship between the work they are asked to do and the goals and objectives of the organisation. They get to feedback if the work is interesting, contributing to success and whether they think that, overall, the organisation will be successful. This is another reason we don't think that ALEiGN will suit a lot of organisations - many just don't need to care. If you're in government then customer satisfaction is just two words - your customers don't have an alternative - you can be as good or as poor as you want to be - but let me be clear - Management and the Executive set this culture - not the people doing the work. And so we go to the wisdom of crowds.
The Wisdom of Crowds
At a rural fair, there is a competition to guess the weight of a prize winning bull. A hundred farmers put in their guesses. If you took the average of those guesses you'd be within a couple percent of the actual weight. This is called the "wisdom of crowds". In a business sense, and we've all been there, if you ask all the people in a project whether it will succeed or fail you'll get a real view of it. If you asked the Project Manager - you'll get another view. Management like the project manager's view because it is what they want to hear - it's part of their reality. They don't want to hear the wisdom of the crowd, because that causes "cognitive dissonance" - basically the situation where you have to hold two opposing views in your head. The first view "I hired these people to get this job done and was told that was going to be fine." with "now they are saying this thing is pear-shaped and going to fail"....what do I do? Get another project manager...that's what.
But what if....what if management said "tell me the truth - we know that we won't get all of these bodies of work right." And using something like ALEiGN you're getting real-time feedback (through the survey and dashboard) of what's working and what's not. So as good managers we go to the ones that aren't working and ask why. If we can fix the problem we do, if we can't we free these people up to work on something else. We call this "radical transparency", in other frameworks is "high trust". If you think about the best teams you've worked with - be it business, sport or a hobby - they will all have had this level of trust and transparency - when things are working we don't get this shits with each other, get fix it.
So, how do we fix it? What are the typical types of problems this fixes? To answer that we'll look at the Theory of Constraints which says that any system can only work as well as its tightest constraint. This might be a process (hiring people, procurement, etc) or human (Jenna's the only person that can do a critical task) or capacity (we can only produce one widget an hour) or capability (we don't have those skills).
The Theory of Constraints
Wikipedia, that most trusted of information says that:
"The theory of constraints (TOC) is a management paradigm that views any manageable system as being limited in achieving more of its goals by a very small number of constraints. There is always at least one constraint, and TOC uses a focusing process to identify the constraint and restructure the rest of the organisation around it. TOC adopts the common idiom "a chain is no stronger than its weakest link". This means that processes, organisations, etc., are vulnerable because the weakest person or part can always damage or break them or at least adversely affect the outcome."
Various other theories I won't go into now talk about balancing systems around these constraints. The basic idea is that, say you have an assembly line, and there is one machine or person that can only process one unit of work per minute, then that is how many units of work your whole system will produce per minute.
In ALEiGN, we help identify these constraints through the monitoring of on-time task completion (see KPI chart). If you find subdomains and/or people that are consistently late in completing tasks - then you'll have a view of where your constraint(s) are. So go talk to these people and see what's up and what you can do to resolve the constraint.
Be aware, once you fix one bottleneck, you'll create another...that's the fun of being a manager - fixing shit never ends! But that's what they pay you the big bucks for, plus people will love you for helping...so suck it up princess and get in there and fight.
The Theory of 150
There is a lot of research in psychology and anthropology (that I won't quote here because I'm lazy) that suggests that the maximum size of a group of humans is 150. This has to do with the number of relationships we can manage in our heads. That is, how many people, their relationship to other people, their demeanour, etc. To be honest, for me that number of 5, but that's me.
So - here are a few points in terms of using ALEiGN...
- If your organisation is under 150, create a single domain and create your subdomains as you like - you can always move them around later.
- If your organisation is over 150, then still create a single domain, but create subdomains of less than 150 people so you have some ability to affect behaviour. I think you need to create teams within these subdomains of around 6-15, the rationale is that I don't think one manager can effectively manage more than this number of people. There are doubtless exceptions - but in general, as a manager, if I have more than about 10 people to worry about I have no time to be a good manager...i.e. go sort out a problem.
- If your organisation is over 1000 - you need to find a model that breaks down the functions of the organisation into groups of 150 or less that are responsible for a given outcome. Let me give you an example - an organisation of 30,000 people that service a customer base of 30 million. They provide 150 products, in 30 locations. You immediately have 150x30 sets of responsibilities = 4,500 so it should be possible to break things down that way - or just create a subdomain structure that gets down to the team level - you no doubt have divisions, branches, etc...
I guess the bottom line here is that if you have broken down the lowest level subdomains to around 15 people, then fixing things that are going wrong is easier, than if it is 150 people or 400 people. The same goes for projects, programs etc...
The Toyota Production System
I could crap on here - but the best idea I think My T had was that you stop the production line when shit happens. So, when, as a manager you see a team or a person in trouble (i.e. in the bottom left hand quadrant of the scattergram in the dashboard) you go in and sort that shit out.
Lean and DevOps
I've intentionally left Agile out here - some bunch of white, middle aged guys in a ski lodge debating what's wrong with software development - mostly afraid it will be outsourced to India.....give me a break!
Lean and DevOps have a few things in common - get people together from different fields, talk, draw, and plan before you commit $. Radical right? Read the Lean Startup. Enough said.
The Scientific Method
My father had a choice - be a concert pianist or a scientist. I'm doing this for a living so guess which he choose. But I did learn about science - take nothing for granted, design an experiment, conduct it, understand your variables, and measure your results. ALEiGN lets you do that - plan at the domain level, execute at the subdomain level and see what happens. "Pivot" as they say in Lean and learn from feedback.
Bryson's Stakeholder Management
CoBIT and all that Jazz