My Next Tour of Duty - Designing and Delivering Talent Cloud Experience

After being part of an incredible and exhilarating ride at Google Cloud, watching it grow more than 300% in 4 years, I have decided to continue my tour of duty outside of Google, joining iCIMS as their Chief Product Officer.

As part of the iCIMS executive management team, I will lead the charter to design and deliver the end-to-end unified Talent Cloud experience across the iCIMS portfolio of products to its ~4,500 customers that employ more than 35 million people worldwide. As the market leader in recruiting technology, iCIMS has a unique competitive advantage to deliver innovative solutions and define a new category of recruiting technology. I’m excited and energized to join this team!

Mature products become platforms and mature platforms become an ecosystem. From Oracle to SAP to Google, my journey has been from a product to a platform to an ecosystem, spanning many different roles. At Google, I relished the opportunity to work on countess projects and initiatives to scale and strengthen technology partner ecosystem to help drive growth. I also learned the ropes of how to think, build, and operate anything and everything at scale while fostering a fast-paced, customer-centric innovation culture.

I am excited to take my collective learning to a domain I am passionate about: Talent Management. I deeply care about creating equitable experiences for all of us, candidates and employees, who thrive to make an impact by coming together to be part of something bigger than ourselves. Designing tools to enable this experience and empower organizations to attract, engage, hire, and advance the right talent is a key to build a diverse, winning workforce. I cannot be more thrilled to embark on this journey!

A New Chapter In My Life; Google

When I decided to leave SAP to take a short sabbatical I didn’t really know what to expect. Six months later I am happy to report that it was one of the best decisions I ever made. These were some of the best weeks and months of my life. After this short period of disconnecting to recharge and rejuvenate myself I am reconnecting to the professional world. I have accepted an offer with Google to lead the API Ecosystem for Google Cloud to help drive adoption and monetization of the Google Cloud portfolio of platform and products, at scale, by working with various partners as well as coordinating efforts internally at Google with product management and engineering.

As I disconnected I felt the life slowed down and I had more time on hands and a fewer things to do. I met with many people during my sabbatical to learn from them and bounce off my thoughts. We tend to postpone taking certain decisions and don’t spend a lot of time thinking about many things in life, personal as well as professional, simply because we are compressed on time and each task, activity, or a decision only gets a fraction of overall available time we have. I tried hard not to work hard. Just slowing down and soaking it all in helped clear up many things. Taking time off also helped me prioritize what I really wanted to do. I am a big believer in unstructured free time where there is nothing planned ahead of time; wake up and take each day as it goes. I enjoyed doing mundane tasks and that took my attention off a typical rapid life of a technologist in the Silicon Valley. I would highly encourage you to take a short sabbatical in your career if the circumstances allow you to do so.

To a lifelong learner and a “product" person nothing excites me more than immersing myself into breadth of possible opportunities at the intersection of technology and business to create meaningful impact at Google. I have always admired Google for its ability to take risk by going after some of the hardest problems that require massive scale, foster innovation, and embrace failure as part of its culture. I have always been impressed with the talent Google manages to hire and retain. I am looking forward to be surrounded by people much smarter than me and learn from them. It’s going to be an exciting ride!

Disconnect To Reconnect

All journeys, no matter how fruitful, come to an end. After a little over nine and half years I decided to leave SAP last week. What a journey this has been!

Making Design Thinking real

I was hired into a multidisciplinary corporate strategy team, set up by Hasso Plattner, the chairman of SAP's supervisory board, and the only co-founder still with the company, whose mission was to help SAP embrace “design thinking” in how it built products and processes as well as how it worked with customers. It was the best multidisciplinary team one could imagine to be part of. We were multidisciplinary to a fault where I used to joke that my team members and I had nothing in common. I am proud to be part of this journey and the impact we helped achieve. Over the years we managed to take the double quotes out of design thinking making it a default mindset and philosophy in all parts of SAP. It was a testament to the fact that any bold and audacious mission starts with a few simple steps and can be accomplished if there is a small passionate team behind it striving to make an impact.

