Who
Luke Swithenbank. Based in Sydney. Ridgeline Studios is a consulting practice that combines technical leadership, platform engineering, and AI implementation as one engagement for startups.
Career
Thirteen years across five companies. Not a chronological CV, just the parts that matter for the work Ridgeline does.
Elastic. SRE on a globally distributed team, working on deployment infrastructure for the cloud offering. The job was reducing deployment cycles from weeks to something the engineering team could actually ship with. On-call, shielding the main software team from support issues, debugging at scale. The lesson that stuck: SRE teams that lack software engineering depth get left out of the room when technical decisions are made, and that has real consequences.
Macquarie Group. First SRE hire. Built the reliability discipline from scratch: incident culture, SLOs tied to business goals, getting the right people to take ownership of their systems. In a large organisation, the technical decisions are rarely the hard part. Getting the right people to understand the problem and take responsibility is. That meant advocating for a monthly meeting with the department head just to make the case for reliability as a practice. Real change requires getting into the right rooms, often without positional authority.
FL0. The title was SRE Team Lead. The reality was building the platform. FL0 was a container hosting service, a Heroku alternative for deploying code from git repositories. I built the Kubernetes operators in Rust, the CI/CD pipeline, the build system, container registry, networking layer, HTTP load balancer, database hosting, and certificate registry. This was hands-on, full-stack platform engineering. Not advisory, not oversight. Built the thing.
Dovetail. Engineering Manager, Platform team. The team owned on-call, CI/CD pipelines, and every orphaned application no one else maintained. We migrated databases, set up pub/sub tooling, improved video transcoding performance, and managed the Datadog relationship. This is also where AI entered the picture. We introduced Claude Code and Cursor across engineering. Initial reluctance gave way once the unlock became clear. The platform team became the enablers of safe AI adoption: helping other teams integrate the tooling while putting proper checks in CI so nothing shipped to production without review. The honest part: deployment speed didn’t improve. The monorepo structure meant AI tools couldn’t get full context across the codebase. AI doesn’t fix deep structural problems.
Slate. Started as Principal Engineer focused on platform, then became Head of Engineering when the CTO resigned. Inherited a role that was actually three roles, external stakeholder deadlines with no product shipped yet, and a relationship that hadn’t been managed honestly. Scoped the platform MVP while running engineering. The AI work here produced the clearest insight: treat AI like a human onboarding into the codebase. Anything you do to help AI work effectively, documentation, clear structure, written context, also makes it easier for the next human to onboard. The real win is getting implicit knowledge out of people’s heads and into the codebase where both humans and AI can use it.
Why Ridgeline exists
I keep seeing the same pattern. Founders who can’t find the balance between good engineering culture and executing well against a good product idea. They either can’t set up a team that integrates product thinking with engineering, or they do neither well and don’t know where to start.
No one is holding all three threads at once: CTO-level leadership, AI adoption, and platform foundations. These get treated as separate problems requiring separate people. But the engineering culture that makes a team accountable, the AI tooling that makes them faster, and the platform decisions that make the product reliable are all connected. Pulling on one without understanding the others is how startups end up rebuilding things twelve months later.
Good engineering culture means accountability and ownership. You build it, you run it. Blameless post-mortems. Space to learn as well as execute. And critically, tying the engineering work back to product thinking and the user journey rather than engineering for its own sake.
How I work
The first thing I focus on is the team. I need to know who I’m working with, what they’re good at, where the gaps are, and who I’m working for. I can only be useful if trust is there, so building it quickly is the priority.
I prefer Slack and in-person communication. I also understand protecting deep work time, so I timeblock specific slots for interrupts, standups, and working through blockers with people.
What’s in scope: platform, engineering, engineering processes and practices, AI. Things that transfer from business to business. What’s not: deep domain knowledge like search algorithms or financial models, IT, accounting, or anything outside engineering. If the engagement is management-focused, the engineering knowledge needs to stay with the team. I’ll delegate the hands-on work so the organisation retains the capability, or we find time to balance both.
I’m transparent about how things are going. I communicate early when something isn’t tracking the way it should be. The engagement goes well when I’ve executed on what I said I would, and the client understood what they wanted from the start. Getting that clarity up front is the most important part.