In our first Labs episode of the year, LinearB COO and Co-founder Dan Lines is joined by CTO Yishai Beeri to explore how elite engineering organizations set and report on their engineering goals.

Modern engineering leaders face a dual mandate of achieving operational excellence while aligning their work with business priorities. To achieve this, you need to deliver software predictably—projects need to be delivered on time, within scope, and as promised so the rest of the business can drive ROI. Dan and Yishai highlight goal-setting methodologies to achieve predictable delivery and key metrics to focus on, ranging from planning accuracy and capacity accuracy to cycle time.

Along with goal setting, we cover how to effectively report on your goals and progress to business stakeholders. Plus, you can download LinearB’s CTO Board Deck Template to leverage in your next board meeting.

“We need to remember that less is more. Don't come with 50 numbers, it's not going to work for the business discussion. Focus on what really matters and always show how that aligns with the business.

If you're talking about predictability, ‘this project is landing on time or 90 percent of it is landing on time, and here's why, and here's the choices that I've made.’

That was when you start overcoming those glazed eyes of some numbers on something that I don't understand. You're seeing success when you get people are asking you to drill down, right?

Episode Highlights:

01:24 Key terms to know when setting goals 
02:17 Engineering leaders’ dual mandate: operational excellence and business alignment 
08:18 How can engineering leaders set goals to achieve both sides of this mandate?
11:37 Why engineering organizations need to deliver predictably 
19:37 How to set goals around resource allocation 
27:30 Reporting on your goals to business stakeholders 
32:56 The LinearB CTO Board Deck Template

Show Notes:

Transcript:

(Disclaimer: may contain unintentionally confusing, inaccurate and/or amusing transcription errors)

[00:00:00] Yishai Beeri: We need to remember that less is more. So don't come with 50 numbers. It's not going to work for the business discussion. Focus on what really matters and always show how that aligns with the business.

So if you're talking about predictability, yeah, this project is landing on time or 90 percent of it is landing on time. And here's why, and here's the choices that I've made. That was when you start overcoming those glazed eyes of oh, some numbers on something that I don't understand.

You're seeing success when you get, people are asking you to drill down. Right. They're asking you smart questions about the data that you're showing.

[00:00:36] Conor Bronsdon: Gardener just released their market guide, showing that software engineering intelligence platforms, help engineering leaders significantly improve both team productivity and value delivery. Through Gardner's in-depth analysis on the critical features of sci platforms and how they can be used to drive engineering excellence.

Linear B was named as a representative vendor. And therefore we're giving away a complimentary copy of [00:01:00] Gartner's sci market guide. Head to the link in the show notes to download your complimentary copy and learn how you can unlock the transformative potential of software engineering intelligence for your team.

[00:01:11] Dan Lines: Hey, what's up, everyone? Welcome to another Labs episode of Dev Interrupted. I'm your host, Dan Lines, LinearB COO and co founder. And in our Labs episodes, we dive deep into data. And best practices that we find. And today we're talking engineering goals and reporting. So what we're going to do, we're going to unpack the data and strategies that elite engineering organizations use to set goals that drive predictable software delivery, and also how you can report on your progress to senior leadership.

Very, very important thing to do. And I'm joined by a voice, who will be, I think, very [00:02:00] familiar to many of our listeners, an expert who has helped countless organizations use goal setting to drive engineering improvement, LinearB's own CTO, Yishai Berry. Yishai, welcome to the pod. Thanks Dan. Great being here.

Awesome to have you on, brother. We're going to dive right in. Our first topic in general is around goal setting in the dual mandate.


Defining our terminology for the discussion 
---

[00:02:30] Dan Lines: I know our listeners are likely aware of the meanings of some of these acronyms that we're going to use here. There's a bunch of them, but I think they're crucial to the topic we're about to discuss.

And so just to make sure we're aligned, I want to quickly Quickly maybe recap some of this terminology, so we'll probably talk OKRs, so OKRs, Objectives and Key Results, KPIs, Key Performance Indicators. These are like the most business [00:03:00] oriented acronyms ever. Then we have SMART goals, S M A R T, which are Specific, Measurable, Achievable, Relevant, Time bound goals.

So those might be some of the things that You know, some of the acronyms that we use. Now, one of the key things we've noticed in goal setting for engineering teams is a shift in what goals need to look like.


The dual mandate of what's expected in engineering teams
---

