Runs the platform engineering practice: CI/CD, deployment safety, internal tooling, and the AI infrastructure delivery teams build on.
Weekends, he's at the painting desk working through a Warhammer 40k backlog one thin coat at a time.
The background.
Luke leads Sigao’s highest-stakes engagements from the architecture and operations side: the systems that have to keep moving while everything around them changes. He owns the pipelines, deployment gates, internal tooling, and AI infrastructure that the firm’s delivery teams and client teams build on, and when an engagement is a large system with a lot of moving parts and a low tolerance for surprises, he is usually the one shaping how it gets built, released, and run.
He earned that role the way platform people usually do: by being handed something large and unreliable and making it boring. At the Alabama CARES program, a hundred-person enterprise team building the state’s Medicaid eligibility system on Dynamics CRM, ASP.NET, and SQL Server in Microsoft Government Azure, he was given a green field and asked to make releases work. He chose the tools, designed the pipeline, and built the automated build and deployment system that took the program from hand-assembled releases to push-button deployments across every environment, with the production design worked out alongside the infrastructure team. Fewer people in the room at release time, fewer surprises, cheaper releases. That is still the shape of the job.
Before that, at the University of Alabama’s Center for Advanced Public Safety, he led the development team behind the state’s eGovernment work, chief among it the Alabama MyDHR Food Assistance portal, and served as the group’s build master, owning the process templates and custom builds that decided whether the team shipped cleanly. He was leading a team and running its release process before he had finished his computer science degrees, which tells you most of what you need to know about him.
He co-founded Sigao in 2017 and has run its platform work ever since. The through-line is the same one he learned painting miniatures: the speed you get to keep is set by the discipline of the layers underneath. Thin coats, boring gates, small batches. He writes about it on the site, and he is happier talking about your oldest open PR than about your model choice.
How Luke runs the work.
- i.Fast is an outcome, not an input.You don’t get speed by pressing harder on the gas. You get it by building the machine that makes going fast survivable: small batches, continuous integration, tests that run, a pipeline the team actually trusts.
- ii.Gates are what let a team move without fear.Nothing ships unreviewed, and not because I distrust anyone. A pipeline that catches mistakes is the difference between driving fast on a track and driving fast in fog. Knight Capital lost $460 million in forty-five minutes to a missing one.
- iii.Find the constraint before you buy anything.If code generation doubled tomorrow, what breaks first? Whatever you just pictured is your bottleneck, and if the AI spend sits upstream of it, all you’ve bought is a bigger pile in front of the break.
- iv.Sprawl is an ownership problem, not a purchasing one.Every tool gets an owner, every category gets a decision, and the census is never a purge. Freeze adoption and it goes underground; own it and it stays visible.
30 minutes, no pitch
The people on this site are the people on the call.
Book a discovery call and you’ll talk to one of the practitioners, not a sales team. We’ll ask hard questions and tell you honestly whether we’re the right fit.