Not everyone understands the importance of the people behind their software. I learned this lesson when selling my company to a non-technology organization.
When we decided to sell Distil, we were fortunate that we had several interested parties. One of these parties was the Canadian Standards Association (CSA). CSA had been an early customer and a great partner for us. I was impressed (and very grateful) that they stepped up to the plate and made a serious offer to acquire Distil. I was even more excited and pleased when their’s was the offer our board accepted. If you are interested (this was in 2009 so it’s not breaking news) you can read CSA’s press release.
CSA made it very clear that they were acquiring the Distil software platform. I thought this was great. To me it meant that they valued what our team had built. More importantly this would guarantee jobs for our team. The team that built the platform and knew how to use the platform were much more important than the code sitting in source control.
In the days before the deal was finalized, CSA sent in their team for due diligence. Lawyers went over our IP. High priced consultants spent 2 days going through our source code. Nobody spent any time reviewing our team.
I should have picked up on this, that there was too much focus on the code and not enough on the people, but I was busy calming and reassuring the team (this was probably the wrong thing to do, but that is another story). I really wanted CSA to get great value from the deal and I knew the team was essential for this to happen.
During the transition, CSA management spent one-on-one time with each employee. Their intent was to make everyone feel welcome. Talking with people afterwards this move backfired. Many came away from these meetings feeling like CSA didn’t understand what they did or contributed to the platform.
Now I made many mistakes though the acquisition and transition. In this case I just assumed that CSA understood that the software platform they were acquiring was really the people behind it. Being in the training business they must have understood that the trainers and teachers were more important than the course curriculum and material. So they must similarly understand that software is people. Right? Boy did I get that wrong!
Here is how CSA works. They will hire a consultant to prepare their standards and training material. Once these are created the original author is no longer needed. The materials go on the shelf, for sale. Years later, if the material needs to be updated then they bring in a consultant (not necessarily the original author) to review and rewrite the document. Their behavior through the acquisition was consistent with this model. As long as the code was well written, it could go on a shelf and be updated later by any “coder”.
Of course software doesn’t work this way. Software isn’t just the lines of code or bytes in the executable. It is the logic, thought, and personality of everyone who contributed to its creation. What is saved in the source code is less important than what is stored in the brains of the people who wrote it.
I wasn’t privy to the details of how CSA integrated Distil into their work force. Two of the CSA executives behind the acquisition have moved on to other organizations. I don’t know if the Distil acquisition had anything to do with their departure. Only two people from the acquired team still work there, so I suspect they had difficulty integrating the Distil platform into their organization. This was probably due to a lack of understanding about the importance of the people behind the platform.
Not everyone understands software and technology. The lesson I learned is that I can’t expect non-techies to understand “obvious” things, like the team is more important than the code. It is mine and everyone’s responsibility to educated those around them — acquirers, managers, customers — that software is people. We can’t just take this for granted. I’m sorry that a great team had to experience frustration and stress for me to learn this lesson.