EnjoyTech

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 ...

"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 ...

The flow , a concept developed by one of my favorite psychologists, Mihaly Csikszentmihalyi, matches the popular performance versus potential matrix that many managers use to evaluate and calibrate their employees. For people to be in the flow they need to be somewhere in the middle moving diagonally up. Ideally, this is how employees should progress in their careers but that always doesn't happen. To keep employees in the flow you want to challenge them enough so that they are not bored but you don't want to put them in a situation where they can't perform and are set up for a failure. Despite of this framework being used for a long period of time I see many organizations and managers continue to make these three mistakes: Mistaking potential for performance Performance, at the minimum, is about given skills and experience how effectively person accomplishes his or her goals. Whereas potential is about what person could do if the person could a) acquire skills b) gain acce...

For an ISV (Independent Software Vendor) it is everyone's job to ensure customer success but it is no one person's job. This is changing. I see more and more companies realizing this challenge and want to do something about it. Sales is interested in maintaining relationship with customers for revenue purposes and support works with customers in case of product issues and escalations. Product teams behave more like silos when they approach their customers because of their restricted scope and vision. Most chief technology officers are fairly technical and internal facing. Most of them also lack the business context—empathy for true business challenges—of their customers. They are quite passionate about what they do but they invariably end up spending a lot of time in making key product and technical decisions for the company losing sight of much bigger issues that customers might be facing. Most chief strategy officers focus on company's vision as well as strategy across li...

I am a big fan of software design patterns. A design pattern is a general reusable solution to a commonly occurring problem within a given context. Software design patterns are all about observing technical abstractions in complex problems by identifying patterns and applying well known solutions to them. My management style is largely based on abstractions. When things get muddy I step away from complexity for a few minutes and explore abstractions. This helps me keep in touch with the bigger picture while I look for solutions to a given problem. When you're too close to a topic you do tend to fixate on complexity leaving sight of the bigger picture. I make a conscious attempt to go between complexity and abstraction when I need to. And, that's perhaps the only way to manage it effectively in pursuit of working smart and not just working hard. Complexity invariably makes people get into an analysis paralysis mode resulting into a decision gridlock that affects the bigger pictu...

As part of my job I have to go to a lot of meetings. As it turns out, all meetings are not equally important. Many times, either during a meeting or after the meeting, I end up asking myself why the hell did I go to this meeting. Sounds familiar? A couple of yeas back, instead of just whining about it, I decided to do something about this situation. I set a personal goal to cut down the meetings that I would go to by 20%. Not only I succeeded but I kept the same goal the year after and I accomplished that as well. This is how I did it: Ask for prep documents and an upfront agenda If the meeting that I am invited to does not have an agenda in the meeting request, I ask for it before I commit to it. This approach has two positive effects: 1) it forces an organizer to think what he/she wants to accomplish that invariably results in a productive meeting b) I have an opportunity to opt out if I don't receive an agenda or the agenda doesn't require my presence. I also ask for prep do...

It is fashionable to talk about talent shortage in the silicon valley. People whine about how hard it is to find and hire the "right" candidates. What no one wants to talk about is how the hiring process is completely broken. I need to fill headcount: This is a line that you hear a lot at large companies. Managers want to hire just because they are entitled to hire with a "hire or lose headcount" clause. Managers spend more time worrying about losing headcount and less time finding the right people the right way. Chasing a mythical candidate: Managers like to chase purple squirrels . They have outrageous expectations and are far removed from reality of talent market. Managers are also unclear on exactly what kind of people they are looking to hire. Bizarre interview practices: "How many golf balls can fit in a school bus?" or "can you write code with right hand while drawing a tree with left hand?" We all have our favorite bizarre interview st...

Being a passionate design thinker I am a big believer in failing fast and failing often . I have taken this one step further; I celebrate one failure every week. Here's why: You get more comfortable looking for failures, analyzing them, and learn from it I have sat through numerous post-mortem workshops and concluded that the root causes of failures are usually the same: abstract concepts such as lack of communication, unrealistic scope, insufficient training, and so on. If that’s true, why do we repeat the same mistakes, causing failure to remain a common situation? Primarily because many people find it hard to imagine and react to abstractions, but can relate much better when these concepts are contextualized into their own situation. Post-mortem of a project would tell you what you already suspected; it's hindsight and it's a little too late. I have always advocated a "pre-mortem workshop" to prepare for a failure in the beginning. Visualize all the things that...

If you have been following this blog you would know that I mainly blog about enterprise software, cloud, and big data with a few occasional posts on design and design thinking. That's what I am most passionate about. Having spent my entire career building enterprise software I have realized that success and competitive differentiation in market place boil down to an organization's unique ability to get three things right where management plays a key role: 1) people who can continuously learn and adapt to change 2) processes that are nimble and evolve as the company evolves 3) products that solve a real problem and delight the end users. While I continue to blog about enterprise software I have decided to evolve this blog further by adding a few management posts going forward. There are a series of management topics that I am interested in but let's start with the basic one which is about my core management philosophy. My management philosophy is "lead, follow, or get o...