Be part of foundation of something disruptive

Being part of the Office of CEO I worked with two CEOs—Henning and Leo—and their respective executive management teams. This was by far the best learning experience of my life. I got an opportunity to work across lines of businesses and got first hand exposure to intricate parts of SAP’s business. As part of the corporate strategy team I also got an opportunity to work on Business Objects post-merger integration, especially the joint product vision. Some of that work led to the foundation of one of the most disruptive products SAP later released, SAP HANA.

Fuel the insane growth of SAP HANA

HANA just happened to SAP. The market and competition were not expecting us to do anything in this space. Most people at SAP didn’t realize full potential of it and most customers didn’t believe it could actually help them. I don’t blame them. HANA was such a radically foreign concept that it created a feeling of skepticism and enthusiasm at the same time. I took on many different roles and worked extensively with various parts of organization and SAP’s customers to explore, identify, and realize breakthrough scenarios that exploited the unique and differentiating aspects of HANA.

HANA’s value was perceived to help customers to do things better, cheaper, and faster. But, I was on an orthogonal, and rather difficult, mission to help our customers do things they could not have done before or could not even have imagined they could do.

I was fortunate enough to significantly contribute to early adoption of HANA—zero to billion dollars in revenue in three years—which also went on to become the fastest growing product in SAP’s history. I got a chance to work closely with Vishal Sikka, the CTO of SAP and informally known as the father of HANA, on this endeavor and on many other things. It was also a pleasure to work with some of the most prominent global SAP customers who are industry leaders. They taught me a lot about their business.

Incubate a completely new class of data-first cloud solutions

As HANA started to become a foundation and platform for everything we built at SAP my team took on a customer-driven part-accelerator and a part-incubator role to further leverage the most differentiating aspects of the platform and combine it with machine learning and AI to help build new greenfield data-first cloud solutions that reimagined enterprise scenarios. These solutions created potential for more sustaining revenue in days to come.

Practice the General Manager model with a start-up mindset

A true General Manager model is rare or non-existent at SAP (and at many other ISVs), but we implemented that model in my team where I was empowered to run all the functions—engineering, design, product management, product marketing, and business development—and assumed the overall P&L responsibility of the team. The buck stopped with me and as a team we could make swift business decisions. The team members also felt a strong purpose in how their work helped SAP. Often times, people would come up to me and say, “so your team is like a start-up.” I would politely tell them claiming my team as a start-up will be a great disservice to all the real start-ups out there. However, I tried very hard for us to embrace the start-up culture—small tight teams, experimentation, rewarding efforts and not just the outcome, mission and purpose driven to a fault, break things to make them work, insanely short project timelines, and mid to long term vision with focused short-term extreme agile execution—and we leveraged the biggest asset SAP has, its customers.

Be part of a transformative journey

I was fortunate to witness SAP’s successful transformation to a cloud company without compromising on margins or revenue and HANA-led in-memory revolution that not only paved the path for a completely new category of software but also became the fastest growing product in SAP’s history. These kind of things simply don’t happen to all people and I was fortunate to be part of this journey. I have tremendous respect for SAP as a company and the leaders, especially the CEO Bill McDermott, in what the company has achieved. I’m thankful to all the people who helped and mentored me, and more importantly believed in me.

Looking forward to not doing anything, at least for a short period of time

At times, such a long and fast-paced journey somewhat desensitizes you from the real world. I want to slow down, take a step back, and rethink how the current technology storm in the Silicon Valley will disrupt the world again as it has always and how I can be part of that journey, again. There are also personal projects I have been putting off for a while that I want to tend to. I’m hoping a short break will help me reenergize and see the world differently. When I broke this news to my mom she didn’t freak out. I must have made the right decision!