[00:03:22] Dan Lines: So engineering leaders today have a dual mandate of both expected to be elite in operational excellence.

So when we think of operational excellence, I almost think of this as like maybe where engineering teams started. It's to deliver the stuff in high quality. Do your engineering thing. We've been doing this, I don't know, 50 years now, 30 years now, ever since I was doing engineering. That's operational excellence.

Like, be really good at engineering stuff. But the other side of it, and I think this is newer, I know it's newer. And I know the [00:04:00] best engineering leaders talk to me about it all the time. A lot of our customers are doing this. It's alignment with business priorities. That's the second part of the dual mandate.

And I think the reason is most organization has recognized, okay, our engineering team is like the lifeblood of the company. There's a product that goes along with it. We sell that product. Maybe it's a SaaS product. And if we're aligned on business objectives, we make more money. I think that's where it's coming from.

And that's the other side of it. So I'm going to, that's kind of setting the table. So Yishai, how has that dual mandate impacted how R& D leaders need to think about goal setting?

[00:04:42] Yishai Beeri: Yeah. So definitely a shift, like you said, if you, you, you go back, um, you know, when I started working in engineering management and leadership, there was always the focus of, Are we running a tight ship?

Are we getting the most out of our developers and that [00:05:00] spend? Are we, um, effective in, um, translating the, you know, the cost of having a dev team into new features? Velocity? There's a very old word in engineering management, um, but also quality. Are we good at what we do as a, as a, as an art, if you like? Um, and I think the strong engineering leaders always had the notion of being aligned with what the business needs, but it's more recent that this is surfacing as something that's measurable and something that needs to be, you know, Tied to how we set goals, how we measure our organization, ourselves, how we report to our peers to, you know, managing up.

That is a little more recent and there's good ways to think about, are we aligned with the business? Are we not just running a tight ship? In an effective operation, we're also, um, tuned to [00:06:00] what the business needs, which means it's, you know, this is about delighting customers. It's about understanding the things that move the needle for the business and for the business to grow or to take the next step in its journey.

Um, we know software is eating the world and every company now is a software company. I think a lot of that shift came from that. It's no longer one of the departments which happens to, you know, dabble with writing code for some either internal or even a product. All the companies are becoming software companies.

If you run an airline, you're a software company, right? If you're selling hamburgers, you're a software company. So, um, having the engineering department, you know, it's rapidly becoming stronger. More of the spend is going there. Decisions which used to live outside, like in IT, or even in other business processes, have become engineering, because engineering, [00:07:00] uh, everything is software.

So now even business processes, in many cases, are run by engineering. All that burden now means that we have to really focus on, are we building and investing our time and energy in the right places? Which is the business alignment part.

[00:07:18] Dan Lines: You know what's so funny about what you were saying? I was thinking a lot about it.

I think it's really smart. And it's almost like this dual mandate, honestly, has kinda been there forever in a sense. Right now, and for the forever future, it's like mandatory. Because of all the reasons that you said, every, every company is a software company, even if you sell hamburgers, you're a software company.

Yeah. But if I think back to when I first started, even in development, very, very long time ago, the best leaders, people would say, Oh yeah, I love that person. Oh yeah. Why do you love that person? Well, that person can talk about when is the [00:08:00] project going to be delivered? They can talk to the CEO about what the CEO's needs are.

What are the most important things that they were almost like amazing translator. They had all of the engineering practices of efficiency, quality, you know, low change failure rate. And they had this other ability to say, okay, I know exactly what the business needs and I can talk to all of the go to market team about how my team engineering is going to hit those goals.

Like those were the best leaders. Now I think it's just like mandatory to be like that. Would you agree? Like the people you think about who are like, great.

[00:08:36] Yishai Beeri: I think it's, it's both becoming mandatory or a sign of, yeah, this is a strong leader for engineering. Um, it's also becoming much more explicit. It's not just a soft thing that you need to have.

There's, you need to be talking about very specific, um, items and, you know, interact with the rest of the business in specific ways. Yeah. Because if you're not [00:09:00] going to be predictable and empower the go to market side of the house Then there's a built in delay between when features and capabilities are ready and when the field can actually sell them, for example, uh, or support them.

So it's becoming much more structured, I think.

[00:09:18] Dan Lines: Yeah, you're right. I mean, and that I think leads us to the data and the goals.


How can engineering leaders set goals that help them achieve both sides of this mandate?
---

