One of my goals is to ensure a successful outcome from the deal. I'll start by defining what I mean by "successful outcome:" That the combination of the two companies produces more value together than we would have been able to achieve alone.

The first thing I did was start writing an Integration Document with my co-founders when we signed the term sheet. This document laid out the specific goals of the acquisition, the resources we had at our disposal, and the key items we would need to request to achieve those goals. Once we had co-edited that document in Google Docs to a point where we were all satisfied with it, I shared it with the ShareThis executive team.

I had already discussed and gotten agreement from Kurt, the CEO, on what the main goals of the acquisition were pre-term sheet. In the integration document, I outlined how we were going to prioritize those goals, and what resources we were going to put into them to achieve the goals.

Importantly, I didn't put dates around those goals. Instead, I ordered them by importance. This is a key part of the scrum methodology that's often employed by engineers, but less often employed by executives: Things take as long as they take. By putting arbitrary deadlines around goals, you're just creating stress and inefficiency for those trying to achieve them. Instead, just order the goals based on what's most important to the company, and get them done in that order. If things aren't moving fast enough, reallocate resources in an agile manner to put even more emphasis on what's important. Everything can't be important at the same time, because when everything is a priority, then nothing is a priority. By trusting your team to produce results, and prioritizing them to work on whatever is most important at any given moment in time, then those things will get done first. It's as easy as that.

I co-edited this Integration Document with the ShareThis executive team using Google Docs until we were all satisfied that the Socialize team had a clear direction that would add the most value to ShareThis based on its goals. This document became the planning document around which our team broke the main goals down into actionable steps, and it now has child planning docs that expand on each goal for the acquisition which have been shared with the ShareThis team members involved in each goal.

This worked very well. So, the first piece of learning I have thus far is to ensure you have a clear understanding of what the acquiring company's goals are, how you'll help achieve them, and then memorialize this understanding in a document that the executive teams of both companies buy into. And importantly, I took on the task of creating this document so the ShareThis team didn’t have to. My perspective was that as the company being acquired, this document was much more important to us than to the acquiring company (which has a lot of other things going on), so the best way to position us for a successful acquisition was to create a framework as early as possible that everyone could contribute to, and take ownership of that framework. To me, this is a core responsibility of the CEO of the company being acquired.

The second major point revolves around cultural integration. Cultural differences can kill an acquisition faster than any other single factor. I've heard many sad entrepreneur's stories that describe how an otherwise well intentioned acquisition failed due to the lack of a cultural integration.

To combat this issue, I've made it a personal priority to work out of the ShareThis main office for the first few months of the acquisition, and to use meals and happy hours as an informal setting to get to know as much of the ShareThis team as possible. Even before the deal was signed I had scheduled conference calls with the executive members of the ShareThis team, to make sure they understood Socialize and could provide input on the main goals of the acquisition, as well as for me to have a better understanding of what their roles and priorities were. Additionally, several members from the ShareThis team, including Kurt, the CEO, will spend time working from the Socialize office. Although doing this feels inefficient since the Socialize office is up in the city of San Francisco, and ShareThis' main HQ is in Palo Alto, about 45 minutes south, the right way to think about it is as an investment we're all making in creating the relationships that will allow us to grow together as a unified entity.

These are my two major learnings thus far. I'll keep adding to this list as I find things that I consider to be critical to the success of any acquisition, and I welcome your comments below, especially if you have personal experience with things that worked well or caused problems.

Read Next

Tody I moderated a discussion today with Socialize executive team members Jason Polites, Isaac Mosquera and Sean Shadmand about how Socialize has created an infrastructure that supports over 7 million API requests per day, 2.5 million social actions (now creating over 1 million new actions per month), 100,000 new users per day, over 7,000 SDK downloads, thousands of live iOS and Android apps running Socialize, all doubling monthly.

I have been getting requests from many companies of all sizes asking how Socialize has built and scaled a large infrastructure with just an 8 person engineering team. Other startups interested in offering APIs and SDKs have wanted to know what we've learned and what pitfalls to avoid, and larger, progressive Fortune 1000 companies have been interested in re-working their infrastructure to be more scalable and efficient.

A partner at Accenture recently told me that I should share some of the secret sauce for other companies to learn from. The Socialize team believes in being as open as possible with non-proprietary knowledge sharing, to help others benefit from what we've learned, and in turn to be able to learn from others as well.

