Category: Tech

As part of the Pardot acquisition a few years ago, there was an extensive technical review during the due diligence. As you would expect, the idea was to evaluate the technical underpinnings of the product and to try and assess if it was well made and will continue to perform as the company grows. Only, a technical review by a third-party is incredibly difficult as languages, frameworks, deployment strategies, etc. are all different and nuanced.

Here are a few areas of technical review in a company acquisition:

• Code Walkthrough – Much time was spent walking two senior engineering managers through how the code was organized and styled. Here, the goal wasn’t to evaluate every line of code, but rather to see that it was maintainable and that we were thoughtful in our approach.
• Architecture – After the code walkthrough, the next step was to draw out the architecture of the product and explain how all the modules interfaced with each other. With a standard Model-View-Controller approach, the basics are usually straightforward.
• Data Storage – With so much information being stored across so many different customers, data storage and retrieval was a big deal. Of particular note were the areas where data was growing the fastest as well as our strategy for keeping up with the growth.
• Deployment – When a software engineer makes a change, what happens before customers get to see or use that change. How much human intervention is required? Is it automated? What tests have to pass? Where does the code go?
• Hosting – With a complicated web-based application, the number of servers and services can be quite large. An acquirer wants to understand how manageable the hosting configuration is and how hosting costs grow as the customer base grows (hopefully there are some economies of scale in the hosting costs as revenue grows).

Note that nowhere during the process was there a consideration for how well our product could integrate with their product or if our product was written in the same language and/or style as their product. For acquisitions whereby the product is going to continue on as a standalone application, the goal is make sure that it’s well made and will continue to perform as the business grows. Technical reviews, in my limited experience, are much easier than expected.

What else? What are some other thoughts on technical reviews in a company acquisition?

Continuing with yesterday’s post 90 Days of GitHub Commits, jumping back into software engineering has really driven home to me why it’s so hard for successful software companies to keep up with new upstarts. Once a product is working, and the startup starts scaling, all the engineering efforts are focused on keeping up with growth, not with the latest technologies. And, over time, as the code gets deeper and broader, it becomes even more difficult to modernize things.

Here are a few thoughts on legacy code base challenges:

• Think of the products you use on a regular basis. Now, think about their user interfaces, especially the ones that are the most legacy (e.g. payroll, CRM, etc.). The older the application, the more antiquated the interface due to a large customer base and the tremendous difficulty updating it.
• Newer technologies often make software engineering faster, more scalable, and more maintainable (when used correctly), which gives an edge to startups using the latest technologies.
• Complicated customer use cases for a limited audience can be even more challenging for legacy products as the market no longer demands the functionality, yet it still has to be maintained because certain customers use it (watch out for frankenstein products).
• Entire markets of new products to mobile-enable legacy products have emerged (e.g. Catavolt) showing that legacy software companies have serious difficulties staying up-to-date

A common question I hear from people outside the software world when talking about a startup idea is “can’t Google/Facebook/Microsoft just update their product to include this functionality?” Yes, it’s technically possible, but there are so many competing priorities and legacy challenges that it won’t ever get done. And, that’s one reason why startups can start with a niche and grow into a formidable competitor.

What else? What are some more thoughts on challenges with legacy code bases?

Just this past week I’ve received two separate requests for help recruiting software engineers. I think it’s a sign of the times with technology continuing to be hot and the corresponding shortage of software developers becoming more acute. So, as someone who’s trying to recruit developers, what are some best practices?

Here are a few ideas for recruiting software engineers:

• $10,000 referral bonus – Offer a $10,000 referral bonus to any employee that refers a software engineer that is hired and stays with the company for six months
• Twitter – Build a brand online through social media and use it as part of the recruiting process
• LinkedIn – Use LinkedIn, both on the job posting side as well as directly soliciting employees of other companies, to find great talent
• Alumni Career Fairs – Sponsor both student career fairs as well as alumni career fairs (e.g. GA Tech has an alumni career fair)
• Technical Meetup Groups – All the major programming languages have regular meetup groups (e.g. the Atlanta iOS Developers meetup) and engineers that attend them are interested in honing their craft
• Recruiters – External recruiters are a way of life in the technology world and the key is to find ones that understand the importance of culture and fit when placing candidates

Recruiting great software engineers is a real challenge, and with serious effort, readily achievable. Build a methodical process and try a number of different avenues to find the right candidates.

What else? What are some more thoughts on recruiting software engineers?

Back when Adam and I started Pardot in 2007, I spent the entire first year writing code full-time and it was awesome. We were blazing a new trail with SMB marketing automation and adding new functionality every week. As the business grew, my software engineering efforts slowed and I focused my energies on ways to best grow the business. After we sold Pardot, I spent the past two years split between the Atlanta Tech Village and Kevy, trying to get both off the ground. Now that construction has been done at the Village for a couple months, I’ve had the opportunity to jump back in and write some code.

In fact, my goal is to continue writing code part-time throughout 2015 — a year of code. Here are a few ideas on the year of code:

• My target is 500 hours of coding over the course of the year (~10 hours/week), but it’ll ebb and flow based on priorities
• My guess is that it takes 50 – 100 hours to achieve proficiency again
• Most of my skills from 2007 are fairly applicable today, if only rusty
• My effort is focused on non-core or net-new items that aren’t yet customer-facing

Like Allen Nance says in Old Dog, New Tricks, the world is becoming more technical and a deeper understanding is important. I’m looking forward to the year of code.

What else? What are some other thoughts on writing code part-time for a year?

Recently I was talking to an entrepreneur about his product. The market already had a couple of inferior solutions to the problem he was solving, each with their own pros and cons. His new product provided a more elegant platform, but also increased the friction for product adoption. Product adoption is a major challenge to building a successful business.

Here are a few thoughts on reducing friction to improve product adoption:

• Research the most commonly performed tasks
• Figure out how to reduce the number of steps required to get the most value
• Ask users if they could wave a magic wand, how would the product work
• Find out what users like and dislike most about the product
• Track the time to wow

Minimizing product adoption friction is one of the best ways to maximize customer success. An unused product is an unsuccessful product.

What else? What are some more ideas on reducing friction to improve product adoption?

While assembling a prototype to assess market demand is dramatically cheaper than 10 years old, there’s still a serious gap between minimum viable product and robust product. Software, like any product, can always be improved. Unlike many physical products, the complexity of a software product is not always understood even after a fair amount of usage.

Here are a few thoughts on the gap between prototype and robust product:

• All software has bugs, but over time the frequency of new known bugs will decrease (assuming minimal new functionality introduced)
• Some software is inherently more complicated resulting in more time and effort required to achieve a robust state
• One gauge to assess product robustness is to get it to the point where there aren’t any known blocker bugs and to have configured 10-25 new customers without any issues (bugs are always going to be present but the severity isn’t always going to be high)
• Product robustness and product/market fit aren’t correlated as the product can be solid without market fit

Prototypes aren’t the same as robust products but they are very important. Entrepreneurs need to budget for continued product development and pay attention to issues.

What else? What are some other thoughts on the gap between prototype and robust product?