Sometimes you interview for a job and the questions are bigger than 45 minutes can hold.
I had one of those. The company is moving from Lambda and ECS to Kubernetes, and they asked how I'd approach it. I gave the basics off the top of my head: inventory everything, document invocations and dependencies, find the owners. That conversation turned into the technical writeups in this repo.
A few days later there was a second interview, and that's when I learned the company was still working on internal buy-in. They asked how I'd handle pushback, which of course mostly comes down to sales.
That changed the shape of the project. The technical plan is the easy part. Migrations like this don't usually fail on the technology; they fail on the people. The engineers who built the current system don't love being told their work is obsolete. The managers want to know it won't blow up their quarter. The execs want to know what they're getting for the spend. The TPMs want a timeline they can defend. Same migration, four very different conversations.
So I went back and wrote those too.
lambda-refactor/andecs-refactor/— the technical approach for each workload type: how to inventory what you have, what patterns to migrate to, and what to do about the awkward edge cases that don't fit either.pitch/— added after that second interview. The same migration explained six ways for six audiences: engineers, managers, executives, TPMs, an elevator version, and the interview Q&A that started this.
I kept it generic, so it isn't really about that one company. Take what's useful.