We’ve helped hundreds of enterprises achieve their business outcomes with the cloud. And its not just “born in the cloud” companies – traditional enterprises like McDonalds, Coca Cola, and Unilever are finding the same success as newer enterprises.
But, that doesn’t mean cloud adoption comes without challenges.
But across the three paradigms, I actually spend most of my time on the Human element of Cloud Transformation. When Enterprises start experimenting with Cloud and see the profound benefits not only in the TCO but with the massive speed and flexibility improvements. Executive decisions are made pretty swiftly to move. When this filters down rapidly to the folks who currently design, engineer and operate the Enterprise IT systems, especially if it is a predominantly on premise environment. There can be a totally normal reaction of
1)What is this going to mean to my me and my career? Will I still have a role?
2)And can lead to FUD, Fear Uncertainty and Doubt. Which can slow down and stall migrations
3)And at the start, FearResistance is completely natural process.
4)There can also be tremendous excitement.
●
The People element is actually of course the most important element of any transformation, its also the most easily overlooked as we rapidly get into ‘solutioning’ mode for business opportunities that arise.
When I was going through this part I felt more like a Psychologist rather than a Technologist on the journey. Its probably fair to say, with all the balls I was juggling I didn’t give it as much attention as it deserved.
In 2016 I was an engineering leader for an ecommerce company undergoing a devops transformation – bringing traditional operations engineers and a basic devops skillset to the organization.
I found myself thinking deeply about the perceived skills gap in my engineers. These engineers were incredibly talented, but they were predominantly skilled in legacy on-premise technology; as a result, they offered largely siloed infrastructure skill sets.
My peers across technology would post unicorn job descriptions – looking for highly specialized generalists who could do it all. In reality, The highly skilled, proactive, and dedicated team I had, was the team I needed. The team members just needed a path, an incentive, and someone with empathy to listen and address their totally human fears of the technology unknown.
Doubling down on the personal side I realized that some folks would be here as we turned the pace up to 11 and encouraged and empowered them to step out of their comfort zones and do something new – even fail at something new, fail fast as the new normal for learning and moving forward.
Denial - until people know what there role is going to be how they can contribute, these is where they are going to stay. So tell them address their fear and instill optimism.
Frustration - so still nobody's has spoken to me about this thing, and I don't like it. I don't know how to technically make this do things I knew how to do previously. Lets over communicate, on everything that is going on. Lets make it super visible, no secret war rooms, lets get it out.
Depression - oh gosh, it really is happening and I still don't know what I am doing. Keep the spark of motivation alive.
Experiment - ok, I am consciously aware I don't know what I am doing, but I am going to give it a go. Have a plan!
Acceptance - up and running!
You need to be aware of all the stages as Leaders, but lets really help with the last 2 steps.
This is a one-day course that can be held on site, virtually or at a training centre, and anyone who wants to get started using AWS. It covers the foundations of cloud computing, storage, and networking. The updated course now addresses 18 AWS services, with in-depth coverage of 10 core services: EC2, S3, EBS, IAM, Auto Scaling, ELB, RDS, DynamoDB, Auto Scaling, and CloudWatch. With comprehensive hands-on lab exercises and instructor-led demonstrations helping students learn how to get started creating real-world solutions on the AWS platform. The updated course also provides students with a clearer path to continue their education with more advanced courses such as Architecting on AWS and Systems Operations on AWS. It provides a really broad exposure to the core fundamental technologies of AWS.
This is a great quote from Andy, there really is no compression algorithm for experience. And in the case of AWS, that means getting your hands dirty with the technology, with the API’s of the services and feature, with the console, with the SDK's and the VPCs. A really important step here, is to create a Sandbox AWS Account for your teams, this can be a stand-alone account that can be created quickly. It will never host production. You can set billing alerts to ensure its budgeted for. You can shut it down each evening. This is a place for your engineers and developers to create and test “Infrastructure as code” and find their ”sea legs” as it were, with the new way of doing things. At this point I found there was a a tremendous amount of opinions on how we should be doing this, but testing and failing with assumptions was a great way to learn. As will as gaining data points to use internally to on how to build things. And also to see the art of the possible. Its an exciting start. You get lots ”wows” and hey “we cans do this” at this point. This account should stay to test things indefinitely.
Linux, Automation, Network are key, ability to stand up new networks ranges that integrate seamlessly with your on premise IP address and BGP routing setup. Configure VPC's, Directory Services, DNS, IP address space, existing on premise firewalls. Super important, lots of folks thing these people go away, they don't, they are very important, was does change is they move away from undifferentiated heavy lifting and can move into Product Development teams, which is a heck of a lot more fun.
Of course for all of us, Security is job zero. And ensuring your Security Objectives are appropriate for you and getting the careful balance on least privilege access can be tricky. So embed a Security Engineer into the team that is going to be building the first products is amazing helpful, they become part of the solution and setting those security standards. No more, going outside the team for Security Advice put them into the team.
Operations Engineers can be brought it. Those questions around.
Steering groups of 23 don’t work – the comm’s don’t work
8 People work
Steering groups of 23 don’t work – the comm’s don’t work
8 People work
Now the team together, gaining experience and quite a few ‘opinions’ on what good like will emerge. At these state Very deliberately there is a massive number of ways to use the AWS Servics and Features when you put them together.
So co-locate this 2 pizza team together, and working in Agile way is the best way. And this is where the power of AWS Cloud really comes together. Because for the first time, that team has all the skills they need in one team to build anything they want. In an premise world I used to have 15 different matrixed teams rolling out services, that was too many folks to put in 1 team and inefficient to do so. But with Cloud and using API’s to access nearly everything its unbelievable.
The Product Manager and the team should work together to prioritise the backlogs priority in the early days. Rule of thumb here. Don’t change reporting lines. At this stage you are pulling together a virtual team. They learn from each other, they start to multi skill by working in closely proximity. 8 is a perfect number to keep communication effortless and everyone having a clear understanding of what each other are doing. There is no where to hide in a 2 pizza Agile team, everyone has to pull their weight.
Encouraging certification was the rocket fuel we needed to accelerate adoption. It plays to so many parts of the journey, including: -
Yes, Classroom training is very useful.
Hands on time essential.
Pair Programming very useful
ACloudGuru
We offer four role-based paths with advancing levels of expertise, plus two Specialty certifications:
Role-Based CertificationsFoundational - Validates overall understanding of the AWS Cloud. Prerequisite to achieving Specialty certification or an optional start towards Associate certification.
Associate - Technical role-based certifications. No prerequisite.
Professional - Highest level technical role-based certification. Relevant Associate certification required.
Specialty Certifications
Validate advanced skills in specific technical areas. One active role-based certification required.