[00:09:24] Dan Lines: So now that it is. Mandatory, and it needs to be explicit. How can engineering leaders set goals that help them achieve both sides of this

[00:09:38] Yishai Beeri: you know, we're now taking this to a more tangible step of, okay, I need to set goals. Like in every business unit, I'm not going to measure everything or goal around everything. It's too much. You need to apply some focus. Um, realizing and understanding that the dual mandate means that, okay, I need to think about at least the two sides.

I need [00:10:00] goals around my operational excellence, about our productivity. Um, but I also have to have some goals around the business alignment. So, the first, like, um, you know, actionable step is make sure you have a goal on each of each side of that dual mandate. A goal on the business alignment part can be around your predictability.

Am I being, like, able to deliver on promises or be predictable about delivery in a consistent way? It could be about, um, are we spending enough on Um, on building new value, are we able to focus enough of our efforts in building and creating new value and not just chasing, uh, putting out fires, uh, just, you know, keeping the lights on?

Do we have enough of our spin on innovation? Or it could be about the key projects, the key initiatives that the [00:11:00] business really cares about and making sure that we are investing enough in these. Not just in our plans, but also in actuals. If I needed 20 people on that project, am I actually getting 20 people on that project?

These are the kinds of goals we can take for the business alignment side. And then on operational excellence, there's, things like cycle time, like understanding our, um, developer experience, our quality. There's a bunch of goals and metrics depending on where you are in where what's really important for you as an organization I think these things are a little easier to measure because they've been around longer.

There's a little more And even on intuition, engineering leaders tend to gravitate to those areas. So, have one on each is a good starting point. Yeah,

[00:11:50] Dan Lines: I think what we want to do, of course, what I want to do on this pod, we have a lot of pods in Dev Interrupted that are about the DORA metrics, cycle [00:12:00] time, change failure rate, deployment frequency, MTTR, then you have all your leading indicators, PR size, rework rate, I'm going to put it aside for a second.

Let's talk about where the industry is going. And you said the one that caught my ear the most was predictability. When I talk to engineering leaders and what I know from my past career, the question that's always asked on the engineering leader is like, when is the thing going to be done? Delivered to me.

When do I get my value? When do I get to close a big deal because you have this new feature that came out? When do I get to retain a customer? So if you don't mind, let's focus in on predictability. And one of the, you know, KPIs that we talk about at LinearB would be the planning accuracy. It sounds cool, and I think it's a great KPI.

Maybe you can start there, but what are the other things that come to mind for you when [00:13:00] you think, Delivering projects on time, predictability.

[00:13:04] Yishai Beeri: Yeah. So I'll start by saying, you talk with engineering leaders and with, with business leaders, the CEOs and you know, the peers around the table, like the marketing leaders, the sales leaders, and As you look, as you look into more larger companies, larger businesses, uh, forward thinkers, they are starting to trade volume or velocity for predictability.

Right? I can take a little less production, but at a better predictability. Right? Why? Because software is, you know, going agile. It's all about trying to move fast, even break things. Tight learning cycles, but then there's the whole surrounding part of the business that needs that predictability. You're not going to be able to pull up a marketing campaign and Uh, in a day, just because they release the agile software team [00:14:00] just delivered, right?

You have to prepare. You have to line up things. Um, not everything in the world can be as agile as software delivery. So predictability becomes more and more important. As you grow as a business, as you have more customers, uh, more varied set of customers, um, and, um, with that in mind, looking at the, the, the, Specific metrics and the specific ways you can measure and goal around predictability becomes really important.

So, planning accuracy, you know, that's a good place to start. This is about understanding how we deliver sprint over sprint. Is our planning and delivery, are they aligned? Are we able to deliver what we promise? First to ourselves, then to our surroundings, um, on a sprint by sprint basis. If you're able to master that, you're on a path to being able to predictably deliver a project, which is like multi sprint, maybe a quarter, uh, a bigger chunk of work.

And then you [00:15:00] have, when you look at, you know, you zoom out, you look at a project. Now you have, um, you can talk about, How much of the project scope did I hit? Did I, is it getting, getting in on time? And it's not just about goaling and reporting. You can also make some decisions before the project ends to optimize what you're landing with.

You're not always going to deliver 100 percent of everything. We know that. There is a time when you look at the data and you say, okay, I need to change something. Maybe give up on these scopes, some items. Focus my energy on the ones that are almost there. So, understanding the, the burn up, if you like, for a project, or for your whole, your whole delivery in a quarter or similar planning cycle.

