Discussion and Comment of the Week - v20

This weekly roundup highlights what we believe to be the most thoughtful and/or interesting discussion of the week. We're also be highlighting one particularly cool comment in each installment. 🙌

The DEV Community is particularly special because of the kind and thoughtful discussions happening between community members. As such, we want to encourage folks to participate in discussions and reward those who are initiating or taking part in conversations across the community. After all, a community is made possible by the people interacting inside it.

Discussion of the Week

For this week's discussion of the week, I'd like to give it up for @adam_cyclones' "😬 Company takeovers, what now?"

😬 Company takeovers, what now?

Adam Crockett ・ Oct 11 '22

#career #discuss

If you've yet to experience a company takeover, it can be a wild ride (speaking from personal experience).

"I love where I work and I don't want it to change"

Adam's apprehension is very relatable and no doubt others who have experienced similar situations are familiar with the worry of potential big changes a company takeover may bring.

Notably, Joe (@theaccordance) chimed in with a shout-out worthy comment full of great advice:

Joe Mainwaring • Oct 11 '22 • Edited on Oct 11 • Edited

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

Comment of the Week

The Comment of the Week is a tie this week! We're rewarding it to both @mykezero & @codingchili for the awesome advice they each dropped in response to @amabdev's thoughtful prompt How do you promote knowledge sharing?

Mykezero • Oct 7 '22 • Edited on Oct 7 • Edited

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!!

@mykezero's comment does a fantastic job of outlining methods for both acquiring and sharing knowledge. It's a punchy, bullet point list and very actionable.

Robin Duda (they/them) • Oct 7 '22

Posted my response here -> tips for boosting knowledge sharing

@codingchili's responded with a link to their awesome post here:

Tips for Boosting Knowledge Sharing

Robin Duda (they/them) ・ Oct 7 '22

#devjournal #leadership #agile

This excellent (first!) post by Robin dives deep and offers some really great guidance for knowledge sharing! I particularly loved the wrap-up section with the "recipe for knowledge".

Some of the guidance in Robin's post intersects with the suggestions in Mykezero's comment, but both resources really compliment each other! Nicely done, y'all — and great prompt, AmabDev.

What are your picks?

There's loads of great discussions and comments floating about in this community. These are just a few we chose to highlight. 🙂

I urge you all to share your favorite comment and/or discussion of the past week below in the comments. And if you're up for it, give the author an @mention — it'll probably make 'em feel good. 💚