May 14, 2024 • 38 mins
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.
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:
- Gartner SEI Platform Market Guide
- CTO Board Slides
- Engineering Leader Guide to Goals and Reporting
- LinkedIn: Yishai Beeri
- Twitter: Yishai Beeri
Support the show:
- Subscribe to our Substack
- Leave us a review
- Subscribe on YouTube
- Follow us on Twitter or LinkedIn
Offers:
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Yishai Beeri (00:00):
We need to remember that less is more.
(00:02):
So don't come with 50 numbers.
It's not going to work for thebusiness discussion.
Focus on what really matters andalways show how that aligns with
the business.
So if you're talking aboutpredictability, yeah, this
project is landing on time or 90percent of it is landing on
time.
And here's why, and here's thechoices that I've made.
(00:23):
That was when you startovercoming those glazed eyes of
oh, some numbers on somethingthat I don't understand.
You're seeing success when youget, people are asking you to
drill down.
Right.
They're asking you smartquestions about the data that
you're showing.
Conor Bronsdon (00:37):
Gardener just released their market guide,
showing that softwareengineering intelligence
platforms, help engineeringleaders significantly improve
both team productivity and valuedelivery.
Through Gardner's in-depthanalysis on the critical
features of sci platforms andhow they can be used to drive
engineering excellence.
Linear B was named as arepresentative vendor.
And therefore we're giving awaya complimentary copy of
(00:59):
Gartner's sci market guide.
Head to the link in the shownotes to download your
complimentary copy and learn howyou can unlock the
transformative potential ofsoftware engineering
intelligence for your team.
Dan Lines (01:11):
Hey, what's up, everyone?
Welcome to another Labs episodeof Dev Interrupted.
I'm your host, Dan Lines,LinearB COO and co founder.
And in our Labs episodes, wedive deep into data.
And best practices that we find.
And today we're talkingengineering goals and reporting.
(01:35):
So what we're going to do, we'regoing to unpack the data and
strategies that eliteengineering organizations use to
set goals that drive predictablesoftware delivery, and also how
you can report on your progressto senior leadership.
Very, very important thing todo.
(01:55):
And I'm joined by a voice, whowill be, I think, very familiar
to many of our listeners, anexpert who has helped countless
organizations use goal settingto drive engineering
improvement, LinearB's own CTO,Yishai Berry.
Yishai, welcome to the pod.
(02:17):
Thanks Dan.
Great being here.
Awesome to have you on, brother.
We're going to dive right in.
Our first topic in general isaround goal setting in the dual
mandate.
I know our listeners are likelyaware of the meanings of some of
these acronyms that we're goingto use here.
(02:37):
There's a bunch of them, but Ithink they're crucial to the
topic we're about to discuss.
And so just to make sure we'realigned, I want to quickly
Quickly maybe recap some of thisterminology, so we'll probably
talk OKRs, so OKRs, Objectivesand Key Results, KPIs, Key
Performance Indicators.
(02:57):
These are like the most businessoriented acronyms ever.
Then we have SMART goals, S M AR T, which are Specific,
Measurable, Achievable,Relevant, Time bound goals.
So those might be some of thethings that You know, some of
the acronyms that we use.
Now, one of the key things we'venoticed in goal setting for
(03:18):
engineering teams is a shift inwhat goals need to look like.
So engineering leaders todayhave a dual mandate of both
expected to be elite inoperational excellence.
So when we think of operationalexcellence, I almost think of
this as like maybe whereengineering teams started.
It's to deliver the stuff inhigh quality.
(03:42):
Do your engineering thing.
We've been doing this, I don'tknow, 50 years now, 30 years
now, ever since I was doingengineering.
That's operational excellence.
Like, be really good atengineering stuff.
But the other side of it, and Ithink this is newer, I know it's
newer.
And I know the best engineeringleaders talk to me about it all
(04:02):
the time.
A lot of our customers are doingthis.
It's alignment with businesspriorities.
That's the second part of thedual mandate.
And I think the reason is mostorganization has recognized,
okay, our engineering team islike the lifeblood of the
company.
There's a product that goesalong with it.
We sell that product.
Maybe it's a SaaS product.
(04:24):
And if we're aligned on businessobjectives, we make more money.
I think that's where it's comingfrom.
And that's the other side of it.
So I'm going to, that's kind ofsetting the table.
So Yishai, how has that dualmandate impacted how R& D
leaders need to think about goalsetting?
Yishai Beeri (04:42):
Yeah.
So definitely a shift, like yousaid, if you, you, you go back,
um, you know, when I startedworking in engineering
management and leadership, therewas always the focus of, Are we
running a tight ship?
Are we getting the most out ofour developers and that spend?
Are we, um, effective in, um,translating the, you know, the
(05:07):
cost of having a dev team intonew features?
Velocity?
There's a very old word inengineering 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 strongengineering leaders always had
the notion of being aligned withwhat the business needs, but
(05:31):
it's more recent that this issurfacing as something that's
measurable and something thatneeds to be, you know, Tied to
how we set goals, how we measureour organization, ourselves, how
we report to our peers to, youknow, managing up.
That is a little more recent andthere's good ways to think
(05:51):
about, are we aligned with thebusiness?
Are we not just running a tightship?
In an effective operation, we'realso, um, tuned to what the
business needs, which meansit's, you know, this is about
delighting customers.
It's about understanding thethings that move the needle for
the business and for thebusiness to grow or to take the
(06:11):
next step in its journey.
Um, we know software is eatingthe world and every company now
is a software company.
I think a lot of that shift camefrom that.
It's no longer one of thedepartments which happens to,
you know, dabble with writingcode for some either internal or
even a product.
(06:31):
All the companies are becomingsoftware companies.
If you run an airline, you're asoftware company, right?
If you're selling hamburgers,you're a software company.
So, um, having the engineeringdepartment, you know, it's
rapidly becoming stronger.
More of the spend is goingthere.
(06:51):
Decisions which used to liveoutside, like in IT, or even in
other business processes, havebecome engineering, because
engineering, uh, everything issoftware.
So now even business processes,in many cases, are run by
engineering.
All that burden now means thatwe have to really focus on, are
we building and investing ourtime and energy in the right
(07:15):
places?
Which is the business alignmentpart.
Dan Lines (07:18):
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 dualmandate, honestly, has kinda
been there forever in a sense.
Right now, and for the foreverfuture, it's like mandatory.
Because of all the reasons thatyou said, every, every company
is a software company, even ifyou sell hamburgers, you're a
(07:41):
software company.
Yeah.
But if I think back to when Ifirst started, even in
development, very, very longtime ago, the best leaders,
people would say, Oh yeah, Ilove that person.
Oh yeah.
Why do you love that person?
Well, that person can talk aboutwhen is the project going to be
delivered?
(08:01):
They can talk to the CEO aboutwhat the CEO's needs are.
What are the most importantthings that they were almost
like amazing translator.
They had all of the engineeringpractices of efficiency,
quality, you know, low changefailure rate.
And they had this other abilityto say, okay, I know exactly
what the business needs and Ican talk to all of the go to
(08:23):
market team about how my teamengineering is going to hit
those goals.
Like those were the bestleaders.
Now I think it's just likemandatory to be like that.
Would you agree?
Like the people you think aboutwho are like, great.
Yishai Beeri (08:36):
I think it's, it's both becoming mandatory or a
sign of, yeah, this is a strongleader for engineering.
Um, it's also becoming much moreexplicit.
It's not just a soft thing thatyou need to have.
There's, you need to be talkingabout very specific, um, items
and, you know, interact with therest of the business in specific
(08:58):
ways.
Yeah.
Because if you're not going tobe predictable and empower the
go to market side of the houseThen there's a built in delay
between when features andcapabilities are ready and when
the field can actually sellthem, for example, uh, or
support them.
So it's becoming much morestructured, I think.
Dan Lines (09:18):
Yeah, you're right.
I mean, and that I think leadsus to the data and the goals.
So now that it is.
Mandatory, and it needs to beexplicit.
How can engineering leaders setgoals that help them achieve
both sides of this
Yishai Beeri (09:38):
you know, we're now taking this to a more
tangible step of, okay, I needto set goals.
Like in every business unit, I'mnot going to measure everything
or goal around everything.
It's too much.
You need to apply some focus.
Um, realizing and understandingthat the dual mandate means
that, okay, I need to thinkabout at least the two sides.
(09:59):
I need goals around myoperational excellence, about
our productivity.
Um, but I also have to have somegoals around the business
alignment.
So, the first, like, um, youknow, actionable step is make
sure you have a goal on each ofeach side of that dual mandate.
(10:20):
A goal on the business alignmentpart can be around your
predictability.
Am I being, like, able todeliver on promises or be
predictable about delivery in aconsistent way?
It could be about, um, are wespending enough on Um, on
building new value, are we ableto focus enough of our efforts
(10:44):
in building and creating newvalue and not just chasing, uh,
putting out fires, uh, just, youknow, keeping the lights on?
Do we have enough of our spin oninnovation?
Or it could be about the keyprojects, the key initiatives
that the business really caresabout and making sure that we
are investing enough in these.
(11:04):
Not just in our plans, but alsoin actuals.
If I needed 20 people on thatproject, am I actually getting
20 people on that project?
These are the kinds of goals wecan take for the business
alignment side.
And then on operationalexcellence, there's, things like
cycle time, like understandingour, um, developer experience,
(11:25):
our quality.
There's a bunch of goals andmetrics depending on where you
are in where what's reallyimportant for you as an
organization I think thesethings are a little easier to
measure because they've beenaround longer.
There's a little more And evenon intuition, engineering
leaders tend to gravitate tothose areas.
(11:45):
So, have one on each is a goodstarting point.
Yeah,
Dan Lines (11:50):
I think what we want to do, of course, what I want to
do on this pod, we have a lot ofpods in Dev Interrupted that are
about the DORA metrics, cycletime, change failure rate,
deployment frequency, MTTR, thenyou have all your leading
indicators, PR size, reworkrate, I'm going to put it aside
(12:10):
for a second.
Let's talk about where theindustry is going.
And you said the one that caughtmy ear the most was
predictability.
When I talk to engineeringleaders and what I know from my
past career, the question that'salways asked on the engineering
leader is like, when is thething going to be done?
Delivered to me.
(12:32):
When do I get my value?
When do I get to close a bigdeal because you have this new
feature that came out?
When do I get to retain acustomer?
So if you don't mind, let'sfocus in on predictability.
And one of the, you know, KPIsthat we talk about at LinearB
would be the planning accuracy.
(12:52):
It sounds cool, and I think it'sa great KPI.
Maybe you can start there, butwhat are the other things that
come to mind for you when youthink, Delivering projects on
time, predictability.
Yishai Beeri (13:04):
Yeah.
So I'll start by saying, youtalk with engineering leaders
and with, with business leaders,the CEOs and you know, the peers
around the table, like themarketing leaders, the sales
leaders, and As you look, as youlook into more larger companies,
larger businesses, uh, forwardthinkers, they are starting to
(13:28):
trade volume or velocity forpredictability.
Right?
I can take a little lessproduction, but at a better
predictability.
Right?
Why?
Because software is, you know,going agile.
It's all about trying to movefast, even break things.
Tight learning cycles, but thenthere's the whole surrounding
(13:50):
part of the business that needsthat predictability.
You're not going to be able topull up a marketing campaign and
Uh, in a day, just because theyrelease the agile software team
just delivered, right?
You have to prepare.
You have to line up things.
Um, not everything in the worldcan be as agile as software
delivery.
So predictability becomes moreand more important.
(14:10):
As you grow as a business, asyou 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 measureand goal around predictability
becomes really important.
So, planning accuracy, you know,that's a good place to start.
(14:33):
This is about understanding howwe deliver sprint over sprint.
Is our planning and delivery,are they aligned?
Are we able to deliver what wepromise?
First to ourselves, then to oursurroundings, 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 aproject, which is like multi
(14:55):
sprint, maybe a quarter, uh, abigger chunk of work.
And then you have, when you lookat, you know, you zoom out, you
look at a project.
Now you have, um, you can talkabout, How much of the project
scope did I hit?
Did I, is it getting, getting inon time?
And it's not just about goalingand reporting.
(15:15):
You can also make some decisionsbefore the project ends to
optimize what you're landingwith.
You're not always going todeliver 100 percent of
everything.
We know that.
There is a time when you look atthe data and you say, okay, I
need to change something.
Maybe give up on these scopes,some items.
Focus my energy on the ones thatare almost there.
(15:36):
So, understanding the, the burnup, if you like, for a project,
or for your whole, your wholedelivery in a quarter or similar
planning cycle.
Making adjustments, but alsotracking quarter over quarter,
are we delivering enough of whatwe promised, enough of what we
planned, in good quality.
(15:56):
That would be a great goal to,to track and improve.
Dan Lines (15:59):
I mean, you talked about kind of the maturity I
would call it, of the spacemaybe moving from I always have
like the CEO in mind'cause Ihave this like CEO archetype of
like, just give me all thestuff.
Like do it fast.
Yesterday, there's, yeah,yesterday, I needed it
yesterday.
A little more maturity of like,okay.
I value predictability because Iunderstand my marketing team can
(16:23):
be in sync.
My enablement team for sales canbe in sync.
My enablement team for CS.
The way that we go out with thisproduct matters to me or this
feature matters to me.
Maybe you have like a Gartnerinterview coming, coming up.
The predictability matters a lotfor the whole business to be in
sync.
And we, we have this in, in ourLinearB product.
(16:45):
It's like, I remember the CEOused to ask me, okay, is the
project going to deliver ontime?
And I would say, yeah, becauseit's like, what else can you
say?
And then it's like, uh, like,why would you want to say no?
Then it's like, you have noconfidence.
Like, yeah, it's going todeliver on time, but then it's
like, yeah, but you said thatlast time with the last project
(17:07):
and it was like three monthslate.
And it's like, oh yeah.
Sorry about that.
That's like a very likequalitative conversation.
Now, here's the newconversation.
You pull up, you know, ourfeature is called forecasting,
but you pull up your for yourproject forecasting mod module
and you say, Yeah, I do think itwill be delivered on time.
(17:29):
There's some risk.
I want to talk to you about it.
Yeah.
Click into the project.
Yeah.
It
Yishai Beeri (17:36):
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 tomake decisions now.
Dan Lines (17:49):
I think it's like, yes, but, and let me show you,
let me bring you in.
You know what?
The planning accuracy for thisproject looks good.
Let's say it means that theteams are able to deliver on
what they say they're going todeliver.
I'm, I'm, I'm doing kind of aconversation.
Let's pretend you're my boss orthe CTO.
I'm an engineering leader.
The planning accuracy looks goodhere.
(18:11):
So that's a good thing.
It's giving me confidence.
But there's something that isconcerning me on this project.
And I want to show yousomething.
It's our cycle time on thisproject.
I'm seeing bottlenecks here andI'm seeing some bottlenecks
because it looks like only oneperson is doing all of our
reviews.
We have a, it's a senior and wehave a lot of juniors on this
(18:31):
project.
Now I know that this project'sdue in six months from now, but
I want to call out this peoplerisk to you.
It's a very mature conversation.
I'd like to add another seniorto this.
And the reason I want to add asenior is to increase my
probability to deliver on time.
And even better now, I know thisis like futuristic stuff, but
this is what we're working onwith some of our customers.
(18:54):
Let me show you a Monte Carlosimulation that if we were to do
this, why I think it will helpus deliver on time.
Now I'm talking with data.
I'm talking with risk levels.
I'm talking with Simulation tothe business of like, let me
bring you in of what it reallytakes to forecast.
I think that's really cool andkind of like next level mature
(19:16):
conversation.
What do you think about that?
Yishai Beeri (19:19):
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 canmove the conversation to let's,
let's make some decisions.
It's probably not just magicallycreate a new resource, but let's
move someone from a project thatis doing well and maybe has some
(19:42):
capacity, uh, that, that theycan contribute here because I
have a bottleneck here.
The data is showing me the kindof risk that I can alleviate
with moving a resource and maybenot lose so much on the other
project because the signalsthere are different.
What?
When the conversation moves tomaking choices and you see the
(20:05):
choice you see the you know theoutcomes it becomes a much Much
stronger conversation.
Dan Lines (20:12):
Okay, so let's do a little summary on the
predictability side, we havesome KPIs, right?
We have planning accuracy.
That's a good one.
We have capacity accuracy.
That's a good one.
We have project forecasting withsimulations.
That's a good one.
And now imagine having that forall of your projects.
(20:33):
You see them all in one view.
That's awesome.
Now there's kind of this likewhat you're saying.
I have to make decisions ofwhat, what to do.
Can you talk to us a little bitabout goals around resource
allocation?
Cause sometimes a lot of thosedecisions might be, ah, I don't
know.
We just were understaffed onthis project.
(20:53):
Is it really the top project?
I could move this one faster ifwe could delay this other one,
but I got to shift some people.
Talk to me about resourceallocation, investment profile,
goals around that kind of stuff.
Yishai Beeri (21:04):
So both resource allocation and investment
profile are ways to look at theactual spin.
Where is my energy going?
Where are my people deployed?
Not just in, in, on paper, onplan, but what is actually
happening?
And I think a very common, um,cycle, and we've seen, we've all
seen this, where Management sitsat the beginning of the quarter,
(21:28):
lays out a plan, allocatesresources.
Yeah, let's take 20 people forthis project.
Let's put this team on thatproject.
This is important for us.
It's a new product or a newfeature.
Let's, um, um, concentrate somework and resources there.
Great.
The plan looks good.
Then reality hits, right?
(21:50):
So this 20 people project, yeah,on paper there's, they're all
there.
But three you haven't even hiredyet, two are busy, uh, with an
old project that they weren'table to ramp down quickly
enough.
Um, another one is pulled to putout fires elsewhere.
Reality is different.
And then the quarter ends andwhy have we missed?
(22:10):
You spend time to realize thatactually we didn't have the 20
people.
So research allocation is a wayto look at what is the actual
spend across projects orinitiatives or any kind of like
slicing the pieces of work inyour, um, dev work and course
correcting.
Yeah, this is what is actuallyhappening.
(22:30):
This is what we wanted.
We can now course correct.
We can help people ramp up morequickly or ramp down more
quickly if a project needs that.
Or we realize that we have agap.
Now we can make a choice.
Okay.
Reality is a bit different.
Let's make a choice about whatto, um, you know, what to give
(22:51):
up on, what to invest more inand so on.
Totally
Dan Lines (22:54):
makes sense.
And now we can have kind of thateducated conversation with the
business.
Okay, so now that we talkedabout kind of both sides of the
dual mandate, some of the KPIsthat you can use for engineering
efficiency, we have our DORAmetrics, we have some leading
indicators, we talked a lot onthe business.
(23:15):
Alignment side, predictability,very, very important.
I want to ask you, in terms ofactually setting goals against
these KPIs, where in the orgstructure should I start?
Is it like a top down thing, abottom up thing?
What are your, what are yourthoughts on that?
Yishai Beeri (23:33):
That's a good one.
I think, uh, there's probablynot one answer.
first of all, there's the orgculture that you have to take
into account.
Um, in some, um, respects, and Ithink mostly on the engineering,
uh, like operational efficiency,there's a lot of sense in doing
this bottoms up and letting theteams decide on which goals to
(23:55):
take and what, like, how to tunethe goals.
Because, uh, in many modern, um,you know, development
organizations, you want to giveautonomy and you have the right
people that you can giveautonomy.
The team knows how it'sdelivering.
They have, maybe even betweenthe teams, there's a difference
in how they're working.
(24:15):
Some could be using scrum, somecould be using Kanban, some
could be using a combination.
Some are building.
You know, SaaS front end, someare doing mobile apps.
So very different ways tomeasure and to benchmark.
So giving autonomy and thebottoms up approach makes a lot
of sense.
And also very strong culture,positive of, you know, it's not
(24:39):
like a big brother watching overyour back and measuring you.
It's more like This is a way foryou to measure yourselves and
report up.
Um, and it still makes sense inthese cases to have a top down
focus.
Yeah, we know as a company, as adev work, we have, we want to
focus on being more efficient.
(24:59):
Let's make sure we look at cycletime top down because it's a
good efficiency and bottleneckdiscovery kind of metric.
Um, if we have a quality issueor a quality, initiative going
on in the company.
We can make that a top down andbake that together with with
bottoms up.
Yeah.
On the business alignment side,I think it's typically running
(25:22):
top down with, you know, orglevel or VP level and then
departments or groups.
Aligning either to the productlines or the way the org is
built.
Um, you want predictability tobe measured across your teams or
groups and then aggregate it up.
That makes a lot of sense comingtop down.
Dan Lines (25:43):
it's kind of like a mix.
One thing that I've seen,especially with the larger
organizations, Let's say youhave a hundred developers plus
5, 2 50 developers, 500developers, and then I don't
know, we, I'm working withcompanies that have 6,000
developers.
I think that there does need tobe something top down around
(26:03):
standardization, I'll call it.
Now, of course you want bottomup adoption, but when I think of
standardization, it's kind oflike, here is how we're going to
measure cycle time.
This is our standard practice ofwhen cycle time starts versus
when cycle time ends, and that'sthe standard for our business.
(26:23):
Here is how we're going tomeasure sprint planning
accuracy.
This is, you know, how we startit either when one day into the
sprint or right when the sprintSo, what I've seen is when you
bring these top down standardsIt kind of says, when do things
start and stop?
And what do the, what are theKPIs that we care about?
(26:44):
Now, after that, we care.
Yeah, we care.
Now you have the standards.
We do care.
I think it's more go deploy thiswith your teams and set your
goals around this.
Here's our high level goals.
You go make it happen.
That's where I've seen it worksreally well.
You have top down standards.
(27:05):
You say the KPIs that thecompany or the business unit
cares about, and you give somehigh level guidance on the
goals.
Now you go make it happen foryour team.
That's, that's kind of what I'veseen work really well.
Yishai Beeri (27:19):
And I think that lets the, the, the teams or the,
you know, lower parts of the orgfocus a little on the leading
indicators.
Sometimes on more technical, um,ways to look at the problem.
So you could, you're thinkingabout cycle time as a top down,
but then for a team to improvetheir cycle time, they could be
looking at smaller PRs.
(27:40):
They could be looking at howlong does it take me to pick up
a PR for reviews, a pickup time.
There are the ways to implementthat goal are a little more
detailed.
And another team may look atdifferent, uh, they have
different bottlenecks.
So they'll, they're going totake a goal around a better
review process.
Or can I automate away some ofmy reviews?
Dan Lines (28:02):
Absolutely.
Now, what I want to do in thelast few minutes of this pod, is
talk a little bit more about thebusiness stakeholders and what
it takes for a VP ofengineering, a CTO, a director
of a business unit.
(28:24):
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, youknow, these KPIs.
But what can you tell us, maybean overview or some tips and
tricks?
I'm an engineering leader.
I'm measuring this kind ofstuff.
(28:44):
How do I approach businessstakeholders?
I've never done it before.
What do I, what do I do?
Yishai Beeri (28:49):
Yeah.
So, um, first, you know, a lotof us hit that wall where, uh,
it feels like no one cares atthe beginning.
You know, everyone is about thesales numbers and the marketing
numbers.
They're used to seeing numbersand data in measurements for
those departments, and they'reused to having engineering say I
think this feature is gonna landin two months.
(29:11):
That's, so there is someeducation, Oh, there's actually
good data to look at.
There's actually a way to drillin.
Um, so come prepared to, to Notjust show the data and the
goals, but also explain why itmatters.
Why cycle time matters so much,because it lets me, um, you
know, learn much faster fromthe, the feedback that I'm
(29:33):
getting from our customers whenour new, uh, the new code hits
the, um, the users.
Um, by reducing thesebottlenecks, I can get so much
more done and improve thequality.
So, be, like, be prepared toexplain why it matters.
I think as engineer leaders, andmany of us are engineers at
(29:53):
heart, uh, we need to rememberthat less is more.
So don't come with, you know, 50numbers.
It's not going to work for, forthe business, uh, discussion,
um, focus on what really mattersand always show how that aligns
with, with the business.
So if you're talking aboutpredictability, yeah, this
project is landing on time or 90percent of it is landing on
(30:17):
time.
And here's why, and here's thechoices that I've made.
Um, I think that, that was whenyou 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'reseeing success when you get,
people are asking you to drilldown.
(30:38):
Right.
They're asking you smartquestions about the data that
you're showing.
Dan Lines (30:42):
Yeah, that, that's, that totally makes sense.
Especially when you startgetting some of that engagement
and questions.
I think my best tip here, whatI've seen work really well, if
you go to your businessstakeholders and say, I'm
putting a new thing on yourcalendar.
So first of all, it's repetitiveand it's going to be repetitive
(31:05):
and it's going to be called ourforecasting meeting, our project
forecasting meeting, and it'smonthly, all you got to do is
show up.
Now, one thing that's cool aboutthat.
You may already have this.
You know, ceremony of aforecasting meeting, you may
not.
So you're going to get some, ifyou don't, some kudos points,
because those stakeholders aregoing to say, I definitely want
(31:25):
to come to a project'sforecasting meeting because
that's what I care about.
Now's your opportunity.
You got them in that meeting tostart hitting them with, is the
project going to deliver ontime?
Let me show you some of theunderlying engineering metrics
of cycle time or change failurerate.
You have the planning accuracy,and maybe you start getting some
(31:45):
questions about that.
And usually what I see is if yourelate it back to what they care
about, which is these businessdeliverables, that is when
you'll get, Oh, now I careabout, Oh, cycle time has
something to do with me gettingwhat I want.
Let me ask a question about it.
Yeah.
So that would be my tip, mybiggest tip.
Have you seen that kind of stuffwork or any comments on that?
Yishai Beeri (32:09):
Yeah.
I think you talk about cycletime in, in, um, you know, in
isolation.
No one cares.
Dan Lines (32:16):
Yeah.
Yishai Beeri (32:17):
You talk about cycle time affecting delivery of
this project, which is What Ineed to sell more as a sales
leader.
Now I can start relating andyou'll be surprised by the kind
of smart questions you get fromyour business peers about the
data and about what it means.
Just like you can ask about thesales cycle and how is the sales
(32:39):
cycle different in differentsegments, right?
It's natural for us to drill inwhen we see the connection.
Dan Lines (32:45):
Yeah, it's so funny.
It's like, uh, Hey, I want to goask 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 aquestion that says, Oh, we're
talking about the delivery ofthis project.
I'm showing you why we'reprobably not going to deliver.
(33:06):
It's because we have a poorcycle time due to a reviewer
bottleneck and you can get yourbusiness stakeholders to say,
Oh, Well, what if we had anotherreviewer?
Oh, great.
Perfect.
Yes.
Cause I would love to addanother reviewer.
Actually, I need a senior one.
I have a job description.
Should we deploy that to deliverthis project on time?
(33:26):
That's cool.
Yishai Beeri (33:28):
Or, or even I can show you through the metrics
that this project is veryefficient.
It's already running veryefficiently.
There's LinearB publishesindustry benchmarks across all
of our metrics.
We are.
actually doing very good in thisproject, which means if you give
me more resources, there's like,they can be very effective here.
(33:50):
Another person in this projectcan really kill it because I've
already removed a lot of thebottlenecks.
Dan Lines (33:54):
Yes,
Yishai Beeri (33:54):
it's now running very effectively.
A new resource is going to bevery effective here.
Dan Lines (33:59):
Let me prove to you that it will work.
So we're coming to the end here.
Could you tell us a little, sowe have a CTO board report that
can be used.
Talk to me about this CTO boardreport.
Yishai Beeri (34:13):
Yeah, so this is a template that, you know, you can
use as a, as a starting point toput some, pull some data from
LinearB or however you measureyour, uh, your key goals, your
KPIs.
And, you know, in basically twoor three slides, convey the key
information to, you know, theboard or the staff meeting and
(34:35):
similar.
Uh, Senior Leadership.
And we're basically splitting itinto two parts.
One is a heartbeat of the healthof the engineer organization.
The key, key, um, metrics, thetop downs.
This could be cycle time andsomething, you know, merge
frequency for developerexperience.
Two or three metrics with atrend, with an industry
(34:58):
benchmark.
Um, um, Context, so you anchorthe numbers.
It's not just three on the, onthe, on the screen.
It's a three, which means we'rein the, I don't know, strong
band of the benchmarks.
So, let's have everyoneunderstand what it means.
And, we, we, we, uh, suggestthat you take a goal.
You're saying, in Q1, my cycletime was three days.
(35:21):
My goal for the next quarter isto like lower it down to two and
a half days.
By having this simple cycle ofthere's a number, there's a
context and a trend and I'mtaking a goal.
You are now really helping yourpeers and your, your managers
trust you that you've, you'vegot this.
I know what I'm doing.
I can see where I'm going.
(35:42):
I have a plan, but I don't thinkthey 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 isthere.
And then the second part is.
These are the key investments,the key projects.
We talked about resourceallocation, so show some data.
There's always going to be thetop three, four, five, maybe
(36:03):
seven projects or initiativeswhich are what everyone thinks
about.
They are the key, uh,investments.
Show the investment, show thatit'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.
(36:24):
You show the engineer metricsfor that project, it's actually
performing well, or this iswhere I'm focusing.
I'm focusing on improving mybottlenecks for this project
before I'm asking for moreresources.
So, my resource spend aligned onprojects and my engineering
health.
The two slides is all you needto really convey the message.
(36:45):
On how are we doing and startmaking decisions, right?
This is about staffing, aboutresourcing, about changes.
Now you can drive a reallyvaluable conversation.
Dan Lines (36:56):
Yishai, thank you so much.
That is a super cool report.
It's a free report.
Thank you for coming on.
Talking to us about the dualmandate and goal setting and
even more so what you said atthe end.
It's really a career builder.
Trust with your peers, settinggoals, visibility and
(37:20):
transparency.
We love having you on the pod.
Thank you so much for joining.
Yishai Beeri (37:25):
Thanks Dan, as always.
This was great.
Dan Lines (37:27):
And you know, to everyone, thanks for tuning in.
If you want to dive deeper intogoal setting, download our free
Engineering Leader's Guide toGoals in Reporting at LinearB.
io slash resources.
Um, we'll also include that, uh,in a link in the description.
(37:49):
And everyone have a great week.
Talk again soon.
We need to remember that less is more.
(00:02):
So don't come with 50 numbers.
It's not going to work for thebusiness discussion.
Focus on what really matters andalways show how that aligns with
the business.
So if you're talking aboutpredictability, yeah, this
project is landing on time or 90percent of it is landing on
time.
And here's why, and here's thechoices that I've made.
(00:23):
That was when you startovercoming those glazed eyes of
oh, some numbers on somethingthat I don't understand.
You're seeing success when youget, people are asking you to
drill down.
Right.
They're asking you smartquestions about the data that
you're showing.
Conor Bronsdon (00:37):
Gardener just released their market guide,
showing that softwareengineering intelligence
platforms, help engineeringleaders significantly improve
both team productivity and valuedelivery.
Through Gardner's in-depthanalysis on the critical
features of sci platforms andhow they can be used to drive
engineering excellence.
Linear B was named as arepresentative vendor.
And therefore we're giving awaya complimentary copy of
(00:59):
Gartner's sci market guide.
Head to the link in the shownotes to download your
complimentary copy and learn howyou can unlock the
transformative potential ofsoftware engineering
intelligence for your team.
Dan Lines (01:11):
Hey, what's up, everyone?
Welcome to another Labs episodeof Dev Interrupted.
I'm your host, Dan Lines,LinearB COO and co founder.
And in our Labs episodes, wedive deep into data.
And best practices that we find.
And today we're talkingengineering goals and reporting.
(01:35):
So what we're going to do, we'regoing to unpack the data and
strategies that eliteengineering organizations use to
set goals that drive predictablesoftware delivery, and also how
you can report on your progressto senior leadership.
Very, very important thing todo.
(01:55):
And I'm joined by a voice, whowill be, I think, very familiar
to many of our listeners, anexpert who has helped countless
organizations use goal settingto drive engineering
improvement, LinearB's own CTO,Yishai Berry.
Yishai, welcome to the pod.
(02:17):
Thanks Dan.
Great being here.
Awesome to have you on, brother.
We're going to dive right in.
Our first topic in general isaround goal setting in the dual
mandate.
I know our listeners are likelyaware of the meanings of some of
these acronyms that we're goingto use here.
(02:37):
There's a bunch of them, but Ithink they're crucial to the
topic we're about to discuss.
And so just to make sure we'realigned, I want to quickly
Quickly maybe recap some of thisterminology, so we'll probably
talk OKRs, so OKRs, Objectivesand Key Results, KPIs, Key
Performance Indicators.
(02:57):
These are like the most businessoriented acronyms ever.
Then we have SMART goals, S M AR T, which are Specific,
Measurable, Achievable,Relevant, Time bound goals.
So those might be some of thethings that You know, some of
the acronyms that we use.
Now, one of the key things we'venoticed in goal setting for
(03:18):
engineering teams is a shift inwhat goals need to look like.
So engineering leaders todayhave a dual mandate of both
expected to be elite inoperational excellence.
So when we think of operationalexcellence, I almost think of
this as like maybe whereengineering teams started.
It's to deliver the stuff inhigh quality.
(03:42):
Do your engineering thing.
We've been doing this, I don'tknow, 50 years now, 30 years
now, ever since I was doingengineering.
That's operational excellence.
Like, be really good atengineering stuff.
But the other side of it, and Ithink this is newer, I know it's
newer.
And I know the best engineeringleaders talk to me about it all
(04:02):
the time.
A lot of our customers are doingthis.
It's alignment with businesspriorities.
That's the second part of thedual mandate.
And I think the reason is mostorganization has recognized,
okay, our engineering team islike the lifeblood of the
company.
There's a product that goesalong with it.
We sell that product.
Maybe it's a SaaS product.
(04:24):
And if we're aligned on businessobjectives, we make more money.
I think that's where it's comingfrom.
And that's the other side of it.
So I'm going to, that's kind ofsetting the table.
So Yishai, how has that dualmandate impacted how R& D
leaders need to think about goalsetting?
Yishai Beeri (04:42):
Yeah.
So definitely a shift, like yousaid, if you, you, you go back,
um, you know, when I startedworking in engineering
management and leadership, therewas always the focus of, Are we
running a tight ship?
Are we getting the most out ofour developers and that spend?
Are we, um, effective in, um,translating the, you know, the
(05:07):
cost of having a dev team intonew features?
Velocity?
There's a very old word inengineering 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 strongengineering leaders always had
the notion of being aligned withwhat the business needs, but
(05:31):
it's more recent that this issurfacing as something that's
measurable and something thatneeds to be, you know, Tied to
how we set goals, how we measureour organization, ourselves, how
we report to our peers to, youknow, managing up.
That is a little more recent andthere's good ways to think
(05:51):
about, are we aligned with thebusiness?
Are we not just running a tightship?
In an effective operation, we'realso, um, tuned to what the
business needs, which meansit's, you know, this is about
delighting customers.
It's about understanding thethings that move the needle for
the business and for thebusiness to grow or to take the
(06:11):
next step in its journey.
Um, we know software is eatingthe world and every company now
is a software company.
I think a lot of that shift camefrom that.
It's no longer one of thedepartments which happens to,
you know, dabble with writingcode for some either internal or
even a product.
(06:31):
All the companies are becomingsoftware companies.
If you run an airline, you're asoftware company, right?
If you're selling hamburgers,you're a software company.
So, um, having the engineeringdepartment, you know, it's
rapidly becoming stronger.
More of the spend is goingthere.
(06:51):
Decisions which used to liveoutside, like in IT, or even in
other business processes, havebecome engineering, because
engineering, uh, everything issoftware.
So now even business processes,in many cases, are run by
engineering.
All that burden now means thatwe have to really focus on, are
we building and investing ourtime and energy in the right
(07:15):
places?
Which is the business alignmentpart.
Dan Lines (07:18):
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 dualmandate, honestly, has kinda
been there forever in a sense.
Right now, and for the foreverfuture, it's like mandatory.
Because of all the reasons thatyou said, every, every company
is a software company, even ifyou sell hamburgers, you're a
(07:41):
software company.
Yeah.
But if I think back to when Ifirst started, even in
development, very, very longtime ago, the best leaders,
people would say, Oh yeah, Ilove that person.
Oh yeah.
Why do you love that person?
Well, that person can talk aboutwhen is the project going to be
delivered?
(08:01):
They can talk to the CEO aboutwhat the CEO's needs are.
What are the most importantthings that they were almost
like amazing translator.
They had all of the engineeringpractices of efficiency,
quality, you know, low changefailure rate.
And they had this other abilityto say, okay, I know exactly
what the business needs and Ican talk to all of the go to
(08:23):
market team about how my teamengineering is going to hit
those goals.
Like those were the bestleaders.
Now I think it's just likemandatory to be like that.
Would you agree?
Like the people you think aboutwho are like, great.
Yishai Beeri (08:36):
I think it's, it's both becoming mandatory or a
sign of, yeah, this is a strongleader for engineering.
Um, it's also becoming much moreexplicit.
It's not just a soft thing thatyou need to have.
There's, you need to be talkingabout very specific, um, items
and, you know, interact with therest of the business in specific
(08:58):
ways.
Yeah.
Because if you're not going tobe predictable and empower the
go to market side of the houseThen there's a built in delay
between when features andcapabilities are ready and when
the field can actually sellthem, for example, uh, or
support them.
So it's becoming much morestructured, I think.
Dan Lines (09:18):
Yeah, you're right.
I mean, and that I think leadsus to the data and the goals.
So now that it is.
Mandatory, and it needs to beexplicit.
How can engineering leaders setgoals that help them achieve
both sides of this
Yishai Beeri (09:38):
you know, we're now taking this to a more
tangible step of, okay, I needto set goals.
Like in every business unit, I'mnot going to measure everything
or goal around everything.
It's too much.
You need to apply some focus.
Um, realizing and understandingthat the dual mandate means
that, okay, I need to thinkabout at least the two sides.
(09:59):
I need goals around myoperational excellence, about
our productivity.
Um, but I also have to have somegoals around the business
alignment.
So, the first, like, um, youknow, actionable step is make
sure you have a goal on each ofeach side of that dual mandate.
(10:20):
A goal on the business alignmentpart can be around your
predictability.
Am I being, like, able todeliver on promises or be
predictable about delivery in aconsistent way?
It could be about, um, are wespending enough on Um, on
building new value, are we ableto focus enough of our efforts
(10:44):
in building and creating newvalue and not just chasing, uh,
putting out fires, uh, just, youknow, keeping the lights on?
Do we have enough of our spin oninnovation?
Or it could be about the keyprojects, the key initiatives
that the business really caresabout and making sure that we
are investing enough in these.
(11:04):
Not just in our plans, but alsoin actuals.
If I needed 20 people on thatproject, am I actually getting
20 people on that project?
These are the kinds of goals wecan take for the business
alignment side.
And then on operationalexcellence, there's, things like
cycle time, like understandingour, um, developer experience,
(11:25):
our quality.
There's a bunch of goals andmetrics depending on where you
are in where what's reallyimportant for you as an
organization I think thesethings are a little easier to
measure because they've beenaround longer.
There's a little more And evenon intuition, engineering
leaders tend to gravitate tothose areas.
(11:45):
So, have one on each is a goodstarting point.
Yeah,
Dan Lines (11:50):
I think what we want to do, of course, what I want to
do on this pod, we have a lot ofpods in Dev Interrupted that are
about the DORA metrics, cycletime, change failure rate,
deployment frequency, MTTR, thenyou have all your leading
indicators, PR size, reworkrate, I'm going to put it aside
(12:10):
for a second.
Let's talk about where theindustry is going.
And you said the one that caughtmy ear the most was
predictability.
When I talk to engineeringleaders and what I know from my
past career, the question that'salways asked on the engineering
leader is like, when is thething going to be done?
Delivered to me.
(12:32):
When do I get my value?
When do I get to close a bigdeal because you have this new
feature that came out?
When do I get to retain acustomer?
So if you don't mind, let'sfocus in on predictability.
And one of the, you know, KPIsthat we talk about at LinearB
would be the planning accuracy.
(12:52):
It sounds cool, and I think it'sa great KPI.
Maybe you can start there, butwhat are the other things that
come to mind for you when youthink, Delivering projects on
time, predictability.
Yishai Beeri (13:04):
Yeah.
So I'll start by saying, youtalk with engineering leaders
and with, with business leaders,the CEOs and you know, the peers
around the table, like themarketing leaders, the sales
leaders, and As you look, as youlook into more larger companies,
larger businesses, uh, forwardthinkers, they are starting to
(13:28):
trade volume or velocity forpredictability.
Right?
I can take a little lessproduction, but at a better
predictability.
Right?
Why?
Because software is, you know,going agile.
It's all about trying to movefast, even break things.
Tight learning cycles, but thenthere's the whole surrounding
(13:50):
part of the business that needsthat predictability.
You're not going to be able topull up a marketing campaign and
Uh, in a day, just because theyrelease the agile software team
just delivered, right?
You have to prepare.
You have to line up things.
Um, not everything in the worldcan be as agile as software
delivery.
So predictability becomes moreand more important.
(14:10):
As you grow as a business, asyou 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 measureand goal around predictability
becomes really important.
So, planning accuracy, you know,that's a good place to start.
(14:33):
This is about understanding howwe deliver sprint over sprint.
Is our planning and delivery,are they aligned?
Are we able to deliver what wepromise?
First to ourselves, then to oursurroundings, 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 aproject, which is like multi
(14:55):
sprint, maybe a quarter, uh, abigger chunk of work.
And then you have, when you lookat, you know, you zoom out, you
look at a project.
Now you have, um, you can talkabout, How much of the project
scope did I hit?
Did I, is it getting, getting inon time?
And it's not just about goalingand reporting.
(15:15):
You can also make some decisionsbefore the project ends to
optimize what you're landingwith.
You're not always going todeliver 100 percent of
everything.
We know that.
There is a time when you look atthe data and you say, okay, I
need to change something.
Maybe give up on these scopes,some items.
Focus my energy on the ones thatare almost there.
(15:36):
So, understanding the, the burnup, if you like, for a project,
or for your whole, your wholedelivery in a quarter or similar
planning cycle.
Making adjustments, but alsotracking quarter over quarter,
are we delivering enough of whatwe promised, enough of what we
planned, in good quality.
(15:56):
That would be a great goal to,to track and improve.
Dan Lines (15:59):
I mean, you talked about kind of the maturity I
would call it, of the spacemaybe moving from I always have
like the CEO in mind'cause Ihave this like CEO archetype of
like, just give me all thestuff.
Like do it fast.
Yesterday, there's, yeah,yesterday, I needed it
yesterday.
A little more maturity of like,okay.
I value predictability because Iunderstand my marketing team can
(16:23):
be in sync.
My enablement team for sales canbe in sync.
My enablement team for CS.
The way that we go out with thisproduct matters to me or this
feature matters to me.
Maybe you have like a Gartnerinterview coming, coming up.
The predictability matters a lotfor the whole business to be in
sync.
And we, we have this in, in ourLinearB product.
(16:45):
It's like, I remember the CEOused to ask me, okay, is the
project going to deliver ontime?
And I would say, yeah, becauseit's like, what else can you
say?
And then it's like, uh, like,why would you want to say no?
Then it's like, you have noconfidence.
Like, yeah, it's going todeliver on time, but then it's
like, yeah, but you said thatlast time with the last project
(17:07):
and it was like three monthslate.
And it's like, oh yeah.
Sorry about that.
That's like a very likequalitative conversation.
Now, here's the newconversation.
You pull up, you know, ourfeature is called forecasting,
but you pull up your for yourproject forecasting mod module
and you say, Yeah, I do think itwill be delivered on time.
(17:29):
There's some risk.
I want to talk to you about it.
Yeah.
Click into the project.
Yeah.
It
Yishai Beeri (17:36):
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 tomake decisions now.
Dan Lines (17:49):
I think it's like, yes, but, and let me show you,
let me bring you in.
You know what?
The planning accuracy for thisproject looks good.
Let's say it means that theteams are able to deliver on
what they say they're going todeliver.
I'm, I'm, I'm doing kind of aconversation.
Let's pretend you're my boss orthe CTO.
I'm an engineering leader.
The planning accuracy looks goodhere.
(18:11):
So that's a good thing.
It's giving me confidence.
But there's something that isconcerning me on this project.
And I want to show yousomething.
It's our cycle time on thisproject.
I'm seeing bottlenecks here andI'm seeing some bottlenecks
because it looks like only oneperson is doing all of our
reviews.
We have a, it's a senior and wehave a lot of juniors on this
(18:31):
project.
Now I know that this project'sdue in six months from now, but
I want to call out this peoplerisk to you.
It's a very mature conversation.
I'd like to add another seniorto this.
And the reason I want to add asenior is to increase my
probability to deliver on time.
And even better now, I know thisis like futuristic stuff, but
this is what we're working onwith some of our customers.
(18:54):
Let me show you a Monte Carlosimulation that if we were to do
this, why I think it will helpus deliver on time.
Now I'm talking with data.
I'm talking with risk levels.
I'm talking with Simulation tothe business of like, let me
bring you in of what it reallytakes to forecast.
I think that's really cool andkind of like next level mature
(19:16):
conversation.
What do you think about that?
Yishai Beeri (19:19):
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 canmove the conversation to let's,
let's make some decisions.
It's probably not just magicallycreate a new resource, but let's
move someone from a project thatis doing well and maybe has some
(19:42):
capacity, uh, that, that theycan contribute here because I
have a bottleneck here.
The data is showing me the kindof risk that I can alleviate
with moving a resource and maybenot lose so much on the other
project because the signalsthere are different.
What?
When the conversation moves tomaking choices and you see the
(20:05):
choice you see the you know theoutcomes it becomes a much Much
stronger conversation.
Dan Lines (20:12):
Okay, so let's do a little summary on the
predictability side, we havesome KPIs, right?
We have planning accuracy.
That's a good one.
We have capacity accuracy.
That's a good one.
We have project forecasting withsimulations.
That's a good one.
And now imagine having that forall of your projects.
(20:33):
You see them all in one view.
That's awesome.
Now there's kind of this likewhat you're saying.
I have to make decisions ofwhat, what to do.
Can you talk to us a little bitabout goals around resource
allocation?
Cause sometimes a lot of thosedecisions might be, ah, I don't
know.
We just were understaffed onthis project.
(20:53):
Is it really the top project?
I could move this one faster ifwe could delay this other one,
but I got to shift some people.
Talk to me about resourceallocation, investment profile,
goals around that kind of stuff.
Yishai Beeri (21:04):
So both resource allocation and investment
profile are ways to look at theactual spin.
Where is my energy going?
Where are my people deployed?
Not just in, in, on paper, onplan, but what is actually
happening?
And I think a very common, um,cycle, and we've seen, we've all
seen this, where Management sitsat the beginning of the quarter,
(21:28):
lays out a plan, allocatesresources.
Yeah, let's take 20 people forthis project.
Let's put this team on thatproject.
This is important for us.
It's a new product or a newfeature.
Let's, um, um, concentrate somework and resources there.
Great.
The plan looks good.
Then reality hits, right?
(21:50):
So this 20 people project, yeah,on paper there's, they're all
there.
But three you haven't even hiredyet, two are busy, uh, with an
old project that they weren'table to ramp down quickly
enough.
Um, another one is pulled to putout fires elsewhere.
Reality is different.
And then the quarter ends andwhy have we missed?
(22:10):
You spend time to realize thatactually we didn't have the 20
people.
So research allocation is a wayto look at what is the actual
spend across projects orinitiatives or any kind of like
slicing the pieces of work inyour, um, dev work and course
correcting.
Yeah, this is what is actuallyhappening.
(22:30):
This is what we wanted.
We can now course correct.
We can help people ramp up morequickly or ramp down more
quickly if a project needs that.
Or we realize that we have agap.
Now we can make a choice.
Okay.
Reality is a bit different.
Let's make a choice about whatto, um, you know, what to give
(22:51):
up on, what to invest more inand so on.
Totally
Dan Lines (22:54):
makes sense.
And now we can have kind of thateducated conversation with the
business.
Okay, so now that we talkedabout kind of both sides of the
dual mandate, some of the KPIsthat you can use for engineering
efficiency, we have our DORAmetrics, we have some leading
indicators, we talked a lot onthe business.
(23:15):
Alignment side, predictability,very, very important.
I want to ask you, in terms ofactually setting goals against
these KPIs, where in the orgstructure should I start?
Is it like a top down thing, abottom up thing?
What are your, what are yourthoughts on that?
Yishai Beeri (23:33):
That's a good one.
I think, uh, there's probablynot one answer.
first of all, there's the orgculture that you have to take
into account.
Um, in some, um, respects, and Ithink mostly on the engineering,
uh, like operational efficiency,there's a lot of sense in doing
this bottoms up and letting theteams decide on which goals to
(23:55):
take and what, like, how to tunethe goals.
Because, uh, in many modern, um,you know, development
organizations, you want to giveautonomy and you have the right
people that you can giveautonomy.
The team knows how it'sdelivering.
They have, maybe even betweenthe teams, there's a difference
in how they're working.
(24:15):
Some could be using scrum, somecould be using Kanban, some
could be using a combination.
Some are building.
You know, SaaS front end, someare doing mobile apps.
So very different ways tomeasure and to benchmark.
So giving autonomy and thebottoms up approach makes a lot
of sense.
And also very strong culture,positive of, you know, it's not
(24:39):
like a big brother watching overyour back and measuring you.
It's more like This is a way foryou to measure yourselves and
report up.
Um, and it still makes sense inthese cases to have a top down
focus.
Yeah, we know as a company, as adev work, we have, we want to
focus on being more efficient.
(24:59):
Let's make sure we look at cycletime top down because it's a
good efficiency and bottleneckdiscovery kind of metric.
Um, if we have a quality issueor a quality, initiative going
on in the company.
We can make that a top down andbake that together with with
bottoms up.
Yeah.
On the business alignment side,I think it's typically running
(25:22):
top down with, you know, orglevel or VP level and then
departments or groups.
Aligning either to the productlines or the way the org is
built.
Um, you want predictability tobe measured across your teams or
groups and then aggregate it up.
That makes a lot of sense comingtop down.
Dan Lines (25:43):
it's kind of like a mix.
One thing that I've seen,especially with the larger
organizations, Let's say youhave a hundred developers plus
5, 2 50 developers, 500developers, and then I don't
know, we, I'm working withcompanies that have 6,000
developers.
I think that there does need tobe something top down around
(26:03):
standardization, I'll call it.
Now, of course you want bottomup adoption, but when I think of
standardization, it's kind oflike, here is how we're going to
measure cycle time.
This is our standard practice ofwhen cycle time starts versus
when cycle time ends, and that'sthe standard for our business.
(26:23):
Here is how we're going tomeasure sprint planning
accuracy.
This is, you know, how we startit either when one day into the
sprint or right when the sprintSo, what I've seen is when you
bring these top down standardsIt kind of says, when do things
start and stop?
And what do the, what are theKPIs that we care about?
(26:44):
Now, after that, we care.
Yeah, we care.
Now you have the standards.
We do care.
I think it's more go deploy thiswith your teams and set your
goals around this.
Here's our high level goals.
You go make it happen.
That's where I've seen it worksreally well.
You have top down standards.
(27:05):
You say the KPIs that thecompany or the business unit
cares about, and you give somehigh level guidance on the
goals.
Now you go make it happen foryour team.
That's, that's kind of what I'veseen work really well.
Yishai Beeri (27:19):
And I think that lets the, the, the teams or the,
you know, lower parts of the orgfocus a little on the leading
indicators.
Sometimes on more technical, um,ways to look at the problem.
So you could, you're thinkingabout cycle time as a top down,
but then for a team to improvetheir cycle time, they could be
looking at smaller PRs.
(27:40):
They could be looking at howlong does it take me to pick up
a PR for reviews, a pickup time.
There are the ways to implementthat goal are a little more
detailed.
And another team may look atdifferent, uh, they have
different bottlenecks.
So they'll, they're going totake a goal around a better
review process.
Or can I automate away some ofmy reviews?
Dan Lines (28:02):
Absolutely.
Now, what I want to do in thelast few minutes of this pod, is
talk a little bit more about thebusiness stakeholders and what
it takes for a VP ofengineering, a CTO, a director
of a business unit.
(28:24):
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, youknow, these KPIs.
But what can you tell us, maybean overview or some tips and
tricks?
I'm an engineering leader.
I'm measuring this kind ofstuff.
(28:44):
How do I approach businessstakeholders?
I've never done it before.
What do I, what do I do?
Yishai Beeri (28:49):
Yeah.
So, um, first, you know, a lotof us hit that wall where, uh,
it feels like no one cares atthe beginning.
You know, everyone is about thesales numbers and the marketing
numbers.
They're used to seeing numbersand data in measurements for
those departments, and they'reused to having engineering say I
think this feature is gonna landin two months.
(29:11):
That's, so there is someeducation, Oh, there's actually
good data to look at.
There's actually a way to drillin.
Um, so come prepared to, to Notjust show the data and the
goals, but also explain why itmatters.
Why cycle time matters so much,because it lets me, um, you
know, learn much faster fromthe, the feedback that I'm
(29:33):
getting from our customers whenour new, uh, the new code hits
the, um, the users.
Um, by reducing thesebottlenecks, I can get so much
more done and improve thequality.
So, be, like, be prepared toexplain why it matters.
I think as engineer leaders, andmany of us are engineers at
(29:53):
heart, uh, we need to rememberthat less is more.
So don't come with, you know, 50numbers.
It's not going to work for, forthe business, uh, discussion,
um, focus on what really mattersand always show how that aligns
with, with the business.
So if you're talking aboutpredictability, yeah, this
project is landing on time or 90percent of it is landing on
(30:17):
time.
And here's why, and here's thechoices that I've made.
Um, I think that, that was whenyou 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'reseeing success when you get,
people are asking you to drilldown.
(30:38):
Right.
They're asking you smartquestions about the data that
you're showing.
Dan Lines (30:42):
Yeah, that, that's, that totally makes sense.
Especially when you startgetting some of that engagement
and questions.
I think my best tip here, whatI've seen work really well, if
you go to your businessstakeholders and say, I'm
putting a new thing on yourcalendar.
So first of all, it's repetitiveand it's going to be repetitive
(31:05):
and it's going to be called ourforecasting meeting, our project
forecasting meeting, and it'smonthly, all you got to do is
show up.
Now, one thing that's cool aboutthat.
You may already have this.
You know, ceremony of aforecasting meeting, you may
not.
So you're going to get some, ifyou don't, some kudos points,
because those stakeholders aregoing to say, I definitely want
(31:25):
to come to a project'sforecasting meeting because
that's what I care about.
Now's your opportunity.
You got them in that meeting tostart hitting them with, is the
project going to deliver ontime?
Let me show you some of theunderlying engineering metrics
of cycle time or change failurerate.
You have the planning accuracy,and maybe you start getting some
(31:45):
questions about that.
And usually what I see is if yourelate it back to what they care
about, which is these businessdeliverables, that is when
you'll get, Oh, now I careabout, Oh, cycle time has
something to do with me gettingwhat I want.
Let me ask a question about it.
Yeah.
So that would be my tip, mybiggest tip.
Have you seen that kind of stuffwork or any comments on that?
Yishai Beeri (32:09):
Yeah.
I think you talk about cycletime in, in, um, you know, in
isolation.
No one cares.
Dan Lines (32:16):
Yeah.
Yishai Beeri (32:17):
You talk about cycle time affecting delivery of
this project, which is What Ineed to sell more as a sales
leader.
Now I can start relating andyou'll be surprised by the kind
of smart questions you get fromyour business peers about the
data and about what it means.
Just like you can ask about thesales cycle and how is the sales
(32:39):
cycle different in differentsegments, right?
It's natural for us to drill inwhen we see the connection.
Dan Lines (32:45):
Yeah, it's so funny.
It's like, uh, Hey, I want to goask 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 aquestion that says, Oh, we're
talking about the delivery ofthis project.
I'm showing you why we'reprobably not going to deliver.
(33:06):
It's because we have a poorcycle time due to a reviewer
bottleneck and you can get yourbusiness stakeholders to say,
Oh, Well, what if we had anotherreviewer?
Oh, great.
Perfect.
Yes.
Cause I would love to addanother reviewer.
Actually, I need a senior one.
I have a job description.
Should we deploy that to deliverthis project on time?
(33:26):
That's cool.
Yishai Beeri (33:28):
Or, or even I can show you through the metrics
that this project is veryefficient.
It's already running veryefficiently.
There's LinearB publishesindustry benchmarks across all
of our metrics.
We are.
actually doing very good in thisproject, which means if you give
me more resources, there's like,they can be very effective here.
(33:50):
Another person in this projectcan really kill it because I've
already removed a lot of thebottlenecks.
Dan Lines (33:54):
Yes,
Yishai Beeri (33:54):
it's now running very effectively.
A new resource is going to bevery effective here.
Dan Lines (33:59):
Let me prove to you that it will work.
So we're coming to the end here.
Could you tell us a little, sowe have a CTO board report that
can be used.
Talk to me about this CTO boardreport.
Yishai Beeri (34:13):
Yeah, so this is a template that, you know, you can
use as a, as a starting point toput some, pull some data from
LinearB or however you measureyour, uh, your key goals, your
KPIs.
And, you know, in basically twoor three slides, convey the key
information to, you know, theboard or the staff meeting and
(34:35):
similar.
Uh, Senior Leadership.
And we're basically splitting itinto two parts.
One is a heartbeat of the healthof the engineer organization.
The key, key, um, metrics, thetop downs.
This could be cycle time andsomething, you know, merge
frequency for developerexperience.
Two or three metrics with atrend, with an industry
(34:58):
benchmark.
Um, um, Context, so you anchorthe numbers.
It's not just three on the, onthe, on the screen.
It's a three, which means we'rein the, I don't know, strong
band of the benchmarks.
So, let's have everyoneunderstand what it means.
And, we, we, we, uh, suggestthat you take a goal.
You're saying, in Q1, my cycletime was three days.
(35:21):
My goal for the next quarter isto like lower it down to two and
a half days.
By having this simple cycle ofthere's a number, there's a
context and a trend and I'mtaking a goal.
You are now really helping yourpeers and your, your managers
trust you that you've, you'vegot this.
I know what I'm doing.
I can see where I'm going.
(35:42):
I have a plan, but I don't thinkthey 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 isthere.
And then the second part is.
These are the key investments,the key projects.
We talked about resourceallocation, so show some data.
There's always going to be thetop three, four, five, maybe
(36:03):
seven projects or initiativeswhich are what everyone thinks
about.
They are the key, uh,investments.
Show the investment, show thatit'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.
(36:24):
You show the engineer metricsfor that project, it's actually
performing well, or this iswhere I'm focusing.
I'm focusing on improving mybottlenecks for this project
before I'm asking for moreresources.
So, my resource spend aligned onprojects and my engineering
health.
The two slides is all you needto really convey the message.
(36:45):
On how are we doing and startmaking decisions, right?
This is about staffing, aboutresourcing, about changes.
Now you can drive a reallyvaluable conversation.
Dan Lines (36:56):
Yishai, thank you so much.
That is a super cool report.
It's a free report.
Thank you for coming on.
Talking to us about the dualmandate and goal setting and
even more so what you said atthe end.
It's really a career builder.
Trust with your peers, settinggoals, visibility and
(37:20):
transparency.
We love having you on the pod.
Thank you so much for joining.
Yishai Beeri (37:25):
Thanks Dan, as always.
This was great.
Dan Lines (37:27):
And you know, to everyone, thanks for tuning in.
If you want to dive deeper intogoal setting, download our free
Engineering Leader's Guide toGoals in Reporting at LinearB.
io slash resources.
Um, we'll also include that, uh,in a link in the description.
(37:49):
And everyone have a great week.
Talk again soon.
Popular Podcasts
United States of Kennedy
United States of Kennedy is a podcast about our cultural fascination with the Kennedy dynasty. Every week, hosts Lyra Smith and George Civeris go into one aspect of the Kennedy story.
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com