Being a Release Lead at Delphix

I joined Delphix as a software engineer in August 2012, a couple months after graduating from Brown University. After a bit more than a year at Delphix, I was invited to take on an additional responsibility and become the release lead for our next major version, Delphix 4.1. As someone who strongly identifies as an engineer, I was nervous! All I knew was that I would be responsible for keeping our engineering team on schedule and ensuring the quality of the product that ended up in our customer's hands.

I had seen three previous release leads in action -- they each had a large and lasting impact on the processes we use at Delphix, the features that integrated, and the general direction of the development process -- but I still didn't know what their responsibilities had been, and I was certain I didn't have all the skills needed to be successful. However, the release management team had intentionally created an environment where even I, as a recent college grad, would be able to bite off more than I could chew and make a couple mistakes without any real risk of failure. Motivated by this, I went for it.

Effective Communication 101

At the outset, I knew a lot about coding, particularly in the areas that I had worked on before, but very little about anything else. By far the most difficult skill that I had to learn on the job was how to communicate across an organization of 70 people.

The first challenge I had was guiding the idea generation phase of the release, where my role was to reach out to people I'd barely spoken to who were generally much more experienced (the head of support, managers across engineering, some of our top developers, etc.) and ask them what features they felt were important to work on during my release. Turning this menagerie of small bugs, multi-year projects, and wish list items into a prioritized list of potential projects was a huge undertaking, and I learned my first lesson of release management: always take notes -- especially when you have no idea what someone is talking about!

It's humorous to look back and think, "When I talked to the platform team managers I really only understood half of the things they suggested as projects," but it would have been a lot less funny if I hadn't taken notes that enabled me to come up to speed after the fact by poking around the product documentation and the bug tracker. I learned a ton about our product by doing exactly those things, which enabled me to anticipate technical problems for unfamiliar projects later on, greatly increasing my effectiveness as a release lead.

The next limitation I ran into was my own bandwidth, plain and simple. When you're trying to track progress across an organization of 70 people, and you have, say, 10 hours in a workday, you can't spend more than 9 minutes talking to each person to get a status update -- nor should you. Though it was tempting to reach out to people on critical projects and get as many touch points as I could, I quickly found myself wading through gratuitous meetings and emails and my personal productivity dropped off precipitously.

A difficult skill I had to learn was maximizing interactions so that I (and the engineers I was syncing with) would have time to actually get stuff done. Mostly this boiled down to preparing questions for meetings ahead of time, but thinking about who was the right person for a question or what meeting would have the highest number of stakeholders were also important aspects.

As a result of hitting my bandwidth limit, I also realized that I should be relying on the strengths of peers who could help me rather than taking everything on myself. Project leads and project managers are there for a reason: they are the experts in their areas and we trust them to communicate their teams' problems upwards. Although it was difficult at first to take a step back, I came to rely heavily on my colleagues to give honest appraisals of their project status, and I found that having many fewer data points did not hinder my ability to do my job at all.

Beyond tracking project status, the release lead wears many other hats: continually driving people to work on their old bugs before the end of the release, ensuring the correct processes are followed for testing and backporting, answering general questions about bug priorities, and so on. I found that choosing the right communication method for each of these was vital in doing the job effectively. For a process or policy that doesn't change much over time, writing or improving a wiki page was the best way to go so you only have to answer the question once.

On the other hand, if I needed a large number of people to all do some normally low priority task in a timely manner, a wide spray email or wiki article never helped -- I really had to ping each individual. At times like these, I found that IM was my favorite tool; I could hold 5-10 short conversations at a time, keep a record of everything that was said, and hold people accountable effectively.

Finally, I learned that when you do something that affects a lot of people, at least a few of them are bound to ask you questions about it. This is a good thing -- it acts as an excellent counterforce to unnecessary bureaucracy and complexity, and guards against you making accidental mistakes -- but you need to be prepared to explain yourself. My final communication lesson is perhaps the simplest: be purposeful in your actions and be candid when answering questions about them, even if you made a mistake.

Conclusion

Being the release lead was a fantastic learning experience for me, and it was fun to step outside of my engineer's shell to work with a large cross-section of the company. I got to know the whole organization better, and the role easily allowed me to have the broadest personal impact of anything in my (admittedly short!) career. I also gained a renewed appreciation for Delphix's excellent engineering team.

As release lead, you live and die by your coworkers' skill in communicating their projects' roadblocks, their ability to debug critical issues right before a deadline, and their inventive and thorough approaches to testing. Having a team of great engineers is ultimately what makes feature-packed product updates possible. (And I almost forgot to mention -- we're hiring!)