Traits & Roles Within a Successful Shape Up Team – Heiko Behrens (VP Product at Memfault)

#2: Today I am speaking with Heiko Behrens, VP of product at Memfault, an IoT reliability platform. Before joining Memfault, Heiko has had an impressive career in engineering roles at Pebble smart watches, working on augmented reality devices at Intel, and most recently on the Oculus VR headset at Facebook / Meta. 

This conversation is part of a series about companies that use Shape Up, a delivery framework originally created at Basecamp. If you've never heard of Shape Up, check the show notes for a link to the video "Shaping in a nutshell" by Ryan Singer, former head of strategy at Basecamp and author of the book "Shape Up - Stop Running in Circles and Ship Work that Matters".

In our conversation, Heiko walks us closely through the product development process at Memfault, and how they've adopted and adapted Shape Up to their liking. What struck me the most was how rigorously Heiko and his colleagues have designed their process, incl. detailed playbooks for the "hats" that different people wear at different times. It feels like Heiko and the team are tackling this process design very much like an engineering problem, even keeping a changelog of how the process evolves with each cycle.

We get to talk about various tools that the team has developed to, for example, keep track of scopes of work, plan who's available, and manage well-formulated project briefings. Heiko also underscores that it's important to embrace the iteration in how you work, and that there's no "end state of enlightenment" that you're trying to reach. 

I hope you enjoy our conversation!

Links:
Contact Heiko: https://heikobehrens.com/
Memfault: https://memfault.com/
Shaping in a nutshell: https://www.youtube.com/watch?v=h_8M23wVjXk
Shapers & Builders job board: https://www.shapers.builders

Creators and Guests

Host

David Arens

Product Manager, Maker, and Host of the Shapers & Builders Podcast

Guest

Heiko Behrens

VP Product @ Memfault

What is Shapers & Builders?

The show about better ways to deliver great software products.