Socialize has created a drop-in social platform that greatly boosts mobile app installs and engagement. If you don't yet know what Socialize does, you may want to learn more about that here before watching this infrastructure talk.

Tody I moderated a discussion today with Socialize executive team members Jason Polites, Isaac Mosquera and Sean Shadmand about how Socialize has created an infrastructure that supports over 7 million API requests per day, 2.5 million social actions (now creating over 1 million new actions per month), 100,000 new users per day, over 7,000 SDK downloads, thousands of live iOS and Android apps running Socialize, all doubling monthly.
I have been getting requests from many companies of all sizes asking how Socialize has built and scaled a large infrastructure with just an 8 person engineering team. Other startups interested in offering APIs and SDKs have wanted to know what we've learned and what pitfalls to avoid, and larger, progressive Fortune 1000 companies have been interested in re-working their infrastructure to be more scalable and efficient.
A partner at Accenture recently told me that I should share some of the secret sauce for other companies to learn from. The Socialize team believes in being as open as possible with non-proprietary knowledge sharing, to help others benefit from what we've learned, and in turn to be able to learn from others as well.
Socialize has created a drop-in social platform that greatly boosts mobile app installs and engagement. If you don't yet know what Socialize does, you may want to learn more about that here before watching this infrastructure talk.
Here's the video, with a summary of the discussion points below:
>
In this 45 minute discussion, the Socialize executive team discusses:
How Socialize approaches infrastructure from the perspectives of process and business logic
How teams of one to two employees each for API, iOS SDK, Android SDK, Web and QA work together to create a modularized API infrastructure
How Socialize teams use APIs to communicate internally within the company to create accountability, efficiency and speed
Best practices in segmenting internal teams around APIs, including integration testing, unit testing, minimizing distraction and documentation
How to then break APIs up into products which can be exposed beyond the company internally, and how each API has its own Pivotal Tracker, Github issue tracking, Sphinx auto-generated documentation and change-request systems
How Socialize treats internal teams as customers of each other, and uses that approach to define and refine the scope of the product, and limits feature creep
How the SDK team becomes the 'head of the product,' scoping and defining functionality back into the company as one of the teams
The value of hardlining, staying away from perfecting an unreleased API, and getting good at creating a plan to deal with grwoth
Using a specific approach to scrum Socialize calls "short-cycle scrum" and tools like Basecamp, Google Docs and Pivotal Tracker to manage situation which often come up, such as capturing and implementing ideas from employees and customers in a structured, productive way, how to stay away from premature design discussions, and how to innovate asynchronously.
How short-cycle scrum allows each team member to be a product lead within their team,
Taking full advantage of Amazon services for databases, redundancy, queueing, hosting, scalability, load balancing, all done programmatically, which allows for spooling up of infrastructure literally in minutes
The benefits of agile development methodologies, and specifically scrum, for those who haven't already used it for development, and how to trust scrum even though it is counter intuitive to remove dates from projects
The importance and value of prioritization of focus, and how we use these methodologies to do that, and make the less important things fall away
How Socialize is breaking up the Socialize action bar into modular components
How on a micro level, within the code base, the Socialize SDK communicates across the stack using the same type of modular infrastructure Socialize employs as a company at a macro level
Best practices around continuous integration with TeamCity, code coverage and testing, using GetSatisfaction for support, and how this approach makes support easy
How Socialize has implemented Splunk not just for log monitoring, but also at the application level for business intelligence, reporting and alerting, and even exposing Splunk data to Socialize clients

Some of you might know that I'm a fan of letting go of goals, or living/working without goals ...

So you might be surprised to know that this week, I decided to encourage my kids to create 2014 goals and a plan for accomplishing those goals.

What gives? Well, I thought I'd use goals as a teaching/learning tool in our little unschooling adventure. I've found goals to be unnecessary for accomplishing things, but I don't believe goals are evil, especially if you use them right. And they can be a useful tool to learn about something.

In this case, I'm helping the kids to learn about achieving things. It can be easy in life, and in unschooling, to let the days pass by without doing anything important or exciting. That's fine if you have a job and are getting a regular paycheck, but if you own your own business or are an unschooler, you don't have that luxury. You can take a few days off, but eventually you're going to have to produce.