Show Notes
Let’s imagine that you are just taking on an engineering organization. Maybe it is new to you or maybe it is completely new. What should you do to set yourself up for success? What are some of the important, or critical, aspects to think through, write down, nail down, or get agreement on?
In a five-part series, Mon-Chaio and Andy look back over the long, and sometimes rambling, episodes of The TTL Podcast and try to condense them down to something more digestible. This episode will guide you to laying the foundation on which everything else will rest: culture, values, long-lived KPIs, and long-lived boundaries.
References:
Transcript
Ep 022 – Starting an Engineering Org (Part 1: Laying the Foundation)
Mon-Chaio: Thanks once again for joining us on the TTL podcast, where today we’ll be discussing the core tactics to use in order to build a great and differentiated engineering organization, either from scratch or through transformation.
Now, before we get to the meat and potatoes, I’d like to take a quick detour. And actually before I even get to the detour. I want to mention that it’ll just be me for this episode. So if you’re hoping to listen to Andy, you’ll just have to wait until the next episode. Now, back to the actual detour.
Andy: Andy here. Something we’re doing with these episodes is that one of us writes and records, and the other does the final editing. So for this episode, as the editor, I have, and on the next episode Mon Chaio has, the opportunity to jump in at times and add our two cents. Which I think should be a little fun.
And now, back to the show.
Mon-Chaio: I was just thinking the other day that the TTL Podcast is now about 20 episodes young. And at least for me, and I’m guessing for Andy as well, I actually sometimes struggle to remember back to a time when we both weren’t podcasting together. It’s kind of been all consuming for a while now. But when I do think back to that evening when Andy was in Seattle and we first started talking about launching a podcast, one thing that I recall is us asking the why question. What would make us different than all these other technical leadership podcasts out there? And whatever that was, did the world need … whatever it was that would make us unique. Would they even listen? Would we have any listeners?
So lots of ideas flew around. But eventually I think we landed on what makes us unique and it’s something to the effect of, one, we wanted to explore issues deeply. We wanted to eschew the easy soundbite answers and really dig into both the research around a topic as well as what our many years of experience tell us about how that research is best applied. Or perhaps not applied. And two, we wanted to talk about topics that maybe weren’t being discussed broadly. Topics that folks perhaps felt uncomfortable talking about in the tech world. Maybe these topics are a bit controversial. Or maybe they’re extremely nuanced with no easy answers. And so talking about, or just leads to more discussion instead of finding a resolution.
Twenty episodes in, I feel like we’ve done a decent job of executing our vision. You know, definitely there’s some hits, there’s some misses, but overall I’m quite happy with where we ended up. One challenge with our vision though, is that it does necessitate a certain length and format for our podcasts, which I’m actually sure is not accessible to some folks. I mean, each episode is approaching about an hour. And we end up discussing many different facets of the problem. In an effort to try to explore the issue as fully as possible. But that means that our podcast definitely doesn’t lend itself to those that are just looking to get to the point. Can you to just get to the point quickly, please? And I get it.
I mean, I was just telling Andy the other day that. Most of the other podcasts, I listened to have timestamp links, so I can just kind of click on those and skip to what I really care about. And, the TTL podcast doesn’t even have timestamp links. So … yeah, it’s not really approachable for everyone, or at least not for everyone maybe regularly every week. And I think that that’s generally okay. That’s why there’s other podcasts out there. There’s a flavor for every listener. But as Andy and I mentioned in our last episode, As we’re coming up to the holiday season, we thought we try something a bit different. A bit more to the point, a bit shorter, a bit more soundbitey. No, I don’t want you all to get used to this.
This is not going to be the regular format going forward. And obviously this isn’t just as a service to those folks that can’t consume or find it difficult to consume our regular content. A big part of this is also for us. It takes us a ton of time to produce our regular episodes. And with the holiday, let’s just call them holiday duties, coming upon both of us, we’re trying to find a way to reduce the amount of time we spend producing episodes for the next few weeks. But that’s just till the new year of course, where we’ll dive back into our regular format, full steam. But until then, our episodes are going to resemble what I think of is an old TV trope, the clip show.
So, but no, no, no. Hold on. Hold on, hold on. Don’t turn us off just yet. Don’t press stop. Just because it’s closer to a clip show, that’s not to mean that we don’t think there’s any listener value out there. We think there is, and not just for part-time listeners. The TTL podcast covers a bunch of disparate topics and Andy and I don’t often tie multiple episodes together into a cohesive picture. So, for example, what does psychological safety have to do with boundaries or developer productivity?
But for the next few episodes, we’re going to do exactly that. We’re going to take a bunch of these disparate topics that we’ve discussed before. And use them to answer our central question for the end of the year of 2023. And that question is, drum roll, please …
“If I’m starting an engineering organization from scratch. Or trying to transform one that I’ve inherited. How do I go about setting myself up for success?”
So we’ll start answering that question with this episode, where we talk about laying the groundwork, the preparation, the foundation. You can think about this work as the strategy document, or the vision document, the business plan. And this is sometimes the overlooked stuff of building teams that if you get wrong can really hinder you for a long term as you’re building on very shaky or oftentimes no foundation.
We’ll follow that up with further episodes summarizing each of the remaining stages. From hiring and filling out your organization to behaviors and processes to set up your new team for success, to structures to ensure things are operating smoothly, to a really super important topic of how to make sure your organization is constantly learning and improving.
All right. So at this point, I think you’ve all indulged, my tangential ramblings enough. So let’s get right to it now. You’ve got a new engineering team. Whether it’s brand new or inherited. What are the first things you need to do to make sure you have a solid long-term foundation to build upon?
In my opinion, the absolute first thing you need to decide is what do you want the culture of your engineering organization to be. We talked about the definition of culture in episode nine, Demystifying Corporate Culture. Take a listen:
Mon-Chaio: That definition of culture, I think makes it clear why this is the facet with which you need to start. Culture governs behaviors and beliefs. So everything you want to do, everything from the processes you want to implement, every behavior you want to elicit, will be orders of magnitude more difficult. If it runs counter to your culture. And this isn’t just the domain of technical organizations. Here’s a snippet of an interview with Steve Kerr, one of the most successful coaches in American professional basketball, talking about the advice he was given when he took his first head coaching job:
As Coach Kerr does a great job of describing, culture is foundational. Much like strategy without understanding where you want to go, your initial steps will be faltering at best and at worst ineffective. You heard Coach Kerr talk about his key cultural values at the end of that previous clip. But how do you go about establishing your key cultural values? A firm base upon which everything else builds. The secret here is actually a minimizing mindset where less is more. Andy and I talk about this process in the Demystifying Corporate Culture episode:
Mon-Chaio: So as you heard the trick here is to pick the smallest subset that you possibly can. The core values that you believe in. And that becomes your starting culture. Culture will change over time. That’s inevitable. But the goal here is to have a north star, something that will be the guiding principle for your new organization, something that you can point to in order to explain the why’s behind the how’s of how you’re working.
The next step, once you have that foundation, is to start thinking about the boundaries of your organization. We talked a bit about what boundaries are and why they’re useful in our first episode ever, Analyzing a Team Situation Using BART:
Mon-Chaio: Later on in the same episode, Andy goes deeper into the defining aspects of boundaries:
As you heard, clarity of boundaries is extremely important. And it’s even important at the very beginning, even before you have a team, for two reasons. The first is that your product will be subject to Conway’s law and setting up the right organizational boundaries will help you create better software, and vice versa. I mentioned this phenomenon in one of our VacationCast episodes, episode 15:
Mon-Chaio: I’m not sold that you should start with a shape of your software and form teams around it, especially in the early stages of your company and organization. But even early on, there are structures and boundaries you absolutely should think about pinning down, which, because of Conway’s Law, will have large effects on your organization and structure. We discussed an important one, long-lived KPIs, in episode two, Longevity of Team Boundaries:
Mon-Chaio: Explicitly laying out clear boundaries based on business level metrics for your AAA teams, that is teams that have authority, autonomy, and accountability, means that, due to Conway’s Law, your engineering organization will be much more likely to build software that also aligns with your core business goals. So the broad effects of Conway’s Law is the first reason to think early about boundaries. The second is that research has shown structure or bureaucracy actually helps create higher performing teams. It sounds a bit counterintuitive, but we touch on why that is in episode 14, The Undeserved Malignment of Bureaucracy. Take a listen:
Mon-Chaio: Now the key phrase to take out of that clip is minimal structure. Not no structure. Minimal structure. No structure leads to organizations performing worse. So boundaries and structure, a part that people often neglect is, in our opinion, centrally important to think about and plan for as early as possible.
It’s important to be clear though, that we’re not suggesting that you go off and put a bunch of different structures and ideals and processes into place prematurely. The concept of YAGNI still applies here. And for those that aren’t familiar, YAGNI, Y A G N I, stands for “you aren’t gonna need it.”
Andy: or if you’re from a more rural background like me, You’d say you ain’t going to need it. None of this fancy aren’t.
Mon-Chaio: This is as true in organizational design as in software. And interestingly, the same misunderstanding about YAGNI reveals itself in org design as in software design. In order for something to be YAGNI, you actually have to think about it. Do the work of deeply thinking about it in order to figure out whether you need it or whether you don’t. And just like in software, even if you don’t need it now, that doesn’t mean you don’t do the quote-unquote extra work to establish the foundations so that when you do need it, it’s easy to bring on in the future.
So to set yourself up for success when starting a new engineering organization, do your deep thinking, then take the minimal set you need to action on right away. Establish your minimal set of cultural values. Establish your minimal set of long-term KPIs and OKRs. Then use those to establish your minimal structure of teams and organizations. That’s going to be your foundation. And in our next episode, Andy will touch on how to build upon that foundation and fill in the structure to build a differentiated and highly impactful engineering organization.
That’s it for this week. Let us know what you think of this episode or about the podcast in general. You can email us at hosts@thettlpodcast.com. That’s hosts@thettlpodcast.com. Also like us, subscribe, and comment on your favorite podcast platform or wherever you listen to The TTL Podcast.
So until next time, be kind and stay curious.
Leave a Reply