Aug 14, 2016

The Inner Workings of “10x Engineers"

I recently gave a talk to our interns and co-ops, and I was pleasantly surprised by the questions they asked about my career growth and the advice they sought. During one of the questions, I shared my perspective about how to get noticed early in your career. Afterwards, I realized that this is the same pattern that I’ve seen with our most highly prolific and transformational software engineers— the 10x engineers. These are the best software engineers in any organization— the “difference makers” on any project. They solve the hardest problems, and blaze a trail for others to follow. They don’t have direct reports— but somehow they are the thought leaders that the team seeks out. They are prolific with their code, and they find ways to make the team better.

Throughout my career, I’ve led some very large Engineering teams, and I’ve found ways to stay close to the top engineers in my teams. I have watched the ways these top engineers worked, and I found that the top 1% can be ten times more productive than the average engineer. Three engineers, in particular, exemplify these traits: Jeff Brewer, Jim Showalter, and Joe Wells.

These 10x engineers excel in three dimensions:

  • Effort
  • Effectiveness
  • Influence


Effort

Let’s face it, all of us have meetings in a given week. These meetings take away from “keyboard time” to crank out code. The best engineers will find more hours in a day and week to write code— and they will work more hours than the average engineer.

For illustration, let’s assume that the average engineer has 10 hours of meetings in a 40-hour week, which leaves only 30 hours for writing code. When you work more hours, the weekly overhead of 10 hours remains the same, but you’ve just created more time for cranking out code. A 50-hour work week provides 40 hours of coding time (33% more than average). A 60-hour week provides 50 coding hours (66% more than average). A 70-hour week provides 60 coding hours, which is double the average. Jeff, Jim, and Joe are some of the hardest working engineers I’ve seen, and they are committing code at all hours of the day and night.


Effectiveness

Writing new code is only part of the software life cycle. Getting your code ready for production and fixing bugs after production eats into the time you have for writing new code. The best engineers create fewer bugs and spend less time debugging their code, which gives them more time to tackle new initiatives. While their teammates are fixing their bugs, they’re working on stories from the next sprint or finding creative solutions to problems that they see coming down the road. They are also very conscious of their time and they manage their time wisely— so that they can carve out more hours for coding. They attend only those meetings where they feel like they are needed and are adding value. They rearrange their calendar so that they have large, consecutive blocks of uninterrupted coding time. Jim teaches other engineers about his approach to time management and how he stays “in flow.” When Jim is “in flow,” he is prolific, and his code is high-quality, tested, durable— and it just works!


Influence

These 10x engineers don’t isolate themselves in a cave. I’ve found these engineers to be at the center of their project teams, no matter how large the team. They actively influence the broader team, and they are sought out by others on the team for advice or help. And boy, are these top engineers vocal! You will find them sharing their opinions on team e-mail aliases and in meetings. They interactive proactively with execs and constructively share their ideas. All of this passion and energy comes from a place of not accepting the status quo so that the team can do great things.

Joe led our largest Engineering initiative—the transformation of the QuickBooks Online (QBO) user interface and tech stack, which resulted in QBO Harmony. Jeff invented the QBO plug-in framework, which allows us to rethink how other applications from Intuit and third-party developers can integrate seamlessly into QBO. Both of these initiatives evolved from their early prototypes and experiments into game-changing technologies. Along the way, they evangelized their work and got “buy in” from other engineers and execs— and they changed the way teams work.


Conclusion

The top engineers are two to four times better than the average engineer in each dimension, and as a result, can achieve 6-10x the output of the average engineer. I’ve also found that these top engineers identify and mentor the engineers they see exhibiting these traits.

Staying close to these top engineers has provided many benefits. I got insight into the inner workings of the broader Engineering team. These engineers were also able to drive change at scale, since they have such amazing “tech cred” with the broader team. Working together, we have achieved amazing outcomes for the business.

Jul 12, 2016

Apps Quickly Becoming an Integral Part of Small Business DNA

