Tactical Routes to Keep Production Code Alive and Running
2 July, 2019
I became the CTO of my current company after it had been active for about five years. There was a code base that had been built by a team of four people during these five years, thus giving it a total of 20 years worth of code. Yet, while there had previously been four people on the team there was just one single engineer left who held all the code knowledge. However, a few weeks after I started this engineer decided to quit and leave the company also, and so all of the code base knowledge would be taken with him. The challenge was to find a solution so that I could keep everything alive and running.
I divided my attention into two arenas. Super tactical route In my country we have a notice period when someone wants to quit. The person must stay with the company for 30 days and then after that time they are welcome to leave. I decided to give an incentive to this last engineer and asked him to stay for an additional 30 days. This gave me two months to spend time with him, to learn from him and his experience as much as I could. In parallel, I contracted freelancers to write new code. This assured that we could still maintain items in production and deliver fresh new code for UI without doing anything more significant on the back-end. Standard tactical route I held off production so that our systems wouldn't tear apart. This meant working late nights for a few months. I also began hiring immediately and focused on getting engineers in the door. I gave the new hires peripheral tasks so that they code jump right into the code and start solving issues that were not necessarily production critical. Over the next year and a half I put in motion two phases for rebuilding our production team. First, hiring R&D- we now have eight people; and second, stabilizing R&D- so we are not in danger of risking our production code. Recently I initiated the beginning of phase three- modernizing and clean up. In the past, we were too busy with hiring and stabilizing the situation that now we need to clean up the mess that has accrued over the past year.
I believe I made one mistake along the way. We are an analytics company so our business, managers, and team members are numbers people. At one point I thought it would be a good idea to bring an analyst onto the team. Although he was a numbers person he didn't have much engineering experience. I thought he could work his way into becoming an engineer overtime. Well he didn't, and it failed. After six months the person quit and left the job. He was frustrated and felt there was too much pressure on him. I realized it probably wasn't the perfect time to bring in someone more on the junior side. Lesson learned I guess: Don't bring on juniors when you're going through a stressful time.
Stefan Gruber, VP of Engineering at Bitmovin, describes when he decided to introduce Scrum into his organization and the moment he realized that tech items were left off the priority list for engineering.
VP of Engineering at Bitmovin
Paulo André, VP of Engineering at TourRadar, discusses different aspects of a scalable hiring process.
VP Engineering at TourRadar
Wayne Haber, Director of Engineering at GitLab, explains how he successfully turned a proof of concept to a full product.
Director of Engineering at GitLab
Veronika Fleisher, Director of Engineering at BitSight, explains how her company implemented a clear promotion process and structured feedback meetings.
Director of Engineering at BitSight
Janssen Choong, Partner at Horizon Connect, highlights the importance of the right hiring strategy when your startup scales rapidly.
Partner at Horizon Connect
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.