Making adjustments, but also tracking quarter over quarter, are we delivering enough of what we promised, enough of what we planned, in good quality. That would be a great goal to, to track and improve.

[00:15:59] Dan Lines: I [00:16:00] mean, you talked about kind of the maturity I would call it, of the space maybe moving from I always have like the CEO in mind 'cause I have this like CEO archetype of like, just give me all the stuff.

Like do it fast. Yesterday, there's, yeah, yesterday, I needed it yesterday. A little more maturity of like, okay. I value predictability because I understand my marketing team can be in sync. My enablement team for sales can be in sync. My enablement team for CS. The way that we go out with this product matters to me or this feature matters to me.

Maybe you have like a Gartner interview coming, coming up. The predictability matters a lot for the whole business to be in sync. And we, we have this in, in our LinearB product. It's like, I remember the CEO used to ask me, okay, is the project going to deliver on time? And I would say, yeah, because it's like, what else can you say?

And then it's like, uh, like, [00:17:00] why would you want to say no? Then it's like, you have no confidence. Like, yeah, it's going to deliver on time, but then it's like, yeah, but you said that last time with the last project and it was like three months late. And it's like, oh yeah. Sorry about that. That's like a very like qualitative conversation.

Now, here's the new conversation. You pull up, you know, our feature is called forecasting, but you pull up your for your project forecasting mod module and you say, Yeah, I do think it will be delivered on time. There's some risk. I want to talk to you about it. Yeah. Click into the project. Yeah. It

[00:17:36] Yishai Beeri: also moves from yes, no to the project is not a monolith.

So there's a bunch of things. These are golden. These are in risk. It's a yes, but, or we have to make decisions now.

[00:17:49] Dan Lines: I think it's like, yes, but, and let me show you, let me bring you in. You know what? The planning accuracy for this project looks good. Let's say it means that the teams [00:18:00] are able to deliver on what they say they're going to deliver.

I'm, I'm, I'm doing kind of a conversation. Let's pretend you're my boss or the CTO. I'm an engineering leader. The planning accuracy looks good here. So that's a good thing. It's giving me confidence. But there's something that is concerning me on this project. And I want to show you something. It's our cycle time on this project.

I'm seeing bottlenecks here and I'm seeing some bottlenecks because it looks like only one person is doing all of our reviews. We have a, it's a senior and we have a lot of juniors on this project. Now I know that this project's due in six months from now, but I want to call out this people risk to you.

It's a very mature conversation. I'd like to add another senior to this. And the reason I want to add a senior is to increase my probability to deliver on time. And even better now, I know this is like futuristic stuff, but this is what we're working on with some of our customers. Let me show you a Monte Carlo simulation that if we were to do this, why I think it will [00:19:00] help us deliver on time.

Now I'm talking with data. I'm talking with risk levels. I'm talking with Simulation to the business of like, let me bring you in of what it really takes to forecast. I think that's really cool and kind of like next level mature conversation. What do you think about that?

[00:19:19] Yishai Beeri: Yeah, I really like the the ability to take this from uh, is this on time?

Yes. No, or why isn't it on time? Right. That's the common question. Why are you guys late? You know, using data, we can move the conversation to let's, let's make some decisions. It's probably not just magically create a new resource, but let's move someone from a project that is doing well and maybe has some capacity, uh, that, that they can contribute here because I have a bottleneck here.

The data is showing me the kind of risk that I can alleviate with moving a resource and maybe not lose so much on the other project because the signals there are different. [00:20:00] What? When the conversation moves to making choices and you see the choice you see the you know the outcomes it becomes a much Much stronger conversation.

[00:20:12] Dan Lines: Okay, so let's do a little summary on the predictability side, we have some KPIs, right? We have planning accuracy. That's a good one. We have capacity accuracy. That's a good one. We have project forecasting with simulations.

That's a good one. And now imagine having that for all of your projects. You see them all in one view. That's awesome. Now there's kind of this like what you're saying. I have to make decisions of what, what to do.


How can managers think about goals around resource allocation?
---

[00:20:43] Dan Lines: Can you talk to us a little bit about goals around resource allocation? Cause sometimes a lot of those decisions might be, ah, I don't know.

We just were understaffed on this project. Is it really the top project? I could move this one faster if we could delay this other one, but I got to shift some people. Talk [00:21:00] to me about resource allocation, investment profile, goals around that kind of stuff.