When operating a business, it’s easy to get absorbed into daily routines, and forget to take a step back and ask, “Is there a better way?” One of the biggest takeaways I can share from my startup experience is to encourage entrepreneurs to explore and discover new technologies that can improve how you operate your business.

With technology changing by the minute and its options seeming endless, business solutions may appear out of reach, too expensive or completely overwhelming to think about. There are, however, free or low-cost alternatives to help your business run efficiently. A recent article in Entrepreneur Magazine discusses how apps and the Cloud provide entrepreneurs a better way to run their small business. Entrepreneurs running their business on the cloud not only benefit from the mobility factor, but also benefit from the many options to integrate new tools that help improve business productivity, operations, and even access to credit.

Let’s take for example Theresa Lee, the founder of Future Glory. Theresa handcrafts socially conscious goods, and she relies on QuickBooks integrations with Shopify and PayPal so she can focus on design, and not numbers. She uses the Shopify for QuickBooks app, which automatically syncs all of her Shopify e-commerce data, sales transactions, and PayPal payments to QuickBooks, giving her back time to focus on creating amazing accessories. Other customers who don't have an online store use the Sync with PayPal app to seamlessly import sales (including line items, fees and taxes), as well as customer information into QuickBooks. By using apps, Theresa manages all the day-to-day bookkeeping herself, spending less than 20 minutes a day on tasks such as invoicing and tracking vendor payments.

As the guy on the hair club commercials used to say, "I'm not just the owner, I'm also a customer." Before my startup was acquired by Intuit in 2009, I used QuickBooks to track my team's budget and expenses and an app from Bill.com to manage and approve purchase orders and bills. I didn't know accounting, but I was actually managing my accounts payable workflow. Imagine that! Bill.com continues to be a popular app that helps accountants and small businesses save time paying their vendors.

The first step to figuring out a solution is to not overthink the problem. Start by identifying software that solves a critical business need and will grow with you as your business grows. As detailed in both my personal example and that of Theresa, the apps that work the best are the ones that fully integrate with the software you use to manage and run your business. It’s a unified approach to business – the apps work together while the data flows into and out of your business software. That’s the best kind of integration!

Increased efficiency trickles into other areas for a business owner, such as mobility. Most software platforms and apps on the cloud have mobile solutions that untie a business owner from their desk and provide access to the same data from a web browser or mobile phone. Even on the go, owners can check inventory, access employee schedules, pull an expense or streamline a payment at any time.

Furthermore, apps can also become a resource for the business by providing funding options. Take Carol Highsmith, for example. Carol, a photographer for the Library of Congress, refined her business so she can focus on her craft of capturing a lasting photographic legacy for generations of Americans. As a self-employed photographer who lives on the road, she cannot spend her days slaving over the books, managing expenses, collating receipts, chasing up payments and stressing over cash flow. Thankfully, she uses QuickBooks Online and Fundbox – a tool that offers small businesses an easy way to advance their outstanding invoices for access to working capital. Carol leans on Fundbox to ease her worries during those highly stressful waits for clients to process payments. Carol says: “I can advance the money for a pending invoice and say ‘this is how I’m going to pay it back.' The money hits my account immediately, and I can check on the repayment status at any time. That's huge."

I encourage small business owners to make the time, take a step back and embrace new technologies or apps available to launch, grow and operate your business. Look for apps that solve your problems and can help you grow your business – and that seamlessly connect to your existing software solutions. And the best part about this all is that you don’t have to go far to find these solutions! If you are a QuickBooks customer, you can visit the QuickBooks App Store to find apps and try them out with your business. And if you're unsure, you can always ask your accountant for guidance.

We will continue this conversation in the fall, when Intuit QuickBooks will host a panel discussion as part of the Small Business Administration’s Small Business Technology Coalition on the use of apps by small businesses. We will provide entrepreneurs with an opportunity to hear directly from other small business owners who are using apps and how they have transformed the way they run their businesses. Small businesses will also have an opportunity to connect with developers who are continuously innovating with small businesses in mind. Stay tuned for more updates on the event shortly.

