Nov 14, 2014

How to Thrive after Being Acquired

It was February of 2009, and the PayCycle exec team had just settled in for their quarterly offsite. We were meeting in our CEO Jim Heeger’s house in Palo Alto, getting ready to review our quarterly progress and look ahead to the next quarter. Instead of the regular agenda, Jim kicked off the meeting with some fairly shocking news. Intuit had approached us with an offer to acquire our 180-person startup, and we were moving forward in the negotiations. Wow, that was a surprising turn of events! With that news, our regularly scheduled offsite turned into a planning session for the upcoming due diligence and other logistics leading up to the acquisition. We eventually announced the acquisition on June 2, and on July 29, 2009 we became Intuit employees.

Fast-forward to today— more than five years later— and the PayCycle acquisition has been a successful acquisition from a business, technology, and people perspective for Intuit. Within the first year after the acquisition, my team integrated the PayCycle online payroll product with QuickBooks Online and released a mobile iPhone app. In the second year, we launched a new full-service payroll offering. All of these were enabled by the services and platform architecture that was developed in 2008. As a result, the payroll customer base has quadrupled over the past five years, and annual revenue has grown by 600%. The PayCycle product line has grown and now generates more revenue each year than the acquisition price.  

And of the original 45-member Engineering team at PayCycle, nearly 40 are still at Intuit and contributing to SaaS efforts across the company. Dan Hing is a Product Development (PD) Director at Intuit Demand Force, Yogesh Bhumralkar is the PD Director for Online Payroll, Jeff Brewer is a Director and Distinguished Engineer, Daniel Gutierrez leads operations for payroll, and Nagesh Tonne is the group development manager for QuickBooks Online Accountant— a new product that he and his team launched this year. We did experience some losses from our Engineering leadership team. Paul Gibson was leading the DevOps architecture for Payroll and QuickBooks Online, but left Intuit a few months ago for a small, public SaaS company.

Five years after the acquisition, more than 80% of the PayCycle Engineering team is still at Intuit and thriving— something which is very uncommon for an acquisition. I would like to share my perspective on the rationale for this tenure and share some experiences from the journey. In this day and age, M&A is a common exit strategy for many startups, and retaining the engineering talent can be critical to the eventual success of the acquisition. In particular, I will focus on the mindset and approach from the acquired team’s perspective, since you are the master of your outlook and approach.

TLDR: Here are the five key principles to thriving after an acquisition:
  1. Leverage your unique talents and strengths.
  2. Be proactive and lead through the change.
  3. Learn from and appreciate the new culture.
  4. Understand why you want to be there.
  5. Be accretive and constructive. 

Leverage Your Unique Talents and Strengths

Over the years, PayCycle had developed great Engineering rigor and operational excellence that was highly tuned for an agile, highly available SaaS operation. Back in 2008, we described our approach as the “DevOps” model where engineers and operations worked hand-in-hand on production architecture and troubleshooting production issues. As a result, we had a track record of sustained 99.9% availability and disaster recovery across two data centers. We also were on agile scrum, with monthly feature releases, weekly bug-fix releases, and the ability to push same-day production changes for urgent issues.

After the acquisition, we maintained our same operational rigor and demonstrated the same success in the new environment. We put “points on the board,” and our new leaders noticed. These early successes enabled us to carry forward our best practices to the teams at Intuit that we have led and are leading.

Be Proactive and Lead through the Change

After an acquisition, your culture does— and should— change as you join a new parent company. Like other changes in life, there are some really good aspects as well as some things that take more time to accommodate. Your individual outlook and attitude during the transition can greatly affect the outcome. Among the many things I had learned from Jim Heeger, our PayCycle CEO, were how to embrace change and how to lead through change. In many ways, Jim was the definitive standard for change leadership, and I still go back to the “playbook” I put together from watching him in action.

Before the acquisition even completed, my leadership team and I discussed the change and what it meant to us and to our teams. We developed a list of the things that we wanted to preserve— the “secret sauce” that made us successful, which we would protect at all costs. But we also made two other lists:
  • What we did not do well and wanted to change— some of these very soon.
  • Other areas where we were open to change— things that were not critical to our success, and where we were not married to the particular choice. These were the battles not worth fighting.

Learn from and Appreciate the New Culture

After the acquisition, we realized areas where Intuit excelled. Intuit had a rich history of customer focus and iterating designs with customer feedback— Design for Delight and Customer-Driven Innovation. We found these practices to be great additions to our Engineering practices, and we rapidly adopted these practices. We modified our Agile practices to incorporate Intuit’s experience design practices—which were superior to those we had at PayCycle.

We also realized that we were now part of a company with more resources (and deeper pockets) than a startup. As a result, we could shore up the areas that were not well resourced or ignored entirely. Also, we had access to a much larger customer base that we could reach through integrations with other Intuit products. Our early integration with QuickBooks Online proved to be a great accelerator for the growth of the online payroll customer base.

Understand Why You Want to Be There

Joining a much larger company was a big change from the start-up life. With additional resources and larger teams come more meetings with decision-makers and stakeholders—and a slight loss in autonomy. As part of a larger company, influencing these additional stakeholders and the ability to work across teams become essential skillsets.

I decided that I wanted to grow my leadership skills and lead at scale— larger teams with broader and more complex product lines. Also, I wanted help accelerate Intuit’s transformation to a SaaS company. Fast forward five years to 2014, and I feel that I have grown significantly as a technology executive and have also played a role in shaping Intuit’s SaaS portfolio. Over the past five years, I have steadily increased my scope and responsibility each year, culminating in a role where I have led a 700-person Engineering team spanning multiple locations and generating over $700M in annual revenue. I have also led the development of one of Intuit’s flagship SaaS offerings—QuickBooks Online. Not bad a journey for a startup guy.

