Preserving the Startup Mentality After an Acquisition
26 November, 2020
null at ReachStack
Some years ago, I joined a startup that was acquired by a large company. I was brought in after the acquisition to help navigate its transformation from a standalone startup of 50 people to being a part of a larger entity of 4000 employees. During the transformation, a lot of people who were in the management roles left the startup and I was rapidly promoted to serve as a liaison person between our startup and the larger company.
I was experiencing the best of both worlds -- I had an opportunity to expand my knowledge but also mentor other people. Mainly, I was helping startup people better understand the enterprise environment, but I was also keen to support enterprise people who were trying to match pace with startup people.
As I was growing in my leadership role I encountered three main challenges:
- The startup didn’t want to operate the sluggish pace of the enterprise. The enterprise valued other things mostly related to reliability and having people to accept that was not easy. People in the enterprise would ossify over time and lean more toward procedural standards rather than aspire to build beautiful software. Some were happy with how things were, but some wanted to re-learn those skills again and find joy in building software.
- The majority of the leadership team at the startup had left and in most cases when leaders start to leave, engineers follow. The startup was acquired in the first place because of all the smart people who were its most valuable asset and we had to make sure they stay on the team.
- Finally, I underwent a rapid transition from being an IC to becoming a manager and had to embrace this swift transformation with all its implications.
Preserving the startup mentality
To preserve the startup mentality I had to improve some of the processes and push for things through personal intervention. In retrospect, improving the processes was the easier part. People would often be more forgetful than intentional about not communicating clearly or failing to set explicit and measurable goals and I had to ensure that our processes would not allow for these things to happen.
However, through personal intervention, I had to guide individuals on the team to practically acquire and become comfortable with our processes. I would mostly be partnering with -- and not yet delegating to -- people until they would become ready to take it over.
The exit of leadership
As the leadership left, I had to take on a leadership role. It did come as a surprise, but I already had a mentor and had worked arduously to improve my own skills as a manager. I had to make sure that my managers would set clear goals for our team and that our communication was streamlined, so there was no ambiguity on the delivery and responsibility.
Also, I had to demarcate clearly my areas of expertise. With so many leaders leaving, things would just land on my plate. I had to differentiate between things that I was familiar with and could do and those that I had to hand off to someone else. Part of that included hiring new people who brought in knowledge and skills that were missing.
My own role
Though the transition happened rapidly I had to find my own path, and more importantly my own pace. I was meeting and talking to a lot of people, did a lot of reading and learning from all available sources while I was also very disciplined at setting my own daily and weekly goals. I was able to balance my time and invest in my own growth as opposed to reactively responding and being focused on the issues at hand. Initially, I was spending a significant amount of my time with the team but as they were becoming autonomous and self-sustainable I was able to focus on more strategic matters.
- I understand that my situation was not the most common one, but be prepared that an acquisition can open up a horizon of possibilities. When you are joining a team after an acquisition you may be signing up for a longer journey than what you expected.
- As engineers, we are thought that our primary focus should be code. We admire its simplicity or beauty and rarely are bothered to focus on more trivial matters such as organization and its structure. Until we become managers. Then we get to realize the importance of a solid organizational structure and the role that management has in securing that code will be completed.
- Be prepared to be more than someone who just writes code. Opportunities appear uninvited and when they do, be ready to grab them. Then, as a natural consequence, your new role will require you to drop on some things and accept that your expertise has shifted elsewhere. You will not be the best developer on the team, but you will become an expert at getting things done.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
A major sign of trust, comfortability, and vulnerability is for someone you lead to be able to say something sucks.
Senior Engineering Manager at Curology
Jonathan Ducharme, Engineering Manager at AlleyCorp Nord, encourages the importance of a workplace environment that cultivates mental wellness.
Engineering Manager at AlleyCorp Nord
Lewis Prescott, QA Lead at Cera Care, explains his journey from a degree in psychology to learning test automation and computer programming.
QA Lead at CeraCare
No online tool will address your team's ability to connect, collaborate, and deliver results if the individuals don't bring the right mindset to work.
CTO at REAL Engagement & Loyalty
Otavio Santana, Distinguished Software Engineer at Zup Innovation, shares his best practices for upskilling without stretching yourself too thin.
Java champion, software engineer, architect, and open-source Contributor at Independent Technical Advisor