I want to disconnect to reconnect.

I am looking forward to do away with my commute for a while, on 101, during rush hours, to smell the proverbial roses. I won’t miss 6 AM conference calls, but I will certainly miss those cute self-driving Google cars on streets of Palo Alto. They always remind me of why the valley is such a great place. For a “product” person, a technology enthusiast, and a generalist like me who has experienced and practiced all the three sides—feasibility, viability, and desirability—of building software the valley is full of promises and immense excitement. In coming days I am hoping to learn from my friends and thought leaders that would eventually lead me to my next tour of duty.

About the picture: I was on a hiking trip to four national parks a few years ago where I took this picture standing on the middle of a road inside Death Valley National Park. The “C” curve on a rather straight road is the only place on that long stretch where you could get cell phone reception. Even short hiking trips have helped me gain a new perspective on work and life.     

"Trying to be nice" Becomes Less Important For Developers As They Gain Experience

No, I didn’t say this, but 56,033 developers in 173 countries who responded to recent Stack Overflow's developer survey did.  I have always enjoyed going through these surveys to validate my several hypotheses and learn new things. I would strongly encourage you to go through the results from the most recent survey here.

Here are some interesting insights:

Occupation

"Full stack developer" is the most identified developer occupation. More and more developers are gravitating towards this occupation where they are simultaneously working on 5 to 6 programming languages or frameworks at time. Rise of new languages and frameworks don’t mean developer fragmentation, but more developers picking up more and more languages. It’s not about SQL or Angular; it’s SQL and Angular.

Ninjas: 10% of respondents self-identified as Ninjas! Yeah. So, yes, watch out.

Age

The millennial: The highest percentage of developers, 28.4%, are in the age group 24-29, followed by 23.6% in the age group 20-24, and 18.1 % in the are group 30-34. This validates my hypothesis: more than 70% of developers are millennial, from youngest to oldest.

Average age: India has the lowest average age for developers, 25.5. This might surprise some people unless you look at the overall population and demographics of India. While there is a large number of Indian developers who are older than 25.5 the current number of engineers graduating from colleges and entering into the workforce are outnumbering some of these developers to bring the overall average down. India is the second most populous country in the world (behind China) with median age of 25. Compare that to the US where the median age is 36. It will all make sense.

Star Trek versus Star Wars: The highest percentage of developers (68.4%) like Star Wars. The same age group also happens to like Star Trek the least (17.6%), if at all they know what Star Trek is. If you really like Star Trek you must be old :-)

Gender disparity

This continues to be the most depressing statistics.

92.8% “developers” are male.

There’s not much salary gap between genders for young developers in the US, but male developers of the age of 30+ get paid up to $20,000 more than female developers. This perhaps explains the ongoing debate: male and female developers get initially hired at similar salaries, but male developers negotiate harder for promotions and raises compared to female developers. I would argue this disparity will most likely be also true for disciplines other than technology.

Diversity

While 73% of developers responded they value diversity, product managers and engineering managers responded they value diversity the most. It validates my hypothesis that people value diversity more when they either hire/manage people or manage a product. While individual contributors still work in a diverse team and most of them value diversity they perhaps don’t realize and appreciate the bigger impact of a diverse team.

Education

Machine learning developers have most likely completed a Masters or a PhD. This isn’t surprising given the complexity around this domain and traditionally how niche it is. As it becomes more mainstream I expect these skills to get commoditized and the numbers will likely change.

Developers, across the board, with Masters and PhD degrees get paid more. Good to know that higher education is still important.

Technology

The most popular stack: JavaScript is the most popular technology (55.4%). No surprises - thanks to Node.js, Angular, and many other frameworks. SQL is the second most popular language followed by Java. This proves the power of SQL as ubiquitous database access language and simplicity of JavaScript that makes it a preferred choice of language even for backend programming.

