Hi Adam,

I've been involved with 3 different acquisitions - including 1 where I was the one being acquired. My take from having this experience a few times:

• Expect change. Everything is on the table when a company is acquired.
• Expect turnover. Some team members being acquired will use the moment for self reflection and will decide it's time to get off the ride.
• Expect some roles to be eliminated due to redundancy. From my experience, this has exclusively been for supporting roles - like our finance team or Office Managers.
• Expect Leadership Turnover on both sides. Three reasons I've seen for leadership turnover:
  • An established leader is using the opportunity for a smooth exit from the business, enabling an acquired leader to take the role.
  • An acquired leader may not thrive in the new environment and may decide to go to an organization better fitting their style.
  • A company's board may decide to fill a leadership role with an external candidate because the acquisition changed strategic objectives.
• Integrating the companies takes time. In my experience, it takes about 1 year from the announcement of an acquisition for the company to be fully integrated as a single entity.
• Be prepared for rebranding. Depending on the strength of the brand, the company's marketing team may carpe diem and use the moment to evaluate a branding change. I have experience this twice, most recently switching from our established brand (KazooHR) to the acquired company's brand (WorkTango).
• It's an opportunity to adopt new technology. Prior to my startup being acquired in 2018, the tech stacks for the two companies was JavaScript (mine) and Ruby (theirs). I pitched and succeeded in establishing TypeScript as the development language going forward for new projects.
• Expect team and company cultures to evolve.
• Sometimes, acquiring another company comes with unexpected perks, like getting extra holidays because the new team members are international

Tough one, being the person who wants to acquire the knowledge, you can use these methods:

1. Take the next maintenance task for any system you do not know:

   • A small ticket is your way into understanding at least the entry point of a system.

2. Pair program with someone who does know the system:

   • You drive and let them steer you into solving the problem or implementing the system.

3. Ask your teammates / manager about the system:

   • They will probably give you an overview and show you the essential parts of the program / system / interaction points.

4. Play with the code and see what happens:

• Make sure the author has taken into consideration that production resources should be disabled by default; no one wants DEV emails going to customers..

Now, as the person who has the knowledge:

1. Write tests for your team:

   • Free documentation along with making sure the system works!

2. Create a wiki and put important processes there.

   • I usually use a markdown editor like Ghosterwriter and using Pandoc to convert the markdown to whatever format is needed.

3. Be willing to share the knowledge and share multiple times if you must:

   • As a team member, it's your job to empower your teammates. Plus, you may need them to know if you ever want to go on vacation!!

Posted my response here -> tips for boosting knowledge sharing