In the meantime, I’d be interested in hearing from you about your experiences in using apps to run your business. What’s working? What’s not working? Which ones do you love? How do you hear about the best apps?

Oct 19, 2015

How to Be a Male Ally for Women in Technology


At my second Grace Hopper Conference, I had a chance to catch up with one of my mentors, Nora Denzel, a tech executive with a distinguished career as General Manager, SVP Engineering, CEO, and Board Member. Nora and I met before she interviewed Sheryl Sandberg at the Thursday plenary session. As always, Nora was fantastic on stage— she was comfortable, funny, and informative. Nora's fireside chat with Sheryl was the highlight for me at this year's GHC! 

Nora has always been a big proponent of women in tech, and she has helped my team over the years. We talked about the progress over the past few years, and in particular how men (like me) can— and must— be allies, advocates, and sponsors for women in technology. For all you men out there, here's my three-step playbook for how you can help the women technologists in your organizations.


Understand Your State and Set Goals

For me, this journey began back in March 2013. I'm a VP of Engineering at Intuit and lead a 400+ person Engineering team. After an all hands in March 2013, I had invited my Directors to join me for the Q&A session. One brave engineer, Denise McInerney, had the courage to ask her manager, Siddharth Ram, why there were no women on my staff. Siddharth and I invited Denise to present at my staff meeting, and Denise led us through an eye-opening presentation on the state of women in technology, which included alarming data on women dropping out mid-career. 

After conducting a detailed gender analysis on my organization, I realized that "Houston, we have a problem." I saw the following trends in my team:
  • There were no women in the following roles: architect, group manager (who leads other managers), or Director.
  • Women comprised 24% of the overall team, but women represented less than 10% of the leadership and staff engineer roles.
  • Women were 3x less likely to be ready for promotion than their male counterparts.
After many skip-level meetings, discussions at my staff, we decided to focus on developing a talent pipeline of women ready for senior leadership roles: Director, group managers, architect, and principal engineer. I asked each Director to mentor at least 2 women managers and each Architect or Principal Engineer to mentor at least 2 women staff engineers.

Over the past two years, we've demonstrated a lot of progress, and the future is bright. Several women have helped lead the change within my organization, and they have been great partners during this journey, and they have become very accomplished technology leaders along the way.
  • Denise McInerney is now an Architect, and she leads the data analytics strategy for our broader Small Business team, which has over 1000 engineers.
  • We now have several women as group managers, who lead large development teams with significant scope and manage other managers.
  • Manasa Murthy leads the front-end team for QuickBooks Online, which is a high-growth SaaS offering.
  • Apparna Ramadoss leads QuickBooks Enterprise, which generates over $300M in direct revenue. 
  • Shruti Kulkarni leads the SaaS billing platform within QuickBooks Online, which helps us bill over 1.2M paying customers. Shruti is an alum from my team, and she is now part of our Platform team.
  • Anandhi Krishnaswamy is the Director of Quality Engineering for the QuickBooks team based in Bangalore, which generates over $1.6B in annual revenue and over 3.5M active customers. Anandhi is also an alum, but we still work closely together.
  • Loy Searle is the Director of Globalization for Small Business, and she leads a team that enables us to deliver QuickBooks in 12 languages to 100 countries. Loy recently joined my staff, and she's already become an integral member of the leadership team.
And the future looks bright. We have many women in the leadership team, and the pipeline for group manager roles and Director roles is promising. For the first time in years, the pipeline for leaders ready for promotions in the coming year is nearly gender-balanced.

Sponsor High-Performing Women 

