Situation

Data exchange with external parties is an absolute necessity for our business. How efficiently and effectively we do this has a huge impact on our operation performance and also the reputation we have with our customers and partners. In this pursuit we were aware that our current monolith had a number of assumptions and deficiencies which made it difficult for us to scale the right way.

With the increasing number of integrations we were building, we knew this was going to become a mission critical aspect but then, considering the other priorities, it was not yet there on my roadmap. However, my engineering counterpart (who I will refer as EM) and I continued to have regular brainstorming on this subject.

As it started to impact our capabilities we decided to act on it. EM was very clear about having a microservice approach which could help us scale this arm of the product platform significantly. Having worked with him for over a year now, I had full trust in his idea and supported it fully. The question was, how will we execute on it. Who will do it?

From the look of it, it seemed like a purely technical initiative and given the number of things I was doing it at that point, I was supportive of my EM spearheading this idea. There happened to an engineer on the team who was not really a system architecture expert but someone who wanted to gain expertise in this area. EM entrusted this person to work on the initiative.

Right around this time, I was going on a 2-3 weeks vacation and I thought the timing is perfect. They could do the technical discovery and when i am back we could turn it into concrete actions. However when i got back, the work had barely started on the tech spec. With much delay the spec was ready and then we decided to build this service and set up different lambdas etc. as per the design.

Task

This is where things started getting really bad. The engineer on this initiative turned into more of an R&D with excessive delays and no real outcomes in sight. He was also not given much technical guidance and he really struggled to build something concrete. We began to be way off from the initial timelines that were proposed and I was worried it was going to impact our overall roadmap but more importantly our ability to build effective integrations for data exchange.

We had to course correct this. For a company with 50 people, an eng resource being fully invested in an R&D without concrete results was a huge expense and I had to salvage this situation.

Action

The first step I apply to any such situation is to introspect.

I somewhere down the line used my involvement in multiple initiatives as an excuse for not fully immersing myself into this initiative especially given it was a technical heavy.

One of my main responsibilities is to align the objectives between different teams especially engineering and business and I clearly did not do that by entrusting too much on my EM to drive. While assigning resource is purely his prerogative, I could have influenced it.

I strongly believe this was purely on me to shepherd it the right way. That is my job and I made it a point never to let this happen again. But coming back to this specific scenario. Here is what I did:

1. Because this was still not productionized, there was no real risk in halting this initiative. I had to work with my EM and take a decision to put the initiative on pause.
2. I went back to the whiteboard with my EM and tried to better understand what the solution was.
3. I challenged ourselves on the approach (BLAMELESS). I was really looking for a way if we could build something bare minimum and then do a proof of concept
4. Through this exercise, I also came up with a roadmap that had clear milestones embedded. This way we could prove the initiative was worth it by showing real and concrete outcomes.

In terms of resource allocation, we also happened to hire an architect level engineer who acted as the tech lead on this and help me and the engineering to design this the best possible way

Result

Though this initiative had a rocky start, I was not only able to salvage but also reap the benefits and achieve the vision we had.

As someone involved in a lot of platform related initiatives, I have immersed myself in understanding the technicalities to the required level.

With a well laid roadmap and clear success metrics, we have improved the overall efficiency of our data exchange capabilities by over 60% in that past 1 year

In my initial days as a Project Manager at my earlier org , i was having an offline discussion with one of the business leaders post a business review meeting and he mentioned about the amount of time his team spends day in & day out to identify & retrieve claims for an audit process . After listening to him, it appeared like a simple request that can be accomplished in couple of days, based on what I heard and I conveyed the same and told that I will talk to one of the Dev’s and confirm. He was pretty excited about this.

I discussed about the ask with the Dev and based on the high level information looking at few data fields that I shared with him. Dev also agreed with my thought process and provided an estimate of 3 days to complete the report. I created a story and assigned to the Sprint and informed the business leader that we will have it ready by end of the week. He was extremely happy & was really appreciative of the effort.

Dev started working on the request and an SME from the business team was involved to assist with identifying all the fields & requirements for the report. During this process, figured that retrieving some of the data fields wasn’t straightforward as it appeared. It required additional analysis & logic to be implemented. Dev informed that he would 2 weeks for completion. When I informed the business leader about this, he was not very happy about the delay.

As Dev was only available part time, we were able to deliver the report in 4 weeks and that resulted in bringing in 30% effort savings every month for the team. Eventually, everything ended well. However looking back, I should have taken time to get accurate estimates upfront before committing timeline, which would have avoided the churn. I did learn from this experience and i am make every effort to gather specifics before commiting timeline.

As the product owner of the homepage at a large ecommerce company, I took on a project that did not go very smoothly because I had greatly underestimated the complexity of the project.

In the midst of working towards a large homepage redesign, my primary stakeholders came to me with a request to add a wider breakpoint to the page in order to make it a more immersive brand experience with larger images. They were really passionate about this, and although it was not a priority given my roadmap, it seemed like an easy way to get some happy stakeholders (we’ve all been there, right?!). I confirmed with device usage data that we had a sizeable audience for the wider breakpoint, and the engineering team confirmed it would be a very low effort CSS change. The biggest lift would be from the stakeholder teams – they would need to get all new creative assets that would fit at the larger breakpoint. And since they advocated strongly for it, I went ahead and slotted the 1 point ticket into the next sprint.

While the engineering work was very straightforward, I failed to grasp the overall coordination effort with getting the changes live. We made the update across the platform, so it touched 9 different brand properties, which were owned by 6 different creative and merchandising teams. Each would need to be trained on the new asset requirements (dimensions, file sizes, etc), and each had a different process for coordinating those assets. We had also had a separate project queued up to support retina images, and I thought, since both of these projects require refreshed creative assets, we should combine these projects and launch them together. This caused even more confusion!

Ultimately I had to carve some time out from other strategic projects to get this initiative back on track. I created extensive documentation for the creative teams, and took the time to meet with each team individually to explain the new requirements and launch plan in detail.

This experience really highlighted for me that just because something is easy for engineering to do, doesn’t mean that it’s overall easy to do! Like any other initiative I led, I should have scoped this out more fully and had a conversation with my stakeholders about the full level of effort (not just engineering effort) and realigned on priorities from there. This was a great learning experience though, and just a few months later I led a project where these insights served me very well.

Let me tell you about a time where a website I managed suddenly showed slow performance and the mistake on our side was it was unnoticed until a user reported the issue to management. As a PM for that project, I took full responsibility of the situation and worked with the engineering team to quickly resolve it. This mistake taught me the importance of focusing and monitoring non functional requirements as well in addition to new feature development /adoption where I was mostly spending my time on. After deploying the quick fix, I ensured that such a mistake doesn’t get repeated by putting a good application management tool in place and set up to receive email alerts and necessary Pagerduty alerts when website behavior exceeds set thresholds/SLAs. I personally took the effort to also learn the tool myself to further analyze past issues and call out optimization areas to engineering. With that effort, we are able to show consistent page load times to be less than 3s. I also shared my learnings with others PMs in my team in a brown bag session so they could also benefit.