[00:21:04] Yishai Beeri: So both resource allocation and investment profile are ways to look at the actual spin.

Where is my energy going? Where are my people deployed? Not just in, in, on paper, on plan, but what is actually happening? And I think a very common, um, cycle, and we've seen, we've all seen this, where Management sits at the beginning of the quarter, lays out a plan, allocates resources. Yeah, let's take 20 people for this project.

Let's put this team on that project. This is important for us. It's a new product or a new feature. Let's, um, um, concentrate some work and resources there. Great. The plan looks good. Then reality hits, right? So this 20 people project, yeah, on paper there's, they're all there. But three you haven't even hired yet, two are busy, uh, with an old project that they weren't [00:22:00] able to ramp down quickly enough.

Um, another one is pulled to put out fires elsewhere. Reality is different. And then the quarter ends and why have we missed? You spend time to realize that actually we didn't have the 20 people. So research allocation is a way to look at what is the actual spend across projects or initiatives or any kind of like slicing the pieces of work in your, um, dev work and course correcting.

Yeah, this is what is actually happening. This is what we wanted. We can now course correct. We can help people ramp up more quickly or ramp down more quickly if a project needs that. Or we realize that we have a gap. Now we can make a choice. Okay. Reality is a bit different. Let's make a choice about what to, um, you know, what to give up on, what to invest more in and so on.

Totally

[00:22:54] Dan Lines: makes sense. And now we can have kind of that educated conversation with the business. [00:23:00] Okay, so now that we talked about kind of both sides of the dual mandate, some of the KPIs that you can use for engineering efficiency, we have our DORA metrics, we have some leading indicators, we talked a lot on the business.

Alignment side, predictability, very, very important. I want to ask you, in terms of actually setting goals against these KPIs, where in the org structure should I start? Is it like a top down thing, a bottom up thing? What are your, what are your thoughts on that?

[00:23:33] Yishai Beeri: That's a good one. I think, uh, there's probably not one answer.

first of all, there's the org culture that you have to take into account. Um, in some, um, respects, and I think mostly on the engineering, uh, like operational efficiency, there's a lot of sense in doing this bottoms up and letting the teams decide on which goals to take and what, like, how to tune the goals.

Because, [00:24:00] uh, in many modern, um, you know, development organizations, you want to give autonomy and you have the right people that you can give autonomy. The team knows how it's delivering. They have, maybe even between the teams, there's a difference in how they're working. Some could be using scrum, some could be using Kanban, some could be using a combination.

Some are building. You know, SaaS front end, some are doing mobile apps. So very different ways to measure and to benchmark. So giving autonomy and the bottoms up approach makes a lot of sense. And also very strong culture, positive of, you know, it's not like a big brother watching over your back and measuring you.

It's more like This is a way for you to measure yourselves and report up. Um, and it still makes sense in these cases to have a top down focus. Yeah, we know as a company, as a dev work, we have, we want to focus on being more efficient. [00:25:00] Let's make sure we look at cycle time top down because it's a good efficiency and bottleneck discovery kind of metric.

Um, if we have a quality issue or a quality, initiative going on in the company. We can make that a top down and bake that together with with bottoms up. Yeah. On the business alignment side, I think it's typically running top down with, you know, org level or VP level and then departments or groups.

Aligning either to the product lines or the way the org is built. Um, you want predictability to be measured across your teams or groups and then aggregate it up. That makes a lot of sense coming top down.

[00:25:43] Dan Lines: it's kind of like a mix. One thing that I've seen, especially with the larger organizations, Let's say you have a hundred developers plus 5, 2 50 developers, 500 developers, and then I don't know, we, I'm working with companies that have 6,000 developers.

[00:26:00] I think that there does need to be something top down around standardization, I'll call it. Now, of course you want bottom up adoption, but when I think of standardization, it's kind of like, here is how we're going to measure cycle time. This is our standard practice of when cycle time starts versus when cycle time ends, and that's the standard for our business.

Here is how we're going to measure sprint planning accuracy. This is, you know, how we start it either when one day into the sprint or right when the sprint So, what I've seen is when you bring these top down standards It kind of says, when do things start and stop? And what do the, what are the KPIs that we care about?

