Plato Elevate Winter Summit has been announced (Dec 7th-8th)

🔥

Back to resources

Aligning Towards Product Discovery

Internal Communication
Collaboration
Team Processes

15 July, 2021

Catalin Stoiovici
Catalin Stoiovici

Head of Engineering Delivery at Capco

Catalin Stoiovici, Head of Engineering Delivery at Capco, discusses aligning engineering processes within an organisation that intensively shifts towards product discovery.

Problem

A few years ago, when I joined a new organisation, I had to navigate many challenges, from working for the first time on a very complex microservices architecture and a High-Availability system to working with OKRs (Objectives and Key Results) and product discovery altogether. My focus was split between ensuring efficient and effective project and product delivery, staff leadership, and team development. In retrospect, I could tell that the biggest challenge was taking ownership of the delivery backlog for a team working with product discovery.

Actions taken

I was fortunate to discover a book, "The First 90 Days" by Michael Watkins, before starting the role. It's a great book that helped me refine my framework of making a positive impact while simultaneously learning the lay of the land and finding your footing.

Firstly, I tried to approach the new role with a learning mindset. I spent time absorbing information and taking notes rather than taking charge and providing answers. Secondly, I tried to balance humility and ego, thus leading with confidence, without adopting a command-and-control style.

Here is a list of some of the actions I took that helped me achieve my goals and be successful:

  • Build knowledge around the product that the Engineering team was developing, especially around how we planned to work with product discovery. As an engineering leader, you must understand the product direction, strategy, and vision. You need all of those to navigate priorities better and, last but not least, build the "P" in the "MAP". I'm speaking about the "MAP" that Daniel Pink refers to in the book "Drive" – the initials stand for "Mastery", "Autonomy" and "Purpose".
  • Understand and shape the technical landscape and technical priorities for the team. Ensure that sprint by sprint, you pay the technical debt cost and prioritise engineering work alongside new shiny product features.
  • Visualise everything that matters. Peter Drucker famously said, “If you can’t measure it, you can’t improve it”. I ensured that every work item that the team was working on is captured and tracked in a ticketing system. Then I made sure the same happened with the outcomes. You should be able to answer whether you're on track with a delivery or not, if what was delivered in a sprint adds value or not, and understand how many production incidents you have at one time.
  • Adopt and promote OKRs. Implemented correctly, OKRs are all about conversations and alignment. They help teams understand what success looks like, how they recognise it, what they need to do to have the best chance of achieving it, what dependencies are there, and who can help and support them.
  • Review the ways of working. It's easy to get stuck doing the same thing over and over again without forgetting why you started doing it in the first place. That's not Agile. Agile is about inspecting and adapting and quick feedback. Reviewing what processes work and what not, experimenting with different ways that could work for your team is vital for finding what you want to keep and what you want to change.

Lessons learned

  • The most important lesson I learned was how to align engineering processes within an organisation that shifts towards product discovery. You will need to change how your team will operate to align with this product discovery.
  • The notion of requirements as a predictable and scheduled phase in the product development process is one of the most challenging habits for product organisations to break. Shifting from "requirements and design" to "product discovery" is a difficult mindset change both for product and engineering people. Both functions need to collaborate closely, agree on priorities, and understand what makes sense to invest in and what not. If you want to have product discovery, you can't have a unidirectional flow from the requirement to implementation and track the delivery plan as you would when you knew from the beginning how the end product should look like.
  • The core use cases of the product we were developing were well known (they've been previously built by a different team in the same organisation). On top of that, we produced our product backlog by running user interviews and adapting the backlog of features per the feedback received. This added a lot of changes in requirements from sprint to sprint. It turns out the discovery process is not always predictable. When things are not predictable, we usually try to force them to become. The temptation to build something and ship it, so at least you know you've delivered something was there, and we fell to it. We used the engineering team for full release cycles to build the software that was tested and deployed into production systems. It took months to get something usable and useful. We've consciously used the Engineering organisation to build a costly prototype and then used our live customers as test subjects. If I had the chance to do it again, I would probably be more resolute in agreeing to build something we might throw away. Or at least before we made sure we understood the end vision so we could better plan it from a delivery perspective and from the technical pieces that the team needed to consider head first.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Specialization vs. Wearing Many Hats

23 November

William Bajzek, Director of Engineering at Sapphire Digital, compares and contrasts a team structure that utilized siloed skill sets and one where everybody’s duties overlap at the edges.

Internal Communication
Collaboration
William Bajzek

William Bajzek

Director of Engineering at Sapphire Digital

Building a New Team in a Foreign Country

23 November

Adam Hawkins, Site Reliability Engineer at Skillshare, went all the way across the world to build a brand new team who worked very differently than he was used to.

Team Processes
Adam Hawkins

Adam Hawkins

Site Reliability Engineer at Skillshare

What It Takes to Understand Other’s Perspective

23 November

Nicholas Cheever, Divisional Vice President, Global Supply Chain Technology at Trimble Transportation, shares how to really understand someone else’s point of view.

Team Processes
Nicholas Cheever

Nicholas Cheever

Divisional Vice President, Global Supply Chain Technology at Trimble Transportation

How to Handle Team Collaboration After a Merger?

23 November

Nicholas Cheever, Divisional Vice President, Global Supply Chain Technology at Trimble Transportation, shares how he helped the acquired company’s team members understand the business mission and give them focus.

Acquisition / Integration
Team Processes
Nicholas Cheever

Nicholas Cheever

Divisional Vice President, Global Supply Chain Technology at Trimble Transportation

Mergers and Acquisitions: Collaboration tools hold a key to bringing cultures together

23 November

Neelima Annam, Sr Director Information Technology at Outmatch, shares how something as minor as collaboration tools can be a BIG issue during mergers and acquisitions.

Acquisition / Integration
Internal Communication
Collaboration
Neelima Annam

Neelima Annam

Sr. Director Information Technology at Outmatch HCM

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.