Hi, I'm Tyler.

I started my career in Operations Centers, where I spent my days working directly with production systems and the teams responsible for them. I was curious about why things worked the way they did, and when I saw something that could be better, I usually wanted to get involved. That curiosity eventually pulled me into engineering and has shaped a lot of my career since.

I've had the opportunity to work on a pretty wide range of things over the years. I've owned production platforms, built automation, and spent plenty of time responding to incidents. I've led the migration of company wide monitoring platforms from a fragmented commercial solution to a fully open source platform, handling the project management alongside the technical implementation. I driven company wide adoption of SLI/SLO practices, coordinating the work across teams while again building the technical pieces behind it. I've often found myself taking the lead on work that crosses team boundaries and needs someone to keep it moving.

These days I'm increasingly interested in the direction behind engineering work. I still enjoy getting into the technical details, especially when there's a difficult problem to figure out, but I also enjoy bringing people together around a project and helping determine where a platform should go next.

More about my experience

Experience

10+Years

Role History

Infrastructure Engineer
Cloud Operations Engineer II
Site Reliability Engineer
Founder / Principal Engineer

Deep Dive

Observability

My interest in observability started before I was responsible for building it. Working in Operations meant depending on monitoring every day, and I got a first hand view of what happened when the platform worked well and when it didn't. I became the lead for bringing the monitoring problems we found back to the observability team and working with them on improvements. Eventually, I moved into SRE and became the primary owner of the platform myself.

That experience shaped how I think about observability. I've been the person receiving the alert and trying to understand what it is telling me, and I've been the engineer responsible for the platform that produced it. I tend to look at observability from both sides because I've spent a significant amount of time on both.

One of the larger projects I led was replacing a fragmented commercial monitoring environment with a company wide open source platform. I was the primary engineer behind the new platform while also driving the project itself. That meant the work went beyond getting the technology running. We had existing monitoring to migrate, engineers depending on it, and a platform that needed to become something the company could operate and continue building on.

Owning observability platforms over the years has also changed what I pay attention to. Collecting telemetry is the foundation, but most of the interesting problems happen after that. I care about whether an engineer can find what they need when something is wrong and whether alerting leads to action rather than becoming background noise. Those are the things that determine whether the platform is actually useful.

I've come to think of observability as a product within an engineering organization. The engineers using it are its users, and operating the platform means paying attention to their experience with it. That perspective has probably influenced my observability work more than any individual tool I've used.

Values

Candor

I value candor and straightforward communication. I want people to tell me when they think I'm wrong, and I try to give them the same respect. Problems are much easier to work through when everyone involved can speak openly about what they see.

Initiative

When I see something that needs attention or could be better, my instinct is to get involved and work on it. That has taken me outside the normal boundaries of my role plenty of times throughout my career. I try to be conscious of other people's ownership while still being willing to step forward when I can help.

Pride

I take pride in my work. When I build something, I want it done well. I have never been a fan of calling something "good enough" when I already know there are problems with it that should be addressed. Those problems have a way of coming back later.

Openness

I've experienced environments where knowledge was guarded closely and others where documentation and knowledge sharing were part of the culture. The latter shaped how I wanted to work.

I write extensively and share what I know freely. I want people to feel comfortable asking questions, regardless of how basic or complicated they might be. Good documentation and open knowledge sharing make the entire team more capable.