Now, after that, we care. Yeah, we care. Now you have the standards. We do care. I think it's more go deploy this with your teams and set your goals around this. Here's our high level goals. You go make it [00:27:00] happen. That's where I've seen it works really well. You have top down standards. You say the KPIs that the company or the business unit cares about, and you give some high level guidance on the goals.

Now you go make it happen for your team. That's, that's kind of what I've seen work really well.

[00:27:19] Yishai Beeri: And I think that lets the, the, the teams or the, you know, lower parts of the org focus a little on the leading indicators. Sometimes on more technical, um, ways to look at the problem. So you could, you're thinking about cycle time as a top down, but then for a team to improve their cycle time, they could be looking at smaller PRs.

They could be looking at how long does it take me to pick up a PR for reviews, a pickup time. There are the ways to implement that goal are a little more detailed. And another team may look at different, uh, they have different bottlenecks. So they'll, they're going to take a goal around a better review process.

Or can I automate [00:28:00] away some of my reviews?

[00:28:02] Dan Lines: Absolutely. Now, what I want to do in the last few minutes of this pod, is talk a little bit more about the business stakeholders and what it takes for a VP of engineering, a CTO, a director of a business unit. Maybe even you're communicating, you know, to the board.

We have, you know, You know, from LinearB board slides that you can use to communicate, you know, these KPIs.


How do I approach business stakeholders with measurement data?
---

[00:28:35] Dan Lines: But what can you tell us, maybe an overview or some tips and tricks? I'm an engineering leader. I'm measuring this kind of stuff. How do I approach business stakeholders? I've never done it before.

What do I, what do I do?

[00:28:49] Yishai Beeri: Yeah. So, um, first, you know, a lot of us hit that wall where, uh, it feels like no one cares at the beginning. You know, everyone is about the sales numbers and the [00:29:00] marketing numbers. They're used to seeing numbers and data in measurements for those departments, and they're used to having engineering say I think this feature is gonna land in two months.

That's, so there is some education, Oh, there's actually good data to look at. There's actually a way to drill in. Um, so come prepared to, to Not just show the data and the goals, but also explain why it matters. Why cycle time matters so much, because it lets me, um, you know, learn much faster from the, the feedback that I'm getting from our customers when our new, uh, the new code hits the, um, the users.

Um, by reducing these bottlenecks, I can get so much more done and improve the quality. So, be, like, be prepared to explain why it matters. I think as engineer leaders, and many of us are engineers at heart, uh, we need to remember that less is more. So don't come with, you know, 50 [00:30:00] numbers. It's not going to work for, for the business, uh, discussion, um, focus on what really matters and always show how that aligns with, with the business.

So if you're talking about predictability, yeah, this project is landing on time or 90 percent of it is landing on time. And here's why, and here's the choices that I've made. Um, I think that, that was when you start, uh, overcoming those, you know, glazed eyes of oh, some numbers on something that I don't understand.

You know, you, you've, you're seeing success when you get, people are asking you to drill down. Right. They're asking you smart questions about the data that you're showing.

[00:30:42] Dan Lines: Yeah, that, that's, that totally makes sense. Especially when you start getting some of that engagement and questions. I think my best tip here, what I've seen work really well, if you go to your business stakeholders and say, I'm putting a new thing [00:31:00] on your calendar.

So first of all, it's repetitive and it's going to be repetitive and it's going to be called our forecasting meeting, our project forecasting meeting, and it's monthly, all you got to do is show up. Now, one thing that's cool about that. You may already have this. You know, ceremony of a forecasting meeting, you may not.

So you're going to get some, if you don't, some kudos points, because those stakeholders are going to say, I definitely want to come to a project's forecasting meeting because that's what I care about. Now's your opportunity. You got them in that meeting to start hitting them with, is the project going to deliver on time?

Let me show you some of the underlying engineering metrics of cycle time or change failure rate. You have the planning accuracy, and maybe you start getting some questions about that. And usually what I see is if you relate it back to what they care about, which is these business deliverables, that is when you'll get, Oh, now I care about, Oh, cycle time has something to do with me getting what [00:32:00] I want.

Let me ask a question about it. Yeah. So that would be my tip, my biggest tip. Have you seen that kind of stuff work or any comments on that?

[00:32:09] Yishai Beeri: Yeah. I think you talk about cycle time in, in, um, you know, in isolation. No one cares.

[00:32:16] Dan Lines: Yeah.

[00:32:17] Yishai Beeri: You talk about cycle time affecting delivery of this project, which is What I need to sell more as a sales leader.

