Search
Prakriti Mateti
One does not simply... rebuild a product
Edit
#technical-debt
#engineering-culture
#product-development
#ruby-on-rails
#agile-development
#monolith
#microservices
Summarized using AI

One does not simply... rebuild a product

Prakriti Mateti • September 12, 2024 • Sarajevo, Bosnia and Herzegovina • Talk

The presentation titled "One does not simply... rebuild a product" by Prakriti Mateti at EuRuKo 2024 addresses the complexities and challenges of rebuilding a technical product while simultaneously improving engineering culture. Mateti shares her experience with Culture Amp's Performance product, which was acquired as a Series A startup but had become outdated and inefficient due to technical debt accumulated over the years.

Key Points Discussed:

  • Need for Rebuild: Mateti explains the necessity of the rebuild as the existing monolithic systems were rendering the product unable to keep up with the evolving needs of their large customer base and a competitive market potentially worth $3 billion.
  • Initial Steps: The team began identifying and classifying technical debt, gaining visibility among stakeholders about the costs associated with these issues.
  • Gaining Buy-In: Buy-in was critical from various levels, from teams involved in the rebuild to executives, achieved through transparent discussions and presenting the benefits of a completely new architecture.
  • Execution of the Rebuild: The rebuild was meticulously planned to proceed in slices, starting with the most critical components, while maintaining a focus on high engineering standards and customer experience. They established guiding principles such as minimizing customer risk and ensuring the rebuild was invisible to them.
  • Technical and Cultural Changes: Besides the product rebuild, Mateti prioritized building a strong engineering culture aimed at enhancing engagement and ownership among the team members.
  • Metrics for Success: The team defined metrics for measuring success beyond traditional methods. They focused on engineering and customer experience improvements, eventually demonstrating significant enhancements in performance metrics, such as loading times.
  • Final Stages and Lessons Learned: Having successfully delivered the first slice of the product, Mateti discusses the challenges they faced, including dependency management and team dynamics during the rebuild process. She emphasizes that the ongoing adjustments and learning experiences are crucial for future phases of the project.

Conclusion:

Mateti concludes that even though rebuilds are often seen as perilous ventures, they can be beneficial under certain conditions. If teams face high technical debt and stagnated innovation, a rebuild might be the best pathway toward growth and market relevance. She offers lessons learned from their journey, suggesting others can adapt their strategies to ensure success in similar endeavors.

One does not simply... rebuild a product
Prakriti Mateti • Sarajevo, Bosnia and Herzegovina • Talk

Date: September 12, 2024
Published: January 13, 2025
Announced: unknown

"A rebuild is never finished, only started"

"Technical rebuilds are doomed to fail"

“It takes 3 times as long as you expect to rewrite a system”

We're rebuilding Culture Amp's second largest product - Performance. It came in as a Series A acquisition 5 years ago and has thousands of customers today with the largest one at 77k users. Against conventional wisdom, we're rebuilding it from the ground up with an aggressive timeline. The underlying model is outdated, slow to iterate on, and not extensible. The monoliths are riddled with tech debt, tightly coupled, patched and band-aided over many times, and won't take us towards the $3b global Performance market we're targeting.

That wasn't challenging enough already so I'm also using this opportunity to rebuild our engineering culture. Setting a high bar for engineering standards, ways of working, and hoping to improve engagement as we go.

In this talk, I'll share:

* How I came to this decision
* How we got buy in from Exec and the Board for a technical rebuild
* How we tried to set up for success, our principles and standards
* Where we failed
* Where we succeeded
* Lessons that could be useful for anyone thinking about rebuilding a product that's hampering speed and hindering your ability to innovate or deliver value to your customers.

The rebuild is still in progress. I don't have all the answers (or any!). But we've already learned much - what to do, what not to do, and where the spiders are hiding.

EuRuKo 2024