There have been many great articles on the difference between mentorship and sponsorship. Mentorship is meeting regularly, being available for questions, and providing coaching and feedback. Mentorship is essential, but it is only the first step. Sponsorship facilitates career advancement by: creating visibility for outcomes and providing opportunities to take on broader roles beyond current charters. Here are some simple ways to sponsor women leaders in your team:
  • Identify mentors for high-performing women, and ensure that mentors meet regularly with their mentees. Many of the men on my staff have been great mentors and sponsors for women technologists: Guy Taylor, Madhav Nair, Dave Pickering, and Siddharth Ram, to name a few. Each of them has invested in meeting monthly with women leaders, including the ones named previously.
  • Invite women leaders and have them participate in your staff meetings and your strategy sessions. This serves two purposes. These women can observe how their leaders operate, and they will understand what is expected at the next level. By having these women present their work, you are creating a natural mechanism for talent reviews and visibility to leaders within your organization.
  • Send a woman leader as your delegate to a meeting when you can't attend. 
  • Invite women leaders to your staff dinners and informal get-togethers. By creating an informal environment where they can participate in the banter, you are developing more informal and casual connections and making yourself and your leadership team more approachable.
  • Give them stretch responsibilities. Shruti and Apparna, who are based in Bangalore, have led innovation programs in Bangalore along with their counterparts in Mountain View.
  • Hold a monthly skip-level lunch with the women leaders in your team. Manimala leads this forum, where my male peers and I are regular attendees. Manimala has recruited external and internal speakers, hosted panel discussions, and has also encouraged women leaders to present their own "journey lines." In this forum, women leaders network with their peers and interact regularly with their senior leaders.
All of these steps will help develop confidence in the women you are sponsoring and will create visibility into their leadership capabilities and outcomes.

It's a Marathon that Takes a Village

Developing the women technologists in your team requires patience and perseverance. Two years ago, my staff defined very specific goals around developing a talent pipeline of senior women leaders, architects, and principal engineers. Each member of my staff played an active role in mentoring and sponsoring women leaders. 

By setting specific goals around mentorship and sponsorship, we saw immediate results after the first year. Before this focus, women were 3x less likely to be ready for promotion than their male counterparts. After one year, we had erased this gap, and men and women showed equal readiness for promotion.

And we've seen many benefits from the process:
  • Overall employee engagement— for men and women— has improved year-over-year to 82. And engagement scores are even higher (84+) in teams where leaders like Dave, Guy, and Madhav have been active male allies for women leaders.
  • Retention rates for women are very high in my team. Over the past two years, only one woman manager (of a population of 20+) has resigned. I still see that as my failure; but, who knows, she might return. 
  • Across Intuit, we have made great progress. Women now hold 29% of all technology roles, up from 24% just a few years ago.
Focusing on advancing women engineers has generated no backlash from the men in my team. We have demonstrated that there is plenty of opportunity for women and men, and we are creating equal opportunities for advancement. This is a message I've repeated in all hands and reinforced with data on promotions. But we're not done. Soon, we will analyze data from the last fiscal year and identify opportunities for improvement.

I hope this blog post has caused you to reflect on your own team and what you can do to join our small— but mighty— group of male allies!

Jan 5, 2015

How My Defining Successes and Failures Have Shaped Me

At Intuit, we use the concept of a "journey line" to share our experiences and highlight defining moments in our career and/or personal lives. These defining moments shape us as individuals and leaders, and they also provide a window into what we value and how we operate. Over the years, sharing journey lines with my teams and my peers has been a great way to understand each other’s leadership styles so that we can work better together as a team.

I would like to share three defining successes and three defining failures. The keyword here is "defining." I have chosen the moments that have significantly shaped my leadership style, who I am, and how I operate.

As a former youth basketball coach of third grade through eighth grade boys, I believe in having a playbook. Since I coached out of necessity rather than basketball acumen, I was always watching other coaches and learning from them. I shamelessly incorporated offenses, defenses, and practice routines from other coaches. Whatever worked, I used. I apply the same philosophy to management. I learn from the best around me and incorporate winning strategies into my playbook.

