The Honest Engineer: What you don’t know by George Cairns

Why transferring knowledge is easy, but transferring insight is hard.

Acquiring Insight.

Story Time:

One way that AL engineers demonstrate the insight we’ve gained through experience is when we realise that an old technical solution might work in a new context.

As an 18 year old nerd from Bolton, in 1998 I got my first ever job. It was in a large retail bank you will have heard of, famous at that time for its annoying adverts. We did all sorts of mundane but important IT stuff, like changing backup tapes, racking servers, arguing with managers and building windows NT4 laptops for distribution to the workforce. We knew there was a base level of demand for various types of laptops, but the OS install, patching and application installs took all day. We’d be asked for a laptop, and the user would have to wait a day or two to get it. Responding to spikes in customer demand became stressful and we needed to come up with a good solution, sharpish.

We eventually figured out that we could solve the problem by keeping a ‘gold-stock inventory’ of laptops in a cupboard, ready to go. The underlying insight is that where a process takes a long time, delivery delay can be closed to nothing by keeping a pool of the deliverable pre-made and ready-to-go. We felt very clever having had come up with this realisation on our own.

An Insight re-applied.

A recent vmware-to-azure VDI migration project required extension of the customer’s legacy VDI Windows 7 client build and deployment service into the cloud. The deployment takes 8 hours. The company had a myriad of ‘orchestration’ type deployment processes that are scripted, complex and long-running.

So we decided to keep a ‘gold-stock inventory’ of pre-built VMs (which is implemented as simply an azure tag named ‘status’, rather than a big cupboard). When a customer requests it, a VM is assigned from the pool, and an automated process (rather than a 39 year old nerd from Bolton) maintains the pool by deploying VMs to replenish it.

The (still running) migration project for the client will improve delivery times of VDI desktops from 8 hours to 1 minute, allowing developers to be on-boarded quicker. A secondary benefit is that disaster recovery of the solution can be provided by pools kept around in different availability zones and regions. The already existing deployment gold-stock pool can be stocked according to the required amount of desktops needed for a site recovery.

The difference between knowledge, instinct and insight.

What I didn’t know is that in 1983, a full eleven years before I was feeling clever about the inventory idea, Andy Grove (the storied CEO of Intel) begins chapter 1 of his famous book ‘High Output Management’ with a full, easy-to-grok elucidation of exactly what it took my team weeks to realise. 

In 2019, both this book and this four year old, insightful article by Kelsey Hightower (author of ‘Kubernetes The Hard Way’) within which the quote *‘Ship Artifacts Not Build Environments’* appears, are still highly relevant to today’s corporations. This is the exact same insight Andy Grove came to and chose to put right at the front of his book. Though Hightower’s insight is a little more specifically related to software delivery, rather than ‘production’ in general, it’s the same pattern they both noticed.

In 2019, we at Automation Logic instinctively knew the solution to a clients problem from our experience in the past, and we transferred to our client the knowledge of how to do efficient inventory-based deployments.

Insight transfer is hard.

It is possible for insight to be bestowed upon you second-hand, but not all experts and leaders are properly equipped to transfer it. They do it through writing and speaking after careful reflection. Watch out for the junior members of your team who have this ability, you might find it useful to have them re-interpret and evangelise your ideas. 

I’m lucky that my colleagues at Automation Logic seem to welcome my incessant questioning, but in a way, they’re lucky too…. it also gives them additional opportunities to reflect on why they do what they do. 

It’s hard to see why a particular solution applies to a problem until you’ve either had a guru explain it so well that it just ‘clicks’, or you have made the epiphanic leap yourself. Unfortunately, sometimes you have to accept that you aren’t ready for a particular concept to make sense. This is also why when you read a book multiple times over the years you get different things from it; you just weren’t ready to receive what was hiding there in prior readings.

However, when an idea does ‘click’, you then see it all over the place, like a conceptual Baader-Meinhof gang. In the twenty years since the laptops, I’ve seen this inventory pattern re-appear so many times that it might even seem annoying to explain why it’s worth the effort. But this is the value of a good teacher. It is what a teacher is, reduced down to the core. Someone who will reduce a complex idea down to your specific level of understanding.

Teachers.

The way to accrue insight without the pain of failure is to surround yourself with people who are more experienced than you, but that alone is not enough. They must also be good teachers, which means two things, they must be able, but also willing to put the work in to consolidate their knowledge into digestible insight.

Not everyone is able to teach. These people work on instinct and are less reflective, so they don’t have deep enough knowledge to explain their decisions, and often don’t know why they do what they do.

Not everyone is willing to teach. Sometimes project pressure leaves them focused on the immediate task, rather than having the time to look at the longer-term benefit to their companies and to society. 

Not everyone is open to be taught either – the answers we require usually already exist in books, articles and our colleague’s heads, but this requires a willingness to reach out to others for help and admitting we don’t always have the answers.

We at Automation Logic subscribe to four key values:-

• Curiosity – always learning 
• Humility – pride without ego 
• Courage – keep our promises; speak our mind
• Collaborative – empathy and teamwork

All four of these are well served by everyone in the organisation, no matter how junior, becoming both better teachers and students.

One of the things we’re most proud of here is our DevOps Academy(https://automationlogic.com/service/devops-academy/), which puts our money where our mouth is when it comes to teaching. If you are a STEM graduate and are interested in working for a company willing to invest in their people’s futures, contact us at info@automationlogic.com

Looking for more interesting content? Check out our Engineering Hub!