Musings on Systems, Leadership, and Organizations

Oh, hello. I didn’t see you there. My name is Jordan Stone and I’m a Scorpio. Maybe you are, too (a Scorpio, at least. If you’re also Jordan Stone, please reach out). Either way, you’re here, by accident or on purpose, because you lead Software Engineering teams or an entire Engineering organization, and want to do that better. You want to do it better on purpose. That’s what I’ve been doing for the last 10 years or so. I haven’t always succeeded. In fact, I’ve failed a few times and messed up a lot more than that. But I’ve also learned a few things along the way, tailoring my philosophy on leadership and the practical steps needed to build strong Engineering organizations. In software engineering we rely on best practices and patterns to build software. Those patterns and practices ebb and flow over time as we identify better ways to build and scale software systems, but they provide us with a template we can use. We identify a problem, find a design pattern best suited to solve that problem, and implement it. Building teams, or entire organizations, often times lacks the same kind of established best practices and patterns we’ve come to rely on when building software. There are patterns, to be sure, but you can’t blindly apply them without considering the context, culture, and stage of your particular organization. This newsletter (this stack? Is “stack” the noun here?) is an attempt to bridge that gap.

This is a topic I’ve been wanting to write about, and have been encouraged to write about, for a long time. I’ve struggled to get started. I’ve struggled because, as with most topics on the Internet, there is so much content available that I didn’t want to just contribute to an already crowded conversation. There are plenty of resources available about improving the way you lead a team, about transitioning from an IC role to a manager role, and about broad industry trends and practices. However, I’ve found fewer resources on how to implement a re-org, considerations when rolling out a career framework, the challenges in introducing new team practices, or using data to help improve an organization’s effectiveness. When we make a change in our code, the software we’re writing happily complies (though maybe in ways we didn’t intend). Changing tools, processes, culture, or entire organizations doesn’t respond in the same way. Every team is unique, which makes pattern matching the way we do with software design more difficult. And so, “blog name” will focus primarily on aspects of leadership such as moving from one-team-to-multiple-teams, scaling organizational and operational excellence alongside scaling software, pushing (and sometimes pulling) your teams along an organizational maturity curve, and working to meet both business and technology objectives. Many of these topics apply to more than just Engineering orgs. While some topics may relate specifically to leading technology organizations, many are what I have found to be truisms in any industry and in any team. And that’s my goal: to contribute back to the collective consciousness on ways to lead effectively, to build sustainable organizations, and to help you make your organization a place people can build and grow their careers.

Ok, so interesting set of topics, but why me? Why not just Google (or ask ChatGPT) “how to do squads” and lead your organization the same way Spotify does? Leading organizations is about doing it for the org you are today, not the one you hope to be in 3-5 years or, worse yet, the one you read about online. And, more importantly, it’s about doing it in a way that best serves your unique culture and the people who comprise it. I’ve had the opportunity to lead at scale-up and growth organizations for much of my career. I’ve done the hyper-growth thing a few times. I understand how culture changes when you go from being the only engineer to a team of five, ten, twenty-five, and beyond. I’ve not only managed managers, but introduced the concept of engineering management to companies several times. And I’ve done it while still being involved in the technical details and occasionally being hands-on-keyboard myself. If you’re leading an organization in a growth phase and trying to figure out how to maintain your culture, establish best practices, or push your org to success, this newsletter is for you. If you’re at a larger, established organization and are wanting to create more leverage, grow the next round of leaders, or become a more data-driven organization, this newsletter is also for you. Fortunately, I don’t know everything. I’ve messed up a lot. And from my failings, I hope to also share learnings to help others avoid the same mistakes. I want to contribute to the collective conversation about engineering leadership, organizational design, decision making, team building, culture, and operational excellence. And it should be just that — a conversation. If you have questions, if a future newsletter speaks to you or a challenge you’re currently facing, please don’t hesitate to reach out. Our teams, our organizations, and our industry-at-large gets better when we work together to lift all ships. I look forward to being one more rising tide that lifts others, helps to cultivate stronger leaders, fosters healthier cultures, and drives meaningful progress in the way we build and scale engineering organizations.