I also stayed true to some coaching principles. For example, I never yelled at the boys, because I would never want another father to yell at my son. I remember one coach from a Redwood City team who yelled at his team throughout the game and after the game, even after they had beaten us! We all remembered him and made sure that we beat his team in a rematch the following year-- boy, did that feel good! I also taught both of my kids golf, and I always focused on keeping it fun-- on the course and at the driving range. Golf is a tough sport, with lots of mechanics to get right. All too many times, I would see a dad criticizing his son on the driving range, trying to help correct his swing. Both father and son were frustrated, and no one was having fun. Golf is about run, right? And who has a perfect swing? We all want to get better. So, focus on the positives and gradually improve our opportunities.

With that spirit of focusing on the positives, let's start with my defining successes:
  1. Crisis Response during Peak Season (PayCycle, Jan 2009): act quickly and take charge during a crisis.
  2. Adapting to Intuit (2009-2010): lead in a positive way, respect the past, and bring people along the change journey.
  3. Scaling QuickBooks Online (2011-2013): build a stable foundation, set lofty but achievable goals, and partner to deliver business outcomes.

But in the spirit of "reviewing film" after a game, here are my defining failures:
  1. Failure to monetize Java (Sun, 2000 – 2004): Pay attention to business outcomes and drive growth for the business.
  2. Failed pivot and persevering on flawed strategy (Cassatt - 2007): when your strategy clearly isn't working, change your strategy! Doubling down on a bad strategy can be a recipe for disaster.
  3. Payroll migration (Intuit - Aug 2010): own the outcome, take charge during a crisis and react quickly, and believe in yourself. 

I will share the lessons I learned from each, and how they have shaped my leadership style. Regarding failures, my philosophy is simple. Learn from the mistake, but don't repeat the same mistake! Failure to learn is not acceptable.

My journey line since 1997


Crisis Response during Peak Season (PayCycle, Jan 2009)


Before joining PayCycle in June 2008, I had led software teams that developed enterprise software and platforms for Java, cloud computing, and data centers-- all of the key ingredients required for creating Software as a Service (SaaS) offerings. However, I had never been responsible for a SaaS offering until I joined PayCycle. With any SaaS offering, you have to plan for daily workloads as well as spikes for seasonality and other unplanned events. For payroll, January is the busiest month. Employers must send out W2's to their employees and 1099's to their contractors, and they must also file quarterly and yearly taxes. January 1 and January 31 are the peak days with traffic 5-10 times higher than normal levels.

During my first peak season, our site experienced extreme performance issues on the first Monday in January. At 10am, all of the servers were pegged. Page-load times increased exponentially from 2 seconds to 10 seconds and to 25 seconds, but only after a certain threshold in sessions. The performance issues were database bound, with massive I/O between the Network Attached Storage (NAS) and the database (DB), but very little activity between the App Servers and the DB. Working with my team, we created three parallel efforts:
  • Physical I/O Capacity: That night, we installed a second shelf of storage into the NetApp to increase IOPS. Kyle, one of the systems engineers, caught the red-eye to Phoenix with the NetApp rep, and they carried a 1TB storage shelf on the plane!
  • Software Throttling: Until we could identify the problem, we implemented throttling in the app so that we could turn away new users when we approached critical thresholds. Users who were already using the offering could continue without impact.
  • Database Tuning: We had multiple calls with Microsoft throughout the day and had their systems engineer onsite the following morning. 
By Noon on Tuesday, we had all three solutions in place, we had solved the problem, and we had identified the root cause. The query optimizer in the database server was executing bad query plans due to poor DB tuning. In November, we had added significantly more (and different) data to one of the large tables, but we had not changed the sampling frequency for updating statistics on this large table. That caused the poor query plans, which resulted in lots of I/O between the DB server and storage. By changing the sampling frequency to 50% on this table and updating the stats, we were back in business!

I survived my first live fire exercise in my new role leading a SaaS offering. Not only was the experience was a great confidence builder; it was a great way to bond with my new team. My key takeaways: act quickly and take charge during a crisis.

Adapting to Intuit (2009-2010)


