Bouncing Back From a Derailed Re-Platform

Problem

I was originally hired at Docusign to re-platform the major money-making product they referred to as the ‘sending experience’. It was built on an old asb.net tech stack and I was meant to transform it into a modern technology stack. What seemed like a pretty exciting and straightforward technology transition became riddled with roadblocks. There were way too many expectations baked into it. 

It quickly turned into an experience transition, then it resembled a product transition by adding new features to excite people. As a Seattle based company, it also became a way for us to unlock new talent in San Francisco which was more motivated with node and new languages. It additionally was thought to be the solution for our cost efficiency projects because we would no longer be using Microsoft based stacks. 

The and’s began to pile up, and attached to that was a very unclear set of expectations. Anytime I would ask someone under any discipline what this transition meant to them, I was met with uncertainty. That, mixed with Docusign’s growing customer base and product acceleration was an interesting realization for me. We were about to rewrite a ten-year-old system that most likely was not entirely documented, with many features and capabilities that we do not price and sell, but were built-in aims of trying to please a customer or fix a bug. 

The turning point for me however came with the acceleration of things. I was meant to hit a certain date with a set of capabilities that needed to be built and begin running in production. We had tiered it by pricing level and when we hit the date, it was a great feeling of getting there, yet the adoption was minimal, both externally and internally. Nobody besides us was really celebrating that we had hit that milestone. Sales wasn’t incentivized to sell a still buggy re-platform that didn’t include all the features they wanted. Lots of teams around us were not setting up and installing/developing against these new versions. 

Despite hitting our goals, we did not gain cross-company support and buy-in, which further proved we were not aligned. This put the whole re-platform into question. I was unsure how to come out of a deficit defined by people not seeing its value and associated sunk costs. I was faced with the transitional wall of either stopping and calling it a day or re-pivoting to figure out how to carry on with the next phases of the project. 

Actions taken

At this point, it made sense to continue, but not how it was set up. I started by bringing clarity to what we were doing through a company-wide, open dialogue about what this project was and was not. 

First and foremost, it was meant to be a technology transition, so we needed to stay with that, meaning no experience or product changes. We were not looking to backtrack, but simply move forward in that direction from that point on. For me, that meant working closely with product and experience. They wanted the same goals, but were comfortable with us finishing a tech transition first, and then accelerating experience and product changes on a more nimble stack with easier release cycles. From there, in a joint agreement to help acceleration, we set a bar with the API’s to stop making changes from that point forward. 

The second part came through understanding what features worked in the old product. We had to investigate what our high-value features were in the old experience and work them into the new. Another thing we did was to work with some of our largest customers by listening to their issues and being upfront with why we were making changes. From there, we had to be competent in what we were doing by staying on schedule and not missing a beat on delivering the promises we were making. It became a company-wide thing until even the CEO’s table was convinced that the project was healthy and on track. At that level, it had executive buy-in, meaning that new customers would now only see the new experience. 

Lessons learned

• I’ll go ahead and say outright that transitions suck. They are just generally really hard for a company and its customers. Clarity, concern (listening to customers), and competence; if you stay true to these points, you have a large chance to be successful in any project. Our real success came when people outside of our team started celebrating our accomplishments. We were able to give them some performance gains and quicker release cycles, which is a very different relationship with the customer than just making changes in front of them. 
• How you bring value to customers is an important aspect of the transition. You have to understand the pain points of your customers. When you speak to customers about making changes versus bringing unannounced change, they feel responsible and accountable with you. We established a lot of trust by being able to bring them along on the journey, learn from them, give them ways to opt-out, and run beta programs in order to quickly reiterate back and fix issues. 
• It is easy to come in with new ideas, but always assume that the decisions made before you had value to them. It is important to understand the ‘why’ before coming in with a fresh set of eyes and deciding that everything is wrong. Every little thing that was previously done had a reason behind it. I felt like the new regime wanted to make it as minimalistic and easy to use as possible with little consideration of what came before. Those who really took the time to understand the customers and the previous work, and then brought that value to the new experience, were the most successful in helping re-write the transition. 
• You may get to the finish line with a perfect project and timeline, but as you evolve in your career, other people have to celebrate your success, not just you. To do that, you have to pull very different muscles. As an engineer, like myself, you may be focused on the ‘how’ very early on, but as you grow in your career as a leader, the ‘what’ and the ‘why’ become increasingly critical to everything you do. It is easy to write this off as a product thing, but it’s really a leadership attribute. You, as a leader, along with your stakeholders, need to be convinced and aligned with the ‘what’ and ‘why’. That transition has taken me awhile to get comfortable with. The more curious you become about the ‘what’ and the ‘why’, is when you start to have an influence on them. Spend energy there and trust your teams to focus on the ‘how’.