The role of collaboration in a remote release

Since I graduated with my degree in computer science in 2011, I have been pretty clear on what I wanted to do. I wanted to work with smart people, for a great company, and dive into software development. 

I didn’t finish college my first go around and was doing just fine until the 2008-2009 financial crisis. I found myself as a single mother, working to provide for my children and struggling to stay afloat. So, I decided to go back to school. I set my sights on computer science because I had a knack for math, logic, and details, and I have several family members who were very successful in the tech world. Over the following two years, in addition to working full time and caring for my children, I spent nights and weekends finishing my degree. My kids were there to see me walk across the stage to receive my diploma. Sure, I did it for the earning potential, but I also did it to show them that hard work pays off.

I received a call from a local Nashville tech company asking if I was interested in joining the QA department. At that point, I had never heard of a QA department. What I thought at the time was a spam call, turned out to be my first step into my career working in tech.

I got hooked on QA from then on. It’s always been a great fit for my personality; the attention to detail, collaboration, and coding skills necessary to excel in the field are all assets that I’ve gotten a lot of satisfaction out of perfecting over the years. 

About two years ago, I set my sights on a new career goal: working at Abstract. To me, it was a dream job. The draw of working with a distributed workforce and not having to endure Nashville’s daily commute was a big factor, but I was also fascinated with Abstract as a product. Having the opportunity to work on a team collaboration tool felt like a great fit to me. 

I’ve always been proactive, so after consistently visiting the Abstract careers page for a while, I saw a QA role go up, and I applied. Now I’ve worked here for almost two years, and was recently promoted to the role of Engineering Manager. 

This year, I had the opportunity to take on the biggest challenge of my career so far when I was tasked with helping to launch a new product remotely. As we geared up to launch Abstract Notebooks — our new designer-specific platform for cross-functional teams to gather requirements, review designs, and continuously measure what works in one space — I knew this would be a big feat to pull off. Managing any product release is always a big effort with many moving parts, and adding a 100% distributed workforce into the mix had the potential to complicate things even further. 

We pulled it off with a lot of work, planning, and careful coordination. Here’s what I learned from the process.

What made this launch different

Being in the role of QA, launching Notebooks certainly wasn’t my first rodeo in terms of managing releases, but it was my biggest. When it came down to it, Notebooks was an entirely new product, so in many ways, we were starting from square one. It took me a while to fully grasp the scope of the project, but I soon realized that it was truly going to involve everyone: sales, marketing, customer support, user education, design, and engineering were all involved, and they all had an important role to play. 

Having this many people involved in a new product launch meant that there were many moving parts. In a lot of ways, it was the ultimate test to see if remote releases can actually work. Would different time zones get in our way? Would we be able to discuss and plan asynchronously and still be on the same page? Would there ultimately be too many moving parts to manage well?

In order to quell these fears, we had to do what we do best: plan and collaborate.

How we learned by doing

In order to run this release successfully, we had to leave no stone unturned. We planned for every possible scenario and roadblock. We needed rollback procedures outlined and in place. The QA automation engineers needed to be involved in case of automated test failures on merge/deploy. Our QA manual test engineers needed a suite of tests to run against production once deployments were finished. There were front end and back end software engineers who needed to coordinate deployments. So it ultimately made a lot of sense for us to use Notebooks in order to launch Notebooks. We had created a tool that was made for situations just like this, so it was the perfect opportunity to put it to good use. 

It was great to see the product working in real time. Each team contributed to one big checklist, and each step was well planned. Having one place to showcase work, review, and discuss feedback allowed us to make decisions quickly and work smarter.

Without being able to collaborate in one place, we would have struggled. There was just so much going on; even outside of big updates to user education and customer support, there were concurrent projects that needed to launch with Notebooks, like an entire homepage redesign and a new tool for our sales team to use. 

And we learned as we went. Every person at Abstract is encouraged to provide honest feedback or raise concerns early and often, and that value held fast throughout the entire process. Once a few concerns were raised, we knew we needed to adjust the ship date. There was scope creep (inevitable for any major launch) that needed to be addressed. Conversations happened to address scope and capacity with the end result being adjustments made to timelines and priorities. We flipped the script when it comes to the frustrating side of software development. A better product and less stressful launch was the result of honest conversations and our ability to make our own weather.

Once we were ready for the actual product launch of Notebooks, the engineering team had to have everything buttoned up before launch day. This meant careful planning, collaboration with QA, and a contingency plan. Thankfully, there were no surprises. This was no coincidence. Again, this came down to learning as we went. We evaluated the project scope on a daily basis, pointing out potential risks and reprioritizations that should take place. It was a constant weighing of workload and what should and should not be included. 

Thanks to everyone’s hard work and commitment to collaborating, this release unfolded like a beautifully synchronized ballet. Everyone hit their marks and moved at the right time, and each team member added to the choreography. We all relied on each other to take the right step at the right time, and thanks to our planning and responsiveness, we never had an urgent issue that couldn’t be resolved quickly.

Tips for remote launches

So what tips can I pass on for running a product launch remotely? Each organization has its own processes, but there are universal truths that everyone would do well to remember.

Evaluate scope early and often 

There’s nothing worse than underestimating the time or workload that’s needed to do something well. Make your plan, review it, review it again, discuss it, and execute it step by step. Good planning assumes that nothing is set in stone, so revisit the scope often and allow for changes.

Remember, strategy is just as much what you don’t do as what you do

Like I said earlier, each organization has its own processes. Find out what works for yours and continuously improve on it. There’s no use relying on an “industry standard” when it doesn’t make sense for your team or your project.

Prioritize collaboration

I can’t stress this enough: collaboration doesn’t just happen out of nowhere. The culture of the company and team you work with matters. Often it comes down to creating the space for anyone to raise concerns early. It’s not enough to encourage people to surface their thoughts, you should cultivate an environment that is psychologically safe from retaliation or judgment. 

At Abstract, when we ship, we ship together. And that’s not an accident. You need to plan strategically in advance in order to see all the moving parts of a large project and how they interact with one another. Using the right collaboration tools adds structure and encourages prioritization.

Just breathe

Product releases are stressful, but if you’ve done all the planning, testing, and hard work that needs to be done, you’ll be fine. I got through it, and you will too.

Interested in software development, QA, or remote launches? Send me a note on LinkedIn.

If you’re interested in learning more about how our Engineering team builds together at Abstract, check out our Careers page.