Emerging technology: Developers seem to be loving React (trending 311.3%). It proves that if you design a better framework developers will flock. Developers are not necessarily married to a specific framework; they love to learn and adopt newer things if it helps them solve their problems in a better way. If you’re are an organization making technology decisions your life is going to get more and more complicated. You have to design your platform and architecture to embrace newer languages and frameworks more frequently than you would have anticipated or desired.

Developers love Mac: Mac is the most popular desktop OS for developers. Windows has been losing its share and this year Mac overtook Linux as the most popular desktop OS.

Employment

Looking for a new job: Indian developers amongst all other developers are either actively looking for a job (29.2%) or will consider an opportunity (60.7%) when approached. This is consistent with what I have experienced: it is extremely hard to retain talent in India and developers will jump ship when offered something slightly better. Employers are outcompeting each other in attracting talent and offering outrageous raises. Unlike many countries, developer salaries are not normalized in India and the country has relatively high inflation rate and weaker currency (against US dollar) making it easier for US-based companies to offer more money to make developers jump ship.

Priorities: German developers prioritize work-life balance over salary. I have personally known many German developers and many would agree to these numbers.

Titles: Developers care less about titles and more about making or influencing decisions as they gain more experience. Titles may sound exotic when developers join the workforce, but they realize over a period of time that titles are often disconnected with compensation and empowerment. These numbers are a reflection of that realization.

Promotions: Getting promoted is one of the biggest priorities for Indian developers. This explains the hierarchical nature of Indian companies and the societal value of a promotion which might be less relevant in the most western countries.

Source: Stack Overflow 2016 Developer Survey

Salary

US and Australia are somewhere on the top when it comes to developer salary (considering purchase power parity). My hypothesis is that good higher technical education and favorable immigration policies in these countries are making it relatively easy to attract the best students and early talent. This creates a vibrant ecosystem where skills are appreciated and valued more compared to other places. Also, good developers attract other good developers.

Large companies tend to pay higher salary than smaller companies. The survey does not seem to reflect the equity versus salary split and preferences - that could have been a better indicator of where and why developers work. Contrary to popular belief freelancers/contractors are paid about 10% less than full-time developers.

Photo courtesy: Thomas Hawk

What Makes You A Good Product Marketing Manager?

"A Pretty Package Can’t Sell A Poor Product” - Bill Walsh

I am a big fan of Bill Walsh and his management philosophy. Following is an excerpt from his book The Score Takes Care Of Itself.

To promote sales of season tickets, I came up with an ambitious (and time-consuming) plan called “Pick-a-Seat Day” in which we put bright red ribbons on all available season ticket seats and invited the public to buy their favorites. And that’s not all. 

On the big promotion day we offered balloons, free donkey rides, ethnic foods, and clowns for the kiddies. Also, free popcorn, soft drinks and hot dogs, jugglers, a Dixieland band, and magicians. It was really a great family event for the thousands of folks who came out to Candlestick Park.

The next morning I arrived at the office early to see what the results of my “Pick-a-Seat Day” promotion were. Or, more accurately, weren’t. Total season tickets sold: seven. (I bought three more myself on the fifty-yard line, just so I could report that we’d hit double digits. In fact, our family still has those seats.) 

“Pick-a-Seat Day” was a total flop, but it was a flop that taught me something very important: A pretty package can’t sell a poor product. Results— in my profession, winning football games— are the ultimate promotional tool. I was trying to sell a bad product, a team that was the worst franchise in sports, that had lost twenty-seven straight road games, and whose record at home wasn’t much better. 

From that point on, I focused my energies exclusively on creating a quality product, a team that was worth spending money to see. When that was achieved, we also achieved a ten-year waiting list to buy a 49ers’ season ticket. 

In your efforts to create interest in your own product, don’t get carried away with premature promotion— creating a pretty package with hype, spin, and all the rest. First, make sure you’ve got something of quality to promote. Then worry about how you’re going to wrap it in an attractive package. The world’s best promotional tool is a good product.

