• AWS at Scale
  • Posts
  • AWS at Scale Part 2. Backing from the Board

AWS at Scale Part 2. Backing from the Board

Welcome to the second post in the AWS at Scale series. Backing from the Board

Table of Contents

Time to Read - 3 minutes

This post is part of a series

Part 1: What does AWS at Scale even mean?

Part 2: Backing from the Board

The article you are reading.

Introduction

Welcome to the second post in my AWS at Scale series where I’m writing to share my strategies, skills and tips on how to build your AWS career, what to focus on to stay relevant, how to make an impact, and where to focus your time & energy in a large corporate enterprise.

I’m Lee and I’ve spent my entire career working at scale in some of the world’s largest corporations.

In my previous post, bullet point one highlighted the following point:

‘Is there backing from the board? Why it’s important, and how to check for it.‘

What do I mean by this? Let’s start explore it! 

If your desire is to build experience with AWS platform concepts on an enterprise scale covering:

  • AWS Organisations

  • AWS Control Tower

  • Secure basline AWS account vending

  • Reference & reusable VPC architecture

  • Reusable Terraform modules for commodity AWS resource provisioning

  • Building a provider / consumer platform model

  • + many others listed in my original post

Then you’ll want to do some research on the company’s commitment to AWS as a primary cloud platform (or Cloud in general).

I’ve worked for a company where Cloud was touted as principle strategic direction of travel (when in reality it wasn’t) and it’s soul destroying, so ensure you get this bit right!

Company Research

Here’s how you do that:

  1. Head on over LinkedIn

  2. Search for the company you are interviewing with

  3. When the results come back, ensure you filter on ‘people’.

  4. Ensure the 1st, 2nd and 3rd connections are selected here.

We are going to search for ex-employees first

  1. In ‘all filters’, ensure that you also have ‘past company‘ selected

  2. Clear the selection under ‘current company’

  3. Add additional filters name and title (title is the one you’ll find the most useful).

  4. Select a title phrase like Architect and hit ‘show results’

  5. Now you’ve got all ex-employees of that company who worked in an architectural role.

  6. Review everyone who worked at the company you are interviewing with and see if there’s an pattern of tenure that would indicate whether or the company struggles to retain talented staff.

  7. Try to reach out to them for an honest conversation “I see you worked at x for several years back in y, I’m interviewing there shortly and wanted to get a feel of the culture and commitment to cloud strategy (or whatever you want) - would you recommend it to someone in my position etc”

  8. See what they post about and what communities they are active in

  9. Repeat steps 4 - 8 but do it for title phrase AWS. Again reach out to these people using the same approach.

  10. Repeat steps 4 - 8 but do it for title phrase Cloud. Again reach out to these people using the same approach.

You’ll really get back some key focused information on Cloud / AWS usage and the strategic roadmap within the company and what’s rolling down from senior management.

Now onto current employees

  1. Again in all filters, remove ‘past company‘

  2. Ensure that you have ‘current company‘ selected

  3. Repeat steps 4 - 8 for in the section above and rather than reach out, take a note of the roles that are currently active and the tenure of each person with the role.

  4. See what they post about and what communities they are active in.

Key takeaways from this method

It’s worth taking the time to do this, you’ll get unfiltered and honest feedback from people rather than combing through bitter anonymous comments on Glassdoor.

You’ll also get a full view of board, CxO and director strategy, committment to cloud and the overall culture of the organisation (which you can cross reference against your own values and principles so you don’t end up frustrated in the role).

Essential Reading

If there is one book that’s impacted me the most in my entire career it’s The Phoenix Project. I read it years ago and I couldn’t put it down.

“Bill, an IT manager at Parts Unlimited, has been tasked with taking on a project critical to the future of the business, code named Phoenix Project. But the project is massively over budget and behind schedule. The CEO demands Bill must fix the mess in ninety days or else Bill’s entire department will be outsourced.”

“Luckily for Bill, he has an unlikely ally: an eccentric potential board member named Erik.“

There’s lots going on in The Phoenix project, the lessons never stop coming but one of my key take aways was Erik (the board member) his influence on the board, and more importantly, the influence and coaching he had on Bill.

Without Erik on the board, Bill doesn’t succeed in turning Parts Unlimited around in 90 days.

That brings me to the last bit..

Backing from the Board

Maybe there is no Erik from The Phoenix Project on your board (there should be!).

Maybe you’re already in an architectureal position within an organisation, you’ve discovered a number of key risks that need highlighting and you’re frustrated with the lack of support within the company to do what you think is right.

The time is always right, to do what’s right.

What can you do here to gain backing from the board, CxO, directors, or at the most senior level available to you?

Identifying the Risks:

Bear in mind that your no 1 priority is securing your customers data, contracted SLA out to consumers is a close second (unless you are providing critical health services etc).

Identify the key risks, but ensure that you present them in a format that a C-level audience can understand. If you can’t do that, ask ChatGPT to give you a few examples.

Here’s an example of how to present a risk of overly permissive lateral networking.

Any CxO would understand the potential for unauthorized access to sensitive data or resources within the cloud environment due to inadequate network segmentation or weak access controls, this risk could result in:

A scenario where an attacker gains access to one part of your cloud infrastructure (perhaps through a compromised user account, leaked API credentials or secrets, or a vulnerability in an unpatched service).

Without proper network segmentation and access controls, the attacker could then move laterally across your cloud network, potentially accessing other parts of your infrastructure that contain sensitive data or critical systems.

Compromised and unaudited lateral movement can then lead to data breaches, major service disruptions, encrypted ransomware attacks or even a complete compromise of the cloud environment.

This could result in significant financial losses, damage to the organization's reputation, and huge regulatory penalties if sensitive data is exposed.

You would then back this up with data, highlighting:

  1. How bad is the current problem? (and how not to make it worse).

  2. How is it currently being threat hunted?

  3. How is it currently being monitored?

  4. Who is alerted first if a threat is detected?

  5. What’s the current response is if a threat is detected?

  6. What are the official recommended architecture patterns to mitigate the risk (from the platform vendor)?

  7. What do other organisations similar to yours do?

  8. Example of any news stories where this has happended in the past.

  9. A good scale of how critical this risk is to the organisation based on other dependendant projects, the future growth of the company and the pressure on technology platforms to deliver in a secure manner.

  10. Which vendors offer solutions?

  11. How do the solutions compare with each other?

  12. What is your recommended solution based on the assessment so far?

  13. Provide an example budget for remediation.

  14. Provide an example budget for continued governance.

  15. Provide an example set of standards & principles that need to be agreed for future alignment.

  16. Identify the change mechanism for implementing the standards and principles (if they don’t exist, recommend that they do and how they can be put in place).

  17. Request a decision.

To sum all that up, here’s one of Barack Obama’s best interviews (and some of the best career advice i’ve ever heard) on just getting shit done.

Now that the risk exists, it’s on the register and it’s been surfaced at the highest level and explained to all senior stakeholders, in the right format.

The next big question is, who going to own that risk (in the event that the response is to do nothing?)

This is where you’ll start to get traction.

Hope that helps!

Call to Action

Thank you again for subscribing to AWS at Scale. If you like my content then please visit these posts online and share them across your socials and support me by tagging me @leewynne

All the best, Lee

Reply

or to participate.