What I learned teaching AWS deployment to frontend devs

I ran a backend deployment workshop for my frontend team. Local → VPS → AWS. EC2, Docker, Nginx, SSL. The kind of stuff I find genuinely interesting and wanted to share.

Before the session I sent a quick survey. "Rate your AWS knowledge 1–10."

Most people answered 2–3. One person said 6.

I thought I had a plan. I didn't.

The survey lied — or I asked the wrong question

Here's what actually happened:

The 2–3 crowd felt lost. Not because the content was wrong, but because I skipped the fundamentals. What even is a VPS? Why not just use Vercel? I assumed "frontend dev" meant "knows roughly how servers work." It doesn't always.

The person who answered 6 wanted more. More depth on networking, more about IAM roles, more Terraform. They sat through slides that felt basic to them.

Same workshop. Two completely different experiences. Both valid frustrations.

The lesson wasn't technical. It was about calibration.

What I should have asked

"Rate your AWS knowledge 1–10" tells you almost nothing.

Better questions:

• Have you ever SSH'd into a server?
• Have you ever set up Nginx manually?
• Do you know what a Security Group is?

Binary answers. Concrete skills. No room for inflated self-assessment or false modesty.

I had the data I needed to run a great workshop — I just didn't ask for it.

The content problem

The workshop covered three environments: Local → VPS → AWS Cloud. The progression made sense to me because I've lived it. For someone who's never touched a server, the jump from "my laptop" to "a computer somewhere in Frankfurt" is not obvious.

For the person with real AWS experience, the progression felt slow. They wanted to talk about auto-scaling and IAM boundaries, not why you need to open port 80 in a Security Group.

You can't split a live workshop in real time. You can prevent the mismatch before it starts.

What I'd do differently

Segment before you start. Even a 3-question pre-survey with concrete skill checks would have let me split the group — or at least set honest expectations for each tier.

Design for the floor, not the median. A confused beginner loses the whole session. An advanced person can explore the bonus slides. The inverse doesn't work.

Name the assumption out loud. "This workshop assumes you've never configured a server before" is a complete sentence. It takes five seconds and saves thirty minutes of people wondering if they're in the wrong room.

What this has to do with leading a team

I do this at work too. I assume shared context that isn't there. I skip foundations because they feel obvious to me. I optimize for the person in the room who looks like me three years ago.

Good workshops and good technical leadership have the same failure mode: mistaking your own fluency for your audience's baseline.

The fix is the same too — ask better questions before you start talking.

The most useful thing I did in that workshop wasn't the EC2 demo. It was the moment I stopped and asked: "Does everyone know what SSH is?" Half the room looked relieved.