Embrace your inner Project Manager

Like any growing software company, we here at Greenhouse have technical debt. Face it: we all do. In our quest to reduce it, we recently completed an upgrade of our main software from Rails 3.2 to Rails 4.2. The upgrade was long overdue, and we still have to do the upgrade to 5.0, but we were happy to retire it.

During this upgrade we learned a lot. We are planning to write a whole series of articles regarding technical details and different upgrade strategies. But this post is about the “softer” skill here: project management.

Project Management? I don’t do that!

Let’s say you have decided that you really want to tackle some major technical debt in your codebase. Rewrite that ancient app that was written before your company pivoted, break your monolithic app into services, or maybe, you just want to upgrade your framework like we did.

That’s great and all, but I am going to guess that you don’t work in isolation. You need a champion! Not a hero coder who will do all the work (more on that in another blog post), but an advocate for change that can speak with the entire company. That person can lay out reasons for the change, communicate progress, and generally do all the coordination that is necessary besides just the coding.

You may be lucky enough to work in a company where your Product Manager may be your advocate, or maybe you’re even lucky enough to have a Technical Product Manager. But if you work at a smaller company, or one that is not that technically minded, this is normally not the case. Product Managers are worried about customer features; Technical Product Managers will be hired in “the future”. Chances are one of the engineers will have to take this mantle on.

For this latest upgrade that task fell to me. Along the way I think I learned a few things about it. So here are a couple of things I learned while managing this process.

Pitching: How to get the work scheduled

I have never met a product manager that liked upgrades or addressing technical debt. It’s not that all the product managers I know are mean; far from it. It’s just that the pain of technical debt is felt most directly by developers, not customers, and the benefits of any technical upgrade are not always easy to spot. It took time for me to learn that part of my job as a developer is to make the case for the upgrade, not just decree it.

When you are planning on asking for the resources and time to do this type of upgrade, you need to put yourself into the mind of your product managers. Devoting resources to upgrading some technical part of the platform is incredibly expensive. Not only does the company spend money on the developer time for the upgrade, but it also loses the opportunity to develop new customer-facing features. This is already a pretty high cost, and you haven’t even started your pitch.

You are going to have to explain the value, i.e. build a business case. Will this upgrade help with security? Make development faster? Will it improve the speed and reliability of your servers? When we put together a plan for the upgrade, we added a single slide to our presentation listing the benefits of doing the upgrade. We talked about technical benefits such as speed and security, but also softer values like developer happiness. You feel the pain of technical debt directly. So you are the person best equipped to talk about why reducing it makes the company stronger.

Communication: How to keep the project going

Once we had approval for the project, we eagerly started coding away. We had a plan going forward on how to run the upgrade, and we had developers dedicated to the cause. All was right with the world, right? Well, no.

While we had a great plan about how to proceed, we didn’t have a plan on how to communicate the project’s progress to the rest of organization. This lack of communication created a crisis of confidence for product and business. The lack of confidence first started manifesting with the head of product walking to my desk every week asking me how things were going. It culminated with the head of engineering pulling me aside to tell me that the project felt like a big black hole to management and that people were scared.

Part of the problem with these types of upgrades is demonstrating what’s been built. When we are building a customer-facing feature, its easy enough to boot up our local server and show the new widget we just added to the dashboard. With this kind of upgrade there is nothing to show except maybe some console output on your machine. So all our managers had to judge the project is what we told them.

We changed our process immediately. We shared our milestones for the project with all the stakeholders. These were pretty simple such as Rails 4 server boots, Docker build and deploys correctly to server, and Tests run (not necessarily succeed). And for each milestone we came up with some sort of metric to measure our progress within the milestone. The metrics weren’t always perfect, but they didn’t have to be. As long as they gave a rough estimation for where we were, it helped management to understand our overall progress. We also began sending out weekly status emails to all the stakeholders. We would outline what we accomplished, what problems we encountered, and what we planned to do the next week.

These steps were very simple, but incredibly valuable. Not only did it reduce the number of queries that we received about the project, but it also built trust. In feedback I got from the Product team after the upgrade, everyone listed the emails as the best tool we gave them to track the progress of the project. That confidence will keep you and your team happily coding away.

Closing: How to finish the project

Depending on the nature of your project, this can be very simple, or (as in most cases) very very complex. For our upgrade we did a Blue-Green release that was complicated by the fact that we had to have two separate queues for background jobs. But the complexity of the deployment is also going to drive the complexity of the communication that is needed to finish the project well.

As we approached the end of the project we started talking to every department to let them know the upgrade was coming. We talked with our Customer Support, Sales, and Infrastructure teams. When we got within two weeks of deployment we had quick daily stand up meeting with a representative of every department directly involved in the release.

All this upfront communication paid dividends during the migration. When things started to go wrong (and something always goes wrong), everyone was prepared and ready to act. Nobody in the company panicked because they knew what was happening, and had clear lines of communication to check in when they needed to. This gave us a great deal of flexibility and adaptability that allowed us to react quickly to issues and fix them on the fly.

Summary

If you have arrived at this point, you’ll notice that all three sections are really about communication. Developers are supposedly not any good at talking to other human beings. But it’s essential if you are going to project manage your upgrade. Talk to your company, and spend the time to make sure people understand how and why you are doing that massively long project.

So go ahead and get the ball rolling. Don’t be afraid of stepping into that advocate roll. You’ll be better for it.

Orion Delwaterman is a Senior Software Developer at Greenhouse Software with 10 plus years of experience in Ruby, Rails, Javascript, and other languages that go bump in the night. He’s also a stage actor who loves doing Shakespeare, and is just a little bit tall.

Work with us. http://grnh.se/jwi0xc