Scrum in my opinion is a pure business practice.
Head Child kind of became a micromanagement tool product.
Thinks its own way. Technology thinks the other way.
Sometimes they balance each other, sometimes they fight each
other. When the project was a failure,
it was most of the time not the tech that was failing, but that
we built the wrong thing. You really need to differentiate
between problems and solutions because a lot of teams are
skipping this step and coming up as a solution too early.
If you want to have an empowered team and you only have
introverted engineers who only want to work on their tickets,
then that's the the strong team. We as an industry, we are
working still like on the conveyor belt.
And the conveyor belt is a useful metaphor for industry and
for manufacturing, but it's not a very good metaphor for
producing software. In a lot of traditional
settings, they see writing code as the manufacturing line, but
the fundamental misunderstanding is that building software is the
design process. We are not implementing A solved
problem, we are solving the problems, so we are making
creative decisions every hour of the day.
The rise of AI is a very good argument for engineers.
I asked them what are they worth in 10 years that you can write
JavaScript? I don't think they're not worth
much in 10 years. So the main topic of our
discussion is move fast and break silos.
What are some of the key practices?
Everything is centered around how we slice the work and how we
are aligning the teams around this work.
What I mean was how the work is sliced.
It's for me about how. Hello everyone, welcome back to
another new episode of the Techni General Podcast.
Today I have with me Klaus Breyer.
So he's kind of like experienced CPTO, right?
I haven't heard about the term CPTO before.
I guess it's something that maybe we can also talk about.
So Klaus, welcome to the show. I'm really looking forward to
discuss the topics that we plan to talk about because it's
something about, you know, highly functional and performing
teams, engineering teams, right? So welcome to the show.
Yes, it's a pleasure. It's an honor to be here.
Klaus, maybe in the beginning, I want you to share a little bit
more about yourself, right? If you can share career turning
points that you think we can learn from you, I think that
will be great. Yes, sure.
So I studied software engineering and directly
afterwards I Co founded my first company.
It was a digital agency and I was the CTO.
This was already 15 years ago, so when the year 2010 now.
And from the beginning I was puzzled or fascinated with the
challenge of how engineers and designers could work together.
At the beginning I thought it was a tool problem then not
using the right tools for better handovers and so on.
But yeah, because this was not something that was teach at
university because we were all just engineers.
So I need to figure it out during my first company and
luckily, and this is a good thing, starting out with an
agency in the career you have a lot of projects or you every
time you have the possibility to start over.
So it's a good start into the career.
In general. I think I would recommend it
because with every new project you can improve what you have
already learned. After I exited this agency, I
founded my next startup. It was AB2B Marketplace SARS,
where brands can do campaigns with influencers.
And this time I was not only CTO but only CPO Chief Product
Officer as well. Because in my first company I
learned when the project was a failure, it was most of the time
not the tech that was failing, but that we built the wrong
thing. So in my second company, I was
very motivated to also step into this product role and learn more
skills and learn how to lead product manager.
So I moved up the value chain, so to say a little bit and
learning more of the product skills.
And as you said, CPTO, it's not common nowadays, but I feel it
gets more and more popular, especially in the software as a
service world where product intake is very closely related.
And I think having a separate CTO and CPO could make sense in
some other cases where you need a lot of industry knowledge, for
example. But most of the B2B says, in my
opinion, it really makes sense to combine those skills.
And yeah, I, I did the startup also for a couple of years and
we exited the startup. And at the moment for the last
couple of years, I'm doing a mix of interim management, some
consulting and interim management.
Since I'm basically infusing my startup spirit into corporate at
the moment, like building startups inside of corporate and
see a whole set of different challenges again.
Because now it's also talking about other stakeholders from a
bigger business about the tech. And ultimately it's also owning
the strategy for the whole business unit and not just being
one of the Co founders. So I moved up the value chain
once more, starting from tech, ending ours responsible for
whole business units. Thank you for sharing such a
unique story, right? So I'm a little bit intrigued by
this CPTO role because it's not common yet, right?
So I think in your experience, having to play multiple roles,
CTOCPO and CPTO, right? And even move even higher up,
right, What do you think are the key critical skills required if
you really want to become one person handling both product and
technology? Because in many places it is
like a duality, right? Product thinks it's own way,
technology thinks the other way. Sometimes they balance each
other, sometimes they fight each other.
But if you're one person, what are the some of the critical key
skills do you think? When interestingly, if you look
back 1020 years ago, a lot of what is now product was part of
technology and part of the responsibility of the CTO.
But then I think of the last 10-15 years we had this, I call
it product movement, where the product became the special
discipline. So maybe even somebody at the
moment having the title CTO could also have the
responsibility for products. So it's at the end just it's
just a title game. But skills wise, what's
important is I think you need to really understand how you need
to understand the principles of product management so that you
are trying to find out the problem before you build a
solution. You also need to know how to
handle those people who are better in those skills than you
are. Because if you have a good
product manager in your team, even the head of product and a
couple of product managers, then they are, they know the
interview techniques better than you are.
But at the end, you are responsible of bringing
everybody together so that everybody can work with the
other departments in the correct way.
And at the end, sometimes it's just a sanity check on being a
sparrings partner for those kind of people in the team.
If it really makes sense to go in this direction because the
interview techniques and the product management techniques,
they should know them. But if it really makes sense in
the context you as a CPTO, you are the the ultimate sparrings
partner. Yeah.
So sometimes also in my view, right, So looking at all the
CPOCTO that I have seen in my career, right, I can see that
product tends to be very optimistic, you know?
Yeah, we can do this. You know, there's so many
things, good vision, you know, very far ahead and sometimes the
technology is the pessimistic 1. So being a little bit more
cautious thinking about how to scale this, secure this and
things like that. Now if you are into one person,
so to speak, right, how do you see this so-called extremes?
Are you sometimes juggling between being optimistic versus
pessimistic, or some tips and tricks that you have done so far
in your role? I feel it's like a pendulum that
swings back and forth because sometimes you are stagnating on
the product side and you are working with the product people
more to really find out the what is the right, what is the ADL
customer profile or problems? Do they have like to really find
out those kind of things? And then on the other, then
there are other phases where you're tackling tech depth
because this is the biggest issue because we cannot scale
with the tech that we're having. So for me, it's it's like a
pendulum. I need to decide where I
focusing at every moment or how I bring it down to a joint
strategy at the end that it makes sense for both worlds, the
challenges that the company's facing.
Right. So I think the art is the
playing the pendulum part, right?
So where you can actually juggle between two different heads and
make sure you keep sanity of yourself, I guess.
So the main topic of our discussion is this thing or term
you coin, you know, move fast and break silos.
It's very similar to, you know, the Facebook motto, move fast
and break things, except that, yeah, except that you put break
silos. So maybe tell us a little bit of
the background. How do you come up with this
motto? So as I said, I'm always since
always fascinated with the challenge of how people are work
together because I'm basically responsible to how people are
working together since the early days of my career.
And so I saw a lot of tools, learned a lot of techniques and
tried out a lot of techniques. And I just realized that we as
an industry are at an interesting point at the moment
because if you look back like to let's look back over 100 years
and let's look back to Henry Ford.
He was a successful car manufacturer, but he was not
like a multinational corporation.
And if you look at the manufacturing process from Ford
back then, the cars were standing at once at one place
and the workers were moving around the cars.
They were building 1 car on one place and it took 12 hours to
build a single car. And as we all knew then Henry
Ford leveraged the conveyor belts for the manufacturing
process and then the cars came to the workers and this caused
that the workers can specialized better on a single task.
And then Henry Ford could produce 8 cars in 12 hours
instead of 1 car. And Ford, he was a very smart
guy because he had not more capital.
The conveyor belt was already invented by other industries,
but it just brought it together and leveraged it for mass
production. And I think this is the
situation where we are right now with product development.
There are a lot of tools out there already, but you need to
know the tools, you need to know that they are existing.
You need to maybe have a little bit of experience with them to
apply them to your situation. And this was kind of my
motivation to work on this topic because I really see a lot of
tools out there. I really see a lot of misaligned
teams in my direct work as an interim manager or if I'm
advising a start up. I think we as an industry, we
are working still like on the conveyor belt.
And the conveyor belt is a useful metaphor for industry and
for manufacturing, but it's not a very good metaphor for
producing software because with a conveyor belt software
development process, you end up in waterfall because you have
one step after the other and you have silos on all parts.
And I think part of the problem is that in a lot of traditional
settings, they see writing code as the manufacturing line.
It's just making it happen. Somebody other already had the
idea upfront, some stakeholder, some product owner, somebody had
already idea. But I think the fundamental
misunderstanding is here that building software is the design
process. Because as a software engineers
we are not implementing A solved problem.
We are solving the problems. So we are making creative
decisions every hour of the day. So I think we need revolution
like the industrial revolution that was kick started by Henry
Ford, but I think it's going into the different direction
because it's going into the directions to how we are making
decisions and who is making the decisions in what context and
and how we are aligning those things.
Yeah. So I think you brought up a very
interesting point, right, Because I can see even in the
industry, right, in the software development industry, so to
speak, so many people still treat software development as
like manufacturing process or assembly line process, right,
where they think producing program is like producing
widgets, so to speak, right. Or maybe car parts in your.
Analogy. Right.
But I think in many, many literature and maybe HR
practices and all that, it seems that this kind of process
actually is not optimal simply because, you know, there are a
lot of ways, a lot of inefficiencies in the process.
So maybe if you can tell us why the difference of software if
you compare to the manufacturing process, because many people
think it's an engineering thing, right?
So it should work similar to manufacturing process.
So maybe what do you think is the biggest difference?
Yeah, the biggest difference is that the software engineers,
they need to find out how they are solving the problem.
Because if you are producing a WeChat or car part, somebody
else has already made the design and already the machines are in
place and the machines are configured and you just press a
button and then you you do something.
With software engineering, it's different.
You need to make decisions the whole day and you are part of
the design process and I think we should embrace this.
We should understand that the developers are part of the
design process and this means, like I will explain later, that
they are starting much earlier in the process, having a say in
what problems we are tackling, having a say in how the
solutions are are designed as well.
Yeah. So I think what you said is very
important, right, for all software engineers and also the
managers, right. So software engineering is
mostly making decisions and design almost all the time,
right? Because when we start the
software is simple, right? But as we grow in terms of maybe
business requirements and all that, you make a lot of changes
that you didn't foresee before in the very beginning, right?
And that's why you keep tweaking, refactoring, maybe
even migrating some parts of your software into something
new. So I think this is probably the
biggest difference against the manufacturing, right?
And if you, if you want to compare it with manufacturing,
then maybe the manufacturing part is the pure act of pressing
a key on the keyboard, like just writing the code.
And as we all know, just writing the code is the smallest part of
we as engineer what we are doing.
Most of the work is happening inside of the head while you try
to how to dissect the problem and so on.
And writing code, we probably will do less and less in the
future with say hi. So it's more and more important
that engineers are really used, leveraged in a way to solve
problems. How do you think you can
convince or maybe influence stakeholders management about
this thing where software engineering is mostly a decision
process rather than a production process, right?
So because this is something like AI would say a
misperception in many of the stakeholders mind.
And most of the time the stakeholders or senior
management of companies, they will have a feeling that
something is not working well with the development process
because they don't get what they were promised or they get it
later than it was promised to them.
So if you talk to externals or about internals as well, I think
nobody is really happy with their process and how they are
doing. And if you look at the
externals, they will see a lot of symptoms of what is going
wrong. And if you look at a lot of, if
you talk to the internals, they will come with a lot of reasons
to you why why staff is not working in the right way.
Yeah. So I think in many software
teams, definitely this is the thing that is happening, right?
And you also have a few things that you think are the problems
in the current status quo of software development practices,
right? Maybe if you can outline some of
the biggest ones that you think would be good to discuss today.
Yeah. I mean, if you started the agile
movement at the beginning, the coders, they had a vision when
they created this manifesto for Agile software development.
Individuals and interactions, working software, customer
collaboration, responding to change, those are all the right
values. But business historically
struggled with understanding engineers.
And so Scrum came up and Scrum, in my opinion, is a pure
business practice, like doing acceptance test, making small
releases, planning games and and so on.
Those are business practices. Those are not software
engineering practices per SE, but it was a tool for business
to make the engineers manageable in a way for them.
Then the result was that a child kind of became a micromanagement
tool because it was used for everything.
Product owners, they are receiving a lot of requests
every day. Some of the requests are urgent,
some of them are not urgent. But the urgent requests, at one
point they get into the backlog and then in the backlog,
suddenly they know they have an urgent request that is also
planned. And if you have other planned
work in the backlog, then your original work gets prioritised
down. And so you are never in a
position as a team where you can really commit to something
because all the urgent requests they are intermingled with what
you have already planned. So it's so it's really hard.
And the result is that the team is doing the trade-offs at the
very end because the time is running out and then you need to
do the trade-offs. But those trade-offs are maybe
not the best trade-offs. Such trade-offs, there could
have been better trade-offs if they would have done earlier on
a higher abstraction level and not just when time is running
out. This is part of my point here
that it's important to make the trade-offs early on with the
engineers and in the organization that is always
striving for efficiency. This causes a lot of people
working on their own and then you end up with a different
development and product organization because product and
engineering, they are optimizing for themselves to cope with the
pressure to cope with the efficiency.
But the problem often is the efficiency is only there because
it was not completely aligned at the beginning.
And then the time is running out and you need to be efficient and
then silos are created. China or ticket systems in
general are not the ultimate tool to help in such a high
pressure solution because developers are out of time.
They say, hey, stop, just create a ticket for me and then we
manage it via the backlog. So and then discuss a situation
where somebody is creating the ticket and somebody else is just
implementing the ticket. And this is for me the the
definition of a silo because you have a wall in between there.
You have not a process where there is a time and place for
new requirements and how you'll find those requirements.
In theory, a silo is a nice place to be because you could
work blissful a long 8 hours a day.
You're just working on tickets and you went into the next
ticket. But in reality, it's not like
that. You have a Kanban board with 10
columns, you have a QA, you have a UXQA, you have somebody else
need to green light something and so on.
And if something is falling through the cracks, the ticket
is going back to the developers. You need to context switch as a
developer and then you need to increase the font size or or
whatever you need to do. And then you put it back.
And it's not just the ticket workflow, it's also you are
interrupted all the time because we live in a world where your Co
workers cannot work on something without asking you constantly
for something. And I mean, even in theory, if
we assume that silos would be nice, it's not like that.
And AI will also not help us with this solution, not from the
communication side, not from the implementation side.
It makes product development even more complicated in my
opinion. Because now you need also to
bring AI to the table like machine learning engineers,
maybe in a separate department, data scientists and and also UX
user experience. You need to bring AI expertise
and user experience expertise together to make really great
product where the AI is really leveraged by the user
experience. Because if you do it
traditionally user experience, they don't know how to work with
AI tools where you have not a guaranteed response, where you
only have response and 5% of the case is the correct one or in
40% of the cases. So you need to bring even more
parties together. And This is why I think 1 needs
to fundamentally look at how teams are making decisions and
such continuously evolving systems.
And I'm here to share my mental model about how to achieve this.
Yeah, I think what you just mentioned, right, it happens in
many teams, right, When we say people practice Agile, which I
think I would say most teams would believe that they practice
Agile in some what in some shape or the others, right, Typically
Scrum, right, and Scrum Bun as well.
So I think the interesting part that you mentioned, it becomes
like a micromanagement tool because when it started, the
agile movement seems to be moving away from that
micromanagement, right? But these days, I think it
happens in many different teams, right?
Even the stand ups is more like a status updates where the
manager or the leaders keep asking about status and all
that. And I can.
See the micromanagement danger part there.
And ticketing is kind of like the practice in most software
engineering team. You create a ticket for your
product requirements, you hand it over to software development,
maybe tester, maybe a few other process right in the stages
before it gets deployed. So ticketing is like the main
collaboration or main communication channel, which I
think sometimes there could be a problem, so to speak, right?
And people don't talk to each other and they talk just through
tickets, right? So I think that also defeats.
Exactly. And I mean, there's a place for
ticket systems and in my opinion it's for support work or for
reactive work like we are calling it.
But feature development with ticket system at its core is not
a good idea, because you really removed the collaboration.
And there is. Yeah, and especially if the
problem itself is not well defined, right, The design is
not well defined. I think it's the communication
and you know, the back and forth, probably opinion sharing,
right, to come up with the perfect kind of like not
perfect, maybe a better design or better solution, right from
cross functional roles. So I think knowing about this
problem, right, the status quo, so many different things that
are not optimal. So tell us a little bit more
about your approach right in this move.
Things break silos. What are some of the key
practices that you want to advocate today?
Yeah, everything is centered around how we slice the work and
how we are aligning the teams around this work.
What I mean with how the work is sliced, it's for me about how
our objectives are defined, how we are slicing problems, how we
are slicing solutions and how are we slicing delivery.
So the first important thing is to understand that all four
things are different. Things like you have objectives
on the highest level, and then you really need to differentiate
between problems and solutions because a lot of teams are
skipping this step and coming up with a solution too early.
And then you also need to really think about how you are slicing
delivery. So slicing objectives, that's
the easiest rule in my opinion, because you can just have one
objective for a team. Like it's either an engagement,
it's growth, or it's monetization.
Like on the highest level, A-Team should only have one
engagement. Or like a unit where you have a
couple of teams, they should all work on the same objective.
And we really need to be clear, I'll be focusing this year or
this half year on engagement or on growth because this then
defines on what problems A-Team should be working on.
Yeah. So maybe let's go 1 by 1, maybe
objective and then development on that.
So maybe, you know, hearing what you say about slicing objective,
I think fundamentally this is one of the biggest problems in
many, you know, software engineering team or product
team, right is because there are so many objectives given maybe
sometimes from the top, sometimes it's from regulations
that come, you know, in the middle of the whatever quarterly
planning or annual planning, right.
So I think slicing it to work on just one objective probably is
kind of like impossible for many of the teams.
Or is there anything that you think maybe a change of mindset,
a change of perspective and change of priorities that could
actually allow team to actually focus on just one objective at a
particular time? So maybe from your experience,
share some practices. So when I talk about slicing
objectives, I mean I'm focusing on the strategic feature
development like what we have as we as a company have on the road
map to develop what to achieve our company goals.
If you have regulatory requirements and those kind of
things, I would try to manage this as what I call reactive
work. Like in a bigger setup, you can
always have a part of the bigger part of the team on strategic
feature development and then you have a smaller part of the team
working on reactive work. And it's just important that the
part of the team that is allocated to the strategic
feature development that they are really working on on
strategic features. And this ratio is something you
need to define in an engineering strategy.
At what point you are, do you have a lot of technical debt and
and so on. Yeah.
Yeah, thanks for clarifying that because I think it's very
important, right, If you want to be practical in you know,
slicing these objectives. So the ratio is something that
every team, every company has to define, right.
I think it's something that depends on the stage of the
company as well. Sometimes if you are still
product doing product development, right, you could
have more ratio of that versus the other reactive thing, right?
And sometimes it could change depending on the situation.
So let's move to the next slicing that you outline, right,
Which is slicing the problem which you know some people use.
You meant. I would maybe quickly, I goodly
would like to add that most of what I'm addressing here is
really towards feature development.
As I said, you need to have keeping the light on the part of
the team. You need to have some part of
the team responsible for directive work.
But all the other things that I have now that will now come,
they are mostly related to strategic feature development.
Yeah. Thanks for the addition of that.
So let's move on to the next slicing which you mentioned
slicing problem, right? And you mentioned.
Some problems. Yeah, in some teams they could
even skip this or they merge it into solutions straight away,
right? So why is it important to slice
the problems? Because I, I don't know
practically how would you do that?
The why for slicing the problems is you need a time and place
where you align with the senior leadership.
What problems are you tackling? And then interdisciplinary team
where an interdisciplinary for me means product design,
engineering, maybe machine learning, maybe some other
expertise. It's all in one team and they
should work as an empowered team on fulfilling this problem.
This is why it's very important to make this distinguished to
make this distinction because if you are starting with a solution
too early and you give the team 1/2 thoughts through a solution
and say no, now you do. Then the team has no way of
really they don't have a saying in what they are building and so
they are not responsible for it and they cannot really commit to
it. So they will then extend the
deadline because they have not really a saying in it and they
assume that it's given that it needs to be like this.
But in the most of the cases, on the one hand, it's not
completely thought through what really the problem is that we
are solving before you're giving something to the team that this
is 1 aspect. And as I said, the other aspect
is that the team needs to be part of the solution.
And really engineering as a first class citizen if you want,
is also part of defining the solution.
That's very important. And when we are slicing
problems, we are just focusing on what is the current context
of the user of the customer and what is our desired outcome.
Like this is really the core of the problem definition.
This is something I am I've taken from the Shape Up
methodology. Shape Up is the product
development process from Basecamp.
They open sourced it a couple of years ago and they are using
such a framing technique as well.
And this really helps for alignment with senior
leadership. And there's also a good
abstraction level of, of defining what are we doing in
the next couple of weeks? Because such a sliced problem
should also come with a certain appetite of how much you want to
invest. The appetite is also a concept
from Shape Up and this appetite is also a concept from shape up
and appetite basically is you have a fixed time box, but you
have a variable scope in the time box.
And if you bring those two things together, you have a
problem. You know what problem you want
to solve and you have a idea of how much time you want to spend
with this problem. It helps and it guides how the
implementing interdisciplinary team is then thinking about
solution. Because if you have a certain
problem and you say I want to invest six weeks for a solution,
then the team will end up with different solutions, then you
should say I want to invest one week with a solution.
And so you can use this problem definition together with the
appetite as a very good communication technique because
business stakeholders can say how much it's worth to them and
the team can say what they could then actually deliver for this.
Yeah, I like this, you know, breaking down into fixed
timeline and variable scope because in many different teams
it's always like top down, you know, we have, I don't know like
annual road map broken down into quarterly road map and the team
just delivered that, right. But actually if we come up with
a well defined problem that is sliced properly according to the
time that we are willing to spend maybe as a company or a
team, right, then we can come up with different solutions.
So I think that's a really novel thing, maybe for some people,
but I do really like how it is being done, yeah.
I mean, even if you're doing estimates, you end up with
variable time anyway because estimates are never correct.
So it's better to embrace this fact and work with a variable
scope instead because if your scope is flexible, you can
always guarantee quality. You can guarantee the cost and
the time that it takes. And so as software engineering
is in its nature, because it's a design process, as I said,
unpredictable, it's basically just the agreement between
senior leadership and the engineering organization.
You are now investing 6 weeks, 4 weeks, one week and giving your
best and solving this problem. And within this time box you are
flexible how you are solving the problem.
Right. So let's move on to the
solutions and delivery, right? So let's say given the team has
been given a fixed timeline and a well defined problem, so to
speak, right? So how would you slice, you
know, the solutioning and the delivery aspects?
It's important that you start with the most important thing
first, because if you want to end after your time box is over,
you need to be able to drop the pen and it needs to be
shippable. So you want to work on one scope
of the solution after the another and you want to start
with the most important scopes first so that you can always
like when we are doing a planning of how we are
approaching a feature development initiative, then
we're building a graph of scopes.
Like we have a handful or 10 scopes and we draw dependencies
and how we want to tackle them. And then a line, a cut off line,
we move it in from the back to the beginning.
And we always ask ourselves, can we cut the project at this point
and does it still make sense or is there something we have moved
further down that is really, really important?
And if you slice a solution in this way, you always make sure
that you need to slide the solution in a way that you can
always stop. Yeah.
So I think that is also kind of like novel, right for some
people because typically when you are given a requirement, you
will come up with the design such that you will just meet
whatever that is expected of you, right.
But I think this mental model that keep on moving the cutting
line, so to speak, right, So that you can deliver value in,
you know, the smallest shape as possible, I think that's also
important. While it's important that after
every scope that you delivered that it's tested and that it's
deployed, it could still be after a feature flag and
everything, but it's really important your your definition
of done for a scope. Because if you just implement
the scope and implement the scope and you move all the
testing to the end, then you can also not end after your time box
is over. So it's always thinking those
increments. And I really like the
granularity of problems, thinking in terms of weeks and
resources like 6 weeks, three people working on it because
it's a good level of granularity to align with the senior
leadership and the rest of the company.
And the level of scopes where you, let's say in six weeks you
have 8 scopes or something like this.
This is also a good granularity to work on one thing for a
couple of days and then finish it.
And after every scope, the team really needs to be in this
mindset of we need to finish the scope.
We need to implement everything that we have in mind, like
finish, we need to get it done to work on the next scope.
This is also an important part. A lot of the times the teams are
comparing what they could have done within the scope and then
they use too much time on the scope and it your plan that you
have at the beginning, it cuts delayed and delayed and delayed.
So you need to have a really sharp prioritization to finish
the scope and also what scopes we need to ship for the whole
initiative. So sometimes it also means you
need to trust the scopes. For example, I remember an
initiative we have planned to roughly build 3 features within
this initiative. And we thought, yeah, we make 3
very shallow features because we want to see how customer are
responding to it and then in later initiative make one or two
of them better. But then during this six weeks
initiative, in this time we had the product manager did a call
with the customer showing what we already had.
And then we realised, oh, it really does not make sense what
we have. And so we changed the scopes of
the whole initiative and decided we do two things well and not
three things pretty pretty shallow.
So if you work like this, you are really agile in a way that
you can adjust what you are doing and you can have real
customer feedback guiding you there.
Yeah. So I also like what you
mentioned earlier about, you know, slicing the work in terms
of weeks and resources, right. So weeks is kind of like small
enough that you can kind of like BHR rather than some teams
actually do it in quarterly planning, right.
So which is kind of like long. So slicing the work is one part
that you think is going to help a lot of teams.
The other aspect is actually aligning teams against this kind
of like work, right? So.
We have missed 1 aspect and this is the slicing of delivery.
But it's a short one I think because if you are, you have
sliced a solution that you start with the most important scopes
and so on and then you actually start working on it and working
on it means everybody is working on the same thing at the same
time. So it does not mean front end is
preparing something, back end is preparing something and then at
one point they are bringing it together.
No, it means everybody is working on the same thing.
Like the designer, the front end engineer, the back end engineer.
Let's say they first start with the overview table of a feature
and they all do the same thing at the same time.
And then they finish this table and then they start with the
edit functionality, and then they do the delete
functionality. And everybody's really working
on the same thing at the same time.
And this needs some adjustments to work like this to not only
chase efficiency, like I said at the beginning, but there's much
more chances for pairing up in this kind of setting, working on
the same thing. It's a lot of chances that front
ends learn something from back end and vice versa.
It's pretty hard for designers sometimes to work like this
because designers, they need to have a bigger picture, they need
to define the styles that they are using and so on.
So this is something that's sometimes a challenge if you
switch to this way of working and if you it's really strict,
this could be mitigated if you have a good component library
already and if you have a ripe major product.
If you don't have this, this situation, then you, I tend to
be a little bit loose here. So I allow the designers to
design a little bit more. And yeah, basically it's not me
allowing them. It's designers come up with the
idea that they need to design other parts of the product as
well of the initiative as well. To make the decisions now, but
we really try to say this is the personal workflow of the
designer. We don't need the whole team to
give feedback on everything. So because you don't want to end
up with 30 or 40 Figma screens and then all the developers are
implementing them at one point. I think for engineering is the
same. Sometimes you need to think
about the architecture a few steps further than what you're
at the moment are doing. But we really try and as a rule
of thumb and the teams that I have led that it's like 70 to
80% of the time is really spent together.
So the delivery is really sliced in a way that everybody is
working on the same thing at the same time.
Yeah. I think the key also when we
want to work that way, right, it's not to build the silos
within the team where you have specialization either like.
Exactly. You don't want to end up with a
lot of mini waterfalls, Yeah. Yeah.
So I think, yeah, try to avoid from that kind of practice where
you have specializations and silo within the team itself.
And it may be worse if you assign tickets to different
stages while you building the team.
Exactly. So slicing is 1 aspect that you
think can help, right? The other aspect is actually
aligning the team with this work, right?
So tell us a little bit more the importance of this alignment.
Yep. So I, I really like the
blueprint of empowered product teams here.
It's from Marty Kagan from the Silicon Valley Product Group.
And the idea is that you have one product team and the product
team has everything the team needs.
You have a product manager. Product manager is responsible
that the team is delivering value to the customer, but also
for the business viability, addressing the business
viability risk. This means the connection to go
to market like does it make sense what we're building to
what we are to the customers that we are acquiring.
And this is different from a product owner in a scrum
setting. A product owner is only somebody
who is writing tickets into a backlog.
Like a product manager comes with a certain skill set.
He or she needs to know interview techniques and you
really need to own this. This person is owning if the
team is really creating value. And then you have designers,
they are responsible for the usability risk and for the
experience. And then you have engineers, and
it should be insourced engineers, because you need to
have insourced engineers to really create this innovation
and really use them also for shaping the solution that is
built after the problem is defined.
So engineers are responsible for feasibility risk and for
delivery. And so you're basically building
the team with all the capabilities.
So you need to hire engineers that can address this
feasibility risk and you need to find the product manager that
can own the customer value and the business viability risk.
And then you give problems to the team or objectives to the
team basically. And then such a team is doing
the discovery of the problems and of the solutions that can
help achieving this objective and also the delivery.
So they should organise themselves and the level of
objectives is the right way of steering such a team.
Yeah, I find that this is the ideal thing that many teams want
to practice. But for whatever reasons, right,
in practice, many things are not running this way, right?
So for example, when we mentioned about empowered
product teams, right, I think still many teams are given
mandates from the stakeholders and management and maybe they're
just given, OK, this is the problem, here's what the
solutions that we think would work, just go ahead and deliver
it, right? And product managers become more
like a proxy rather than, you know, an empowered one, right,
that can come up with the solutions, maybe even thinking
about doing interviews, coming up with the well defined
problems and all that. So tell us, what do you think we
should do in order to kind of like align these teams practices
such that it becomes more empowered because it's, I think
it's still pretty rare in many software engineering teams.
Yeah. If you look at the problem,
you're on the one side, you have the skills of the individuals,
that the individuals need to have the skills.
And the other part is that you as a technical leader create the
organization for it. And so it's really two parts.
And the part with the, the part that you as a, as a tech leader
can do yourself is like aligning the organization around it.
Here I always like to start with defining the problems, because
if you start with the problem definition, you can do it on
your own or you can, let's say the product, you have a product
manager and he's, he knows what it means to be an empowered
product team, but you're struggling with the rest of the
organization. They give requirements and so
on. Then I feel it's the
responsibility for the technical leader to create the process
that the team can work as an empowered team.
And this means if stakeholders are coming with concrete
requirements like with solutions, you take them and you
rephrase them has problems. And then you go back to your
stakeholders and you say, are those the problems that you want
to address? Just making sure like it's just
ensuring and it's not even you can really do this without being
offensive. Like you just say we have a new
product, we have a new product process.
We want to focus on the problems 1st.
And then if you are doing the work for them, but then
afterwards you discuss it with them, then sometimes they really
they want to make sure that the problems are correct.
So they will give you feedback and help you with the product
definitions. And then you slowly can educate
them that this is your process, but you need to define the
process. And but this is a good starting
point. And Yep, the the other solution
is where the other situation is, where the stakeholders are,
whether it's not an issue with the stakeholders, but the team
is not willing to work in this way or not capable.
And I mean, here you need to invest in the skills of the
people or maybe you need to switch people.
Because if you have, if you want to have an empowered team and
you only have introverted engineers who only want to work
on their tickets, then that's the wrong team.
Maybe you can educate some of them.
And for me, the rise of AI is a very good argument for engineers
because their skills of writing JavaScript or Go or whatever.
I asked them what are they worth in 10 years that you can write
JavaScript. I I don't think they're, they're
not worth much in 10 years, maybe not even in five years,
maybe even not next year, I don't know.
But at one point your skills of writing code are not relevant
anymore. I think that is safe to say at
the moment and this is my main motivation for the engineers to
bring them further at the beginning of the process and
really shaping the solutions, be also part of shaping the
solutions. Yeah.
And this comes back to the earlier, right, when we
mentioned about slicing the objectives and slicing the
problems, right? Because engineers definitely we
can come up with the solutions, right.
But understanding the objectives, that's the first
thing, right. And then the problems defining
the problems, getting involved in defining the problems, I
think that kind of like. Exactly.
So we have a review process also for problems, so that engineers
read all the problem definitions and can give their feedback also
on this stage. So this is the most important
step. Be really clear about the
problem you want to solve. Yeah, I really like that because
many, many times I've heard the emphasis on the objectives,
right, Well defined objectives with clear metrics and all that.
And then the problems is something that probably we can
practice right in order to involve the engineers to come up
with more innovative solutions and they really understand what
exactly the problems that we need to tackle to achieve that
objectives. Also as part of the alignment of
the teams, you mentioned that you prefer a small team and
small here is the 2-3 people team.
I think this is really small, but tell us the argument behind
this. What I mean is I prefer two to
three people collaborating at every point in time.
This means two to three people implementing 1 initiative, like
implementing one solution to a problem, but it also means two
to three people collaborating on shaping the solution.
It means two to three people discussing what problems should
be solved. Like I would always aim for
small groups that have all the capabilities that they are
needing. So this means, for example,
let's say we are shaping a problem that we want to solve.
So we are shaping the solution. And then you need to have a
technical, a senior technical person there.
You need to have a product manager, you need to have a
designer who knows about interactions.
And so they are collaborate and shaping a solution.
But it does not mean that those are the same people need to
implement this because sometimes you maybe want to have a
different pairing and implementation phase where you
are pairing a junior with a senior and maybe it's the same
designer and maybe the product managers not that involved
during the delivery, just from time to time.
So you have then another team of two to three people and would
also aim for two to three people making those decisions.
With the senior leadership, it's basically a, let's say ACEO,
it's a technical leader, CTO, and it's a product manager or
whoever is in responsibility of the process.
Because if you have more people, you have more communication
because communication scales exponentially.
If you have three people, everyone needs to talk to two
others, so you end up with three lines of communication.
But if you have, let's say 5 people in a team, everybody is
talking to four other peoples. If you imagine it as a graph of
people who need to talk to each other, that the picture is much
more more complex. Bring together who can make the
decision like from a authority point of view but also from a
skill point of view and then you can make decisions pretty fast.
And they need to be a enabled, they need to have the allowance
to make this decision. This is important from a process
wise. Right.
Thanks for the clarification. So it's more like a dynamic,
kind of like teaming. Of.
Group of people working on certain particular thing, right
at the time and you mentioned about the communication
challenges if let's say you grow into more people, right?
Definitely, you know, there are more lines, right, To
communicate with each other and not to mention the
misunderstanding that could happen as well when you have so
many people. One of the aspects is about the
alignment with the value streams, right?
This is also partly what you emphasize, right?
Alignment with value streams. So tell us what is the thing
here? Yeah.
So this is an idea from the Team Topologies book from Matthew
Skelton and the ideas that you have all the capabilities in the
team that you need to deliver value to the customer from the
idea of what value we want to deliver to the customer to the
delivery. So it does.
For example, bad practice would be to have a dedicated design
team, a dedicated front end engineering team, dedicated back
end engineering team, because then you have a lot of handovers
between the teams. What you really want is to have
one team with a designer, a front end engineer and a back
end engineer. But the same goes also for other
handovers. Let's say you divide your teams
along the customer journey. So for example, if you're an
e-commerce and then you have one team for search, one team for
the catalog, one team for checkout, one team for payment,
one team for fulfilment. So you also have a lot of
handovers if you want to change, if you want to implement the
change of how you delivering value to the customer, let's say
you're implementing A discounting mechanism or
something like this. So also here you want to have
teams that are capable to work on all parts of the platform.
I think it's too much to dive deeper into the ideas of team
topologies because there are really ideas and how you can
maintain a coherent architecture and coherent user experience
around those kind of teams. But I just want to touch it here
because it's also very important if you build such an empowered
product team that it really has all the capabilities that's
needed. And this goes a little bit back
to the of of the slicing of problems because we need to
slice the problems also in a way that they are fitting your
teams. But this is something that we
will touch in one of the next parts when we talk about how we
are mapping the sliced work to the different levels of the
organization. Yeah, I think Team Topologies
definitely highly recommend everyone to follow if you
haven't heard about it. So I think what you mentioned
just now is the concept of stream aligned team, right?
So it's one of the team structure that is advocated
within the Team Topologies. So let's go to the mapping of
the work itself to the organization.
So how can people do that? Now I'm basically bringing
together the idea of the two to three people always working
together with how we are slicing the work.
If you start at the bottom and the delivery team, you have two
to three people walking, delivering.
Yeah. And then you have a level above,
you have the slicing of the solutions there.
Normally you would have a three factor of an engineering lead of
a product person and the designer design lead.
And they, as I said, the more senior people, they should slice
how the solutions are looking for this team.
And then they have a couple of three or four teams below them.
For them, they are slicing the solution because they have the
most insight into the system and then they need to check with
them during delivery. And one level above, maybe you
have a middle management layer, director of engineering,
director, product director design.
This is the place where you slice the problems because you
need to align to the objective that you're slicing.
You need to align on the objectives on the topmost layer
on the CEOCTOCPTOCPO like technical product leadership and
also design leadership. So the idea is that you have
always two to three people, that you always have the required
skills and that they are able to make the decisions like
objectives on the top, what problems to address on the
director level, if it's a bigger organization, if it's a small
organization, it's probably the same people that are slicing the
solutions. Yeah.
So I find this kind of alignment is very, very crucial, right,
Especially when your organization grows really large,
because sometimes people couldn't really identify the
work that they're doing, how it actually aligns with the
business, right? Be it, you know, efficiency,
engagement, revenue, whatever that is, right?
So sometimes people just don't understand what problems they're
solving, what objectives they're aligning to.
And I think it's a small simple exercise of aligning all these
like objectives, problems, solution delivery can really
help people to give the clearance like the clearer
picture of, you know, what things they achieve together as
a company, right? And it's also important to note
that this is not top down. It's really a two way exchange
like one of the principle of Tokyo asked that stuff is
bubbling up from the bottom again.
Like if you have a problem with delivery, you cannot deliver
something, then you go one step up to the people who sliced the
solution with you. And if you then find out, oh, we
need to solve a different problem, then you go one step up
again. And so it goes up and down and
it really needs to be a dynamic process.
This is not because if it would only top down, then we have
waterfall again, but for interdisciplinary waterfalls.
Right. So we have discussed so many
things right just now about your thing, right move things and
breaks our laws. Are there any things that you
think we should also cover because the time is approaching
almost to the end now. So are there any things that you
want to chip in more here? Just maybe one thing for a large
organization, this is that like big organisations and just one
empowered product team, I think it's important to think of the
reporting structures of the company as a technical leader.
With the reporting structure you can steer to a certain degree
how the teams are working. If I want the teams to work on a
scope by scope, then I let report them scopes.
So then they are forced to think in scopes and yeah, they can
make it more complicated and work different anyway.
But I probably will find it out because then the results are not
in check with what they are reported.
This is just important. And there are a couple of tools
also from Basecamp, a tool like the hill chart.
The idea of the hill chart is that work is more like a hill
than a straight line. So you have always an uphill
phase when you are figuring things out and then you have a
downhill phase of making things happen and then you could align
the scopes on the uphill phase. Then I as a leader understand
all the team is with this scope in this phase.
They are trying to find out what it's about or I know how they
just need to implement it. So this is a different view from
you as a leader. And this is what I meant with
granularity. When then I see and I can
compare the scopes from a couple of teams and I can see are they
making good progress or are they having unknowns because they are
flagging the unknowns. I want them to flag unknowns on
the hill chart as well. Then I quickly can see if they
understand what I want from them, how to work as well.
And there are other tools from Basecamp like moving the needle
where you have a scale, time is progressing linearly and you
manually need to set a needle of how far you are into the
process. But maybe we'll leave a link and
people can look it up. It's a tool from Basecamp and
it's always inspiring to see what they are doing because they
think about product development in such a different way.
And then you are still free to implement it in your own tools,
in your mirror board and your confluence.
However I like to know it. Right.
So definitely, we'll put all of them in the show notes for
people who want to study further right about those techniques
from Basecamp. So Claus has been a great
conversation. I think we all learn a lot about
a thing or two, how to optimize our product development or
software development, right? So as we reach the end of our
conversation, I have only one last question, which I always
ask to all my guests. I call this the tree technical
leadership wisdom. If you can think of them just
like advice, maybe if you can share your version today that
will be great. Yeah, sure.
So first would be don't give your team a backlog of stuff.
Give give your team a clear goal and a deadline and then let them
figure it out. That is would be my first thing
because it also helps you as a leader to really think about
what we want to achieve and not get distracted and a lot of
small things first, this and this and then and the second one
would be stay calm because nobody is doing agile in the
right way or not. I have not seen two companies
doing the same process. So I think it's important to
stop asking yourself if you implement a certain methodology
like Scrum or Safe or whatever correctly.
I think it's more important to really observe what is going on
in your organization and then adjust accordingly.
But. That said, it's a segue to my
third advice. You really need to understand
what others are doing and what trends are there in the
industry. Like we have a lot of
interesting trends like multiple development, also a good podcast
episode with you. And there are trends like shape
up and you need to talk to other leaders how they are doing it
and being exchanged with them to really understand what they are
doing. And I think it's more important
to understand, as I said, what are the problems of your own
team and what others are doing, and then come up with good
solutions for them. Yeah, I really love them, Right?
Staying calm, right? So nobody actually practiced
anything perfectly, I would say, right?
And it's also highly contextual. I will slightly tweak the third
one to listen to the podcast. So if you want to learn, you
know, about new techniques of other things that people are
doing, thought leaders in the industry.
So thanks for pointing that out as well.
So Claus, if people love this conversation, they want to
follow up with you, ask you more questions.
Is there a place where they can find you online?
Yeah, sure. So I have a blog.
The domain is VO1 dot IO and I'm also active on LinkedIn.
So on on LinkedIn I post more shorter things and on the blog I
sometimes post longer things. And yeah, I share my thoughts
and I test some resonance because I'm also thinking of
maybe writing a book about this topic on one day.
So if you're interested in interdisciplinary topics and how
teams should or can work together, and feel free to
follow me there. And yeah, beyond that, I'd like
to invite everybody with listening to this podcast to
just connect with me. Also, on a personal level, I'm
very curious to hear how others are approaching their team set
up, how they are slicing their work, how they are creating
strategic alignment. Yeah, either if they have a
concrete challenge or just want to exchange ideas or just share
if they're maybe proud of their own approach, because such
conversations also help me to develop this topic further.
And yeah, in some rare cases, if I have time, I maybe can also
help hands on as an advisor or as an interim lead, but I don't
want to promise too much. But sometimes it's one thing
leads to another and I can help actually.
Yeah, out of curiosity, what is behind this name?
VO1 dot IO? It is quite unique I find.
Yeah, it's just this mindset of starting with the version 01,
like with the the first iteration of my blog basically.
And I have kept this mindset since my early days and at the
moment I think it's probably my 3rd or 4th iteration of the
block. But her name still sticks
because it's this mindset. Always create a version 0.1 and
then see how the resonance is and then continue from there.
Love that. So yeah, thanks for sharing.
Thank you so much for today's discussion, Klaus.
I hope people would learn a thing or two again about move
things break silos, right? Not break things, right?
Yes, move things, break silos.