My last post described my experiences and the lessons I learned after being acquired by Intuit. I won't restate them all here, but I will provide some additional insights. Every company has a unique culture. I learned to appreciate that culture and find ways to contribute in a respectful and accretive way. This goes back to my coaching philosophy. Lead in a positive way, respect the accomplishments of the past, and bring people along the change journey.

Scaling QuickBooks Online (2011-2013)


In March 2011, I was asked to the lead the Engineering team for QuickBooks Online (QBO). During my first week in the new role, QBO experienced three major outages, each lasting more than 4 hours. Although the outages were caused by human error in the data centers, the root cause for the long recovery time was a lack of scalability in the application. Luckily, I had a pretty extensive playbook from my PayCycle days, and I had been through very similar situations. However, in my new role, I had dependencies on other teams across Intuit: shared services that were used by QBO and production infrastructure (servers, networking, and storage).
  • I worked with my peer, Jack Tam, who led shared services, and we developed a firefighting plan as well a long-term scalability plan. After the fires were out, Guy Taylor, who led Operations, and I developed a plan for High Availability and Disaster Recovery which included provisioning two new data centers and upgrading the entire production stack (servers, networking, and storage). 
  • With my Engineering team, I set an ambitious goal of improving application-tier scalability by a factor of 10. I had done some "back of the envelope" calculations and knew that this scalability was possible. Instead of setting an incremental performance goal, I set a more audacious goal, which challenged the team to think "out of the box" and find transformational opportunities. We eventually achieved a 7x scalability increase later in the year while reducing hosting costs by 50%.

Now, we had a scalable and reliable platform for QuickBooks Online. When I had joined earlier that year, QBO experienced weekly outages. In fact, Guy and I would regularly spend Fridays dealing with production issues and outages. By the end of the year, we were achieving 99.9% availability. Now that we were no longer dealing with fires, we had time to think about more transformational changes that could drive business growth.
  • Partnering with Heather Kirkby, who led Product Management, and Joe Wells, an Engineering Fellow from my team, we led a pivot on QBO that eventually reshaped the entire user interface for QBO. We stopped all incremental UI development and completely overhauled the UI tech stack-- from server-side Java UI to a rich-client with JavaScript and CSS. This work evolved into a new design effort for the QBO UI.
  • Working with Vishy Ranganath, who led the QBO team in Bangalore, and Anshu Verma, an architect in Vishy's team, we delivered QBO worldwide with support for 10 languages, 40 currencies, and global accounting standards. 

Today, QuickBooks Online is one of Intuit's flagship offerings, and QBO is driving growth across Intuit's small business ecosystem. My key takeaways: build a stable foundation, set lofty but achievable goals, and partnership is key to delivering outcomes.

Failure to Monetize Java (Sun, 2000 – 2004)


Now, let's talk about my key failures and what I learned from each one. During my five years at Sun, I helped create the Java platform. I led teams that contributed to Java 2 Enterprise Edition (J2EE) 1.3, J2EE 1.4, the Java Web Services developer pack, and the Java and XML (JAX*) technologies. We changed the way the world creates applications, and the Java platform is still one of the predominant development platforms. However, we failed to make money from Java for Sun. The Java group at Sun built a great platform, but every other J2EE partner enjoyed more monetary success than Sun's J2EE application server product line. When Linux and x86 servers disrupted Sun's high-margin Solaris and Sparc hardware businesses, the software group could not fill the gap on revenue and profit. Sun's top line revenue and profitability began to erode, and Sun never recovered from that decline.

This failure became readily apparent when Oracle acquired BEA for $8.4B and then acquired Sun a year later for $7.4B. At its heyday, Sun had over $16B in annual revenue and a $100B market cap. Although BEA was the most success J2EE application server vendor, it only had $2B in annual revenue and a much smaller market cap than Sun's. Every time I pass by the Facebook campus in Menlo Park-- the former Sun campus-- I'm painfully reminded of this failure. Could I have done more to monetize Java? During my days at Sun, I focused primarily on the technology and platform, and I didn't lean into the business.

My takeaways: Pay attention to business outcomes and drive growth for the business.