00:00:10.200 it was um 30 hours of flying door too to get here um so thank you for inviting me
00:00:15.879 and welcoming me into this beautiful city One does not simply rebuild a
00:00:21.640 product Emy Jackson said that it takes three times as long as you'd expect to rewrite a system and a colleague of mine
00:00:28.320 at culture amp very kindly said a rebuild is never finished only started how philosophical cultur amp is an
00:00:34.840 employee experience platform that does a whole bunch of things that you don't care about particularly I work on the
00:00:40.480 performance product which you don't care about much either but um I'll tell you that it helps customers to build High
00:00:45.600 performing teams which eventually lead to Better Business outcomes that's all I'm going to say about the company today
00:00:51.879 so this performance product came into culture amp through an acquisition of a series a start up 5 years ago in
00:00:57.920 2019 at the time it was really small but since then we've grown it to thousands of customers today now in total these
00:01:05.360 customers launch anywhere between 850 to 1,000 performance review Cycles in one
00:01:10.520 month and our largest cycle has about 45,000 employees participating that's
00:01:15.799 just to give you an idea of the scale and set the stage for the stock so the global potential
00:01:21.479 performance Market though is $3 billion this is where we want to go someday
00:01:26.880 towards a performance product that can lead This Global potential Market obviously we are very very very very
00:01:33.159 very far away from it right now up until last year there were many compounding technical obstacles in our way of
00:01:40.040 building that market leading performance product so this product is two monoliths one for the front end and one for the
00:01:45.759 backend the underlying domain model data model backend models and architecture were all outdated and our customer needs
00:01:52.200 had evolved since we bought this product originally there were also other modules sharing the same code base with us so
00:01:59.320 one-on-one and our goals products were all inside the same monolithic Cod base a whole bunch of shared concerns all
00:02:05.960 lived in the same house as well so things like notifications tasks authorization things that you would call
00:02:11.480 maybe more platform concerns then on top of that there was an enormous amount of tech de from
00:02:17.120 trying to scale and grow the product rapidly post acquisition and then finally it contained a lot of decisions
00:02:23.000 that were correct decisions at the time that they were made by the developers trying to bring this to Market quickly
00:02:28.640 but they were not correct decisions anymore in 2023 there were also eight teams working
00:02:34.519 inside these two monoliths with terrible domain separation there were too few people who understood how the entire
00:02:40.519 system worked or how both the code bases worked teams would invest weeks in starting a feature and then they just
00:02:45.959 wouldn't be able to finish because they would collide with another team working in a completely different part of the code base or so they thought there was
00:02:53.120 high coupling and low ownership the monoliths could not benefit from any shared tooling or infrastructure that
00:02:58.200 was available at culture amp all of this combined to create a very fearful engineering culture low engagement low
00:03:05.080 pride in our work and teams moving very very slowly basically I am describing the opposite of a high performance
00:03:11.319 culture the product itself was working for our customers and it was meeting expectations but in the near future
00:03:17.080 these challenges that I described before they would have seen us grind to a halt unable to innovate so we needed to
00:03:23.519 invest now to ensure that this product would continue to grow and scale and serve our customers for many many more
00:03:29.200 years to cut a long story short we were stuck in a hole a hole that maybe looks familiar to many of
00:03:35.280 you my name is prti so I'm a director of engineering as you heard um here from Australia at my first European
00:03:41.599 conference represent um so I'm just going to take a quick photo so I have proof that I was actually
00:03:47.640 here so today I'm here to talk you through our journey of getting out of that hole via a full rebuild I'll share
00:03:55.239 a few key Reflections at every step and I'm hoping that maybe that will make you
00:04:00.519 feel less alone the next time that you are in a hall going on a similar Journey let's start with the first step
00:04:07.480 so the first step was getting to the point where we even knew that we needed to rebuild before any talk of rebuilding
00:04:13.959 like obviously we tried everything else I used to hear a lot of noise when I joined about enormous Tech there's so
00:04:19.880 much Tech we're drowning in Tech but this teched didn't have any shape any name or any classification it was not
00:04:25.560 understood by our stakeholders the cost that it was exacting was not appreciated app it so we started by identifying
00:04:32.080 every last bit of tech debt inside the monoliths we gave it a classification and we gave it a name we ensured that
00:04:37.680 senior leadership exec our cross functional Partners in product and design could all talk about it then we
00:04:43.479 prioritized it bit by bit like everyone does we tried to fix it we tried to chip away at it that was taking way too long
00:04:49.840 and even if we did fix all the tech debt remember it was only one ring in those five rings of problems that I showed you before so it would still leave us unable
00:04:57.080 to iterate on the underlying domain and data model even if we somehow fixed all of the teched so next we tried peace me
00:05:04.440 re architecture inside the monoliths we identified domains that we could re architect while keeping the monolith
00:05:10.160 around those domains functional and working this actually worked but it was way too slow we had to finish doing the
00:05:17.039 peem architecture and then we had to take the product to winning in the market as well that would have taken far too long so in parallel with re
00:05:24.160 architecting we also tried extracting domains out of the monoliths everything was deeply intertwined it's just a big
00:05:30.680 bowl of mud spaghetti we did not have quick foundations for starting up new
00:05:35.800 microservices M mud spaghetti delicious why did I say that we did not have any
00:05:41.160 shared services available to like solve common concerns like notifications emails authentication authorization
00:05:47.759 account data employee data like where were we going to get all of this information we set up a small dedicated
00:05:53.319 tiger team and they executed like one example domain they extracted it from the monolith they documented it and they
00:05:59.400 created created a pattern for other teams to follow but again doing all of this helped us realize the reality which
00:06:06.080 is none of these approaches would get us where we needed in time to lead the market so we basically needed a really
00:06:13.440 big reset now as I go through the steps I said I'll share a few key Reflections at
00:06:18.520 every step a few things that went well for us during this first step what was previously a very amorphous statement of
00:06:25.520 oh no too much take de that turned into a clear breakdown with prior ization and rough difficulty levels for all the
00:06:32.479 major items of tech we were able to take that and use it to create visibility among leaders outside of the performance
00:06:38.960 product building awareness empathy and understanding in the rest of the organization we worked cross
00:06:44.919 functionally so that meant even if I personally was not present in the room there were other people from product and
00:06:50.039 design who would also be able to raise tech concerns and have that shared language and then trying everything else
00:06:56.599 possible before suggesting the rebuild doing it with High transparency meant that everyone was more receptive to
00:07:03.720 hearing that we needed to start over from scratch a few things that I've learned for next time maybe I should have
00:07:09.879 suggested it sooner now this is a really tricky one because if you suggest it very soon then people assume ah it's
00:07:17.160 just Engineers being Engineers they always want a fresh start they want to rewrite everything they want to work on Greenfield they hate Legacy and I feel
00:07:23.800 like no one takes you seriously but if you leave it too long then you've wasted valuable time that you could have
00:07:28.919 actually invested in rebuilding the product the second one is establishing trust and then seeking forgiveness over
00:07:35.080 permission we did a lot of the ground work without asking for explicit permission because we had already built some
00:07:41.479 trust now that we knew what had to be done the Second Step was to get byy in from everyone else we needed Buy in from
00:07:48.440 the teams who were going to do this work from design and product pairs from senior leadership that's other directors
00:07:54.680 and VPS and then finally we needed buying from exec and the board as well
00:07:59.800 to get that buy in first we need to know where we want this product to go this is a radar showing everything that the
00:08:05.680 rebuild will unlock for our customers in the outer rings so it's the promise of what can come after a rebuild
00:08:11.840 opportunities that are not even possible with the current monoliths we started with some Blue Sky
00:08:17.720 Architecture brainstorming we got a bunch of engineers in a room and we said hey if there were no constraints knowing
00:08:23.680 what you've learned today uh from our current product its limitations and where we want it to go how would you you
00:08:29.720 architect this product from scratch we did a lot of brainstorming sessions and people came up with many
00:08:35.800 different architecture options then we converged all those options into a potential architecture for the new
00:08:42.159 rebuilt product the goal here was just to validate the need for a rebuild we didn't want to decide the architecture
00:08:48.200 down to every last detail at this point we just wanted to see that if we took an ideal architecture and we compared it
00:08:54.040 with what we are living with currently then how different does it look if it looks very different that makes makes
00:08:59.600 our case for the rebuild much stronger so building that radar of opportunities doing these architecture exercises they
00:09:06.200 helped us to get buy from the team we involved cross functional stakeholders like product and design in the
00:09:11.360 conversation throughout and we kept senior leadership close to the work so that was enough to get Buy in from them
00:09:17.440 as well and then of course the previous things I shared that we tried before doing the rebuild we tried working on
00:09:22.760 Tech dead be M architecture that helped get senior leadership on board as well because they knew that we weren't just jumping ahead to a rebuild
00:09:30.680 to get exec by in obviously we needed a few more steps here we consulted a trusted external advisor this is someone
00:09:36.640 who has successfully actually completed a rebuild but I think more importantly they have seen several rebuild failure
00:09:43.040 modes and they kind of know what doesn't work as well finally we took all these inputs and we put them together in an
00:09:49.320 exec presentation which told the holistic story of the performance product I feel like that last step is
00:09:55.240 probably what got us through the final 20% of buyin we were seeking approval to completely rebuild this product from
00:10:00.959 scratch which is a really big deal for this company but it couldn't mean that our customers would see no new value for
00:10:06.640 a year or two years or who knows how long it's going to take I know now but at that time we didn't know so the
00:10:12.720 broader performance offering needed to continue on in other ways while we would be rebuilding our first piece the other
00:10:18.880 perform teams would deliver the most critical work that was necessary before we could go all in on the rebuild
00:10:24.680 together that helped us to get exec buing some reflection C for step two so
00:10:30.600 things we did well I think talking to that neutral external adviser who had a lot of experience under their belt was
00:10:36.040 great because it gave a lot of credibility to our plan then one of our product BS did a great job taking
00:10:42.160 everything that we had pitched and crafting a holistic narrative he put our customers first in that conversation
00:10:48.040 rather than focusing purely on the engineering side of things even though this was an engineering Gru we took the time to work out loud
00:10:55.320 with our stakeholders being deliberate about who needs to be included in every conversation ensuring that they were coming with us
00:11:01.800 on every step of the journey so that when we came with our final ask it was not a surprise for them instead by that
00:11:08.639 point they were kind of invested and now they sort of wanted it as well and
00:11:13.680 finally slowing down at this step really enabled us to go faster later although slowing down kind of cost
00:11:20.279 us as well so that was a bit of a double-edged sword we worked away from the teams longer than I originally
00:11:25.519 wanted to which created a lot of uncertainty for engineers in imagine you're in a team just working on the
00:11:30.760 regular performance road map and then in the background there's all these people and all these talks about a rebuild but it's all Whispers And murmur and it's
00:11:36.880 not very clear I also wish that we had created more active spaces for debating our Tech choices collectively as a group
00:11:44.279 I feel like we failed to get true buying on some of these Tech choices at the start which later on contributed for our
00:11:51.279 pivot so we had to Pivot away from Hanami back to rails after we had written a lot of code normally I duck
00:11:58.560 after I say that but I don't see any Hanami enthusiasts throwing things at me so I'll just keep
00:12:04.399 going it also shaved a few years of my lifespan because it shook some confidence in what was already a really
00:12:10.240 big bet now we had buyin but it was still a very big risky ask we proposed that
00:12:17.600 we'll pick up one slice we'll deliver it all the way to our customers in doing so we'll prove out our new architecture the
00:12:23.440 new domain model the technology choices and our ability to actually do this in a reasonable time frame there was an
00:12:29.839 immense amount of pressure and high visibility on this first slice literally the whole company's eyes were looking at
00:12:35.959 the team working on this it that's because it was a big bet for the entire company not just for this product we
00:12:42.320 knew that if the First Slice failed or went sideways that it would risk the existence of the rest of this rebuild
00:12:48.880 all of this made it very important for us to kick off really strong with the First Slice because there was a lot riding on
00:12:54.560 it we had to set it up to succeed with everything we that was available to us so we started by setting some goals we
00:13:01.079 all love setting goals on the product side our goal was to produce a domain model that we can
00:13:07.000 iterate on architecture which will support future use cases clear ownership for teams during and after the
00:13:14.199 rebuild well that sounded too easy and we like to live dangerously so I shared earlier some challenges that the teams
00:13:20.720 were facing at the time we thought n it let's rebuild the teams as well
00:13:27.160 so at the same time as rebuilding the product we also decided we're going to create fast moving teams strong
00:13:32.320 engineering culture strong ways of working High engagement opportunities for learning growth and development all
00:13:37.920 of those things we were going to do it all we were going to do it simultaneously in a really aggressive time frame that was crazy who
00:13:44.560 decided to do that it's me um we laid out some ground rules or
00:13:50.639 principles to try and help us succeed here we called the first principle like for like we were not going to uplift the
00:13:57.120 entire user experience and we were not going to add any new features at all we were going to take our existing product
00:14:03.000 and stand it up over here on a futureproof codebase and domain model using the latest tooling and Foundations
00:14:08.759 we would be reasonable of course and we would try to do things the right way we would end off life some features that were not being used we would use our
00:14:14.920 design system components and we would set high standards but we were not going to add anything new that was for two
00:14:21.000 main reasons firstly we don't want this rebuild to last forever if we tried to redesign the entire customer experience
00:14:27.720 while also rebuilding the entire domain model and rewriting every single line of code that was going to be a NeverEnding
00:14:33.440 project we didn't want continuously changing goal posts secondly we wanted to reduce customer risk as much as
00:14:39.360 possible the rebuild should be invisible to customers they really don't care our next principle was that we
00:14:45.320 would phrase the monoliths we would not allow the old and the new product to potentially drift away from each other
00:14:50.959 in different directions we would not allow any communication back from the new product to the old one and we would
00:14:56.959 never allow some customers to be sitting on the old and some customers to be sitting on the new for long periods of time decommissioning the old one was
00:15:03.600 part of our definition of done and then finally we resolved to be deliberate in every step we take we are
00:15:09.880 taking the time and we are putting in effort to create high engineering and design standards we are investing in
00:15:15.639 building High performing teams as we go through this journey the total scope of the rebuild
00:15:21.279 which we call Core performance was divided into roughly six spaces obviously you don't care about this
00:15:27.440 product and what the six spaces are so let's just use this as a representation for the first piece the First Slice we
00:15:33.839 picked up self-reflections so we chose self Reflections for these reasons firstly it
00:15:39.480 was well used by customers we wanted real customer traffic to the First Slice otherwise how would we validate our
00:15:45.759 choices second it was in the worst shape of all six pieces because it had not been touched in the longest the third
00:15:53.240 reason was that it was relatively isolated so big very massive ball of spaghetti but C Reflections Maybe could
00:15:59.199 have been untangled a little bit that means that we could focus one full team on self-reflections rebuild while the
00:16:05.360 other teams continue on their normal road maps delivering the most critical customer features this gave us time and
00:16:11.959 space to validate our decisions in the First Slice while also solving some immediate customer needs before we
00:16:17.800 phrase the monoliths entirely this was essential to that last 20% of buying that I mentioned before
00:16:24.079 forming the holistic narrative around the ray belt and then finally self-reflections had just the the right
00:16:29.160 level of complexity we didn't want too much and we didn't want it to be too easy either we felt like if we can do this one then it'll be a fair
00:16:35.360 representation to say now we have some confidence that we can probably do the others as well then we took a few targeted steps
00:16:42.920 to set up this first slice for Success we created a Goldilocks time frame commitment long enough that we do it
00:16:49.959 right but not so short that we are forced to cut a lot of Corners this time frame commitment would make us think
00:16:56.160 about trade-offs rather than spending too long trying to rebuild everything perfectly we kicked off with a small a
00:17:03.279 team of sorts we brought in a mix of our strong performers domain knowledge subject matter experts embedded in
00:17:09.400 knowledge of adjacent things like the design system frontend tolling backend tolling by bringing in people from other teams across the org I feel like this
00:17:16.439 gift reveals my age and if you didn't laugh I know your age as well we then took a Firm Stance of
00:17:23.559 adopting all internal standards where internal standards didn't exist yet because of very in maturity levels like
00:17:30.240 accessibility was not super mature at the time we tried to establish our own informal metrics while still maintaining
00:17:35.679 high speed and we needed an internal PR campaign to get people excited this
00:17:40.960 initiative would have felt really risky intimidating to ambitious maybe and quite scary so we needed a PR campaign
00:17:47.520 to get people buzzed about it most of that work and and we actually did manage to ship the First Slice overall I would
00:17:54.240 say it went really well but of course I would say that it's my project um but no really we like we didn't ship anywhere
00:18:00.360 close to the initial date that had been suggested to us as a Target but we did ship very close to the first estimate
00:18:06.400 delivered by the team we scaled up as we rolled out to larger and riskier customers we had very few
00:18:12.679 incidents this was the most crucial step of all five so most of what I shared in the previous slides the goals the
00:18:18.360 principles how we set the team up for Success it's all part of what went well in this step but I will add a few more
00:18:24.440 Reflections at this stage we set up a clear decision-making framework that owed us to move fast it helped us get
00:18:30.720 clarity on what's the decision who is the decision maker who do they need to consult what's the level of the decision
00:18:36.320 and an engagement model with our senior leadership stakeholders obviously this was a very exciting project and everyone
00:18:42.600 at the company wanted to have their fingers in the Spy but this saved us from being blocked by the availability
00:18:47.720 and schedules of others from seeking approval for everything and from having too many cooks on the kitchen I don't
00:18:53.559 know if you've noticed but all my metaphors are around food um and maybe that's something that I should reflect
00:18:58.919 in myself but I'll keep going for now it empowered the team to make bold choices and move fast um and honestly I feel
00:19:05.600 like that one point is enough for its own conference talk we had a lot of firm trade-off conversations and we
00:19:11.679 aggressively protected the scope of the EAP we took on a few informed risks of course the gold to looks time frame was
00:19:18.000 really good because it forced us to avoid gold plating and think hard about like what's good enough and what standards do you need to
00:19:24.159 set we got clear prioritization from exec and Leadership that helped us to get capacity dedicated across other
00:19:30.520 teams where we had dependencies the first slice had 18 dependencies outside the perform teams and then we invested
00:19:37.720 time early in building a new domain model for the entire product not just for the First Slice we did that with a
00:19:43.159 cross functional group involving a few key leadership stakeholders as well this was a tough ride which means a
00:19:50.039 lot of lessons learned for me first of all the initial Target date the high visibility high pressure of the market
00:19:56.720 and the company it made the team feel really stressed then establishing
00:20:01.760 momentum was a big struggle for them they had been thrown into the deep end and asked to start building this
00:20:07.480 immediately and not given any time to plan many of the team members were strangers to each other because we brought them in from different parts of
00:20:13.400 the company so they were not able to prioritize planning refinement estimation at the correct stages of the
00:20:19.520 project they eventually did these things but it was quite late and by then it had already impacted their momentum and
00:20:25.440 their engagement we also learned a lot of lessons on dependency management this is the biggest cross team initiative that
00:20:31.760 has ever been done at cultur amp culture amp has about 300 people in the product group um and this is the biggest we had
00:20:38.039 ever done at the time we didn't have a high maturity model to manage dependencies and cross team collaboration particularly because we
00:20:44.760 knew this project would take at least a year that was quite a big ask we have all that stuff now which is
00:20:50.360 good now with this rebuild being like Fike it looks fairly invisible to customers so it's kind of hard to
00:20:56.159 measure success we could not measure success in the usual ways like you have a
00:21:01.480 hypothesis you validate the hypothesis you have product analytics customer adoption Revenue metrics like that's how
00:21:06.840 you would normally measure success but we couldn't do that because it was invisible we had to Define what metrics
00:21:11.919 were important to measure and how we would measure them to ensure that ongoing buyin we decided to go with
00:21:17.200 engineering and customer experience metrics instead so think back to the goals I had shared before and the
00:21:22.760 principles we wanted the new experience to feel similar or a little bit better but it definitely could not be worse and
00:21:28.840 we also wanted teams to feel pride in their work like they are high performing delivering high quality
00:21:34.039 products we used the largest contentful paint time as a simple proxy for the customer experience metric a good LCP is
00:21:41.120 considered up to 2.5 seconds so the old products average was 3.3 seconds very
00:21:46.960 bad uh the new On's average is 1.5 seconds very good the max LCP of the new
00:21:52.120 product is also in the green range now there are a few features that are really heavy and they deal with a
00:21:57.520 lot of data so we measure the performance of just those features separately and we assumed that if these features are improved we don't need to
00:22:03.799 check the performance of every single action that the customer can take on the developer experience side of things the
00:22:09.840 front-end deploy time used to be 20 to 40 minutes now it's under 10 minutes and the backend deploy time was 40 minutes
00:22:17.320 to an hour and now it's less than 5 minutes we also made huge improvements
00:22:23.039 to the adoption of our design system and accessibility one metric which we did not use at the time but I have gone back
00:22:29.360 and added it into the slides recently so in the old product there were 560 usability issues to sitting in the
00:22:36.039 design backlog and then as we've gone through the rebuild we've already fixed 312 of those issues even though we are
00:22:43.000 rebuilding like fores that's a huge customer experience Improvement what can I say about this
00:22:49.159 step everyone loves a good metric we were able to prove that even though we are building like fik we are still
00:22:55.159 delivering measurable customer value as well as cultur Ram value it's not just an engineering Gru anything we can do to
00:23:01.919 make that ongoing Buy in Easy particularly from people outside of engineering and product who may not understand why we're doing this we did
00:23:08.679 struggle to measure some of these metrics the old version is very hard to work with we need to invest more time I
00:23:15.159 think upfront in um instrumenting this and I would also love to set up specific metrics next time to instrument key
00:23:21.640 trade-off decisions so we can validate afterwards whether we made the right decision or not it was a really hard journey but we
00:23:28.279 did it we shipped the First Slice we gained confidence that we knew what we were talking about and we were on the right track we had a massive retro and
00:23:35.200 reflection session post for celebration recognition acknowledgement
00:23:40.679 schwarma unfortunately it was not too long of a break we immediately were
00:23:46.400 forced to Pivot to what's next one down five to go projects
00:23:51.760 basically done am I right we had to take everything we learned from the First Slice which was pages and pages of wins
00:23:57.799 and lessons and turn that into a plan for the remaining five slices but we did
00:24:03.080 not have a plan or to be more truthful I did not have a plan we had done just
00:24:08.480 enough big picture thinking to validate the need for the rebuild and to get Buy in but then after we shipped the First
00:24:14.200 Slice suddenly we were expected to have a plan for the remaining five slices we didn't have even a p forget about a plan
00:24:21.799 so remember when I showed you this radar we went back to the radar first we extracted some potential future road map
00:24:27.480 items to use as examples it was important to never lose sight of why we are doing this reil it's not just for
00:24:33.279 fun it's easy to get lost inside the weeds of a mostly technical rebu we had to keep current the opportunities that
00:24:39.679 the rebuild needs to unlock to be considered a success it was time for you guessed it
00:24:45.440 more brainstorming we got a group together and we considered multiple potential architecture options this time
00:24:51.080 for the entire scope of the product based on what we had learned from the small First
00:24:56.320 Slice next we thought of possible team structures for the remaining slices now that the First Slice had shipped we had
00:25:02.679 Frozen the monoliths and we could put all four teams onto the rebuild initiative we overlaid those team
00:25:08.559 structures on top of the architecture options those are the crude circles in the screenshot yes that is the peak of
00:25:15.000 my visual design skills then we considered different stakeholders perspectives on what we
00:25:20.960 should optimize for the idea was not to just arrive at one list it was more about surfacing unspoken priorities and
00:25:27.919 gauging that we were at least 80% aligned directionally finally we picked the
00:25:33.360 option that made sense for everything I talked about so first the anticipated product road map then layer on top of
00:25:39.399 that the architecture options and then layer on top of that the ideal team structures which allow fast iteration
00:25:45.200 domain ownership and high performance so imagine all three in layers I only have two hands we needed a plan that worked
00:25:51.399 vertically across all of these layers I present to you the plan so things that served us well in
00:25:58.640 this phace the overlay method of looking at Major facets that could influence our success simultaneously product road map
00:26:04.720 ideal path architecture ideal team composition that was a bit unusual but considering all these together allowed
00:26:10.000 us to see the trade-offs very clearly and to come up with the most acceptable plan getting Clarity on what everyone
00:26:16.440 was optimizing for was really important everyone was coming at it from their own area of expertise we had to get that
00:26:22.279 shared understanding to help us find the option that worked for the most attributes that we wanted to optimize
00:26:28.840 we tried to set a cultural expectations in the teams that you should prepare for frequent change and we asked them for
00:26:35.559 high agility as we went through the rebu and finally it's very rare at culture amp to have one product space
00:26:42.480 with multiple teams focusing on only one initiative with very few distractions that Focus was a gift and so we tried to
00:26:49.039 leverage it as much as possible a couple of things we struggled with in this step the high change
00:26:54.799 environment we needed to Pivot this plan a couple of times as always happens plans don't go as per plan no matter how
00:27:01.760 much you try to set those expectations early change is still hard and not everyone can be equally
00:27:07.880 resilient the visibility and the pressure that we thought would decrease after the first slice did not decrease I
00:27:14.600 don't even know how but somehow it actually increased so let's skip ahead a few
00:27:19.840 months this is where we are now seeing the light at the end of the tunnel we know what we're doing a lot of unknown
00:27:25.039 unknowns have been validated now we only have known unknowns we've put four teams on it instead of one team so we have
00:27:31.159 maximum paralyzation we are about to ship the next three pieces all together
00:27:36.200 by the end of this month because customers use them alog together their data is linked and remember the
00:27:41.360 principle about V2 not communicating back to V1 so they have to move all together so that's like very very very
00:27:48.320 close to done as you can see in the middle box there hopefully by the time I return from this conference that middle
00:27:53.799 chunk will have shipped yes I left at the perfect time by the way while the TV is trying to just ship that last bit of the most
00:28:00.440 critical slice of this rebuild it's fine so that will leave just one last slice remaining which we have started and we
00:28:06.399 are hoping to finish by the end of this year and then profit I guess is this
00:28:11.840 talk being recorded and uploaded so it's on the record now that it's going to ship by the end of this year that's great cool cool cool
00:28:17.960 cool so I'm not going to talk about step six today we are still executing the final bits of the rebu and step six is
00:28:24.000 not done yet I'm not really sure how it's going to finish if everything goes to then it's going to finish this
00:28:30.399 way but if things go as planned then it's going to finish this way so I guess
00:28:35.960 you'll have to invite me back to the conference next year if you want to find out how it ends so people say that rebuilds are all
00:28:44.240 always a bad idea I'm here to disagree I say that if you have a domain model that
00:28:51.640 can't take the product forward I'm just going to make this a little bit bigger you're stuck with series a decisions
00:28:57.440 that areand it over and over again your teams are slowly grinding to a halt and you have a lot of tight coupling you
00:29:04.279 have an underperforming product but it is a huge potential market for that product and you have tried everything
00:29:10.840 else then a rebuild could be your best shot you could do it with steps that
00:29:16.240 look something like this with the stuff I shared earlier what went well for us what didn't go well for us and the lessons that we
00:29:22.480 learned however if these conditions are not true for you then I can't help you
00:29:28.760 you're on your own and you've just wasted the last half an hour I'm kidding it doesn't necessarily mean that a reel
00:29:35.519 is not for you but you might need to look at the steps I shared before the things that went well and didn't go well
00:29:41.799 for us and you might need to figure out how to tweak those for success in your specific conditions but I mean yeah it
00:29:48.880 could also mean that a rebuild is not the right step for you I'm not here to sell rebuilds by the way I don't know I
00:29:55.399 just work here so thank you for listening and if you have any question questions please find me afterwards or hit me up on Discord
Prakriti Mateti
@itirkarp
Explore all talks recorded at EuRuKo 2024
+39