I see this as a chronic problem in the software industry and many product marketing managers make it even worse. They tend to impose their own belief system in isolation while marketing to prospects without championing product and customer views as well as ignoring competition and where the product fits in the market. Over a period of time I have learned a few lessons observing and woking with them as well as being one of them for some part of my work.

Amplify the value proposition, don’t recreate it: One of the most common mistakes I observe product marketing managers make is to recreate value proposition of a product instead of amplifying it. A lot goes into making a great product - finding the end user needs, designing compelling experiences, and enabling them with technology. Product managers and engineers spend a lot of time making great products. Don’t reinvent the wheel; it’s precisely those stories and the unique characteristics of the product you want to amplify. As a product marketing manager your job is to tell great stories and not to rewrite them. Find the right medium and use it to your own advantage. Get customers excited and help them see the possibilities.

Sell the problem, not the solution: I have seen people focus on a very narrow definition of competitive differentiation, pricing and positioning. It’s not just about pricing and positioning; customers shop in categories for a specific set of problems or challenges they may have. As a vendor you need to have empathy for your customers on their buying process. Spending time articulating how your products solve their problems is far more important than outlining features and outsourcing the task of matching features with JTBD of your customers. Product marketing managers tend to fixate on what they are selling as opposed to what customers are buying.

Apple commercials are a great example of bringing products to life in scenarios and stories without marketing a product feature-by-feature. These commercials are designed to emotionally connect with consumers in their lives on why they need to buy Apple products and what they might use them for. Communicating with buyers on how you understand their problems is far more important than telling them they can do whatever they want with your products. This is especially hard when you’re selling technology and what customers are buying is a solution.

You need to understand the market, competition, and customers, not in isolation, but how they move with each other. Most product marketing managers I have seen take either a market view and force products to customers or take a customer view in justifying how it meets demands of the customers, but fail miserably articulating how their products fit in the market with the competition because they ignore the market. You have to do both. You could decide to ignore what you don’t prefer but your prospects won’t.

Focus on what customers are buying and not what you’re selling: Most successful go-to-market strategies are the ones that are profoundly simple. I have observed product marketing managers fail at one of the most basic tasks to ensure the prospects understand what they are buying. With complicated pricing, packaging, and a combination of deployment options, more often than not, customers are confused about what they are buying even if a product could potentially solve their problems. This confusion creates friction and customers end up buying what they understand in simple terms and that may not be your product even if it is superior to your competition. If you can’t simplify the value proposition in simple English without any jargon and offer an extremely clear explanation of what they are buying and how they can operationalize it with the lowest time to the highest value you’re not doing your job well.

Leverage irrationality: Software is rational, human beings are not. I have seen product marketing managers take a classical demand-supply economics as their go-to-market basis. They strongly feel that the product (supply) should somehow fit into an existing need (demand). While, to large extent, I do hope product managers (and not product marketing manages) are looking at those opportunities, but not all products are designed that way. It’s your job to tap into this very irrationality, the behavioral economics, to create demand for the product. Make customers want your products and not just need them. Better understand behavioral economics to decide how you will market the product, how you will package it, and how you will sell it. Customers don’t make decisions based on the product merit alone; good sales people know this and they leverage these aspects in their sales cycle. What I find strange, especially in enterprise software, is that product marketing managers stay oblivious to the fact that customers don’t always make rational choices. Perhaps it’s the formal business education or the “knowledge curse” that gets in their way and they overthink a human behavior situation and make it an economics issue.

Footnote: This is not an attempt to stereotype all product marketing managers and make them look stupid. In fact I have met and worked with some really bright product marketing manager. This is simply an attempt to outline how they might be able to channel some of their energy in a different way to be more effective in certain situations.

The Discriminatory Dark Side Of Big Data