Failed pivot and persevering on flawed strategy (Cassatt: 2007)


In late 2004, I joined Cassatt, a well-capitalized cloud computing startup. Bill Coleman, former CEO of BEA, was at the helm of Cassatt, and he was a prolific fundraiser. Cassatt was an early pioneer in cloud computing, at a time when it was called utility computing. Cassatt followed a classic enterprise sales model, with a 9-12 month sales cycle that started with a POC and resulted in a 7-figure enterprise deal. Our direct sales force tried to convince companies to transform their IT shops into private clouds that were managed by Cassatt software. We were early pioneers in cloud infrastructure, and even pitched our technology to Amazon when they were building EC2 (the precursor to AWS). Unfortunately we never achieved a scalable business model. Each year, we signed a new 7-figure deal but continued to burn $1-$2M per month.

Gamiel Gran, who led business development, and I led an effort to develop a power-management appliance that relied on a viral sales model with a much shorter sales cycle. We leveraged the IP and existing software to focus on power management for departmental labs and server closets. Unfortunately, we were not successful in pivoting the company to this approach. Instead, the company doubled down on an even more elaborate and all-encompassing cloud-computing platform. After three and a half years at Cassatt, I joined PayCycle. A year later both companies were acquired, and the deals were announced on June 2. Intuit acquired PayCycle for $170M, and CA acquired Cassatt for less than $10M. Cassatt had raised over $150M in funding over the years, and every investor was wiped out.

My takeaways: when your strategy clearly isn't working, it's time to change strategies! Doubling down on a bad strategy can be a recipe for disaster.

Payroll migration (Intuit - Aug 2010)


I alluded to this failure in my previous post, but I will provide more of the gory details here. After Intuit acquired PayCycle, PayCycle became the go-forward platform for Intuit Online Payroll (IOP), and we planned to migrate customers from the former payroll offerings to the PayCycle platform over the following year. Over the course of 9 months, we migrated the 60K standalone IOP customers to the new PayCycle offering without any issues, other than concerns over price increases. The next 60K payroll customers were using a payroll solution that was tightly integrated with QuickBooks Online-- and that's where all hell broke loose.

We had known about feature differences between the former Intuit and the new PayCycle payroll offerings, but migrated customers on the standalone offering did not complain about the missing features. However, the QBO-Payroll customers complained quickly after migration, and their reaction was quite vocal. They called in droves to customer care for help with the migration, which resulted in long wait times for customers on the phone as well as long handle times. And customers also complained on social media and community forums.

I made two key mistakes here. First, I was lulled into a false sense of security from the standalone payroll migration. Even though early indicators from the QBO payroll migration showed signs of customer frustration with the feature gaps, I ignored those early indicators. The migration was a long project, and I wanted to finish. Everyone wanted to be done. So we "ripped off the bandaid" and migrated 60K customers in 30 days. The other mistake was not reacting quickly. I waited two weeks before mobilizing the team to address the most critical feature gaps. In the meantime, we continued the migrations. The right call would have been to stop the migrations, address the customer concerns, and then resume the migrations.

My key takeaways from this experience:
  • Own the outcome: Take charge during a crisis & react quickly. Had this been a production issue or outage, I would have reacted quickly. However, this situation was an entirely new experience for me-- a "feature outage" or product gap.
  • Believe in yourself: It gets real lonely when things are bad. I led the remediation effort and product work to address the gaps, and at times it felt like I was in Siberia. However, you can't let one mistake-- no matter how large-- stop you from moving forward. Even after striking out in baseball, you will still have many at-bats in the remaining innings; and great baseball players only get on base 30% of the time. Pick yourself up, dust yourself off, and get back in the game.

I updated my playbook with the lessons I learned from this particular failure. Since then, I've been responsible for two product migrations, and they've gone much smoother. I applied everything I learned from this one and had contingency plans in place. "What doesn't kill you, makes you stronger." I hope you've learned something about me and have learned from my same mistakes.

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.