April 29, 2025 • 37 mins
In this episode of The Agile Within, I explore the fascinating Agile journey of Safety IO with Max Dazer, Agile Lead. Discover how Max navigated through frameworks like the Spotify model, Lean principles, and the Theory of Constraints to foster collaboration and break down organizational silos.
Gain insights into Safety IO’s innovative ecosystem planning and how the Theory of Constraints helped the team prioritize work, reduce wait times, and optimize delivery. Max also shares how embracing the Product Operating Model brought teams closer to business outcomes and bridged gaps across the organization.
Whether you're a Scrum Master, Agile enthusiast, or industry leader, this episode is packed with actionable lessons to elevate your approach to Agile transformation. Tune in now and take the next step on your own Agile journey!
Connect with Max on LinkedIn:
linkedin.com/in/maximilian-dazer-b43875199
Check out the Road 2 Mastery:
Follow us on LinkedIn:
https://www.linkedin.com/company/the-agile-within
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:06):
Welcome to the Agile Within.
I am your host, Mark Metz.
My mission for this podcast isto provide Agile insights into
human values and behaviorsthrough genuine connections.
My guests and I will sharereal-life stories from our Agile
journeys, triumphs, blundersand everything in between, as
(00:29):
well as the lessons that we havelearned.
So get pumped, get rocking.
The Agile Within starts now.
Attention, Scrum Masters andAgile enthusiasts, Are you ready
to level up your skills andconnect with the best in the
industry?
Well, the Online Scrum MasterSummit is your chance to hear
(00:51):
from world-class Agile experts,gain real-world insights and
explore the latest trendsshaping the future of Agile.
Best of all, it's 100% free andcompletely online.
Happening from June 17ththrough the 19th, this event
brings together thousands oflike-minded professionals for
(01:13):
engaging talks, interactivesessions and hands-on workshops.
Don't miss this opportunity tosharpen your skills and expand
your network.
Sign up now atonlinestrummastersummitcom.
And now on to the show.
I hope everybody's having anabsolutely fantastic day out
(01:33):
there today.
Welcome back.
This is Mark Metz, with theAgile Within.
My guest today from Berlin,Germany, is Max Daser.
Max, welcome to the show.
Hi, Mark.
Yeah, thank you for having me.
So, Max, you and I connected awhile back in a training class.
Do you remember that?
Speaker 2 (01:51):
Yeah, it was the Road to Mastery, which was like a
really great experience to haveback in the days.
Speaker 1 (01:58):
Really was, really was, I think often about those
times.
So give a plug to Road toMastery.
If you haven't done that before, maybe I'll put a link in the
show notes.
How about that for ourlisteners out there?
So, max, before we get further,I want to dive into our
icebreaker question.
And if I were coming to Berlin,germany, for a day and had
never been there before, what'sone thing that Max would say
(02:20):
that I couldn't miss doing?
Speaker 2 (02:22):
I think there are, in general, like a lot of tourist
attractions, but I know you'renot looking for those.
So I think Berlin has onereally key feature it's
decentral.
So, depending what you like,you can go in a district and it
feels like a completelydifferent city.
Like, just to name something,wedding feels completely
(02:44):
different than to PrenzlauerBerg.
So, depending on what you like,you can go to these different
districts and you can even havelike a really kind of posh
experience or like more groundedexperience, depending on the
districts you go.
And that's something I alsoreally appreciate about Berlin.
Berlin is a really honest city.
(03:04):
When you go and walk across thestreets, you will see a little
bit exaggerated like amillionaire next to either some
working class guy or even ahomeless person, both drinking
their beers at 7am.
So if you kind of like thisvibe, berlin will be perfect for
you, no matter what.
And I would really recommendgoing into different bars, like
(03:25):
in Wedding, you have like a lotof great bars that are really
for lack of a better wordancient, but in a good way.
So that's what I would everyonerecommend Check out Wedding
it's one of my favoritedistricts and enjoy it All right
.
Speaker 1 (03:40):
Well, max is an Agile lead at a company called
Safetyio.
They have been on a journey.
Their agile journey has hadlots of twists and lots of turns
, and Max and I were talking.
(04:02):
And Max, why don't you, ifwe're thinking of a timeline,
and you've got that startingpoint over on the left and maybe
you can picture, you've got acircle that's on the line and it
says start here.
Where are we starting at in ouragile journey with safety?
Speaker 2 (04:07):
io?
Yeah, that's a really goodquestion.
So I'm at safety ao since roundabout four years, like right
after covet hit, and so when Ijoined it was like a purely
remote company just out ofnecessity, and also relatively
small.
We were like 50 people aroundabout around like six teams.
(04:30):
The numbers might be slightlyoff, but that's the more.
It's more or less true.
And it was a company that wasworking in the Spotify model.
You had different tribes andsquads, all of this kind of
language, and I joined as aScrum Master for a specific
tribe, so to say.
They were doing softwareservice solutions for worker
(04:54):
safety, so everything that is,workers that work in
safety-critical situationswithout going super in-depth
about it.
That's what we're trying to dothat everyone can work in safety
.
And I joined there and wasmostly really focused in this
kind of squad level.
I personally never liked theSpotify model, so I was always
(05:14):
fighting against it becausepeople might disagree.
But how I approached theSpotify model for me it was like
a strong metrics organizationwith different names.
So it's usually a good way fora company of changing without
really changing, because youjust changed names.
Like you don't have adepartment, you have a tribe and
(05:37):
you then have squad instead ofteams and when people like this
naming that's fine, I alwaysfind it found it a little bit
cringe, so that that was onepersonal uh opposition I had
against this model.
Were you alone in thatsentiment?
I think not completely.
I think no one really liked thenames, but we were also and
(06:00):
that's across the journey seeingthat this model didn't really
help us to satisfy our needs.
Because when I started, I didn'timmediately jump and try to
disabandon the Spotify model.
I was focused on my teams.
I was working with three teamsand trying to help them.
So there it was like for lackof a better word what I would
describe as basics from masterstuff, not that it's easy or
(06:23):
boring, but it was reallytalking about.
Okay, what does our processlook like?
Let's visualize it.
Let's do a value stream session,talking about WIP limits, that
maybe for a team of six peoplewe don't work on 20 items at the
same time, and why it makessense.
Introducing like differentmetrics, like flow metrics,
wasn't big enable for us andworking on technical excellence.
(06:46):
So improving our test coverageand moving to like a continuous
delivery from really releasingmaybe once per month to nearly
daily.
What I'm describing here islike a journey over like a year
and when we there, we had ourdifferent teams that were
relatively high performing, butwhat we noticed that this
(07:08):
doesn't necessarily result in aglobal phenomenon.
And I think that's when we tryto question the Spotify model.
So I stopped here for a secondbecause I could really go on big
money log, but I was not alone.
But I think for us to questionthe Spotify model, we really had
to push it to its limit that wereally feel it's not suiting
(07:31):
our needs.
Speaker 1 (07:32):
Okay, so as a recap, make sure I'm understanding
correctly.
So when you came in to safetyio, the team maybe even at the
department level or even the orglevel had adopted a Spotify
model.
And when they did that, theyreally were able to just kind of
take their own processes andtheir own organization and just
(07:53):
kind of drop it in as is andreally didn't encounter a lot of
resistance into the Spotifymodel.
You did that for about a year.
You start challenging something, so what's the next step in the
journey?
Speaker 2 (08:06):
The next step.
That's what I called like anecosystem process, Because,
without going super in-depth,but to give you like a
high-level overview about ourstructure, we have cloud
solutions, mobile solutions andalso hardware devices.
We approached every one of themindividually.
So software as a service waslooked at as a product, the
(08:29):
mobile solution as a product,the hardware solutions as a
product and I don't want to getpicky about names because it's
justified in a sense, but whenwe approach it from a customer
perspective, they want theentire solution because
everything works together.
They want the entire solutionbecause everything works
together, and we saw it ondifferent features that just
because the mobile team isfinished doesn't mean the
(08:50):
feature is done, Because theremight be other teams who need to
do something, and there thiskind of Spotify model, which is
really driven by autonomy, wassomething that we could not like
.
We were not able to create thismuch autonomy, even with
domain-driven design, which wasone way to approach it, that at
least the software as a servicesolution doesn't have that many
(09:13):
dependencies, because we weregrowing over this journey that
I'm describing from like yearzero we're joined to like year
two and like initially doubled.
So now we're close to 100people and like round about 12
teams.
So autonomy is still important,but we also realized our system
(09:34):
, our organization, doesn'tnecessarily need to optimize for
autonomy as much as the Spotifymodel, so I think that was why
we questioned it.
And this ecosystem approach wasreally based on a lot of
different concepts.
So I don't want to say that Ididn't invent anything, but it's
inspired by less theory ofconstraints, lean principles and
(09:56):
really trying to embed thiskind of system thinking in our
approach and trying to identifywhen we think about a feature
approach.
And try to identify when wethink about a feature, what does
it really mean from a customerperspective?
Do we need other teams?
So this means we cannot onlyplan in the mobile part, but we
need an ecosystem approach wherewe plan there first and zero
(10:17):
constraints has something that Icall full kitting, which means
you prepare like everything.
You need to know that a workitem can flow through your value
stream without beinginterrupted.
That's what you're trying tocreate.
Obviously, this will not workthe first time and everything.
Every reason that you'regetting blocked.
You should write it down andtry to embed this in your kind
(10:37):
of full kitting list.
But that proved really valuablein reducing some of the wait
time.
Maybe one last example.
Speaker 1 (10:44):
Sorry to interrupt you, but what about that?
Because you mentioned thatthere was a matrix-style
organization that kind of hadbeen embedded in there, that you
were, I guess you assumed that,and so how were you breaking
down those dependencies to moveaway from having these handoffs,
so to speak?
Speaker 2 (11:07):
to move away from having these handoffs, so to
speak.
So I think that for now it'snot completely about just
removing dependencies, becausewe think about experimenting
there more, but for now we haveclearly embedded teams that work
on the embedded devices and sowe don't have like a
cross-function team in thatsense that stretches across
different technical, technicaldomains.
(11:27):
So we still have thesedependencies.
They are not that many likethat it's the main thing we want
to get rid of.
Like it's not the mainconstraint.
What we were witnessing is morethat because everything was
planned individually like if youhave a product manager for web
and a product separate productmanager, if you have a product
manager for web and a separateproduct manager for mobile and a
product manager for thehardware device, they are not
(11:49):
necessarily incentivized toprioritize a feature that
another product manager, anotherproduct owner needs to say oh,
that moves up into the backlog.
So there we use one thing fromless which says and it's maybe
not also in Scrum but you haveone product backlog per product.
So ecosystem is the product.
(12:10):
It means we should have oneproduct backlog.
So this means we need some wayof visualizing the work for the
ecosystem and prioritizing it atthe start and that was the
example I wanted to get into.
What we can see, and it's alittle bit of a made-up example,
but a mobile team starts afeature and then realizing, oh,
(12:32):
we need the web team.
They go to the web team, say weneed you, when do you have time
?
They say, oh, we're working onsomething we.
We can start this in two weeks.
That's like a good scenario.
So what does the other team do?
Because mainly organizationsdon't like idle time, which is
another thing we could get intowhy this is bad, but usually
organizations don't like idletime, so the mobile team would
(12:54):
most likely start new work andthen wait for the other item
that is still like in progressuntil the web team gets to that.
And in the best case scenariothey just do their work and then
everyone can continue.
But the more realistic scenariois that they have questions and
then you need to refine it,potentially with them.
But you also started somethingelse that also needs your
(13:16):
attention and then suddenlyyou're having a split focus and
from there on you're potentiallyin a bad multitasking situation
that can spiral out of control.
So what you're doing there toalso approach from a lean
perspective, you cannot limityour work in progress, because
each team might, by accident,trigger more work in another
team.
(13:36):
So that's why we try to move itout of the team level and bring
it to the ecosystem level, andI think that was really this
kind of next iteration that alsomade us then abandon the
Spotify model and the names.
Speaker 1 (13:53):
So I'm curious to know did you have a WIP limit at
the ecosystem level?
Speaker 2 (13:58):
So I think we're using different things there and
that's maybe also somethingwhere I'm a little bit biased.
I am a huge bottom-up guy, sothis means also especially my
kind of where I started in thescrum master role.
I started with something, myteam experiment.
If it works, let's roll it out,and that can make you sometimes
slow.
So, um, you need to mix it withuh, with top down, yeah, and
(14:22):
the short answer is yes.
The slightly longer answer isthe first problem we encountered
was there is no shared languagehow we talk about work.
Like it's really hard to limitwork when everyone has a
completely differentunderstanding about it.
And I know that's right nowabstract.
But just to give like a reallybasic example, right out of Jira
(14:43):
Epic, when we ask thesedifferent teams what Epic meant,
we get different answers.
For some, an Epic was it's apiece of customer value, like an
independent thing that we couldrelease and the customer gains
something from it.
For other teams, it was like wewere seeing implementation
Epics, testing Epics and so on,so like a kind of waterfall-ish
(15:05):
breakdown into Word, which isanother problem entirely, but
still that's how they thoughtabout work.
Another team was using epicsjust to like store work.
So they had.
We had as an example, wediscovered like a technical
depth epic, which was like aimmortal, because you would just
(15:25):
whenever you found something,it was like, oh, we should fix
this event At one point you, youjust add it into this
tech-to-concept epic and it waslike a container of work that
you would always pull stuff out.
And from all of these versionswe can debate what is right and
wrong and how you should use it,and that can be an important
conversation.
But the reality was, well, wedon't have a common agreement.
Everyone uses the same word buthas a different meaning there.
(15:54):
So that's where we try to say,well, maybe let's and I know
some people don't like it butlet's standardize how we talk
about work and how we thinkabout work.
And I think that was the firstkind of key step we had to take
in order to be able to limitthis ecosystem, and that was
like a crucial step.
But then, yes, we moved to someway of limiting the ecosystem.
It's a little bit harder toexplain there because it's not
as straightforward that you justhave a limit of four features
(16:15):
can be in the ecosystem.
It's a little bit more complexthere.
Speaker 1 (16:20):
So I often say that life isn't black and white.
Many times it's some shade ofgray in the middle.
So you usually can't go fromall the way from one extreme to
the left to an exact oppositeextreme on the right.
So to give full, 100%, totalautonomy to the teams to let
(16:41):
them do whatever they want to do, I think everybody would agree
that that system is probablygoing to fall apart.
They're all off, kind of doingtheir own little missions, but
at the same time, if you go allthe way on the other end of the
spectrum and say we're going tostandardize everything and this
is how the process is across theecosystem and we're going to
(17:01):
spell it out to a T, I think youprobably wouldn't have many
developers left right.
If that was the case, theywould be so frustrated with
having to be told exactly notjust what to do but how to do it
.
So it's how do you define thatmiddle piece to negotiate, to
find the sweet spot?
And so I'm curious to know how,what that process was like for
(17:23):
the, for the teams.
I'm sure you got some pushbackon some ideas, right.
Speaker 2 (17:27):
Yeah, and maybe also as a disclaimer, it's not that
we're fully there.
I think it's generally alsoreally hard to reach an end
state in these kind of productdevelopments.
It's always in motion.
But something that's helped tofind, or getting closer to, this
kind of sweet spot, as you'vecalled it.
What personally helped me wasthe theory of constraints,
(17:52):
because how I would describe itwithout going fully in depth
with theory of constraints isbecause it's a lot, but I think
it's kind of anti-dogmatic.
So it's not necessarily arguingthat you need to optimize for
autonomy or something else.
It's arguing try to understandyour system foremost and try to
(18:15):
then be flexible.
And I give you one example ofwhat I actually mean with that.
So I've described thisecosystem approach, at least on
a high level.
The complexity in this processlies is sometimes a feature is
purely in one technical domainand one team can handle it and
can more or less delivercustomer value and quickly
iterate on it.
But sometimes you might needall the teams in the ecosystem,
(18:40):
which makes it a little bitharder than to like.
You cannot approach it the sameway.
These two features, these twowords would be handled
completely separate.
And to get more specific, eventhere, if something is purely in
one team, you potentially don'tneed to have coordination
meetings about that because it'sin your team.
You kind of capture this withall your team meetings, be it a
(19:03):
daily or refinements and so on.
That all should be enough totackle that.
But if you have a featureacross an embedded domain, a
mobile domain and a web domain,individual team refinements will
not get you there.
What helped us to find the sweetspot is again pushing this
planning up front and sayinglet's agree on priorities and
(19:23):
what we have to do first on thisecosystem level, let's apply
this for-kitting approach, whichmeans answering the basic
question which teams do we needfor that?
Like, we have a customerproblem and we want to solve,
which teams do we need?
We will not always be right andthat's also not the goal, but
for a lot of features we canactually tell which teams will
(19:44):
have to do something.
We cannot necessarily alwaystell how and what exactly they
have to do, but we can tell theyhave to do something.
We cannot necessarily alwaystell how and what exactly they
have to do, but we can tell theyhave to do something.
And if we figure that out, thisalso means they should have
potentially some shared planningsessions, and the goal
obviously, is that we can goback into our individual teams
and then go back to autonomy andwe just do our stuff, but we
(20:05):
cannot start there.
So, to recap it we just do ourstuff, but we cannot start there
.
So, to recap it, we just didn'ttry to say, oh, we want to
optimize for one thing, be itautonomy or be it 100%
predictability.
We said let's move thisplanning of work really upfront,
move it on the ecosystem level,so out of the team level, let's
agree on priorities here andwhen we do our full kitting and
(20:29):
understand which teams we need,this kind of dictates how we
approach the work.
So if it's more dependencies,we plan it together, that we can
understand the nature of thedependency and how we want to
approach this work.
We might have some kind ofshared refinements and some kind
of coordination meetings aroundthis.
If something is purely in oneteam, it's not part of this.
(20:54):
Ecosystem coordination meetingsas an example, because no other
people need to hear about it.
So that's one example how wetry to be anti-dogmatic and not
saying, oh, but our frameworkwants us that we do this and do
step B, and I think that wasreally helpful.
Speaker 1 (21:11):
Customers don't care what framework you use, right?
Speaker 2 (21:14):
Yes, and I think also what we have to like.
I can't be really specific here, but these teams work also in
different processes right now.
So our embedded teams were morein a waterfall-ish process,
which we may want to change.
But I also want to be honestthat the main problem we're
(21:35):
seeing right now is not thatthey're doing waterfall, that
it's really not connected tothat.
The main issue we were facingis that priorities were set on
the team level, not theecosystem level.
You might want to change theprocess and adapt it, but for us
, it was really just helpful insaying we don't really care how
you work, we can figure this out.
Just let's get into onehigh-level shared process and
(21:58):
everything else will follow fromthere, and that also, in my
opinion, is really good tocreate buy-in, because we're not
coming like the all-knowinggods and being graceful to them
that we're finally payingattention to them and now they
need to work like us.
It's more like a sharedlearning experience, and that's
how I in general like toapproach it, because I don't
(22:20):
know how to do good embeddeddevelopment, being completely
honest there.
So I don't want to dictate howthey work, but I want to figure
together with them out what areour problems and how can we fix
them?
Speaker 1 (22:33):
So I want to talk to you just a second and get your
thoughts on this, because thisis a situation that I've
encountered in the past.
And so the situation that wewere in was we had multiple
teams and a team was assigned toa product and they knew that
product, they knew how tosupport it, they knew everything
about it because that's whattheir specialty was.
(22:53):
But then some products justlike okay, for the next two
quarters, we really need to dialback on this product.
We're not getting the salesfrom it.
Customers just aren't using itor they're happy with where they
are.
Where they really need is inthis other product over here,
Like maybe your software is aservice solution, for instance.
(23:14):
That's where we need to put ourenergy.
So what the ask is from peoplethat aren't in the software
development side is well, whycan't you just move the other?
I'm giving air quotes resources, I hate that term, but why
can't we just move resourcesfrom one team to another?
So instead of having 10 on oneteam and 10 on the other, let's
just put eight on one and two onthe other, and that way we can
(23:37):
make more progress, and theteams would really have a heart
attack because they're like I'venever worked in this system
before, so it's going to take mea long time to ramp up.
So that was another problem forus to solve of getting ahead of
the game and doing some crosstraining and making sure that
people did have that big pictureview of the ecosystem, like you
talked about it.
But have you encounteredsituations like that and how did
(24:00):
you approach those Max whereyou were being asked to shift
the teams around?
Speaker 2 (24:06):
I would say we don't have this problem super severely
, that we need to figure it out.
I think what happens sometimesif we're saying one product, we
want to dial it a little bitback, that we're saying why
don't we just have one or twopeople from this team go to
another team where we definitelyneed what there's like a lot of
(24:27):
more work coming up there,because we assume that's where
the real value lies.
So I think there we have someflexibility.
It's not necessarily that it'sright now on feature level,
because then also from a budgetperspective, these people would
then be added into like asresources and be then part of
(24:47):
this new team and don'tnecessarily would switch around
that soonish again.
But what I'm trying to saywe're we're not really that high
in fluctuation, so it happenssometimes and then we can
reasonably figure it out.
But there it was not enoughpain that we need to say, well,
let's maybe look at, look at forlack of a better word for a
process how can we figure thisout and switch people around and
(25:10):
then train them?
This hasn't been the mainproblem, however.
The other part of my answerwould be what is really valuable
in, for example, an ecosystem,because it can still happen
inside this ecosystem.
That we're saying for feature Bthat is now upcoming, we see
80% of the work on the embeddedteam and the embedded team might
(25:32):
be four people, while the restof the other software teams, be
it mobile and cloud, might be 40.
This can, like this is animportant thing to be aware of,
that.
Well, maybe our constraint itfor that feature might be
embedded.
Why this is important is, againfrom a theory of constraints
(25:53):
approach.
If you want to improve yoursystem performance, you need to
aim at the constraints.
So you need to first of all andI know sounds stupid, but know
where your constraint is.
And that's not as easy toanswer Because, coming back to
our journey, where we were whenwe planned in the individual
teams, if every team is workingon like 100%, you have so much
(26:17):
work, especially in like aknowledge work, that you don't
necessarily see the constraintthat easily, see the constraint
that easily.
So you need to really bethoughtful about this and do
this kind of full kitting thatI've mentioned earlier that you
are able to tell where is ourconstraint.
Because even in our ecosystemthe constraint moves depending
(26:39):
on the work, on the nature ofthe work.
So it's not like that.
We can say, oh, the constraintis always there and either we
want to keep it there or we wantto move it to a specific.
So it's not like that.
We can say, oh, the cost rangeis always there and either we
want to keep it there or we wantto move it to a specific place
because it's moving.
So you need to build also yourkind of signals in that tells
you where is it moving towardsto, because if it's not embedded
anymore and now it's cloud, youpotentially want to focus your
improvements there.
(27:00):
That might be hiring morepeople.
But finally, answer yourquestion.
What can be really helpful tounderstand is idle time is not
an enemy.
Not necessarily, because alsofrom the constraint, the theory
of constraints approach, theonly thing that should work at
100% of its capacity is toconstraint.
So in our example, if embeddedis to constraint, they should
(27:24):
really work at their optimalcapacity.
All the other teams, if theyare idle for this specific
project or feature, it doesn'tmatter that much, like it would
matter if it's so severe thatthe constraint suddenly moves
really somewhere else.
But this idle time you could intheory think about, can we use
this idle time Like either theyjust start work that doesn't
(27:45):
need the embedded team, so theyjust do other work.
That's one way to approach it.
But you can also say is there away that we can help out the
embedded people?
It's not necessarily aboutmaking a mobile engineer become
an embedded engineer, but isthere some work we can help with
?
It might be some sort oftesting, system level
verification or other things,and it can be important to raise
(28:07):
these questions.
So that would be my answer toyour kind of questions.
At first we didn't completelyhave this problem, but something
like theory of constraints canreally help you to focus.
That you understand.
Do we even have this problem?
Should we even focus onincreasing, like hiring more
mobile engineers, because maybeyour constraint's not there and
(28:28):
it would not really matter.
Speaker 1 (28:30):
Okay, Max.
So we talked about starting offat the Spotify model.
Then you moved on from that andyou started taking some things
from Agile, from Lean, fromTheory of Constraints.
Bring us up to where you aretoday.
Speaker 2 (28:44):
So one thing that I have mentioned and that becomes
important right now thatSafetyio is really
engineering-centric.
We're part of a biggercorporation where this ecosystem
is really important andSafetyio it's purely engineering
leadership.
For a time, even the productowners, as we called them, were
(29:06):
part of engineering.
That's not necessarily bad, butyou're hitting a glass ceiling
because you're in your agilebubble and everyone is there,
and then you have the rest ofthe business who are on another
island, it feels like.
So I think what we startedthere to give it a name was
trying to use these principlesfrom the product operation model
(29:27):
, like framed by Martin Kagan,and saying we should involve the
entire business and try toexplain them why we work like
this and why we can leveragethis and also be then more
customer-centric, Because withthis high of engineering focus,
it has a lot of benefits.
(29:47):
But it can also sometimes meanthat you're losing a little bit
of customer contact In the worstcase also getting into this
kind of feature factory set thatyou can see you don't need to
be engineering-driven for that.
A lot of marketing-drivencompanies achieve that, but I
think that is where we werestuck.
We got to this ecosystem leveland it helped a lot, but we
(30:09):
still had like different partsof the organization, like sales
and product marketing, that werereally far away from us and I
think, on discerning where weare right now in getting like
embedding or implementing theseproduct operational principles,
this helps us right now of likebridging this gap.
Speaker 1 (30:30):
That's interesting.
So what was the biggestimprovement within the product
operation model that you feellike improved the way that you
worked.
Speaker 2 (30:41):
I think it depends how you want to look at it.
Something we've done on anecosystem level also was putting
way more emphasis on goals.
People can argue you don'tnecessarily need a product
operation model for that andthat's fair.
But that's like a practice wedid.
We're implementing OKRs.
(31:05):
But if you go not just lookingat practices but more like also
the principles, I think theproduct model kind of forced
everyone to be more outcomefocused so that you actually
understand oh, that's why wecould use something like okrs,
because you can also usedifferent ways of think about
outcomes and ways to measurethem.
But suddenly this is was drivenby different kind of
departments for lack of a betterword in this organization Like
(31:29):
product marketing is now waycloser to the engineering teams,
making sure that we're settinggoals in collaboration and
having this kind of transparencyon why we're doing this and the
need for it.
And I think that is this kindof biggest improvement of saying
, well, we were on our islandfor a while, but maybe let's try
(31:51):
to leave it and go back intoour big corporation and seeing
where we can align our processes.
Speaker 1 (31:59):
Did you ever have to have a conversation?
And I'm asking I'm not tellingIf anybody that knows me, that's
a famous tagline that I that Ilike to use to delineate.
So I'm not telling this, I'mreally asking but did you, did
you have to, or someone have to,have a communication with the
engineers to say we understandthat well-engineered software is
(32:21):
very important, but we'reasking you to do more.
The solution that we're notlooking for, or the goal I
should say, but we're asking youto do more.
The solution that we're notlooking for, or the goal I
should say that we're notlooking for, is wonderfully
engineered pieces of software.
It's meeting business outcomesfor real users.
Did you have any conversationslike that where you told them
(32:41):
what you're doing is important?
We just need to expand out ofthat.
Speaker 2 (32:46):
So I think there yes, I think we obviously talked
about why we want to do theproduct model and we had
different reactions across thecompany, like some people said,
oh, that's what we always wantedto do.
And then I reacted with, oh,that's great, we're finally
doing it.
Or like, oh, we're doing thisright now and always wanted to
do it's just a new name.
(33:06):
So we had these different kindof reactions.
I think what in the productmodel, but also before, we
really tried also from like afrom management, for lack of a
better word to help people tounderstand.
You're not necessarily herejust to create code.
We want to understand are weactually making a difference?
(33:27):
In order for that, we need towork empirical.
So this means we need to havesome sort of metrics that we're
inspecting to see if we'remaking progress towards an
objective.
If we want to do that, we needto understand the business world
, because for some stuff, youcan maybe look at some
performance metrics, and that'salso important.
If you really want tounderstand, if you're changing
(33:48):
customer behavior and then alsomaking an impact on your own
business, you need to bridgethese gaps.
And I didn't think people likewe're a big company, so I cannot
say that everyone loves thischange.
But in our setups we we arestill leveraging, like the, the
basic scrum setup of having likea product manager, a
cross-functional team, whoeverthey need, their developers, qas
(34:13):
and design, and we always tryto say we, we want to have like
close collaboration.
If you don't know how, that'salso fair.
Like, if it's really a problemthat we don't know how to work
with design, it's a fair point.
Like that's also fair.
If it's really a problem thatwe don't know how to work with
design, it's a fair point.
That's why we're on thisjourney and want to use this
principle from a product model.
Then let's figure it out andlet's try stuff.
(34:35):
So it's answering a little bit,but I think a crucial step was
from also engineering leadership, saying you're not just here to
write code.
We still care a lot abouttechnical excellence and pushing
a lot of there.
But you cannot just opt out andsay, oh, I don't care about how
we set up goals and I don't careabout the goals, I just want to
(34:57):
do something.
We will not get rid of you.
It's an individual.
If they stand by that, that'sfine.
Like it's.
If it's an individual if theystand by that, that's fine.
But we also want to be clearthat in like a career ladder
that we're having, then you canonly reach a certain point.
Like if you then want to climbup to the next rank at one point
, you need to then also embracethis kind of change.
(35:20):
But really, for now at least,what I experiencing the teams
are really open to that andagain, some are positive, saying
we wanted to do this always.
Now we finally get the chanceto do it.
And for the people who said wealways did it, it's just a new
name, we just try to tell themthat that's also not completely
accurate.
Like we need to be honest withourselves that because of our
(35:41):
engineering focus we had kind ofreached the glass ceiling and
it's not helpful to just say, oh, we always wanted to do it like
that.
Now a new word comes, let'sembrace it.
Speaker 1 (35:54):
Well, max, you term this as a journey, and I think
that's very aptly named, becauseit's not a destination.
It's a journey that's ongoing,so you continue to evolve.
I'm anxious to hear how yourjourney progresses.
So thank you for taking us onthis journey from a high level.
About safety IO.
It's been very interesting tohear.
I always enjoy talking with you.
(36:16):
If our listeners out there wantto get in touch with you,
what's the best way for them todo that?
Speaker 2 (36:21):
Mainly LinkedIn.
I'm not really a huge socialmedia guy, so if you want to
find me, linkedin is probablyyour best chance.
Speaker 1 (36:29):
All righty, we'll put a link to your profile in the
show notes to make it easy foreverybody.
Max, really appreciate youcoming on the show today, buddy,
it's been real helpful.
Speaker 2 (36:38):
Thank you very much for having me Again.
I really enjoyed ourconversation.
Speaker 1 (36:42):
Me as well.
All right, everybody.
That brings another end to thisepisode of the Agile Within.
We'll see everybody next time.
Thanks for joining us foranother episode of the Agile
Within.
If you haven't already, pleasejoin our LinkedIn page to stay
(37:03):
in touch.
Just search for the AgileWithin and please spread the
word with your friends andcolleagues Until next time.
This has been your host, markMetz.
Welcome to the Agile Within.
I am your host, Mark Metz.
My mission for this podcast isto provide Agile insights into
human values and behaviorsthrough genuine connections.
My guests and I will sharereal-life stories from our Agile
journeys, triumphs, blundersand everything in between, as
(00:29):
well as the lessons that we havelearned.
So get pumped, get rocking.
The Agile Within starts now.
Attention, Scrum Masters andAgile enthusiasts, Are you ready
to level up your skills andconnect with the best in the
industry?
Well, the Online Scrum MasterSummit is your chance to hear
(00:51):
from world-class Agile experts,gain real-world insights and
explore the latest trendsshaping the future of Agile.
Best of all, it's 100% free andcompletely online.
Happening from June 17ththrough the 19th, this event
brings together thousands oflike-minded professionals for
(01:13):
engaging talks, interactivesessions and hands-on workshops.
Don't miss this opportunity tosharpen your skills and expand
your network.
Sign up now atonlinestrummastersummitcom.
And now on to the show.
I hope everybody's having anabsolutely fantastic day out
(01:33):
there today.
Welcome back.
This is Mark Metz, with theAgile Within.
My guest today from Berlin,Germany, is Max Daser.
Max, welcome to the show.
Hi, Mark.
Yeah, thank you for having me.
So, Max, you and I connected awhile back in a training class.
Do you remember that?
Speaker 2 (01:51):
Yeah, it was the Road to Mastery, which was like a
really great experience to haveback in the days.
Speaker 1 (01:58):
Really was, really was, I think often about those
times.
So give a plug to Road toMastery.
If you haven't done that before, maybe I'll put a link in the
show notes.
How about that for ourlisteners out there?
So, max, before we get further,I want to dive into our
icebreaker question.
And if I were coming to Berlin,germany, for a day and had
never been there before, what'sone thing that Max would say
(02:20):
that I couldn't miss doing?
Speaker 2 (02:22):
I think there are, in general, like a lot of tourist
attractions, but I know you'renot looking for those.
So I think Berlin has onereally key feature it's
decentral.
So, depending what you like,you can go in a district and it
feels like a completelydifferent city.
Like, just to name something,wedding feels completely
(02:44):
different than to PrenzlauerBerg.
So, depending on what you like,you can go to these different
districts and you can even havelike a really kind of posh
experience or like more groundedexperience, depending on the
districts you go.
And that's something I alsoreally appreciate about Berlin.
Berlin is a really honest city.
(03:04):
When you go and walk across thestreets, you will see a little
bit exaggerated like amillionaire next to either some
working class guy or even ahomeless person, both drinking
their beers at 7am.
So if you kind of like thisvibe, berlin will be perfect for
you, no matter what.
And I would really recommendgoing into different bars, like
(03:25):
in Wedding, you have like a lotof great bars that are really
for lack of a better wordancient, but in a good way.
So that's what I would everyonerecommend Check out Wedding
it's one of my favoritedistricts and enjoy it All right
.
Speaker 1 (03:40):
Well, max is an Agile lead at a company called
Safetyio.
They have been on a journey.
Their agile journey has hadlots of twists and lots of turns
, and Max and I were talking.
(04:02):
And Max, why don't you, ifwe're thinking of a timeline,
and you've got that startingpoint over on the left and maybe
you can picture, you've got acircle that's on the line and it
says start here.
Where are we starting at in ouragile journey with safety?
Speaker 2 (04:07):
io?
Yeah, that's a really goodquestion.
So I'm at safety ao since roundabout four years, like right
after covet hit, and so when Ijoined it was like a purely
remote company just out ofnecessity, and also relatively
small.
We were like 50 people aroundabout around like six teams.
(04:30):
The numbers might be slightlyoff, but that's the more.
It's more or less true.
And it was a company that wasworking in the Spotify model.
You had different tribes andsquads, all of this kind of
language, and I joined as aScrum Master for a specific
tribe, so to say.
They were doing softwareservice solutions for worker
(04:54):
safety, so everything that is,workers that work in
safety-critical situationswithout going super in-depth
about it.
That's what we're trying to dothat everyone can work in safety
.
And I joined there and wasmostly really focused in this
kind of squad level.
I personally never liked theSpotify model, so I was always
(05:14):
fighting against it becausepeople might disagree.
But how I approached theSpotify model for me it was like
a strong metrics organizationwith different names.
So it's usually a good way fora company of changing without
really changing, because youjust changed names.
Like you don't have adepartment, you have a tribe and
(05:37):
you then have squad instead ofteams and when people like this
naming that's fine, I alwaysfind it found it a little bit
cringe, so that that was onepersonal uh opposition I had
against this model.
Were you alone in thatsentiment?
I think not completely.
I think no one really liked thenames, but we were also and
(06:00):
that's across the journey seeingthat this model didn't really
help us to satisfy our needs.
Because when I started, I didn'timmediately jump and try to
disabandon the Spotify model.
I was focused on my teams.
I was working with three teamsand trying to help them.
So there it was like for lackof a better word what I would
describe as basics from masterstuff, not that it's easy or
(06:23):
boring, but it was reallytalking about.
Okay, what does our processlook like?
Let's visualize it.
Let's do a value stream session,talking about WIP limits, that
maybe for a team of six peoplewe don't work on 20 items at the
same time, and why it makessense.
Introducing like differentmetrics, like flow metrics,
wasn't big enable for us andworking on technical excellence.
(06:46):
So improving our test coverageand moving to like a continuous
delivery from really releasingmaybe once per month to nearly
daily.
What I'm describing here islike a journey over like a year
and when we there, we had ourdifferent teams that were
relatively high performing, butwhat we noticed that this
(07:08):
doesn't necessarily result in aglobal phenomenon.
And I think that's when we tryto question the Spotify model.
So I stopped here for a secondbecause I could really go on big
money log, but I was not alone.
But I think for us to questionthe Spotify model, we really had
to push it to its limit that wereally feel it's not suiting
(07:31):
our needs.
Speaker 1 (07:32):
Okay, so as a recap, make sure I'm understanding
correctly.
So when you came in to safetyio, the team maybe even at the
department level or even the orglevel had adopted a Spotify
model.
And when they did that, theyreally were able to just kind of
take their own processes andtheir own organization and just
(07:53):
kind of drop it in as is andreally didn't encounter a lot of
resistance into the Spotifymodel.
You did that for about a year.
You start challenging something, so what's the next step in the
journey?
Speaker 2 (08:06):
The next step.
That's what I called like anecosystem process, Because,
without going super in-depth,but to give you like a
high-level overview about ourstructure, we have cloud
solutions, mobile solutions andalso hardware devices.
We approached every one of themindividually.
So software as a service waslooked at as a product, the
(08:29):
mobile solution as a product,the hardware solutions as a
product and I don't want to getpicky about names because it's
justified in a sense, but whenwe approach it from a customer
perspective, they want theentire solution because
everything works together.
They want the entire solutionbecause everything works
together, and we saw it ondifferent features that just
because the mobile team isfinished doesn't mean the
(08:50):
feature is done, Because theremight be other teams who need to
do something, and there thiskind of Spotify model, which is
really driven by autonomy, wassomething that we could not like
.
We were not able to create thismuch autonomy, even with
domain-driven design, which wasone way to approach it, that at
least the software as a servicesolution doesn't have that many
(09:13):
dependencies, because we weregrowing over this journey that
I'm describing from like yearzero we're joined to like year
two and like initially doubled.
So now we're close to 100people and like round about 12
teams.
So autonomy is still important,but we also realized our system
(09:34):
, our organization, doesn'tnecessarily need to optimize for
autonomy as much as the Spotifymodel, so I think that was why
we questioned it.
And this ecosystem approach wasreally based on a lot of
different concepts.
So I don't want to say that Ididn't invent anything, but it's
inspired by less theory ofconstraints, lean principles and
(09:56):
really trying to embed thiskind of system thinking in our
approach and trying to identifywhen we think about a feature
approach.
And try to identify when wethink about a feature, what does
it really mean from a customerperspective?
Do we need other teams?
So this means we cannot onlyplan in the mobile part, but we
need an ecosystem approach wherewe plan there first and zero
(10:17):
constraints has something that Icall full kitting, which means
you prepare like everything.
You need to know that a workitem can flow through your value
stream without beinginterrupted.
That's what you're trying tocreate.
Obviously, this will not workthe first time and everything.
Every reason that you'regetting blocked.
You should write it down andtry to embed this in your kind
(10:37):
of full kitting list.
But that proved really valuablein reducing some of the wait
time.
Maybe one last example.
Speaker 1 (10:44):
Sorry to interrupt you, but what about that?
Because you mentioned thatthere was a matrix-style
organization that kind of hadbeen embedded in there, that you
were, I guess you assumed that,and so how were you breaking
down those dependencies to moveaway from having these handoffs,
so to speak?
Speaker 2 (11:07):
to move away from having these handoffs, so to
speak.
So I think that for now it'snot completely about just
removing dependencies, becausewe think about experimenting
there more, but for now we haveclearly embedded teams that work
on the embedded devices and sowe don't have like a
cross-function team in thatsense that stretches across
different technical, technicaldomains.
(11:27):
So we still have thesedependencies.
They are not that many likethat it's the main thing we want
to get rid of.
Like it's not the mainconstraint.
What we were witnessing is morethat because everything was
planned individually like if youhave a product manager for web
and a product separate productmanager, if you have a product
manager for web and a separateproduct manager for mobile and a
product manager for thehardware device, they are not
(11:49):
necessarily incentivized toprioritize a feature that
another product manager, anotherproduct owner needs to say oh,
that moves up into the backlog.
So there we use one thing fromless which says and it's maybe
not also in Scrum but you haveone product backlog per product.
So ecosystem is the product.
(12:10):
It means we should have oneproduct backlog.
So this means we need some wayof visualizing the work for the
ecosystem and prioritizing it atthe start and that was the
example I wanted to get into.
What we can see, and it's alittle bit of a made-up example,
but a mobile team starts afeature and then realizing, oh,
(12:32):
we need the web team.
They go to the web team, say weneed you, when do you have time
?
They say, oh, we're working onsomething we.
We can start this in two weeks.
That's like a good scenario.
So what does the other team do?
Because mainly organizationsdon't like idle time, which is
another thing we could get intowhy this is bad, but usually
organizations don't like idletime, so the mobile team would
(12:54):
most likely start new work andthen wait for the other item
that is still like in progressuntil the web team gets to that.
And in the best case scenariothey just do their work and then
everyone can continue.
But the more realistic scenariois that they have questions and
then you need to refine it,potentially with them.
But you also started somethingelse that also needs your
(13:16):
attention and then suddenlyyou're having a split focus and
from there on you're potentiallyin a bad multitasking situation
that can spiral out of control.
So what you're doing there toalso approach from a lean
perspective, you cannot limityour work in progress, because
each team might, by accident,trigger more work in another
team.
(13:36):
So that's why we try to move itout of the team level and bring
it to the ecosystem level, andI think that was really this
kind of next iteration that alsomade us then abandon the
Spotify model and the names.
Speaker 1 (13:53):
So I'm curious to know did you have a WIP limit at
the ecosystem level?
Speaker 2 (13:58):
So I think we're using different things there and
that's maybe also somethingwhere I'm a little bit biased.
I am a huge bottom-up guy, sothis means also especially my
kind of where I started in thescrum master role.
I started with something, myteam experiment.
If it works, let's roll it out,and that can make you sometimes
slow.
So, um, you need to mix it withuh, with top down, yeah, and
(14:22):
the short answer is yes.
The slightly longer answer isthe first problem we encountered
was there is no shared languagehow we talk about work.
Like it's really hard to limitwork when everyone has a
completely differentunderstanding about it.
And I know that's right nowabstract.
But just to give like a reallybasic example, right out of Jira
(14:43):
Epic, when we ask thesedifferent teams what Epic meant,
we get different answers.
For some, an Epic was it's apiece of customer value, like an
independent thing that we couldrelease and the customer gains
something from it.
For other teams, it was like wewere seeing implementation
Epics, testing Epics and so on,so like a kind of waterfall-ish
(15:05):
breakdown into Word, which isanother problem entirely, but
still that's how they thoughtabout work.
Another team was using epicsjust to like store work.
So they had.
We had as an example, wediscovered like a technical
depth epic, which was like aimmortal, because you would just
(15:25):
whenever you found something,it was like, oh, we should fix
this event At one point you, youjust add it into this
tech-to-concept epic and it waslike a container of work that
you would always pull stuff out.
And from all of these versionswe can debate what is right and
wrong and how you should use it,and that can be an important
conversation.
But the reality was, well, wedon't have a common agreement.
Everyone uses the same word buthas a different meaning there.
(15:54):
So that's where we try to say,well, maybe let's and I know
some people don't like it butlet's standardize how we talk
about work and how we thinkabout work.
And I think that was the firstkind of key step we had to take
in order to be able to limitthis ecosystem, and that was
like a crucial step.
But then, yes, we moved to someway of limiting the ecosystem.
It's a little bit harder toexplain there because it's not
as straightforward that you justhave a limit of four features
(16:15):
can be in the ecosystem.
It's a little bit more complexthere.
Speaker 1 (16:20):
So I often say that life isn't black and white.
Many times it's some shade ofgray in the middle.
So you usually can't go fromall the way from one extreme to
the left to an exact oppositeextreme on the right.
So to give full, 100%, totalautonomy to the teams to let
(16:41):
them do whatever they want to do, I think everybody would agree
that that system is probablygoing to fall apart.
They're all off, kind of doingtheir own little missions, but
at the same time, if you go allthe way on the other end of the
spectrum and say we're going tostandardize everything and this
is how the process is across theecosystem and we're going to
(17:01):
spell it out to a T, I think youprobably wouldn't have many
developers left right.
If that was the case, theywould be so frustrated with
having to be told exactly notjust what to do but how to do it
.
So it's how do you define thatmiddle piece to negotiate, to
find the sweet spot?
And so I'm curious to know how,what that process was like for
(17:23):
the, for the teams.
I'm sure you got some pushbackon some ideas, right.
Speaker 2 (17:27):
Yeah, and maybe also as a disclaimer, it's not that
we're fully there.
I think it's generally alsoreally hard to reach an end
state in these kind of productdevelopments.
It's always in motion.
But something that's helped tofind, or getting closer to, this
kind of sweet spot, as you'vecalled it.
What personally helped me wasthe theory of constraints,
(17:52):
because how I would describe itwithout going fully in depth
with theory of constraints isbecause it's a lot, but I think
it's kind of anti-dogmatic.
So it's not necessarily arguingthat you need to optimize for
autonomy or something else.
It's arguing try to understandyour system foremost and try to
(18:15):
then be flexible.
And I give you one example ofwhat I actually mean with that.
So I've described thisecosystem approach, at least on
a high level.
The complexity in this processlies is sometimes a feature is
purely in one technical domainand one team can handle it and
can more or less delivercustomer value and quickly
iterate on it.
But sometimes you might needall the teams in the ecosystem,
(18:40):
which makes it a little bitharder than to like.
You cannot approach it the sameway.
These two features, these twowords would be handled
completely separate.
And to get more specific, eventhere, if something is purely in
one team, you potentially don'tneed to have coordination
meetings about that because it'sin your team.
You kind of capture this withall your team meetings, be it a
(19:03):
daily or refinements and so on.
That all should be enough totackle that.
But if you have a featureacross an embedded domain, a
mobile domain and a web domain,individual team refinements will
not get you there.
What helped us to find the sweetspot is again pushing this
planning up front and sayinglet's agree on priorities and
(19:23):
what we have to do first on thisecosystem level, let's apply
this for-kitting approach, whichmeans answering the basic
question which teams do we needfor that?
Like, we have a customerproblem and we want to solve,
which teams do we need?
We will not always be right andthat's also not the goal, but
for a lot of features we canactually tell which teams will
(19:44):
have to do something.
We cannot necessarily alwaystell how and what exactly they
have to do, but we can tell theyhave to do something.
We cannot necessarily alwaystell how and what exactly they
have to do, but we can tell theyhave to do something.
And if we figure that out, thisalso means they should have
potentially some shared planningsessions, and the goal
obviously, is that we can goback into our individual teams
and then go back to autonomy andwe just do our stuff, but we
(20:05):
cannot start there.
So, to recap it we just do ourstuff, but we cannot start there
.
So, to recap it, we just didn'ttry to say, oh, we want to
optimize for one thing, be itautonomy or be it 100%
predictability.
We said let's move thisplanning of work really upfront,
move it on the ecosystem level,so out of the team level, let's
agree on priorities here andwhen we do our full kitting and
(20:29):
understand which teams we need,this kind of dictates how we
approach the work.
So if it's more dependencies,we plan it together, that we can
understand the nature of thedependency and how we want to
approach this work.
We might have some kind ofshared refinements and some kind
of coordination meetings aroundthis.
If something is purely in oneteam, it's not part of this.
(20:54):
Ecosystem coordination meetingsas an example, because no other
people need to hear about it.
So that's one example how wetry to be anti-dogmatic and not
saying, oh, but our frameworkwants us that we do this and do
step B, and I think that wasreally helpful.
Speaker 1 (21:11):
Customers don't care what framework you use, right?
Speaker 2 (21:14):
Yes, and I think also what we have to like.
I can't be really specific here, but these teams work also in
different processes right now.
So our embedded teams were morein a waterfall-ish process,
which we may want to change.
But I also want to be honestthat the main problem we're
(21:35):
seeing right now is not thatthey're doing waterfall, that
it's really not connected tothat.
The main issue we were facingis that priorities were set on
the team level, not theecosystem level.
You might want to change theprocess and adapt it, but for us
, it was really just helpful insaying we don't really care how
you work, we can figure this out.
Just let's get into onehigh-level shared process and
(21:58):
everything else will follow fromthere, and that also, in my
opinion, is really good tocreate buy-in, because we're not
coming like the all-knowinggods and being graceful to them
that we're finally payingattention to them and now they
need to work like us.
It's more like a sharedlearning experience, and that's
how I in general like toapproach it, because I don't
(22:20):
know how to do good embeddeddevelopment, being completely
honest there.
So I don't want to dictate howthey work, but I want to figure
together with them out what areour problems and how can we fix
them?
Speaker 1 (22:33):
So I want to talk to you just a second and get your
thoughts on this, because thisis a situation that I've
encountered in the past.
And so the situation that wewere in was we had multiple
teams and a team was assigned toa product and they knew that
product, they knew how tosupport it, they knew everything
about it because that's whattheir specialty was.
(22:53):
But then some products justlike okay, for the next two
quarters, we really need to dialback on this product.
We're not getting the salesfrom it.
Customers just aren't using itor they're happy with where they
are.
Where they really need is inthis other product over here,
Like maybe your software is aservice solution, for instance.
(23:14):
That's where we need to put ourenergy.
So what the ask is from peoplethat aren't in the software
development side is well, whycan't you just move the other?
I'm giving air quotes resources, I hate that term, but why
can't we just move resourcesfrom one team to another?
So instead of having 10 on oneteam and 10 on the other, let's
just put eight on one and two onthe other, and that way we can
(23:37):
make more progress, and theteams would really have a heart
attack because they're like I'venever worked in this system
before, so it's going to take mea long time to ramp up.
So that was another problem forus to solve of getting ahead of
the game and doing some crosstraining and making sure that
people did have that big pictureview of the ecosystem, like you
talked about it.
But have you encounteredsituations like that and how did
(24:00):
you approach those Max whereyou were being asked to shift
the teams around?
Speaker 2 (24:06):
I would say we don't have this problem super severely
, that we need to figure it out.
I think what happens sometimesif we're saying one product, we
want to dial it a little bitback, that we're saying why
don't we just have one or twopeople from this team go to
another team where we definitelyneed what there's like a lot of
(24:27):
more work coming up there,because we assume that's where
the real value lies.
So I think there we have someflexibility.
It's not necessarily that it'sright now on feature level,
because then also from a budgetperspective, these people would
then be added into like asresources and be then part of
(24:47):
this new team and don'tnecessarily would switch around
that soonish again.
But what I'm trying to saywe're we're not really that high
in fluctuation, so it happenssometimes and then we can
reasonably figure it out.
But there it was not enoughpain that we need to say, well,
let's maybe look at, look at forlack of a better word for a
process how can we figure thisout and switch people around and
(25:10):
then train them?
This hasn't been the mainproblem, however.
The other part of my answerwould be what is really valuable
in, for example, an ecosystem,because it can still happen
inside this ecosystem.
That we're saying for feature Bthat is now upcoming, we see
80% of the work on the embeddedteam and the embedded team might
(25:32):
be four people, while the restof the other software teams, be
it mobile and cloud, might be 40.
This can, like this is animportant thing to be aware of,
that.
Well, maybe our constraint itfor that feature might be
embedded.
Why this is important is, againfrom a theory of constraints
(25:53):
approach.
If you want to improve yoursystem performance, you need to
aim at the constraints.
So you need to first of all andI know sounds stupid, but know
where your constraint is.
And that's not as easy toanswer Because, coming back to
our journey, where we were whenwe planned in the individual
teams, if every team is workingon like 100%, you have so much
(26:17):
work, especially in like aknowledge work, that you don't
necessarily see the constraintthat easily, see the constraint
that easily.
So you need to really bethoughtful about this and do
this kind of full kitting thatI've mentioned earlier that you
are able to tell where is ourconstraint.
Because even in our ecosystemthe constraint moves depending
(26:39):
on the work, on the nature ofthe work.
So it's not like that.
We can say, oh, the constraintis always there and either we
want to keep it there or we wantto move it to a specific.
So it's not like that.
We can say, oh, the cost rangeis always there and either we
want to keep it there or we wantto move it to a specific place
because it's moving.
So you need to build also yourkind of signals in that tells
you where is it moving towardsto, because if it's not embedded
anymore and now it's cloud, youpotentially want to focus your
improvements there.
(27:00):
That might be hiring morepeople.
But finally, answer yourquestion.
What can be really helpful tounderstand is idle time is not
an enemy.
Not necessarily, because alsofrom the constraint, the theory
of constraints approach, theonly thing that should work at
100% of its capacity is toconstraint.
So in our example, if embeddedis to constraint, they should
(27:24):
really work at their optimalcapacity.
All the other teams, if theyare idle for this specific
project or feature, it doesn'tmatter that much, like it would
matter if it's so severe thatthe constraint suddenly moves
really somewhere else.
But this idle time you could intheory think about, can we use
this idle time Like either theyjust start work that doesn't
(27:45):
need the embedded team, so theyjust do other work.
That's one way to approach it.
But you can also say is there away that we can help out the
embedded people?
It's not necessarily aboutmaking a mobile engineer become
an embedded engineer, but isthere some work we can help with
?
It might be some sort oftesting, system level
verification or other things,and it can be important to raise
(28:07):
these questions.
So that would be my answer toyour kind of questions.
At first we didn't completelyhave this problem, but something
like theory of constraints canreally help you to focus.
That you understand.
Do we even have this problem?
Should we even focus onincreasing, like hiring more
mobile engineers, because maybeyour constraint's not there and
(28:28):
it would not really matter.
Speaker 1 (28:30):
Okay, Max.
So we talked about starting offat the Spotify model.
Then you moved on from that andyou started taking some things
from Agile, from Lean, fromTheory of Constraints.
Bring us up to where you aretoday.
Speaker 2 (28:44):
So one thing that I have mentioned and that becomes
important right now thatSafetyio is really
engineering-centric.
We're part of a biggercorporation where this ecosystem
is really important andSafetyio it's purely engineering
leadership.
For a time, even the productowners, as we called them, were
(29:06):
part of engineering.
That's not necessarily bad, butyou're hitting a glass ceiling
because you're in your agilebubble and everyone is there,
and then you have the rest ofthe business who are on another
island, it feels like.
So I think what we startedthere to give it a name was
trying to use these principlesfrom the product operation model
(29:27):
, like framed by Martin Kagan,and saying we should involve the
entire business and try toexplain them why we work like
this and why we can leveragethis and also be then more
customer-centric, Because withthis high of engineering focus,
it has a lot of benefits.
(29:47):
But it can also sometimes meanthat you're losing a little bit
of customer contact In the worstcase also getting into this
kind of feature factory set thatyou can see you don't need to
be engineering-driven for that.
A lot of marketing-drivencompanies achieve that, but I
think that is where we werestuck.
We got to this ecosystem leveland it helped a lot, but we
(30:09):
still had like different partsof the organization, like sales
and product marketing, that werereally far away from us and I
think, on discerning where weare right now in getting like
embedding or implementing theseproduct operational principles,
this helps us right now of likebridging this gap.
Speaker 1 (30:30):
That's interesting.
So what was the biggestimprovement within the product
operation model that you feellike improved the way that you
worked.
Speaker 2 (30:41):
I think it depends how you want to look at it.
Something we've done on anecosystem level also was putting
way more emphasis on goals.
People can argue you don'tnecessarily need a product
operation model for that andthat's fair.
But that's like a practice wedid.
We're implementing OKRs.
(31:05):
But if you go not just lookingat practices but more like also
the principles, I think theproduct model kind of forced
everyone to be more outcomefocused so that you actually
understand oh, that's why wecould use something like okrs,
because you can also usedifferent ways of think about
outcomes and ways to measurethem.
But suddenly this is was drivenby different kind of
departments for lack of a betterword in this organization Like
(31:29):
product marketing is now waycloser to the engineering teams,
making sure that we're settinggoals in collaboration and
having this kind of transparencyon why we're doing this and the
need for it.
And I think that is this kindof biggest improvement of saying
, well, we were on our islandfor a while, but maybe let's try
(31:51):
to leave it and go back intoour big corporation and seeing
where we can align our processes.
Speaker 1 (31:59):
Did you ever have to have a conversation?
And I'm asking I'm not tellingIf anybody that knows me, that's
a famous tagline that I that Ilike to use to delineate.
So I'm not telling this, I'mreally asking but did you, did
you have to, or someone have to,have a communication with the
engineers to say we understandthat well-engineered software is
(32:21):
very important, but we'reasking you to do more.
The solution that we're notlooking for, or the goal I
should say, but we're asking youto do more.
The solution that we're notlooking for, or the goal I
should say that we're notlooking for, is wonderfully
engineered pieces of software.
It's meeting business outcomesfor real users.
Did you have any conversationslike that where you told them
(32:41):
what you're doing is important?
We just need to expand out ofthat.
Speaker 2 (32:46):
So I think there yes, I think we obviously talked
about why we want to do theproduct model and we had
different reactions across thecompany, like some people said,
oh, that's what we always wantedto do.
And then I reacted with, oh,that's great, we're finally
doing it.
Or like, oh, we're doing thisright now and always wanted to
do it's just a new name.
(33:06):
So we had these different kindof reactions.
I think what in the productmodel, but also before, we
really tried also from like afrom management, for lack of a
better word to help people tounderstand.
You're not necessarily herejust to create code.
We want to understand are weactually making a difference?
(33:27):
In order for that, we need towork empirical.
So this means we need to havesome sort of metrics that we're
inspecting to see if we'remaking progress towards an
objective.
If we want to do that, we needto understand the business world
, because for some stuff, youcan maybe look at some
performance metrics, and that'salso important.
If you really want tounderstand, if you're changing
(33:48):
customer behavior and then alsomaking an impact on your own
business, you need to bridgethese gaps.
And I didn't think people likewe're a big company, so I cannot
say that everyone loves thischange.
But in our setups we we arestill leveraging, like the, the
basic scrum setup of having likea product manager, a
cross-functional team, whoeverthey need, their developers, qas
(34:13):
and design, and we always tryto say we, we want to have like
close collaboration.
If you don't know how, that'salso fair.
Like, if it's really a problemthat we don't know how to work
with design, it's a fair point.
Like that's also fair.
If it's really a problem thatwe don't know how to work with
design, it's a fair point.
That's why we're on thisjourney and want to use this
principle from a product model.
Then let's figure it out andlet's try stuff.
(34:35):
So it's answering a little bit,but I think a crucial step was
from also engineering leadership, saying you're not just here to
write code.
We still care a lot abouttechnical excellence and pushing
a lot of there.
But you cannot just opt out andsay, oh, I don't care about how
we set up goals and I don't careabout the goals, I just want to
(34:57):
do something.
We will not get rid of you.
It's an individual.
If they stand by that, that'sfine.
Like it's.
If it's an individual if theystand by that, that's fine.
But we also want to be clearthat in like a career ladder
that we're having, then you canonly reach a certain point.
Like if you then want to climbup to the next rank at one point
, you need to then also embracethis kind of change.
(35:20):
But really, for now at least,what I experiencing the teams
are really open to that andagain, some are positive, saying
we wanted to do this always.
Now we finally get the chanceto do it.
And for the people who said wealways did it, it's just a new
name, we just try to tell themthat that's also not completely
accurate.
Like we need to be honest withourselves that because of our
(35:41):
engineering focus we had kind ofreached the glass ceiling and
it's not helpful to just say, oh, we always wanted to do it like
that.
Now a new word comes, let'sembrace it.
Speaker 1 (35:54):
Well, max, you term this as a journey, and I think
that's very aptly named, becauseit's not a destination.
It's a journey that's ongoing,so you continue to evolve.
I'm anxious to hear how yourjourney progresses.
So thank you for taking us onthis journey from a high level.
About safety IO.
It's been very interesting tohear.
I always enjoy talking with you.
(36:16):
If our listeners out there wantto get in touch with you,
what's the best way for them todo that?
Speaker 2 (36:21):
Mainly LinkedIn.
I'm not really a huge socialmedia guy, so if you want to
find me, linkedin is probablyyour best chance.
Speaker 1 (36:29):
All righty, we'll put a link to your profile in the
show notes to make it easy foreverybody.
Max, really appreciate youcoming on the show today, buddy,
it's been real helpful.
Speaker 2 (36:38):
Thank you very much for having me Again.
I really enjoyed ourconversation.
Speaker 1 (36:42):
Me as well.
All right, everybody.
That brings another end to thisepisode of the Agile Within.
We'll see everybody next time.
Thanks for joining us foranother episode of the Agile
Within.
If you haven't already, pleasejoin our LinkedIn page to stay
(37:03):
in touch.
Just search for the AgileWithin and please spread the
word with your friends andcolleagues Until next time.
This has been your host, markMetz.
Popular Podcasts
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
On Purpose with Jay Shetty
I’m Jay Shetty host of On Purpose the worlds #1 Mental Health podcast and I’m so grateful you found us. I started this podcast 5 years ago to invite you into conversations and workshops that are designed to help make you happier, healthier and more healed. I believe that when you (yes you) feel seen, heard and understood you’re able to deal with relationship struggles, work challenges and life’s ups and downs with more ease and grace. I interview experts, celebrities, thought leaders and athletes so that we can grow our mindset, build better habits and uncover a side of them we’ve never seen before. New episodes every Monday and Friday. Your support means the world to me and I don’t take it for granted — click the follow button and leave a review to help us spread the love with On Purpose. I can’t wait for you to listen to your first or 500th episode!