Your team's code is changing fast, if they're doing things right. That means that as a CTO, VP of Engineering, or other technical leader, your detailed understanding is continuously out of date. Even in a small engineering team, you're probably long past the point of keeping up with each and every PR.

But you need some level of visibility into your team's codebase, so you understand enough to represent your team effectively and take part in meaningful discussions.

Two caveats. I'm talking mainly about organizations:

• who are free to move quickly, without strict specs written before any coding begins. If you're writing code for defense systems, you still need to understand, but you're intentionally slowing down your team's velocity for quality control purposes.
• where decision-making is pushed out as close as possible to the people doing the work. There's ample evidence that this approach is the best way to speed up your team's output, but I acknowledge there are still top-down development teams where architects make all the decisions

_Why?

‍

You've got O(100) meetings this week. Why do you need to spend time getting visibility into your code?

You're the public face of your team. Especially if you're an external CTO, you're joining sales calls and key customer meetings, answering questions about the technology they're buying. They're asking you questions about your team's security posture, or whether you've seen and dealt with the latest vulnerability in the news. They're asking you how and where you're leveraging generative AI in your platform. You need to make sure that the statements you're making align with where your team's work is heading.

At a previous company, I had just finished a call explaining to our biggest customer why we couldn’t run their particular workload due to architecture limitations. Immediately afterwards, one of my engineers reminded me that the team had found a workaround, built a prototype, and it was working well. I had been dealing with fires elsewhere for a few weeks so I completely missed this development. While the customer was pleased to hear the good news, I definitely seemed out of touch with my team’s work.

‍

You're the leader of your team. When you say things that are out of sync with the direction your team is headed, folks pick up on it. They don't expect you to know all of the details—in fact, your team should know more than you, but that's a topic for a future blog post. But when you speak about the direction of your tech (e.g. architecture, philosophy), it should be in line with what they're building.

‍

Spreadsheets (you know the ones I mean) need to be filled out. You need to help with the diligence process to land deals, which means helping your sales team with the latest and greatest answers to the questions in 256-line spreadsheets and security questionnaires. When you answer a question like "describe your system monitoring and logging capabilities, including the types of metrics and events you track," you want to be answering with the latest and greatest, without interrupting your key engineers.

After personally spending tens of hours filling these out to unblock sales deals, I created “cheat sheets” for sales engineers, but those in turn needed to be updated. I was convinced that getting our SOC2 compliance would obviate the need for filling out spreadsheets, but that optimism was ill-founded. SOC2 was merely a checklist item—the spreadsheets and questionnaires kept coming.

‍

Architecture discussions need you to be up to speed. Depending on the makeup of your team, you might be heavily involved in architectural decisions, or may lean on your architects. Either way, you should be involved in the major ones. In order to contribute, you need to be up to speed on the most recent changes. If your team has been moving services off of VMs onto GCP's Cloud Run to gain the efficiencies of serverless architectures, or have started to move some services to edge nodes, you should be aware of where and why these changes have already happened, long before you join a discussion about rolling out the approaches more broadly.

The key to all of this is that visibility leads to understanding, and understanding means you can do your job more effectively.

_How?

‍

"I don't need to understand. I just ask my directors / architects / etc." Sure. But the same "code acceleration" effect is true for them. If you've set your team up to run at full speed, the codebase is changing quickly. As an engineering leadership team, you collectively need to know when shifts happen, get ahead of changes, and understand the rationale.

How do you get visibility into how your codebase is changing?

Lines of code? I think at this point we can call this approach passé.

Quality of code? Now you're getting closer.

Understanding code? Much, much better. Understanding your codebase means that you have a strong grasp of the overall architecture, from components to design principles. It means you have an awareness of the major areas of technical debt in your codebase and how they're changing over time, so you can prioritize and manage that debt in a way that works with your company's business goals. Understanding means you know where areas of your codebase suffer from siloing or thin bench depth within your team, so you can identify and fix knowledge gaps as you guide your team. And understanding means that you deeply understand risks, so you can help your team make informed decisions about mitigation.

You'll hear more in future blog posts from Ted, Adrianna, Rachel, me, and other folks on the Flux team, but understanding code is exactly what we're focused on helping engineering leaders with.