Be Accretive and Constructive

Now, the ride has not always been easy, and I’ve made my share of mistakes along the way. However, I’ve learned from each of those situations— setbacks, things that didn’t go my way, or my own missteps— and grown as a result. There’s a sailing expression that one of my colleagues uses which is quite appropriate: “Smooth seas never made a great sailor.” In fact, becoming a better sailor requires being tested on choppy seas and bad weather. Dealing with adversity— and surviving— makes you a better leader.

In the early days, I didn’t understand some of the cultural norms at Intuit. I found that I was bringing up great points and ideas, but no one was listening— or worse yet I was shutting down discussions. I got some great coaching from my General Manager, Nora Denzel, and she also hooked me up with an executive coach. I also reached out to Brooks Fisher, an experienced Intuit exec whom I had met during the due diligence. After great coaching and my own self-reflection, I made a few subtle adjustments to my style and used more inquiry instead of advocacy. By rephrasing the same points as questions and by asking more questions to understand, I was able to engage in discussions and get others to appreciate my points of view— and eventually reach constructive outcomes in a collaborative fashion. By being more patient in discussions and by taking time to understand the history and context, I was seen as someone who there to help— and not someone who was there to critique and criticize.

Wow, did the floodgates open. I was invited to more discussions, and I was able to contribute to more strategic decisions. As a result, I was able to have greater impact across the company with our technology strategy and along the way share the recipes for our “secret sauce”— the best practices that had made our startup successful. Eighteen months after the acquisition, I was asked to lead the QuickBooks Online Engineering team, and as they say… the rest is history.

One of the things I learned from Nora and other execs at Intuit is to have a “teachable point of view” and share it more broadly. Over the coming posts, I plan to share some of the lessons I’ve learned along the past 5 years as I scaled my leadership. I also plan to share my leadership style. Stay thirsty my friend…

Nov 5, 2014

Advice from Tony Lam on How to Design Great Services

After a great keynote session at the Intuit Tech Forum, 300 engineers packed the Building 6 conference room for a talk by Tony Lam, CEO of Reverb Technologies. Tony shared best practices and advice on how to design great API’s to empower large development teams-- great advice indeed for us at Intuit as we are well underway on a company-wide services journey.  Here are my takeaways from Tony’s great talk.

Great developers are lazy and want to avoid doing the same things over and over. If you build great API’s and do the right things, your development teams can be more efficient. Hammock-driven development: do the right things upfront so the downstream things are easier. Service-based software is the new normal for development. Clean interfaces allow you to integrate systems developed with different languages.

But great API’s must (1) be easy to understand, (2) easy to try, and (3) easy to build against.
  • Façade: build a beautiful, simple interface to your system. Tony stresses the importance of having a great façade, even if the underlying system is complicated and not well decomposed.
  • Describe every aspect of your API’s interface, and get feedback from the consumers early. Swagger— just do it.
  • Build your client and server simultaneously with Swagger codegen. JSON + Mustache Templates generates working code that can serve as the foundation for your code.
  • Documentation is a must-have. And you should update the documentation at the same time as the code. Annotations in Java will get picked up automatically in swagger.
  • Client SDK’s are the fastest way to integrate with your service.

Jay Kreps Shares Lessons He Learned at LinkedIn

Jay Kreps, Principal Staff Engineer, shared lessons he learned during his past seven years at LinkedIn.

Scaling the Site: Started with standard Oracle DB and separate systems for search and social graph. Moved to key-value store (Voldemort) and Hadoop, which augmented the Oracle DB’s. Now added kafka on top of Hadoop and separated newsfeed and espresso.

  • Few simple cheap primitives: Like OpenGL which has triangles as basic primitive, think about high-performance basic primitives like key-value store. Picked on an anti-pattern from alums with centralized user table. 
  • Ops first: Teams with most operational focus spent the least amount of time on operations. Keep production designs simple and do them well—maybe at the expense of newer, fancier designs.
  • Do hard things later: Use asynchronous and offline/batch when possible instead of request-response patterns. 

Scaling the code base: How do you scale as you grow the size of the Engineering team? Started with a monolithic application and decomposed the application into services. Originally was not a very disciplined decomposition. 
  • Services (may) scale development. Bad services are worse than no services. 300-400 services without appropriate tools to diagnose and debug services. Dependencies not well understood. Treat the service as a product, with a team that owns the service and provides appropriate documentation and artifacts. Service layer evolution: Moved from Spring-RPC to REST + JSON.
  • The service contract is binary: Instead of just exposing existing code as a service, develop the service contract first and then write the appropriate code.
  • Isolation vs Utilization: Develop services with the right granularity. How many services should you have? He recommends having a team of 5 develop each service as a rule-of-thumb to ensure that services have the right granularity. He recommends against a model where a single engineer is responsible for several services. 

Scaling software engineering: Cutting up the codebase.
  • Build your process: They moved from using wiki pages that track lifecycle to tools and services that manage the life cycle: from review, to check-in, to build, to rollout.
  • Governance: Need a balance between central planning (communist) and free-for-all every team does their own thing (capitalist).
  • Treat code as property. Someone is responsible for the code— functionality, hygiene. That eliminated a lot of bureaucracy. 
  • But you need effective government. Don’t duplicate integration layers. Standardize where you can: monitoring.
Great stuff! I always enjoy learning about best practices and lessons from other companies. It's a great way to compare notes and also accelerate your own Engineering practices and technology.