Cardio Partners: Into the Fire
Overview
I was brought in by Gnar, 2 months after the initial delivery date, to help complete the second half of a redesign for Cardio Partners’ in-house software. The original plan for the software was for it to combine their existing tech stack and freshen up the code base so that future development was simpler. I knew I was walking into a mess but goodness I didn’t realize how deep the pile would go.
The Cardio Partners project had two major feature sets that were initially supposed to be built by the same team sequentially but instead ended up being built by two separate teams:
Equipment: this was the original team that was working on the project they had two designers, two PMs, and a full dev team of 8-10 engineers. They had been working on this part of the project for going on 12 months when I started.
Services: this was my team, we had one designer (me), one PM, and two engineers. This part of the project was supposed to have been gathering Requirements and Documenting the feature sets needs for a month before I joined.
Discovery
I joined the first week and was expecting to have a pile of research and documentation to dig through. Instead I was given some technical documentation about the legacy software and a shrug. After many meetings of me explaining that what had previously been gathered was useful but not everything we needed; I finally received the all-clear to begin gathering requirements myself. At this point a new PM was brought in, and we started gathering Requirements in earnest. I brought the team up to speed with how we should be documenting this information. We defined their user/organization hierarchy, new service types, how they would be scheduled, the requirements for scheduling, how we were tracking all of the above, in weeks.
Outcomes of Discovery
I received glowing feedback from my PM and the client about how I was helping right this ship and getting what we needed. We began to build a rapport with Cardio Partner’s Subject Matter Experts and things started moving smoothly.
Design and Development
After we got our major pillars outlined we began design. Unfortunately this project was so behind schedule before I even began, that we immediately had to start development. This meant our design to dev pipeline was one sprint at most at the beginning. We were planning, laying, and executing tracks all at once.
Even with us entering into production in a major way, we still kept discovering new wrinkles. One of the largest was how interconnected certifications were with the rest of the software. We were spinning up classes that created certifications, that allowed users to then teach a class. This feature, and others, kept throwing curve balls at us but our rate of hitting those balls kept skyrocketing.
One of my favorite features I designed was the dashboard card weight system. Since Cardio Partners’ users were extremely mixed-desk in role. This meant that we could not just design a dashboard for each role. I designed a system for applying points to different cards for each role then based on the roles applied to a user, we could assign an order to the cards equal to the highest score on each card. This ended-up being so successful that we used this system app wide to determine how the cards cascaded based on the role viewing an entity.
After a couple months of hard work we had gained ground on development and actually had a backlog of work for them. This meant rework went way down and the quality of our output went way up. Our documentation kept improving and leadership on both Gnar and Cardio Partners took notice. They both came to the Services Team and asked how we were making such great progress. We had functionally lapped the Equipment Team. We spoke about the changes we had made, how our Requirements are documented and validated, and how are diagrams are made and maintained. This led to them both proposing we combine teams…
Outcomes from Design and Development
I was able to catch-up to a team working 6 months longer than I was. All with less churn and happier engineers. The client trusted me and my process.
The Beginning of the End
Unfortunately this marked the last couple months of this project. None of us on the Services team thought combining teams at this late of an hour was a good idea. We had built rapport, a system, and relationships that meant we could move quickly. We were already helping Equipment to do the same and taking on some of Equipment’s work to help out. Combining ultimately led to a ton of slow downs. No one knew who was owning any particular part of the project and things became more complex no matter how I tried to adjust for it. This slow-down ultimately caused the project to fall apart. The client just couldn’t allow for anymore delays.
Outcomes of the End
Even though this project was not a success, I still am incredibly proud of my work on it. I worked under great pressure and stood up to the plate taking on a leadership role when that was not what I was brought in for. Every one I worked with has said that my efforts, and experience, made a massive difference on the project.