It has happened again. Researchers have discovered that Google’s ad-targeting system is discriminatory. Male web users were more likely to be shown high paying executive ads compared to female visitors. The researchers have published a paper which was presented at the Privacy Enhancing Technologies Symposium in Philadelphia.

I had blogged about the dark side of Big Data almost two years back. Latanya Sweeney, a Harvard professor Googled her own name to find out an ad next to her name for a background check hinting that she was arrested. She dug deeper and concluded that so-called black-identifying names were significantly more likely to be the targets for such ads. She documented this in her paper, Discrimination in Online Ad Delivery. Google then denied AdWords being discriminatory in anyway and Google is denying to be discriminatory now.

I want to believe Google. I don’t think Google believes they are discriminating. And, that’s the discriminatory dark side of Big Data. I have no intention to paint a gloomy picture and blame technology, but I find it scary to observe that technology is changing much faster than the ability of the brightest minds to comprehend the impact of it.

A combination of massively parallel computing and sophisticated algorithms to leverage this parallelism as well as ability of algorithms to learn and adapt without any manual intervention to be more relevant, almost in real-time, are going to cause a lot more of such issues to surface. As a customer you simply don't know whether the products or services that you are offered or not at a certain price is based on any discriminatory practices. To complicate this further, in many cases, even companies don't know whether insights they derive from a vast amount of internal as well as external data are discriminatory or not. This is the dark side of Big Data.

The challenge with Big Data is not Big Data itself but what companies could do with your data combined with any other data without your explicit understanding of how algorithms work. To prevent discriminatory practices, we see employment practices being audited to ensure equal opportunity and admissions to colleges audited to ensure fair admission process, but I don't see how anyone is going to audit these algorithms and data practices.

Disruptive technology always surfaces socioeconomic issues that either didn't exist before or were not obvious and imminent. Some people get worked up because they don't quite understand how technology works. I still remember politicians trying to blame GMail for "reading" emails to show ads. I believe that Big Data is yet another such disruption that is going to cause similar issues and it is disappointing that nothing much has changed in the last two years.

It has taken a while for the Internet companies to figure out how to safeguard our personal data and they are not even there, but their ability to control the way this data could get used is very questionable. Let’s not forget data does not discriminate, people do. We should not shy away from these issues but should collaboratively work hard to highlight and amplify what these issues might be and address them as opposed to blame technology to be evil.

Photo courtesy: Kutrt Bauschardt

The Art Of Delegation - My Ten Principles For Healthy Team Culture

"Delegate almost to the point of abdication" - Warren Buffet

I have worked with numerous leaders at all levels and have seen the best and worst practices in how they delegate or they don’t. Here are my 10 principles of delegation that I practice and advocate based on the lessons I have learned by being on both ends of the spectrum.

1. Delegating is not simply about asking someone to do something for you; it’s about setting expectations on desired outcome and offering to help.

2. Delegating does not mean being a slacker but shifting focus instead on right things; as a leader, more often than not, doing right things is more important than doing things right.

3. Delegating something that you typically won’t is the best way to empower your employees; all other empowering talk is cheap.

4. Never take credit for what you delegate; in fact never take credit for anything that you accomplish.

5. Delegation leads to transparency; most employees struggle to get a bigger picture and don’t have insights into what their managers do.

6. Don't say, “I trust you,” instead delegate a task where an employee understands she would not have gotten an opportunity to work on it unless the manager had her trust.

7. Put yourself in the shoes of whom you are delegating to; manage their concerns, emotions, and challenges instead of yours.

8. If afraid of delegating a task imagine the worst case scenario before you delegate it and mitigate the situation by setting expectations and periodically monitoring the progress to make you comfortable delegate.

9. If still afraid of delegating unpack the task into sub-tasks and start with delegating the first sub-task; it’s always the first step that is incredibly hard to take.

10. Share with your employees what you don’t want to delegate; help them build empathy for what you do and motivate them to step up for that task the next time.

Photo courtesy: tanakawho