Hello! 👋 I’m Tyson.
I love solving tough problems, improving lives through technology, growing communities, and making the world a better place.
At work, I’ve found success as a software engineer, consultant, technical leader, and people manager. Since 2008, I have been creating great software inside many organizations with the help of some amazing people. I do my best work when I am part of a team that is ethical, curious, diverse, motivated, and kind. I currently work at Infinite Labs.
At home, I enjoy spending time with family and friends, making music, working out, gaming, reading, cooking, and drinking fresh coffee. If you’d like to get in touch, you can reach out to me on LinkedIn; I use he/him pronouns.
I’ve worked with a lot of different software languages, frameworks, technologies, tools, and applications. I’m excellent with React/TypeScript frontends, Spring Boot backends, and Kubernetes-based platforms, but by no means limited to those options. I’m flexible on persistence layers and data services. If you’re looking for more detail, I keep track of that stuff in a skills matrix.
I like working full-stack, and then some. I write my best code when I write my tests first, and I can teach you TDD, too, if you want. I think great code works well and conveys meaning to the people reading it. I like putting working software in the hands of real users, as often as possible. I like integrating, releasing, and deploying my software to production when all of my tests pass, automatically, and I like doing whatever it takes to make that process reliable, secure, and continuous.
I like Agile more than waterfall, and I like XP best of all, but I know through experience that a culture of trust and empowerment matters more than the prevailing management paradigm. I believe organizational structure deeply influences software architecture, and vice versa, so I like being in a position where I can influence both. I’ve seen Conway’s Law borne out in practice more times than I can count, and I agree with Gerald Weinberg that “no matter what the problem is, it’s always a people problem.” I think we undermine what we can accomplish together when we label each other (or ourselves) as “technical” or not.
TL;DR Do what works, do the right thing, be kind.
Returning to the Labs team as a principal engineer has been an exciting opportunity to test what I learned working inside of a product organization. I have brought new insights and appreciation for our clients' experiences from my time on the "product side" with EverQuote. This time around, I have been staffed to projects in financial services, federal government, veterans' affairs, renewable energy, health care/wearables, large-scale retail, and international shipping.
As a principal engineer, I routinely leverage both the breadth and depth of my past experiences. Sometimes, I am staffed as a generalist, identifying the areas of a project that need the most help, and learning what I need to learn to make the most impactful improvements. Other times, I am staffed as an expert in a core technology that's of use to the client, and expected to provide technical expertise and/or mentorship.
By choice, my role does not include people-management responsibilities this time around. However, as a principal engineer, I tend to be used in more of a tactical or strategic role on engagements. Sometimes, that means working within with a dev team, as a tech lead, helping the team adopt practices that led to long-term success. Or, it could mean working as a software architect, helping to devise a high-level plan for large projects spanning several delivery teams. Other times, I consult closer to the account level, helping our delivery teams chart a path to success with client leadership.
I've navigated a few significant shifts in company culture this time around. Our in-person consulting strategy had to adapt to a remote-first world. Ironically, with many organizations in our industry returning to office, we are now navigating the opposite change. And, in the wake of the VMware-Broadcom merger, the Tanzu Labs team has become Infinite Labs, a part of Infinite Ranges. I have learned a lot about staying focused and grounded in times of change.
At EverQuote, I got the chance delve deeply into the online advertising and insurance space. Upon arrival, I was put to work immediately to the task of bootstrapping a brand-new product with a very small team. I brought my "consulting toolkit" to bear, leaning especially on techniques for getting a newly formed team communicating effectively and producing useful software quickly. The product went live in production after 2-3 months of initial development, and was earning over $50K/day of revenue by the end of my tenure.
My job also included people management responsibilities. I had one direct report when hired, with plans to hire or reorg to add more to my team. The product team grew from about 3 people to 15-20, very few of whom reported directly to me, which created challenges of its own! After nine months, I had to make a decision on whether to see the project through to the next phase with a team of 6-7. Ultimately, I decided to return to consulting.
I took on the people manager role in an effort to make a stronger impact on the success of my office, and in doing so, I developed a new perspective on the operation of our business. A large part of people management at my level could be summarized as bridging our leadership's goals with the individual intentions and motivations of my reports. I have found that I'm able to produce such alignment best when I am able to practice candor, empathy, and trust on both sides of that bridge.
As a "P-level manager," I straddled the line between technical and organizational leadership. The role was about between roughly 75-90% engineering and 10-25% people management, depending on need. Maintaining my responsibilities as a contributor motivates me to a high degree, and I love that it keeps me attuned to the experiences of the majority of the office and to my reports.
Becoming a software engineer at Pivotal Labs has been a profoundly transformative experience for me. At Labs, we espouse a very structured work methodology for its Labs teams: we aim to colocate 40 hours a week, pair program for 100% of our development time, and test-drive 100% of our code. Exceptions arise, but prove the rule--a deep understanding and commitment to Pivotal's engineering practices bring me and my teams product success time and time again.
Software engineering has been only one component of my role. We are client-facing consultants as well, driving constantly toward our their definition of success. Most of my project teams have been split 50/50 between Pivots and clients, and we prioritize pairing with our client's team members while we are onboarding them to our methodologies. As I have matured in my role, my daily project activities have become nearly 100% client-facing.
US Patent #9588938. System-solver co-warping for time-domain solutions of continuous systems.
Certified Kubernetes Application Developer (CKAD). Verification ID: CKAD-2000-003055-0100.