0:00
so maybe let's start at roles of the team uh you mentioned this release Sheriff a product Genie responder a tech
0:07
lead uh project manager product owner you have a lot of roles actually oh yeah yeah yeah yeah yeah and uh my question
0:15
do these rotate are these hats or are these people hats these are hats and the
0:21
fact that um we have so many named roles it is probably a testament to our VP of
0:27
engineering Ryan he is really into playbooks so we have for these different
0:32
roles we have dedicated pages with that describe the responsibilities the the
0:39
reason for a role and what is expected from them and that you know coming back to Performance Management that is really
0:45
helpful but also to set the tone and we are iterating on those two
0:52
foreign welcome to Shapers and Builders the show
0:59
about better ways to deliver great software products today I'm speaking with haiko Barons VP of product at
1:06
memfort an iot reliability platform before joining Memphis had an impressive
1:13
career in engineering roles at Pebble smart watches working on augmented reality devices at Intel and most
1:20
recently on the Oculus VR headset at Facebook meta this conversation is part of a series
1:27
about companies that use shaper a delivery framework originally created at
1:32
Basecamp if you've never heard of shape up check the show notes for a link to the video shaping in a nutshell by Ryan Singer
1:40
former head of strategy at Basecamp and author of the book shape up stop running
1:45
in circles and ship work that matters in our conversation haiko walks us
1:51
closely through the product development process at manifold and how they have adopted and adapted shape up to their
1:57
liking what struck me the most was how rigorously Haiku and the team have designed their process including
2:04
detailed playbooks for the hats that different people wear at different times it feels like Haiku and the team are
2:11
tackling this process designed very much like an engineering problem even keeping a change log of how the process evolves
2:18
with each cycle we get to talk about various tools that the team has developed to for example keep track of
2:26
scopes of work plan who's available and manage well-formulated project briefings
2:32
haiko also underscores that it's important to embrace the iteration in how you work and that there's no end
2:39
state of Enlightenment that you're trying to reach so without further Ado let's get into our conversation
2:46
[Music]
2:53
I'm very excited to be speaking to you today um you've had quite the illustrious
2:58
career could you briefly take us maybe through the formative steps that led to
3:03
your role as head of product at Memphis now I've been in the software industry for
3:10
almost 25 years now selling software there making software I am a programmer
3:16
by heart software engineer and I've done anything from being an individual contributor in small companies did game
3:24
software for tax advisors and lawyers was a consultant for you know financial
3:29
institutions like the New York Stock Exchange did things such as tooling for
3:35
programming languages mobile applications you name it and then I've been like a software like an engineering
3:42
manager architect CEO of my own startup ones which failed miserably and then I
3:49
moved to the Silicon Valley joining a startup called Pebble SmartWatches we did the first SmartWatches before Apple
3:56
watch or Android Wear had been there that also failed and from there I moved
4:02
over to Intel the the chip manufacturer where some of my former teammates joined
4:07
me over there and then we built like had worn embedded devices and then after that I went over to Oculus VR headsets
4:15
Oculus is um part of former Facebook now meta and
4:21
when I moved back from the valley back to Germany where I'm now I left Facebook and instead joined friends of mine
4:29
um in their startup manfloat but what do you all do um can you talk a bit about how big is
4:35
the team how long has the company existed what's life science right I looked up those numbers to be
4:42
prepared for it because that changes um continuously we are hiring Shameless plug and so I had to look at the numbers
4:50
of the week when I joined um we were in total of 14 that's one
4:56
four people with eight Engineers so pretty heavy um and then I would separate that into
5:02
none ICS non-individual contributors at the point that was our CTO
5:08
um and then the rest was product engineering I must say that our product it's a SAS web application but it's not
5:17
the traditional stack it's fairly um diverse and it's Tech stack because
5:23
we are doing three major functions for the embedded world and in order for to
5:29
do that we have to have an on-device agent so it's not just a web back end and web front and we have to have code
5:36
that runs on these teeny tiny very constrained devices and that leads us to the need of an SDK for
5:44
super small scale microcontrollers that have kilobytes of RAM and code space over Android AOSP with megabytes of
5:53
space sometimes even gigabytes and then the third category which we recently started to support is embedded Linux so
5:59
our team needs to be able to understand these Stacks to talk directly or indirectly to our backend we have
6:05
companies that run like scientific drones in the Pacific talking to us via
6:11
iridium satellite uplink with like very low bandwidth and then we have other companies that have continuous internet
6:17
connection because it's an embedded Linux device on the on the ethernet and that all talks to the back end back
6:23
end is really challenging because we have these millions of devices continuously talking to us so we have
6:29
not the usual setup where you have you know a postgres SQL database to query whatever you want that just doesn't work
6:36
and then on top of that ultimately that comes like you know an API surface and web front end so all of this had been
6:42
built with these eight people or seven at the time and then I joined um as the first product person dedicated
6:48
to product and what I didn't tell you and my intro was I've not been a product manager in my entire career this is the
6:55
first time I was doing this it was scary but um when I was um
7:01
considering new jobs two former friends of mine and CEOs of two
7:07
different startups independently asked me if I wanted to be their like product person
7:12
both very technical products and and then I read up a little bit consulted my network and asked other product people
7:19
um if that if they would consider me to be a product person and they always saw me like that and that was interesting I
7:26
certainly can relate to our target audience I formerly was one of ours but
7:32
I I clearly was lacking the experience in the actual doing the the tool belt
7:37
was just not there unlike software engineering of course you did mention you founded your own company right oh
7:43
yeah yeah yeah and you were the CEO and you were kind of thinking about product of course so product thinking was always
7:50
top of my mind even in my other functions you know as a tech lead or or architect or when you are maintaining an
7:57
SDK for um like a product with a substantial user base you clearly think with product
8:04
and mind but for example like if I say rice here
8:09
every PM will immediately know what that means I didn't know at the time I mean roughly I mean I mean if you if you talk
8:16
I mean I mean it's ice oh yeah and I studied business administration next to computer science so sure I have like a
8:22
business background and if I had as an engineer heard about rice I would have thought I mean this is so obvious why do
8:29
you even care and yes many of these tools are obvious if you think about it but having common language and
8:36
um shared experiences on top of um the same methods goes a long way so
8:43
like having tools and Frameworks are really um liberating I find and not so much
8:50
narrowing your your abilities to act anyway you asked me about company size
8:56
and I think that is today so today we are that's two years later Grew From 14
9:02
to 47 as of this week and we are still hiring and we're very ambitious did I
9:07
tell you that we are hiring we have amberish's hiring goals across the board including our product team
9:13
engineering is 16 people now and I would contribute uh split this
9:20
differently now none I see so that's Founders and management we now have management level here is four people and
9:28
then we split our engineering team and I'm sure we will get to those later in the conversation but we we started with
9:34
a very homogeneous perspective of our engineering and now we split this into solutioning and devex
9:42
Engineers that directly interact with our customers who are also Engineers our
9:47
solution needs to be integrated into their product that's five
9:53
we split off a platform team as one of our many learnings um when after we introduce Shape Up
10:00
their platform team consists currently of three people and because of like different circumstances we are down to
10:06
four product engineering people that is nothing this is like much smaller than
10:11
what we started off with especially if you consider that our product team now contains two people not just me but
10:18
another very talented product manager um so in total this is like 18 people
10:25
involved in engineering but depending how you're looking at it only
10:30
four Engineers actually being doing product engineering we this is the four
10:36
is the area where we had like a larger number in the past of course where we are hiring
10:42
um the most aggressively because um the number of these people determines
10:47
how many Builder projects we can run in parallel and the kind of downsizing tufo
10:52
is that a temporary thing is that a result of anything in particular oh yeah that is a result of like many learnings
10:59
I think two major factors contributed to this um we
11:05
had to let go our people in the most recent past um who were not
11:11
working well with this mode where you are a builder and responsible
11:17
um by yourself the learnings we took is that we need to hire um with that entrepreneurial
11:23
um my and and um pragmatic perspective in mind we also focusing on very senior people these
11:30
days and I have a long list of laws I see in shape up and I think this is maybe not a flaw but an implication you
11:37
need to have a team that is compatible with it and the other one is we separated that
11:44
platform team and that is in turn also a learning um and maybe it's also entangled our
11:51
text tag is as I mentioned fairly complex and so it it requires
11:56
um breadth to fully understand how to work on a particular area in an area on
12:03
a feature and so the platform team's goal is to simplify certain areas document them better putting in place
12:10
safeguards but also most recently the platform team is helping us to
12:17
evaluate and explore technical feasibility before so you can see this
12:23
as either shaping or pre-shaping before we even start a project so that there
12:28
are fewer unknowns before we start a project and then last not least the platform team is there to support the
12:35
Builder team so they are not completely off the chart but they are
12:41
not within the people we can draw from when we produce what we call a cycle
12:46
plan yeah yeah cool and we'll get into kind of detail on on all of these things
12:52
um but it's good to have the phrases out there to draw um drop on it cool um I think this is a
12:59
good time to kind of transition a bit into talking about Shape Up and to kick
13:04
things off there I wanted to ask you how did you get into shape up what were your first encounters with it and what was
13:10
your initial reaction to it yeah so as I said I'm doing this for a while when I
13:15
started there was no scrum and uh and then in the most recent years I would say in the past 10 years scrum was
13:22
everywhere and agile agile methodologies and that that could either be kanban or
13:27
scrum what I noticed is that oftentimes that was uh an ever-growing backlog of tickets
13:36
that were at least at the top of that um pile of of tickets roughly stack ranked
13:43
by priority and then you had various forms of grooming meetings where tech leads or
13:51
knowledgeable engineers in certain areas plus pm and then maybe sometimes stakeholders were trying to assess what
13:57
to work on next and then there are various boards sometimes one board sometimes topic oriented boards and you
14:02
would push them from the left onto the board to very detailed explanation of
14:07
the tickets to a facilitated Handover and that handoff and then an estimation bottom-up estimation and then of course
14:13
like you have velocity aim for so many tickets and then at the end half of it at best gets done because
14:20
priorities changes over time and as the missions are off and very
14:25
frustrating and that's roughly where mempod was before I joined
14:31
no surprise here I mean this is how many companies I'm aware of are operating
14:36
right now and some are better at it but that's not because of process but because of their past experience and
14:42
individual Talent at it and then when I joined
14:48
um I you know I know the team for a long time so the founders are actually ex-pablers and
14:54
um I was even there when we had been discussing whether or not to create a company out of this idea of building a
15:00
iot reliability platform as we do now with memfold I didn't want to join those
15:06
startup at the time but I was involved very early in all of this and and then later joined two years after it um it
15:12
was around and at the time most if not all of the engineers were ex-peddlers and people I worked with and
15:19
one person who actually introduced shape up to the company Fausto he he was not an expeddler and so he was very fond of
15:27
shape up and he introduced me to this book so I read the book I have the book here and
15:33
um I was basically laughing at it you know arrogant engineering perspective uh
15:41
nothing new here Hill shots this is just a glorified progress bar who needs that
15:46
like vertical bump and who knows needs this like potato shaped scope maps and
15:52
like all of it is basically just um more fluff then um some you know real like usable advice
15:59
and then a few things really helped me here and I'm not sure I'm not
16:05
sure how I got to this but what I realized later is that um I really liked time boxing
16:12
time boxing and then the circuit breaker I like the idea of
16:18
um not managing individual projects independently but rather having cycle boundaries because it would allow me and
16:24
I'm not sure this has been said in the shape up book but what I wanted to introduce is the ability to rearrange team constellations based
16:32
on the projects and if you have Circle or cycle boundaries it is ensured that
16:37
everybody becomes available at the start of the next cycle I found this really um intriguing
16:43
and then the reason why the team had introduced this was desperation like
16:49
being desperate but also they wanted the engineers wanted autonomy and that is a
16:55
two-edged sword I think it works kinda in our world because our Target audiences are primarily Engineers
17:02
so Engineers have customer empathy but to this date we don't have a single
17:07
product designer we're hiring and it is all on the engineers
17:13
and um but I I could see that this would happen regardless with or without shape
17:19
up and why not embracing it so when I joined the first ever Shape Up Cycle was
17:25
um just like it just had started and it it was a disaster like I think
17:32
with these let me look at my numbers um eight people in total let's say seven
17:38
people um they were all like running in circles I think we had as many projects scheduled for this first cycle as there
17:43
were people and like nothing got complete and it was a disaster but um it set the stage and then from there
17:50
we continued and oh yeah I have even more concerns about shape up it should actually drop them just here or like how
17:57
do you wanna there will be space definitely to explore kind of the Fall so I think to
18:03
structure the conversation I would say let's talk about what you have what you learned how you iterated and then where
18:10
you are now and then talk about what is kind of what Still Standing issues you have with it
18:15
okay so we do have a backlog of no changelog I can pull this up real quick
18:21
I I won't share the actual details but I can scroll through it um so what we maintain from Circle one
18:28
is a change log of all the things we were changing and we we tried things out we learned they were better or worse and
18:34
then move uh back so what entry are you on in this in the change log uh we are
18:40
at B18 that is a builder cycle 18. so first of all the observations
18:46
I made even before um we started cycle two was that this was
18:52
unrealistic as um we are still a startup
18:57
and maybe if you have a very mature product um what is being said in the product uh
19:02
book is true but like the idea that bugs are nothing special and you can wait um for six weeks until you address them is
19:09
not working period um we have constant fires everywhere and
19:17
something simply cannot wait for six weeks so we needed a way to address them earlier at the same time I really value
19:25
the idea of uninterrupted uh thinking deep thinking time as a former engineer
19:30
so what I introduced is the rule of a what I call a responder that was like inspired by first responder and
19:38
um so um they are there for emergencies and the responders goal is to Shield
19:43
Builders from anything that happens unpredictably
19:51
yes so um well I mean they are part of the cycle plan so what we do before each
19:56
cycle is we create what we call a cycle plan uh that that actually that
20:02
materialized much later we realized that people were not always sure
20:07
what was going on because we were shuffling team cancellation to best meet
20:12
the requirements of each Builder project and and so like what we introduced is this artifact called a cycle plan that
20:19
is usually ready the week before the cycle starts sometimes earlier and there
20:24
think of it as a it's basically a calendar you have
20:29
horizontally the weeks of the cycle and then each row is either a project for the Builder projects or the individuals
20:37
if you have different other functions and then to the right it's either a large bar depicting a project or if it's
20:45
individuals also when they are out vacation time or anything or what other
20:50
roles they have we have since then introduce roles such as the release Sheriff shepherding along releases or
20:57
product Genie who helps our customer success team with product related questions that basically at the
21:04
traditional term for this is probably sales engineer and that is like that schedule on call
21:11
that that is all like visible there for the upcoming cycle and then we use it as a communication tool
21:18
um how did we get there it's I was asking if the uh
21:24
if they sit outside of the projects I guess well yeah outside the product we still see them as part of the cycle
21:31
um and we deliberately put them either like down to that responder um role or in one particular project
21:39
deciding who should work on a particular project is it delicate
21:44
um exercise many um um inputs go into that decision making
21:50
process um and it's not what you might think as in first and foremost skills
21:55
it's not just like who knows um the problem space the best to work on a
22:00
particular project it's also um another thing we introduced are formal
22:06
roles we have the role of a tech lead with enable the team the one person who
22:11
ultimately like Shepherds along with the other engineers and um makes like critical decisions is the
22:18
person talking to other stakeholders we have the project manager also coming
22:23
from engineering which is sometimes tough but we learn we also tried it not um being from Engineers but
22:31
um we learned that you need to have like deep knowledge about the daily circumstances of the engineer who
22:37
sometimes is stuck and everything in order to do um very detailed management
22:42
and then a third rule we have in each project is um provided by product which is the
22:47
product owner and their rule is to answer questions about value for uh and
22:55
and like if there are certain Alternatives um assess which one is a better
23:01
compromise from customers perspective not so much effort or timing but really this
23:07
and they also help the Builder team Gathering additional information with like if absent if it wasn't present in
23:15
the pitch um during the during the project to basically shielded the builders further
23:20
so I think yeah many of these learnings went into how do we best allow Builders to focus on their
23:26
projects timing is another thing we went from six weeks to hey let's have projects of
23:33
different sizes we call them it was a part of the book like small batch big badge yeah so like we discarded that in
23:39
the end we went down to four weeks and we are now at five rigs this is not
23:45
because six week is the magical number or anything it kind of is I think like we need at least four weeks
23:52
but we also learned that we are a product company after all and other
23:57
functions such as sales and marketing needs to be aligned and what we are doing right now is a five plus one one
24:05
being one week of cooldown we also had like two weeks of cooldown in between [Music]
24:10
um so that if you put two of these together you have a full quarter
24:18
that doesn't quite line up you need one extra week so we have every other cycle we have two weeks of no Builder cycle
24:25
and that is usually when we schedule a an offside or something as well
24:30
um but yeah this is coming up at the next cooldown at the end of this quarter is going to be two weeks
24:36
um where we are again meeting in Berlin and um not only work on stuff we otherwise
24:42
don't get to but like discuss a long-term perspective and and anything else that you do better in person
24:49
I would say let's now talk about the main pillars of your adoption of shape
24:54
up today and I want to break this down into the parts that the book kind of has which
25:01
are shaping betting and building if that still makes sense for your context yeah it does
25:08
so shaping uh we still have pictures we oh that's also one of the first
25:15
things I changed I found the pitches to be too um
25:20
disconnected from the business so our template includes business
25:26
related items as um what's the value of this and I don't mean I all of this is from
25:34
the perspective of memfault you might be tempted to declare the value as an O after this feature is there the customer
25:40
can use the feature well um well you that's of course like a um
25:47
tautology you then sometimes say well happiness increases cool but then like how you
25:55
need something that is makes pictures comparable to other pitches and the reason is I sometimes got the impression
26:01
from the book that this is very Ivory Tower Bridge a few distinguished people
26:07
get into a room and then come out with a decision what we do instead is we we
26:12
discuss this fairly in the open ultimately it's on me to decide what to work on but
26:18
um I want people to understand the decision making behind it and for this to be transparent I put business value
26:24
out of it and that includes what what's the value of it and then very important why is it
26:29
important well in the startup everything is important but then combined with why is it urgent why do we need to put out
26:36
this particular fire right now why can it not wait another six weeks and if you are really diligent about that
26:43
I would Echo what has been said in the book it's yes many things can actually wait for six weeks these plannable
26:48
things um there are always customers who yell the loudest at you or
26:55
um are at the verge of um churning or whatever but like ultimately most things
27:00
can wait another cycle and now it's you look at things in value importance and
27:06
urgency before even looking at the solution and so that enables a lot of people to
27:12
contribute to the shaping process you can now suddenly pull in customer success and sales into the craft of
27:20
creating pitches and that's what we do I must admit that the full pitch I've
27:25
never seen a full pitch exclusively being written um by anyone without the help of product
27:33
but we have one very successful pitch improving our demo data for our sales
27:39
reps like they are doing sales conversations we have a demo instance of our product and they want to show
27:46
um or like use the product to support a certain narrative and the demo data we had was not cohesive in that narrative
27:54
so we had to have particularly designed demo data on our product and that was done
28:01
um with our like with with sales and um together with product and is a huge
28:08
success it's not really directly a feature in our product but ultimately creates a value in the company and I and
28:14
this this distinction to me is very important product is not just there to crank out features it's there to improve
28:20
company value uh as a whole so making that separation is important and then shaping everybody in the
28:27
company is invited to do pitching technical solutioning mostly comes from
28:34
engineering or product I'm trying to hire technical product managers who can
28:39
also do solutioning at a fairly technical level and we are hiring and
28:47
um yeah so that leads to oftentimes the the upper part of the pitch being contributed by others but then
28:53
solutioning ultimately um product I'm just going to ask you on on that um because I I've read a bunch
29:00
of case studies on Shape Up where teams are saying pitches can come from
29:06
anywhere but rarely have I myself personally seen this happen did you do
29:12
like did you train the other tips in any particular way to to enable them to kind
29:17
of break down this barrier yeah so what we do is yes
29:23
um I think um if you a few weeks after I initially joined I
29:29
ran a company-wide workshop as part of our offsite everybody in the company was involved in
29:36
you know taking a step at pitches um we tried this on and off so I think maybe in total we tried like three or
29:42
four instances where people were strongly encouraged to contribute pictures um I would say that this was not the
29:49
main facilitator instead what we instantiated
29:55
um is what I call now a shaping meeting it's a weekly meeting where I pull in
30:00
the different functions of the company so that is a
30:06
standing meeting where I have customer success sales
30:11
engineering CTO formally also I'm our CEO but he's not part of it anymore and
30:18
then myself and that is mostly to get perspective on things from these
30:23
different angles I want to call out that marketing is not part of it maybe we change that in the future
30:31
um too many cooks is also a problem but then this is primarily at the beginning of each new shaping cycle
30:37
um a way for me to get a fresh perspective on things but what it also means is that these people don't think
30:44
like on a daily basis in pictures and products and and projects on anything but rather they have like all these
30:50
learnings and concerns and now you funnel that into digestible
30:56
clusters and say you know that would be a good pitch candidate and and now it's their motivation to somehow get to such
31:03
a pitch and I think from all of the engineering certainly contributes sales as I mentioned Demolator for example but
31:10
then also especially customer success Andy she's leading our La customer success team is really behind the idea
31:16
of pictures as a tool to get um attraction for her team and and then
31:22
she delegates that to to her team and ultimately at the very least they
31:27
come up with that top part and especially and we also pull in customer success um basically for every pitch to justify
31:34
the importance and and validate the urgency so I would say
31:41
it has been planted as a successful idea people realized that um this structure
31:47
really helped us getting away from this running in circles constant firefighting which took us roughly six months after I
31:54
joined they saw that we could really deliver things with this tool and I
32:00
think it's to the leadership of the company um recognizing this and then carrying it
32:08
back to their respective teams and also the value of the the standing meeting I think just keeps it top of
32:14
mind and yeah it's everybody into this process right so that's also different
32:20
from the media from the book we didn't have this right away I don't know exactly when we introduced this but the
32:26
sending meeting is basically a um it converges towards the betting
32:32
table the betting table is the last so to speak um meeting of a giving shaping cycle
32:38
it's not just a singular event what happens is that we have um for each new
32:44
cycle or we have one notion page where we are discussing that there's like a
32:49
standard template for the first opening meeting like let's get together let's collect everything is everything still
32:54
wherever you think it is did we learned anything is anything like urgent to force us to think about it of course
33:00
that can happen at any time and then that uh produces pitch candidates or
33:06
pulls pitches out of our pitch back lock we have a backlog of pictures
33:11
and put it onto um it's basically yeah another Board of
33:17
potential of pitch candidates for a given cycle and then it's a function of how much
33:24
time do we find to flesh out and shape the pitches which is indirectly a
33:30
measure of is it really that important and also availability of people and
33:36
steadily we narrow down which pitches will ultimately make it
33:42
and we use this time of Discovery to also go back to the platform team for
33:47
example to a form and form technical feasibility or customer success going back to customers to understand
33:53
urgency better and then ultimately I think this way we have really well informed data when we finally place our
34:01
bets but I must say that the betting table is fairly uneventful at this point it's almost always already decided
34:09
at least like informally and another point of awareness we do
34:15
have a company meeting a weekly All Hands Where I report on not only the
34:22
current Builder projects and their progress but also what we currently think of for the upcoming cycle so that
34:30
people are aware interesting so the those weekly meetings
34:35
they aren't the same agenda every time but what you talk about depends on the life cycle of where you are towards the
34:42
next starting the next cycle yeah there are like always goals as in um we need
34:48
to have locked down um the candidates by this week so and
34:54
then like to drive some urgency there are there's this limbo state of
34:59
the first weeks of a builder cycle where nobody really feels urgency to work on these pitches
35:06
um and so you need to like you know drive this a little bit where do you pull the resources from when you have a pitch coming from
35:12
customer success to help them go into the solution and so I imagine you know
35:17
they are very strong in filling out as you mentioned the top part about the problem the value and the urgency the
35:23
importance um and then in the first one or two weeks of the ongoing cycle I assume that
35:29
you then kind of say okay this is something where we feel like we we can push for a solution and shape a solution
35:34
so we can bet on it next time how where do you pull those resources from to get to the technical solution
35:40
so customer success as I said is very motivated they have
35:45
access to our devx and solutioning team anyway and they oftentimes
35:53
present pictures that are directly informed from particular recurring customer need and those Engineers have
36:01
the skill to write out at least the solution at the boundary to the customer that is not complete but at least it's a
36:08
starting point and then we use like product management time to do the
36:14
refinement and everything the fact that these pitches are incrementally and openly written is also
36:24
allowing us to pull in to ask for feedback early on so
36:29
honestly oftentimes pitchers are not ready weeks before but only days before
36:34
but at least rough structure is there and then we ask oftentimes either the
36:40
platforms like the most knowledgeable um Engineers or the engineers we foresee working on these pictures in the end to
36:47
give early feedback and to socialize these ideas and then you refine I think almost always it's ultimately a
36:55
product uh during the final solutioning before we oh and we also had cases where
37:02
the pitch wasn't even ready and we still Bet On It but it's um ultimately it's ready before the kickoff like kickoff
37:10
is where you go through the entire again we have a
37:16
template for this as well like the kickoff meeting but it's ultimately deciding on these rules and the team and
37:21
then um going through the pitch they have done this asynchronously before uh collecting
37:29
answering all the questions that can be answered immediately but leaving with a set of questions we need to Circle back
37:34
on so that we can start with scoping I feel that we already going into the scoping I want to say one more thing
37:40
about the shaping phase um cycle plan is absolutely important
37:46
the cycle plan informs the betting table and vice versa
37:52
this is really entangled and our we had a recent inflation and titles
37:58
because we are startup and we're growing um VP of engineering I'm actually not a head of product I'm actually BP of
38:04
product um we had this ongoing debate about
38:10
um what comes first betting placed bets or cycle plan I always wanted availability
38:16
and preferences of team members to inform what bets took place how to staff
38:22
these projects and then ideally even know so early that I could know what to where to invest the most time shaping
38:29
time on so that is and then ultimately it is it is a mix it is um we're very entangled
38:36
but this cycle plan really helps as a communication tool and it's crucial for
38:42
engineering because we use like in an organization you always need
38:48
to do Performance Management and evaluating um how somebody performs but also if you
38:53
have new people how to onboard them um if people if Engineers want to extend their skills
38:59
um where to put them and with this very Dynamic concept of shape up you need
39:05
something that accounts for that too and the cycle plan and the close discussion
39:11
with our VPO of engineering is the tool to allow for that
39:16
interesting I did want to um ask you one thing about betting that maybe takes us a bit off the Reds but
39:23
I'm still gonna do it um because you you leaned so heavily on the aspect of urgency as part of the
39:29
decision criteria that you have and I wonder how you balance that with kind of a more long-term view on where you want
39:36
to take the product yeah one of the many flaws of shape up it doesn't have an answer to that right like what about
39:42
roadmap um what about tasks that don't fit in just a single cycle
39:49
what about tasks where you have one-way decisions not like clearly a shape up
39:55
comes from a front-end heavy product team where you don't have long lasting contracts and humans the the end users
40:01
are very um um forgiving when it comes to changes every
40:08
in others cycle we have a product where our SDK runs on these millions of
40:15
embedded devices with an SDK that is only updated every so often so some
40:21
design decisions are very hard to correct you need proper planning and
40:26
that is not really specific to shape up it's more agile methodology in general but like these are all problems that
40:33
shape up has no real answer for so roadmap I am not a big proponent of road maps in
40:41
general at least not in the classical sense where you predict uh delivery
40:47
dates of features um that's very much against the idea of
40:54
um like an agile company if you have found product Market fit and
41:00
you have um like government contracts sure um I think we have roughly product
41:06
Market fit for our initial set of features but still there are so many obvious and undiscovered things it's
41:14
about when to deliver them and I don't want to make commitments because that um there was down our options I totally
41:22
recognize that marketing and sales depend on this to make promises but we try to not make promises
41:28
so that's roadmap we have a substitute which I call River system
41:34
is actually not so much a one-dimensional thing or like multiple Lanes it's more
41:41
you know to talk in mathematical terms it's like an Asic leg directed graph of
41:48
um Petras like things depend on other things you need to ship something in a certain order they are not just on a one
41:55
axis but we need at least these three things lead to this one and then it enables certain other things
42:02
that allows us to understand roughly um like several things first in which
42:08
order do we have to do something what is on the horizon to give perspective and Direction but also sometimes we had a
42:15
goal last year where we wanted to ship our Linux SDK you can work backwards and see we actually need three Cycles to get
42:22
to that if we want to get it done we need to have the first one now and that
42:27
that actually happened to drive urgency in the at the betting table we said okay so like this is a given we have to have
42:33
this because otherwise we won't get this done is that strictly a roadmap but it's helping for this perspective thing we
42:41
also have larger topics where we know early on that this is not going to be
42:46
doable in a single cycle and there it's yeah I think I always wrote those
42:51
um it's basically a more like an aspirational design dock where I'm describing a solution
42:58
Howard could be in roughly a year and then people review it as a as we do
43:04
this at Ben fold with rfcs and and they they look at it as if it was a like real
43:09
project description but it is not it's a source to draw pictures from
43:15
and this allows us to pick from the larger description
43:22
depending on the current needs and immediate value without losing that like a longer term perspective so we have one
43:29
feature that led to I would say three yeah I think three projects in total and we have another one which we call Fleet
43:36
sampling interesting thing I think you will find that if you Google menthold and Fleet sampling it's really unique to
43:42
our product but um John our like PM uh he said
43:48
it's probably the eighth project now we do a run Fleet sampling is that a smell
43:54
and I don't think that's a smell I think so what we don't do is doing one of
43:59
these um projects one after another but rather we have perspective and we decide again
44:06
after each cycle what to work on next and more often than not it's really surprising to me and people who have
44:12
done shape up for a while probably have noticed this too something like a close Contender like the third project we
44:18
didn't get to in one cycle isn't necessarily even on the table the next time and and
44:24
um that here translating to this aspirational design dog oftentimes means that you have one cycle working on it
44:31
and then there's a cycle without working on it and maybe another one and then two consecutive ones and it really depends
44:36
on the immediate value and Market situation that informs when to work on
44:42
it but the aspirational document gives you the perspective so that each
44:48
individual pitch is not in isolation is that one more yeah we have
44:54
um our pitches sometimes we are lazy and we do this backwards in our solution we sometimes add stretch items knowing that
45:02
we most likely won't get to it and then we haven't talked about building yet and we will be terribly out
45:08
of time here um building has one artifact at the end which we
45:14
call a project a debrief where the team themselves describes what they have accomplished how much of this is
45:20
immediately adding really value they're jotting down the known limitations and then there is a section
45:28
planned work like that we committed to work on that's usually cool down you know the last few things or we sometimes
45:34
bargain sometimes bargain with future responders or the platform team thank you cycle plan to have that
45:41
ability like to open up that possibility and then we have possible like future steps
45:47
and that is basically direct input for future pitches and then the future pitch doesn't necessarily need to be in the
45:53
next cycle refers back to this one and also gives perspective interest yeah I think these are our
45:59
tools for this I guess [Music] we'll be enjoying the conversation I
46:04
wanted to take a moment to thank you for listening and to let you know about the Shapers and Builders job board on
46:11
Shapers dot Builders yes that's the domain you'll find jobs in software
46:17
development design product management and other roles at companies that work with Shape Up many of these rules are
46:24
remote and teams who use Shape Up generally run at a more sustainable healthy and meaningful Pace than the
46:31
hamster wheel of two-week Sprints so if you're looking for a job in Tech or
46:36
trying to find great people head over to the Shapers and Builders job board at
46:42
shapers.builders now let's turn back to the conversation let's talk about building and we've
46:49
covered a lot of ground so I think we can speed through some of these um what I did want to talk to you about was the
46:55
roads on the team and you've kind of given an overview stretch Scopes I have here I wanted to talk about then the
47:01
circuit breaker for sure because this takes guts and I want to hear your perspective on it
47:07
um and then maybe whatever other tweaks you have what other hacks you found um yeah on the building side so maybe
47:13
let's start at roads of the team uh you mentioned this release Sheriff a product Genie responder a tech lead uh project
47:22
manager product owner you have a lot of roles actually and my question do these rotate are
47:30
these hats or these people hats these are hats and the fact that we have so
47:36
many named roles it is probably a testament to our VP of engineering Ryan he is really into playbooks so we have
47:45
for these different roles we have dedicated pages with that describe the
47:51
responsibilities the the reason for a role um what is expected from them and that you know coming back to Performance
47:57
Management that is really helpful but also to set the tone and we are iterating on those two
48:03
um so the responder we can maybe take this out but like the responder is basically working off of
48:10
um a kanban board um to work on the most recent
48:16
um discovered very urgent things that cannot wait and then there is also downtime where we
48:23
have planned work you know this traditional backlog of things that are not quite large enough to justify a
48:30
buildup project and so this is managed by product
48:35
not during cooldown during cooldown the board is owned by the platform team because it's meant to work on technical
48:42
stuff and improve the situation so then ownerships toggles at this for this one week
48:48
and so we have this one lane that's called a top top Lane that says like
48:54
like drop everything else we need to work on this now and then every um but other than that we try to have only 10
49:00
kanban board like 10 active um tickets and then people can choose from it we have the Builder and then within the
49:07
Builder we have um the tech lead the project manager and then product owner owner is coming extra from the outside
49:14
from product Tech lead is um responsible for all technical
49:20
decisions um when there are like two ways to to do
49:25
something they need to have the foresight to not dig yourself in a corner for example I
49:31
mean that's ultimately you have that in every team I think and no matter if shape up or not and then um the project
49:38
manager is interesting because there is this
49:44
what to ship and when so in our Playbook we say we want one shipped
49:49
scope within the first two weeks we call that the unambitious scope
49:55
and that is try to drive the idea of shipping incrementally
50:02
we totally recognize that there's often a discovery phase at the beginning of each project so you need to be really unambitious
50:09
with this scope and to ship anything and um doing all of this deciding what to
50:16
work on who to work on this that's the responsibility of the project manager and of course you need to have like deep
50:21
technical understanding and also understanding of the skill set of the people you have there on the team and so forth
50:27
to help with that we abandoned like first of all these potatoes like
50:33
here cover up the book like these these Maps I think are not 100 useless what I like about it is
50:40
two things the circumference shows it as a closed problem a close
50:48
problem space and then also there is no overlap I really like that so like what you work on is
50:55
um by itself complete yeah uh sometimes you have you know if you have a time at
51:01
the end you polish everything but um ultimately I like that and then thinking of it as a vertical slice like this is
51:06
truly shippable um that I like about this but otherwise I think this is fairly useless what
51:13
um helps really to drive that project management discussion is dependency like again within a project you oftentimes
51:19
have we do this first I'm not talking back in front end I'm talking this deep
51:24
vertical thing and then it makes sense to do either of these two now if it's either of the two what how
51:31
to decide to work on it well you could say always the one with less effort or you say maybe it's the most value but
51:38
then what is more valuable and this is where um the product owner rule comes in and the project management ultimately
51:43
decides so what we settled on is a two-dimensional representation of these scopes
51:49
deep um showing them as blobs by them by themselves but not
51:54
within this potato but rather um as you know a dependency graph and then we have two axes one to the bottom
52:01
like top down is time this is what we intend to work on and then left to right is the value each presumed shipped scope
52:09
rings and the PM helps um deciding what adds value and only the
52:16
engineering team really knows the effort and then we are trying to find Alternatives well if this is so valuable
52:21
but so late can we do something you really see that right like oh we do all these things and almost none of them add
52:27
value only this one last thing adds value how can we somehow maybe split this or do anything to get to Value
52:34
earlier and this visualization really makes this obvious so that's why these
52:39
roles are so important because um the the timing and the dependencies really comes from within the builders
52:45
and the value comes from the outside and the product owner so that's what you call enhanced scope
52:52
Maps right yes that's yeah I shared for the audience I shared notes and what they read beforehand let me actually go
52:58
through those um no overlap yeah that's what I like but top down left right skip Loop uh yes
53:04
this really blobs with arrows in between Engineers tend to think in dependencies
53:10
regardless but they oftentimes don't think and Scopes as individually
53:16
shippable features so Engineers would like to do the foundational work uh that by itself
53:23
has no value and then you really need to train to do not the 100 foundational work but
53:30
forty percent forty percent and then the additional 40 yes that is now redundancy because you cannot do the clean
53:38
Foundation but if you do only 40 foundation and then some that builds on it you have something shippable and that
53:45
that is something you need to train and that is again I think regardless of shape up or not this visualization helps
53:51
and then this is why these roles are important I find but Shape Up enforces it maybe more than a Sprint that just
53:58
carries over what didn't get done into the next right Fair yes oh and then
54:03
looking at the circuit breaker and then something probably so that we
54:09
really embraced at Facebook so Oculus is Facebook everything at Facebook was behind a
54:14
feature flag and people may not know this people are not even on facebook.com anymore but people
54:22
um who are on facebook.com are simultaneously roughly in
54:27
about 300 parallel a b tests different ones like you open
54:34
Facebook I open Facebook and we see we are subject to different code paths and we are subject to three 300 totally
54:40
independent experiments there are thousands of uh concurrent feature Flags
54:46
and every development happens not in feature branches but on Main Branch and you guard them with feature Flags so
54:54
when I joined Facebook I thought that's great they must have discovered a fantastic way to avoid that inherent
55:02
complexity you know aspect oriented programming or something who hasn't seen the code base that's far
55:09
from the truth it's um it's a miserable um
55:15
it's a miserable mix of if statements and and different other patterns it's very unmaintainable and really difficult
55:22
if you think of it like if something at the beginning of a function or somewhere and then asynchronously
55:27
somewhere else functionality that needs to match depending on a feature Branch like this is very complex to to get
55:34
right we do release flags as well um we call them release Flags to um with
55:41
the intention to not use them for a b testing or have them on permanently but
55:47
the the goal is to eventually get everything that is behind a release flag released
55:52
like there is no we have a way to turn them on site wide per customer even per user but there's
55:58
no way to exclude someone and that is potentially we really want to embrace that we want to ship everything but
56:04
think of it as future Flags so we have these release flags and Scopes are
56:09
usually behind the release flag sometimes even behind several so that we can start working on it and
56:15
ship it and will at least like complete the engineering work but we have at that
56:21
point not yet exposed all customers through that behavior and the smell that comes from this is
56:30
that we have quite a lot of unreleased features in our code base now because of
56:37
the circuit breaker like um at the end of a cycle we sometimes um
56:43
determine that this was not meeting our quality bar or the feedback we got another flow of shaper by the way like I
56:50
think feedback comes way too late and then at that point this uh the team has been dismantled
56:55
um so like we learned that this is not um delivering what we anticipated so we
57:01
don't turn it on at the very least not for all of our customers maybe the one customer that is satisfied with it great
57:07
they will run with it but we know at some point we need to get back then it's up to a future betting table whether or
57:13
not we decide to fix it for real or as it happens quite often as you can see
57:19
from the many release flags that didn't um have been like lifted
57:24
they just sit there and maybe um the problem here is that you have a
57:30
lot of unnecessary complexity now in the code you need to maintain all of this
57:35
I believe this is true for software in general anything that is not perfect is
57:41
an ongoing cost and maintenance here it's particularly sad because you
57:47
don't pull value from it the only value is that it's easier for a future project
57:52
to continue working on it but yeah the circuit breaker works for us um by release flex and by having the
57:59
unambitious scope we oftentimes have at least something shipped towards the goals of a pitch
58:06
maybe not the most valuable thing but at least something and then oftentimes
58:11
especially like the last one or two Scopes sometimes we broke in parallel on those um are behind the release flag
58:18
before we wrap up the building say oh there's one last thing I wanted to ask you on the building side and then I have
58:23
about two questions left for you so thank you so much for taking all this time with me on the on the building side
58:30
um you also share notes with me that talked about a replacement for the hill chart that's not actually a replacement
58:37
but like um that's really sad so when we started off
58:42
um the people who have uh read the book and in particular have used Basecamp
58:47
before we're saying oh it doesn't it will not really work for us because we don't have Hill charts and
58:54
I said well I mean the whole charts aren't really not the most critical piece it really helps conveying the idea
59:00
that everything is an uphill battle until you've found a solution for a particular scope and then it's easy if
59:06
you have digested this we don't need a Halo chart but then still the team was pressing so we have at Menthol something
59:13
which we call Mad Men fault awesome day which is a day every cycle where the
59:19
entire company not only engineering works on whatever they like to improve their own skill sets or company or
59:26
anything but they were like their daily work and I took one of those to implement a
59:32
hill chart tool like really fancy it looked nice like drag and drop like there are many tools out there but they
59:38
they don't look so great and also I wanted a tight integration with our issue tracker so and then we had
59:45
basically one ticket representing a project and you saw that image and then
59:50
you click on it and you can like do like all the fancy movement and new Scopes move them around add just like a few
59:56
notes send it and you could embed this to notion with like web embeds and at a
1:00:03
point I thought oh maybe we ship this as a product itself because it's so cool and then we learned that there was not
1:00:10
much value in her charts outside of the team so I initially I shared the hill shots
1:00:16
of the ongoing projects during our All Hands meeting and people without context
1:00:22
don't know what a scope description really means and I spent so much time making sure that the labels of these
1:00:28
dots would not overlap and everything is legible in the end I learned nobody really cared
1:00:34
but the respective Builder projects themselves and at that point
1:00:40
what gives and soon uh sooner than later the team themselves lost interest in
1:00:45
using them um it was more important to use that two-dimensional scope visualization which we don't have
1:00:52
a good name for scope map I guess um so by now we absolutely don't use her
1:00:59
charts anymore and use um this the two-dimensional scope Maps which don't really reflect progress so we thought
1:01:05
about oh each blob there could be you know a pie chart or we could depicted as
1:01:11
um showing the size shows the total effort and then it shrinks and you leave um as an outline the original size and
1:01:18
then you can see how things basically the remainder of the work shrinks turned out that the team has enough
1:01:23
context um to know all of this so there is not really much there maybe as we grow and
1:01:31
um people who do care cannot have the context anymore because it's too many
1:01:37
projects maybe at that point we have to introduce something again but for the time being who charts
1:01:43
have no value for us I think that's a good segue into one
1:01:49
other question I had um about you mentioned this a couple of times you are hiring you're growing
1:01:55
that's right and um I was wondering since Shape Up is kind
1:02:03
of a niche framework and you've even taken the book that somebody could read and put a totally different spin on it
1:02:09
do you pay a kind of special tax now when you're onboarding people or how do you go about onboarding people into your
1:02:16
process versus you know if they join the scrum team they basically know what to expect what the rituals will be and so
1:02:22
on during our hiring process both Engineers as well as product people are generally
1:02:29
excited some of them know Shape Up and those who don't are intrigued by the
1:02:34
promises so it's generally a very positive vibe that goes that comes from it
1:02:40
after onboarding I don't think it is too much of a change
1:02:46
as an engineer as a new hire you lean on your teammates and just there you have
1:02:51
your Tech lead and from that perspective it's not much different than any other methodology you ultimately get exposed
1:02:59
to a new area and the tech lead Shepherds you along and you work off of
1:03:05
tickets so I don't think onboarding is particularly difficult and what we do is we again thanks to the cycle plan we try to
1:03:13
level up or like um expose
1:03:18
previously Builders to becoming a tech lead and a project so we are in the process of doing this expecting that
1:03:25
basically everybody today needs to be the tech lead for this next generation of Engineers that we have to hire this
1:03:31
year and um so this is so you can like a conscious step we are taking
1:03:39
but I don't think this is unique to shape up and I really enjoy that this
1:03:44
book exists and then our playbooks exist and oftentimes there is but the book says and then we say yeah yeah we tried
1:03:51
that and that doesn't work because of XYZ so yeah I don't see a real problem there
1:03:58
um if anything a builder project really is beneficial over classic kanban
1:04:05
responder work because it gives more structure so what we try to do for new
1:04:10
hires engineering new hires is to put them on a buildup project rather
1:04:15
than working off of the responder board um and just to stay on the topic of
1:04:22
hiring for one more second you mentioned in the beginning how that how you reflected upon needing to hire for
1:04:29
Fitness to shape up as a as an idea or it kind of it demands certain
1:04:35
characteristics of somebody yes maybe you want to speak yeah you need um a good amount of pragmatism like you
1:04:43
cannot strive for the what I often are oftentimes called The Gold version like
1:04:48
the if you had infinite amount of um resources that would be it
1:04:54
um I I even don't believe that like if you have an infinite amount of resources that is not a guarantee for a great
1:05:01
outcome I worked at Facebook before and then the other one is you need
1:05:10
for this autonomy to work you need self-driven people with like customer
1:05:15
empathy that like think in in value they add and not so much technical
1:05:21
only maybe that's the same thing like you don't strive for technical Excellence
1:05:27
but for good enough to meet the value and and yeah maybe that is the same
1:05:33
thing pragmatism and all of it and and that is not everybody's um cup of tea and I I totally acknowledge that
1:05:40
um maybe maybe I took your questions wrong maybe there is a text you have to
1:05:45
pay in form of the people you want to hire but thankfully um
1:05:51
um we are very aligned at the company as to which people we want to hire when it comes to product for example
1:05:58
we have a multi-step hiring process as as it is um and we have a take-home project as
1:06:06
part of our hiring Pipeline and that is write a pitch I want every product person including
1:06:13
the product designers um to be able well I mean both both they
1:06:19
product managers and product designers to be capable of shaping a solution they need to be able to come up with
1:06:25
Solutions and they need to be able to put it in words that are digestible within minutes
1:06:31
um like and then we share with them the template our template we link to the original book as Source material and
1:06:38
then we have a scenario that is not memfold actually but something everybody can understand or should understand if
1:06:45
there are product people and then it's their goal to to write a pitch so I hire for this in mind
1:06:52
yeah makes sense and then I guess it's not so much a text though so you were right to kind of turn that down but a
1:06:58
filter that you have yeah yeah before I come to my closing questions is there
1:07:04
anything you feel like uh we've missed um in preparing for this talk do you see anything that you want to get in one
1:07:12
observation is that in the early days after we successfully implemented this success being defined as we went from
1:07:20
Total everything is chaos to we can finally tackle strategical
1:07:26
um projects strategic projects I think that took us about six months
1:07:32
um and after that other teams like the go to market team they wanted to adopt a shape up as well that didn't go so well
1:07:40
um I am not too deep into that to answer why um but I can say that they were like
1:07:46
intrigued by the idea and wanted to adopt it maybe there is something there
1:07:51
um maybe it is just um like coincident that it didn't work for us
1:07:56
um maybe maybe try it out oh yeah we still do retrospectives and I
1:08:01
think that is that we do that during cooldown and that is a great source
1:08:09
um of ideas to refine the process and Define
1:08:15
redefine all of this oftentimes that leads to new experiments we want to try for example
1:08:21
project management should come from engineering or Cadence needs to be altered or we need a real re-brief as a
1:08:30
tool to inform other functions in the company and also write perspectives are they
1:08:36
within the Builder teams or are they across the whole cycle everybody so we do per Builder team one dedicated
1:08:43
retrospective and then the responders all together Drew one platform team does one solution and does one and then we do
1:08:50
a roll up so from the retrospective we condense action items um and these action items are then
1:08:56
shared across all but what we do because in order to keep the iteration kind of
1:09:01
the same then for everybody I guess that's swag exactly so oftentimes like um and then we like we have this culture
1:09:08
at my fault where we give um shout outs and and Kudos um a lot like during all hands we have a dedicated select channel
1:09:14
for it but that also happens during retrospective and oftentimes like there are learnings in the Builder project
1:09:19
that affect platform and responders for example it was so great they could help us and then it's really interesting to
1:09:26
see how platform perceive that at the same time and sometimes that that holistic perspective leads then only to
1:09:32
the change in process great yeah the responsibilities of a
1:09:37
builder are many I forgot to mention but also user facing documentation user here
1:09:42
being another engineer but still is part of the deliverable so coming back to
1:09:47
your tax you're paying yeah if you need a well-rounded experienced crowd to to
1:09:54
run a successful Builder project but I think one way you are making this work if I understood you correctly is by
1:10:01
having these detailed playbooks and to be able to share the expectations very transparently with everybody in the same
1:10:08
way yeah I mean transparency certainly is a quality of our company but in the end it's um the individuals and every
1:10:15
person um on the company who has to meet these expectations and
1:10:21
I I can imagine that this is difficult I mean hiring a general is difficult I have a hard time finding
1:10:28
um the the right people but I hear that this is true everywhere so
1:10:33
and and I can for my past experience yes that is true I don't think if you set
1:10:38
the goal of a hiring experienced uh people with our particular needs I think
1:10:45
it would be equally challenging with or without Shape Up makes sense all right second to last
1:10:52
question what advice you can be quick on this one but kind of
1:10:58
what tidbits of advice would you give other teams thinking about trying shape up and maybe the way to think about it
1:11:04
is if you know what might you tell Haiku who's living in a parallel universe
1:11:09
that's off by one or two years is there any shortcut you could have taken to where you are today or is it really did
1:11:15
you have to go through all this pain of iterating your way here I don't call that pain
1:11:21
and I'm not saying that we are converging to the one truth um the team is changing and so are the
1:11:29
preferences I wouldn't be surprised if in a year from now we are closer to
1:11:34
something we have unsuccessfully tried in the past that is now working so I would totally Embrace iteration not um
1:11:41
to reach you know Enlightenment but to embrace the nature of an ever-changing
1:11:48
environment uh what would I tell myself I think independently from Shape Up
1:11:54
for me this whole product thing was really new and still is uh when I'm interviewing people oftentimes these
1:12:00
people have more experience than the like actual product work than I have and we've counted in years
1:12:07
um embracing that uh when you're when you're only thinking about shape up like maybe all of this sounds new to you like
1:12:14
just like try it out uh it it's easy to say at a
1:12:19
company that is relatively small uh where you take on a lot of risks anyway but I would generally
1:12:26
um advise people to just um try out what they if there's something broken and there's a need to make a change
1:12:32
um I found shape up as a viable Foundation next to
1:12:37
more popular approaches lastly I'm always on the hunt for
1:12:42
interesting book recommendations that go beyond the most recommended product management product development books so
1:12:49
my question to you is what book can you recommend for our audience that has an impact on your work but that's from a
1:12:55
different domain maybe yeah if there's something so let me first start like you asked me that question uh like you sent
1:13:00
me that question last night and like I have some books on the like uh here um and actually the first thing I come
1:13:06
to moment is actually a product um book it's um called Product roadmaps relaunched
1:13:11
um and this is great material if you want to rethink Road mapping
1:13:17
um and don't treat it as a delivery schedule but because it's um on the topic I will leave it out still a brief
1:13:24
recommendation and then the next thing I'm an engineer by heart a book I read probably 15 years ago dreaming in code
1:13:32
this is it was really fun I think for some people especially the first 200 Pages or so are a bit dry a very
1:13:39
technical um Scott Rosenberg describes a real world
1:13:44
um project that arguably Falls in that category of infinite resources infinite time and it didn't go nowhere and maybe
1:13:52
I should read it again again it's been like 15 plus years I think from my perspective today they
1:13:59
were lacking strong product in that journey and I think a strong like
1:14:05
product team would have um pushed like this is a spoiler it didn't really go nowhere this is a open source project by
1:14:11
now and you can totally use it but it's not popular I think proper product work could have made this
1:14:18
a success but then there's one thing I really want to share and it's another book it comes from my hiring work last night I was
1:14:25
reviewing one of these take home um projects and the kinderberg
1:14:31
are closed with a section so like usual pitch and
1:14:37
intertwined with thought process but then the last page was so I ran this
1:14:43
prompt our description of the problem which is not even in the shape picture form but like just the prom the general
1:14:50
thing and then you need to transfer it into the problem statement and like value and all of it Plus Solution I put
1:14:57
that through chat GPT like we all have heard about AI in the recent months and
1:15:02
its advancements so the candidate um also put what AI had produced based
1:15:09
on the prompt and at first I was in disbelief because that was a pitch better than some I have reproduced by
1:15:15
humans so I went over last night which at GPT and actually try that ourselves using our interview pitch prompt
1:15:23
and it's amazing so it doesn't even teach like that's without our template
1:15:29
just the problem prompt and it says product pitch it doesn't even mention Shape Up and the structure is
1:15:37
surprisingly close to um the structure um that's spit out in the end surprisingly close to a pitch
1:15:44
format including solution and problem statement and then for those of you who haven't tried this out you can actually
1:15:49
push a button to re-um render like reiterate and propose different answers
1:15:55
and each time I was reading through that of course like sometimes the format diverged more from shape up than other
1:16:01
times each time I learned something so um that was maybe they literally there was a rabbit hole section uh or a value
1:16:08
section and each time there was something ah interesting that is a really interesting point here so I will
1:16:14
make a change to how I'm going to work on pitches where I will use um chat GPT
1:16:20
to um as an augmentation to my tool set to detect gaps in my pitches
1:16:28
where I have basically yet another person or like um
1:16:33
source to provide ideas towards that pitch to maybe discover blind spots that
1:16:40
I otherwise would have missed so that would be my recommendation that's super interesting I like that the augmentation
1:16:46
was though you're learning it not the oh I don't need to hire anymore oh no I mean like the actual solution was not
1:16:53
like really implementable I mean it was on the surface okay but like it's not
1:16:58
what you really need no I mean it's it's great to discover gaps and who knows maybe in a few years it will actually be
1:17:04
able to do that and then the the focus of your work is to carefully
1:17:09
um craft the prompt um I don't mind but like this was
1:17:17
um a surprise to me last night all right Haiku thank you so so much for your time
1:17:22
um where can people find you online if they want to follow up with questions or connect with you connect with me because
1:17:28
they want to start a career at memphis.com well that would be that um aforementioned website uh it's I think
1:17:35
it's memphis.com careers we are an international company I'm working in uh
1:17:41
like West Coast where we've been found in San Francisco we have an office in Boston but the product team we try to
1:17:46
hire in the EU time zone and Berlin so at menopause you will write me at haiko
1:17:52
at memphis.com and then personal website is highcorebearance.com I'm sure you can link to that from the show notes
1:17:59
there's not much on it a few hobby projects of mine um but then
1:18:05
um certainly ways to reach out to me and please do if you are interested in
1:18:10
working with us cool thank you so much Aiko it was a pleasure thanks David
1:18:15
[Music]
1:18:23
Michael I certainly did if you like this show it really goes a long way if you
1:18:28
leave a favorable review wherever you're listening to this and to find jobs at companies that work with shape up like
1:18:35
manfold remember to check out Shapers dot Builders again that really is the
1:18:41
domain thank you so much for listening and I hope you have a great day [Music]
1:18:47
thank you [Music]