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.