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

🔥

Back to resources

Inheriting a Project Behind Schedule

Deadlines
Productivity

19 May, 2021

Shawn Hartsell
Shawn Hartsell

Lead Software Engineer at InVision

Shawn Hartsell, Lead Software Engineer at InVision, recalls his early days at a new company as he took over a project that was falling behind schedule.

Problem

I joined a company that was in the midst of changing its financial billing model. The project of rewriting the whole system had been in development for a year and a half and had been passed around to different teams. However, no significant progress was made, and I was hired to take up where everyone had left off.

When I joined the Monetization team, I was told that the project would be completed within three months, an unrealistic assessment made on past estimations. Even a cursory glance at figures assured me that this was not possible. Project objectives were not clear, no tracking was set up (not even in Jira), dates seemed randomly picked, and PMs could not come to a consensus on how the UI/UX would look like in the end . Moreover, the whole project was looked at from an isolated perspective of building code without thinking about the larger business impact.

Actions taken

For starters, we had a week-long onsite with the original product and engineering team and all key stakeholders to reevaluate what has been done so far. The intensive communication also helped us familiarize ourselves with the problem, gain domain knowledge and identify the most critical gaps.

After I did some digging, I realized that problems were not of technical nature. The code itself was quite decent. But as we started to map out the project and learn more about business cases, we realized that the code could not satisfy all of our business requirements. It had nothing to do with the code being buggy or alike but with gaps in product ownership. In lengthy conversations I had with the former PM, I realized how everything was wrapped in assumptions, and as a new person on the team, I was rather critical towards assumptions.

Soon I learned that the project was not tracked in any other way than spreadsheets. I collected all available plans and created a centralized repository of all the documents. I studied all of the existing documents and did some back of the napkin math because we had no data to base our estimations. I was reluctant to make any commitments with insufficient data, particularly not to dates set by past team leads. Being transparent about that was critical because the leadership was led to believe that the project was further along than what it was.

To be able to provide some crudest estimation, we had to make a formal delivery plan of what we were going to build. The PM and I worked hard to put everything in Jira and then formalize the plan. We invited all stakeholders to take a look and give their feedback.

We laid all of the feature gaps in the plan. Once we wrote stories for the features, we committed not to work on anything until we knew what the definition of Done was. The definition of Done should also include who -- other than a developer working on a feature -- should define that. That was assigned to different stakeholders, and we slowly started to rope them into the decision-making process. That was a precondition to do the gap analysis -- what we didn’t have and what we should have.

The next thing I did was formulate a timeline that was not anything but easy with insufficient data at my disposal. I was cautious about setting up the final date and instead decided to go with small, incremental wins. I broke down everything into incremental deliverables and milestones. Some stories I inherited were too broad and too vague, for example, “write trial system,” and I had to reframe them first to be able to break them down.

We also sped up our regular two-week sprint cadence into a weekly sprint which enabled us to receive feedback faster. Our goals were based on that weekly cadence, and every week we were able to demo working software in production. We were lucky to have a great infrastructure that would allow us to deploy in production anytime we wanted. As we were pushing out more and more features, we started to work more intensively with internal stakeholders. They could give us fast feedback on which we could iterate even faster. By iterating quickly, using things like feature flags that we could easily toggle on and off, people could develop code safely while playing with the software.

Finally, gaining trust as a newcomer who took over a project other people worked on before was often taxing. I had never intended to diminish their efforts, but I had to provide an explanation about the obvious disconnect between our different approaches. Being open and transparent at all times helped me to earn trust even as a newcomer. The leadership appreciated my efforts to provide them with accurate data, and while they had more domain knowledge, they were willing to listen to my ideas.

Lessons learned

  • The importance of having a plan that breaks down deliverables into something that will bring incremental value to customers is critical. Including your customers and end-users in the development process as soon as possible will help you gain trust and correct mistakes quickly.
  • A great benefit of agile methodology and fast deployment is that you can receive fast feedback and reiterate rather quickly. In the end, the project that was planned to be completed within three to four months took about a year and a half. However, we were shipping bits and pieces all along the way and were open to feedback from customers and end-users.
  • Though I was new to the company, I worked on similar projects before and was able to identify complexities from the business perspective. I understood that the entire rewrite would heavily impact different stakeholders and, from the very start, made sure to have them on board.

Discover Plato

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


Related stories

Working From the Ground Up

23 November

Adam Hawkins, Site Reliability Engineer at Skillshare, uprooted an entire product and built it back up again with the help of his team.

Deadlines
Toxic Atmospheres
Adam Hawkins

Adam Hawkins

Site Reliability Engineer at Skillshare

Why Overloading Product Teams Never Work

23 November

Adi Purwanto Sujarwadi, VP of Product at Evermos, shares how he identified the symptoms of his overworked product team and worked towards defining conflicting priorities.

Managing Expectations
Product Team
Deadlines
Stakeholders
Adi Purwanto Sujarwadi

Adi Purwanto Sujarwadi

VP of Product at Evermos

Succeeding as the First Product Hire in a Startup

2 November

Priyanka Naik, AVP of Product and Technology at J.P. Morgan, shares her plan to bring a product to execution as the first product hire in a startup.

Alignment
Goal Setting
Product
Deadlines
Roadmap
Priyanka Naik

Priyanka Naik

AVP - Product and Technology at JP Morgan

Creating an Engineering Vision

25 October

Mustafa Furniturewala, VP of Engineering, uncovers how he created a succinct engineering vision with their company's values in mind.

Alignment
Mission / Vision / Charter
Goal Setting
Productivity
Mustafa Furniturewala

Mustafa Furniturewala

VP Of Engineering at Coursera

Powerful Reasons Why Goal Setting Is Important

12 October

Mary Fisher, Software Engineering Manager at DrChrono, shares how goal setting provides the foundation to drive an organization.

Goal Setting
Dev Processes
Deadlines
Productivity
Motivation
Cross-Functional Collaboration
Prioritization
Agile / Scrum
Mary Fisher

Mary Fisher

Software Engineering Manager at DrChrono

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.