Now I can start relating and you'll be surprised by the kind of smart questions you get from your business peers about the data and about what it means. Just like you can ask about the sales cycle and how is the sales cycle different in different segments, right? It's natural for us to drill in when we see the connection.

[00:32:45] Dan Lines: Yeah, it's so funny. It's like, uh, Hey, I want to go ask for new hires for engineering. The answer is always no. Do more with what you have. We're in an efficiency mode. But if you could ever get a question [00:33:00] that says, Oh, we're talking about the delivery of this project. I'm showing you why we're probably not going to deliver.

It's because we have a poor cycle time due to a reviewer bottleneck and you can get your business stakeholders to say, Oh, Well, what if we had another reviewer? Oh, great. Perfect. Yes. Cause I would love to add another reviewer. Actually, I need a senior one. I have a job description. Should we deploy that to deliver this project on time?

That's cool.

[00:33:28] Yishai Beeri: Or, or even I can show you through the metrics that this project is very efficient. It's already running very efficiently. There's LinearB publishes industry benchmarks across all of our metrics. We are. actually doing very good in this project, which means if you give me more resources, there's like, they can be very effective here.

Another person in this project can really kill it because I've already removed a lot of the bottlenecks.

[00:33:54] Dan Lines: Yes,

[00:33:54] Yishai Beeri: it's now running very effectively. A new resource is going to be very effective here.

[00:33:59] Dan Lines: Let me [00:34:00] prove to you that it will work.


What is the LinearB CTO board report?
---

[00:34:02] Dan Lines: So we're coming to the end here. Could you tell us a little, so we have a CTO board report that can be used.

Talk to me about this CTO board report.

[00:34:13] Yishai Beeri: Yeah, so this is a template that, you know, you can use as a, as a starting point to put some, pull some data from LinearB or however you measure your, uh, your key goals, your KPIs. And, you know, in basically two or three slides, convey the key information to, you know, the board or the staff meeting and similar.

Uh, Senior Leadership. And we're basically splitting it into two parts. One is a heartbeat of the health of the engineer organization. The key, key, um, metrics, the top downs. This could be cycle time and something, you know, merge frequency for developer experience. Two or three metrics with a trend, with an industry benchmark.

[00:35:00] Um, um, Context, so you anchor the numbers. It's not just three on the, on the, on the screen. It's a three, which means we're in the, I don't know, strong band of the benchmarks. So, let's have everyone understand what it means. And, we, we, we, uh, suggest that you take a goal. You're saying, in Q1, my cycle time was three days.

My goal for the next quarter is to like lower it down to two and a half days. By having this simple cycle of there's a number, there's a context and a trend and I'm taking a goal. You are now really helping your peers and your, your managers trust you that you've, you've got this. I know what I'm doing. I can see where I'm going.

I have a plan, but I don't think they really care if it's going to be two and a half days or 2. 3 days. You have a plan. You know what you're doing. They are, the confidence is there. And then the second part is. These are the key investments, the key projects. We talked about resource allocation, so show some data.[00:36:00]

There's always going to be the top three, four, five, maybe seven projects or initiatives which are what everyone thinks about. They are the key, uh, investments. Show the investment, show that it's aligned to, to, um, the priorities. You're not overspending, uh, by, uh, you know, a big margin on an area that no one cares about.

You show the engineer metrics for that project, it's actually performing well, or this is where I'm focusing. I'm focusing on improving my bottlenecks for this project before I'm asking for more resources. So, my resource spend aligned on projects and my engineering health. The two slides is all you need to really convey the message.

On how are we doing and start making decisions, right? This is about staffing, about resourcing, about changes. Now you can drive a really valuable conversation.

[00:36:56] Dan Lines: Yishai, thank you so much. That is [00:37:00] a super cool report. It's a free report. Thank you for coming on. Talking to us about the dual mandate and goal setting and even more so what you said at the end.

It's really a career builder. Trust with your peers, setting goals, visibility and transparency. We love having you on the pod. Thank you so much for joining.

[00:37:25] Yishai Beeri: Thanks Dan, as always. This was great.

[00:37:27] Dan Lines: And you know, to everyone, thanks for tuning in. If you want to dive deeper into goal setting, download our free Engineering Leader's Guide to Goals in Reporting at LinearB.

io slash resources. Um, we'll also include that, uh, in a link in the description. And everyone have a great week. Talk again soon.

​[00:38:00]