Standardising on Awesomeness

Slide 1
In 1929 on the corner of 5th Ave and 34th street - a large farm block was acquired in order to make way for the site where, at the time, the tallest building in the world would stand.

The Empire state building was to be bigger than the proverbial Texas.

Slide 2
The Empire state building was to be bigger than the proverbial Texas.

A colossal 102 stories high, measuring 381m high, the Empire State Building would prove to be a statement of architecture and construction at the point in time.

The timing of the construction coincided with that of the start of the great depression so, understandably, there were many reasons, “constraints” that could hamper the build project.

The architects had plans completed in just 2 weeks any one done a software design in 2 weeks?, and soon after construction began

Slide 3
If the speed of the architectural plans was amazing, then the speed of the build was nothing short of awesome.

Building at a rate of 41/2 stories a week, it took just over a year to complete. That's approximately 4 months ahead of planning - remember the great depression had taken its grip across the country at this stage.

Anyone delivered code 4 months ahead of schedule

Slide 4
So 4 months ahead of schedule and a completion budget of only 2/3 the forecast, faced with such enormous constrains, such as the great depression, what were the driving factors for such an awesome story?

I could hazard an educational guess - you know some DevOps Fu -

Some diversity?

Perhaps some awesome sauce in their teams (based on the 5 dysfunctions of a team)?

Perhaps they had cross functional teams?

Limited their work in progress?

Made global optimisations rather than local ones?

I could not find any evidence for or against any of these ideas - but I did find one interesting piece of evidence on continuous innovation.

Slide 5
You see the workers developed a mini train system that could carry 8 times more raw materials than the trusty wheel barrow.

The evidence seems to suggest this "tooling" innovation as being one of the main reasons behind the speed of the build.

Which also leads me to believe, they were making global optimisations, not local ones,

Which then leads me to believe they had a team structure that was robust, committed and held each other to account.

So they could build the biggest building in the world, at an unbelievable pace, without any compromises.

There was also evidence of adaption -> architects had envisaged a airship dock on the 102 floor which defined the arichecture plan for that floor - upon review, this become too complex and the idea was dropped but they managed to adapt that floor.

Slide 6
So, it seems that DevOps ideas were alive and well in 1929! So it's super frustrating for those of us in the tech world, when it seems that project after project fails to meet such awesome "Empire State Building" standards.

Anyone had more awesome projects than non-awesome ones?

Today I will share some insights on my DevOps journey and uncover some dysfunctions of which I’ll offer my opinion.

Now what I encourage from you all is your perspective. If there are elements I present to which you disagree, then please engage me - we'll both be better off.

Reach out to me during or after this session, or follow up on twitter, or email and let’s talk that out.

Slide 7
So how does one standardise on awesomeness? It takes a lot of work, but to do this, we need to understand the past, and our first history lesson is on a guy named Taylor and how Taylorism has defined how we operate.

Slide 8
Slide 9
Who would have thought that by understanding the whole system, we could achieve more…

Slide 10
Slide 11
Who would have thought that by understanding the whole system, we could achieve more…

Slide 12
Slide 13
Slide 14
Slide 15
Slide 16
Stephen Parry ‘s vision, mission etc

Jody Mulkey’s ability to create an emotional tie to what we do

Slide 17
Add the quote culture is defined by the leaders ability to tolerate the worst behaviour

Slide 18
Patrick Lencioni has a great tool – Thematic Goal based on his proposition that if everything is important, nothing is. What is that 1 rallying cry for the next 6 months that spans all departments and can be used as a tie break to help focus the work we’re doing.

If you’re interested in applying this, just reach out and I can put you in touch with a great facilitator

Slide 19
Evidence to suggest that a diverse coalmining team were 40% more efficient

Slide 20
Slide 21
Snowden’s complexity theory in where they explain the chasm type boundary between simple and complex?

Slide 22
Slide 23
Slide 24
Slide 25
Slide 26
Absence of trust, fear of conflict, Lack of commitment, avoidance of accountability inattention to results

Slide 27
Slide 28
Protocol check
Glad, mad, sad, Afraid

Slide 29
As a team how do we have those crucial conversations -> hey Reuben, for the last 3 days you said it was going to be finished. Yet every morning you say oh I slipped…

These crucial conversations are the responsibility of the whole team, not just the “master”

Slide 30
Slide 31
Slide 32
Slide 33
There is enough evidence to suggest there are requirements for being a member in a kick ass team that produces awesome software.

Slide 34
All that fin hard skills allow us to build up our emotional IQ. And why is this important – you sad ops

Slide 35
How about your first code review
Or how you felt when someone critiqued your code
Or how people change your configuration on your dev box
Or the emotional attachment to a specific technology or pattern or process

But works the other way -> tying an emotional outcome to our work

Slide 36
How by changing our language we can have different perspectives

Strategic bets

Slide 37
Slide 38
There’s two an org can run

Hire talented people and engage them
Hire “yes people” and tell them what to do

Don’t hire talented people and then tell them what to do

Slide 39
Identify and get feedback on managing constraints

Slide 40
Identify and get feedback on managing constraints

Slide 41
Say good morning and good night
Laugh
Eat and cook together
Write on walls
Read Fiction
Design the designing – API the pipeline, Set the SLA for platform services
Embrace the fringe -> diversity
Language
Meet out in the Open -> Love this one information radiator
Everyone leads at some point
Invert Everything -> Empathy
Bring the Outside in -> Whanau
Mirror -> This is great – creative documenting – Not only what, but how and by whom

Don’t try and script kiddie this, apply it for your implementation

Slide 42
You’ll know because there will be more than just you trying to make things awesome.