Welcome!
Welcome to Engineering Together, my little corner of the web where I hope to share some of what I’ve learned (and continue to learn) over a couple of decades in Engineering leadership roles. Throughout my career I’ve had the good luck to experience and lead a wide variety of great Engineering organizations. Most recently I was head of Engineering at Starburst, a data platform company commercializing the open source Trino project, so had the opportunity to work at the intersection of SaaS and Open Source. Before that I was at Salsify, an Enterprise SaaS scaleup helping manufacturers manage and publish digital content about their products, where I led the growth of Engineering from the early team of ten to over 170 engineers. Earlier in my career I was CTO at Endeca through its exit to Oracle for over $1B, and was a lead architect on its core search engine. And along the way I’ve been on various startup teams, including as an advisor and board member.
I’ve always wanted to write about insights from this journey along the way, but frankly never fit it in alongside actually doing the actual work of being an Engineering leader. I’m always amazed by people who find the time to do meaningful thought leadership work while also leading a team and (one hopes!) also leaving time for family and life. But recently I’ve entered a career phase where I’ve decided to focus more on fractional CTO work instead of continuing the full time drive, and part of the appeal is getting some discretionary time for extracurriculars such as this.
You might be wondering, does the world really need more digital ink spilled on Engineering leadership? Over the last decade or so it feels like Engineering leadership transformed from an artisanal practice passed along via oral tradition into a well documented set of scientific best practices. I remember seeking out wise counsel from other Engineering leaders about stuff like how to structure and organize teams, how to properly measure delivery and productivity, how to report out to the rest of the executive team and board, etc... but now there are any number of awesome blogs and books you can pick up and simply RTFM. What could I possibly add?
My experience tells me that there is still room for more on the subject. I think every Engineering leader has had the experience of hitting real world situations where they know the best practices cold, but somehow still find themselves facing down hard questions about what to do for real.
Why me?
I hope I can bring a distinct perspective here based on the way my career in tech so far has unfolded. For one thing, I was a bit of an “accidental” Engineering leader. After many happy years as a practicing Engineer, I wasn’t seeking out an Engineering leadership role, but got tapped for my first CTO role by a CEO who saw something in me that I didn’t see in myself at the time. Taking on that challenge somewhat out of the blue was humbling but an amazing experience, and I certainly had to lean on one of my key superpowers of “being willing to ask the seemingly dumb question.”
I’m also grateful for the timeframe in which my career has unfolded. In my grad school years the web was just barely emerging. Established programming languages of today like Java and Python were brand new. In my early professional years SaaS was just starting to emerge, AWS didn’t yet exist, and git hadn’t been created (I remember the joy of migrating from the ever clunky cvs to the relatively sleek svn). All this to say that, so many of the best practices of Engineering were nascent or non-existent, and I’ve been grateful to experience so much of the maturation of our industry as it happened.
Why now?
As Engineering tools and practices have emerged and matured, so have Engineering leadership concepts and approaches. Looking back twenty years, we were so focused on top-down process questions like implementing agile and scrum. Today it feels like picking a pragmatic bog-normal process happens with little fanfare, and meanwhile today there’s such a healthy appreciation of understanding bottoms-up developer experience, the idea that the engineers on the ground and closest to the work are in the best position to call out opportunities to make the environment better and more productive. Similarly, in the past we were focused on such crude ways of measuring Engineering, such as story point completion, while today there’s been so much progress in identifying the factors that really matter to productivity, such as cycle time and deploy frequency.
Which isn’t to say that Engineering leadership has gotten easy! Arguably, the sheer quantity of ideas and tools and approaches that we have to pick from, and the rate at which they’re evolving and new tools are emerging, makes it in some ways harder than ever. For example, as much as our understanding of metrics has improved, we’ve also seen an explosion in the set of metrics that have been explored, and the last few years have seen the emergence of multiple standards like DORA and SPACE. In many ways we’ve gone from the challenge of “DIY figure it out” to “the paradox of choice!”
What’s ahead
My hope here is to share my experiences navigating the space, and I hope provide some ideas that will be helpful to senior Engineering leaders, especially CTOs or VPs of Engineering in software organizations.
My thematic interests revolve around integrating the Engineering function into the business, for example, ensuring strong connectivity between Engineering prioritization, structure, and strategy with the goals of the business. I’ve been particularly interested in the measurement of Engineering, which is a well-known thorny problem, but also one where even incremental progress can be very valuable and important, maybe even more so now in a world where AI is rapidly changing the dynamics of software development. Also, coming from a hands-on Engineering background, I care a lot about Engineering culture topics. I know when I was a practicing engineer, I had both good and bad experiences in terms of how I was able to collaborate within and beyond Engineering. And as an Engineering leader, I felt it was my mission to distill the conditions that encouraged and enabled good Engineering culture and codify these into the ways of working on my teams.
I hope you’ll subscribe or come back and read some of my stuff! I’m looking forward to engaging and learning, and thanks in advance for stopping by!