Leadership README
Table of Contents
Last updated May 2026
My name is Tyler, and I’m an engineering leader. This is a guide for people who work with me, report to me, or are curious how I think. It is also a mildly over-engineered attempt to make working with me easier. It is a living document and a starting point, not a substitute for building trust through real work.
Current chapter
I recently moved from leading a broader Platform Engineering organization to leading a small team where the job is to learn quickly, build deliberately, and find product-market fit through the right product bets.
The short version #
I want the people who work with me to feel clear on what matters, trusted to think, comfortable disagreeing, and supported when the work gets murky.
I care about clarity, ownership, customer evidence, simple solutions, and honest feedback. I like steady forward motion. I dislike silent drift, avoidable ambiguity, and process that no one can explain.
I believe habits compound, action reduces ambiguity, and a lot of what looks like luck is really preparation, judgment, and action meeting opportunity at the right time.
A little about me #
I started my career as an engineer and spent more years as an individual contributor than I have as a manager or director. That still shapes how I lead. I care about engineering judgment, clear ownership, and teams that can move without unnecessary drag.
I studied Computer Engineering and Systems Engineering at Colorado State University. Go Rams!
I have worked across various industries: national defense, industrial robotics, biotech, and cloud marketplaces. Much of my career has been spent in complex systems and organizations trying to scale without slowing down.
Most recently, I led Platform Engineering teams focused on developer experience, golden paths, API integrations, automation, and AI-assisted development. That work taught me a lot about reducing friction across an organization.
I will make mistakes. I try hard not to make the same mistake twice. I have thick skin, so if something in this README does not match your experience with me, call it out.
I am a strong believer in Lean Software Development: deliver value, eliminate waste, shorten feedback loops, and keep learning. I have also written and spoken about engineering practices, including co-authoring Microservices in Real Life: Contract Testing, co-hosting webinars on observability, and presenting on AI and integration strategy for Managed Service Providers (MSPs).
This chapter changes some defaults #
For a while, my job was to help a larger platform organization scale: clearer standards, stronger enablement, more leverage across many teams.
My current job is different. I am leading a smaller team working closer to product-market fit. That means I want to optimize for:
Some of my old instincts are still useful. Some need to relax. In Platform Engineering, it was often my job to think about the future system: standards, leverage, repeatability, and scale. In product-market fit work, the job is often to learn what is true before we harden too much around what might be true. That requires a different kind of discipline. If I am adding too much ceremony, asking for scale before we have signal, or making communication heavier than the work requires, I want you to tell me.
What you can expect from me #
I will try to make the "why" clear: the customer problem, the business goal, the tradeoffs, and what success looks like.
On a small team, I will be closer to the work. I may ask deeper product, technical, or customer questions. If that ever feels like control instead of support, say so. I am aiming for helpful proximity, not becoming a human Jira workflow.
When the work is ambiguous, I will usually push us toward the next useful move: talk to a customer, test the riskiest assumption, write down the tradeoff, ship a smaller slice, or make a decision we can learn from.
I care about reliability and craft, but I do not want us overbuilding before the problem has earned it.
I will make decisions visible, clear friction where I can, and create air cover when the team needs focus.
I will give feedback clearly and with good intent, and I want the same in return.
More hours should not be the default answer. If everything is important, nothing is. If the work does not fit, we should cut scope, clarify priorities, or make tradeoffs visible.
When I know something, I will share it. When I do not, I will say that too.
What I expect from you #
If something is unclear, blocked, larger than expected, or pointed in the wrong direction, raise it early. Bad news does not improve with age.
When possible, bring the problem, the options you see, your recommendation, and what still makes you uncertain.
Take pride in your work, ask for feedback, and keep getting better at your craft.
I value solutions that are understandable, observable, and appropriate for the stage of the product.
Product-market fit comes from evidence, not internal conviction. We should be honest when the signal disagrees with us.
Preparation matters. Attitude matters. Opportunity matters. Action is what turns those things into outcomes.
How I work with direct reports #
Communication #
I prefer clear, high-signal communication. Async is usually best for status, context, and simple decisions. Meetings are a tool, not my default - like all tools, they can be useful, misused, or somehow turned into a recurring 60-minute status ritual. Live conversation is better for ambiguity, conflict, product tradeoffs, customer learning, or anything where 15 minutes together prevents two days of drift.
I also value simple, direct language. If we cannot explain the problem clearly, we probably do not understand it well enough yet.
Decisions #
I do not want us waiting for perfect information. For small, reversible decisions, I prefer speed. For larger decisions, I like lightweight written thinking: what problem are we solving, what options did we consider, what tradeoff are we choosing, and what evidence would make us revisit it?
1:1s #
1:1s are for you first. They are not status meetings. I want them to be useful for coaching, context, feedback, career growth, decision support, and places where you feel stuck.
Feedback #
I prefer feedback that is specific, timely, direct, and useful. I try to give it that way, and I appreciate receiving it that way too.
The best feedback cultures have safety, effort, and benefit: people feel safe giving and receiving feedback, they practice it often enough that it becomes normal, and the feedback helps the work or the relationship improve.
Things I need to watch in myself #
I have a strong bias toward systems thinking. That is useful until it is not.
I can sometimes see patterns, abstractions, and future scaling problems earlier than they need to be solved. In Platform Engineering, that instinct was often an asset. In product-market fit work, it can become a liability if it pulls us away from learning quickly.
I care a lot about the work. That is usually good. It also means I need to make sure intensity does not get confused with urgency on everything.
Closing #
This README is not meant to make working with me formulaic. It is meant to make it easier.
People are complex. Teams are dynamic. Context changes. I reserve the right to grow.
If you work with me, I hope you feel challenged, trusted, supported, and clear on what we are trying to accomplish. I also hope we can laugh often, because the work is hard enough without taking ourselves too seriously.