<acronym id="uye6a"><small id="uye6a"></small></acronym>
<acronym id="uye6a"></acronym>
<acronym id="uye6a"><center id="uye6a"></center></acronym>
<acronym id="uye6a"></acronym>
Showing posts with label management. Show all posts
Showing posts with label management. Show all posts

Monday, June 20, 2016

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.     

Wednesday, April 22, 2015

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

Thursday, July 31, 2014

Inability Of Organizations To Manage "The Flow" Of Talent Management

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 access to more opportunities c) get mentoring. We all have seen under-performers who have more potential. In my experience, most of these people don't opt to underperform but they are put in a difficult situation they can't get out of. We routinely see managers not identifying this as a systemic organizational problem but instead shift blame to employees confusing potential for performance suggesting to them, "you could have done so much but you didn't; you're a slacker." A similar employee with equal performance but less potential would not receive the same remarks on his/her performance.

Treating potential as an innate fixed attribute

One of the biggest misconceptions I come across is managers looking at potential as innate fixed attribute. Potential is a not a fixed attribute; it is something that you help people develop.

These out-performers who are not labelled as "high potential" are mostly rewarded with economic incentives but they don't necessarily get access to opportunities and mentoring to rise above their work and a chance to demonstrate their potential and make a meaningful impact.

Fixating on hi-potential out-performers

Not only managers fixate on hi-potential out-performers but they are also afraid that these employees might leave the organization one day if they have no more room to grow and if they run out of challenges. As counterintuitive as it may sound this is not necessarily a bad thing.

We all live in such a complex ecosystem where retaining talent is not a guarantee. The best you can do is develop your employees, empower them, and give them access to opportunities so that they are in a flow. As a company, create a culture of loyalty and develop your unique brand where employees recognize why working for you is a good thing. If they decide to leave you wish them all the best and invest in them: fund their start-up or make them your partners. This way your ecosystem will have fresh talent, place for them to grow, and the people who leave you will have high level of appreciation for your organization. But, under no circumstances, ignore the vast majority of other employees who could out-perform at high potential if you invest into them.

Wednesday, March 12, 2014

Why And How Should You Hire A Chief Customer Success Officer?

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 lines of businesses but while they have strong business acumen they are not customer-centric and lack technical as well as product leadership to understand deep underlying systemic issues.

Traditional ways to measure customer success is through product adoption, customer churn, and customer acquisition but the role of a Chief Customer Success Officer (CCO) extends way beyond that. One of the best ways to watch early signs of market shift is to very closely watch your progressive customers. Working with these customers and watching them will also help you find ways to improve existing product portfolio and add new products, organically or through acquisitions. Participating in sales cycles will help you better understand the competition, pricing points, and most importantly readiness of your field to execute on your sales strategy.

I often get reached out by folks asking what kind of people they should be looking for when they plan to hire a CCO. I tell them to look for the following:

T-shaped: Customer don't neatly fall into your one line of business and so is your CCO. You are looking for someone who has broad exposure and experince across different functions through his or her previous roles and deep expertise in one domain. The CCO would work across LoBs to ensure customers are getting what they want and help you build a sustainable business. Most T-shaped people I have worked with are fast-learners. They very quickly understand continuously changing business, frame their point of view, and execute by collaborating with people across the organization (the horizontal part of T) due to their past experience and exposure in having worked with/for other functions.

Most likely, someone who has had a spectacular but unusual career path and makes you think, "what role does this person really fit in?" would be the the right person. Another clue: many "general managers" are on this career track.

Business-centric: Customers don't want technology. They don't even want products. They want solutions for the business problems they have. This is where a CCO would start with sheer focus on customers' problems—the true business needs—and use technology as an enabler as opposed to a product. Technology is a means to an end typically referred to as "the business."

Your CCO should have a business-first mindset with deep expertise in technology to balance what's viable with what's feasible. You can start anywhere but I would recommend to focus your search on people who have product as well as strategy background. I believe unless you have managed a product—development, management, or strategy—you can't really have empathy for what it makes to build something and have customers to use it and complain about it when it doesn't work for them.

Global: Turns out the world is not flat. Each geographic region is quite different with regards to aptitude and ability of customers to take risk and adopt innovation. Region-specific localization—product, go-to-market, and sales—strategy that factors in local competition and economic climate is crucial for global success of an ISV. The CCO absolutely has to understand intricacies associated with these regions: how they move at different speed, cultural aspects of embracing and adopting innovation, and local competition. The person needs to have exposure and experience across regions and across industries. You do have regional experts and local management but looking across regions to identify trends, opportunities, and pace of innovation by working with customers and help inform overall product, go-to-market, and sales strategy is quite an important role that a CCO will play.

Outsider: Last but not least, I would suggest you to look outside instead of finding someone internally. Hiring someone with a fresh outside-in perspective is crucuial for this role. Thrive for hiring someone who understands the broader market - players, competition, and ecosystem. This is a trait typically found in some leading industry analysts but you are looking for a product person with that level of thought leadership and background without an analyst title.

About the photo: This is a picture of an Everest base camp in Tibet, taken by Joseph Younis. I think of success as a progressive realization of a worthwhile goal.

Monday, January 20, 2014

Focus On Abstraction And Not Complexity

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 picture. In many cases, not being able to make a decision has far worse consequences than not solving a problem which may or may not be important in long run. Abstracting complexity helps me make a decision with focus on consequences as opposed to a short term solution. Abstraction also allows me to spot behavioral and systemic problems as opposed to tactical and temporal problems.

Ask yourself what you remember the most about a couple of complex problems that you solved last year and the answer most likely won't be how great your solution was but it very well would be what the problem actually taught you. It's not the complexity that you will cherish but the simplicity, the abstracted experience, is what will stay with you for the rest of your life to help you find solutions to similar problems in future.

Photo courtesy: miuenski 

Thursday, October 31, 2013

How I Accomplished My Personal Goal Of Going To Fewer Meetings

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 documents for a meeting; I prepare for all my meetings and I firmly believe that meeting time should be judiciously used to discuss what people think about the information and make important decisions as opposed to gathering information that could have been accomplished prior to a meeting.

Opt-out with an alternative ahead of a meeting

If I believe the agenda is partially useful but I won't add any value by being part of the meeting, I connect with an organizer ahead of the meeting to clarify a few things or give my input, either in person or via email or phone. In most cases, me reaching out to an organizer serves the purpose and I don't have to go to the actual meeting. If I do end up having to go for such meetings I ask an organizer for a permission to either walk-in late or leave early. This saves me a lot of time and I don't have to sit through a meeting when I am not required to be there.

Postpone a non-critical meeting

If I see that I am invited to a non-critical meeting, I ask to postpone it by a few days citing my non-availability. In many cases, the issue would have been resolved in a few days and we won't be required to meet. It is important to decline the original meeting request and ask the organizer to create a new meeting request in future even if you have an intent to postpone and not cancel the meeting. Most people don't create a new meeting request and I won't hear back from them.

DVR the meeting

I ask organizers to record certain meetings when I believe that parts of a meeting would be useful at later stage. I fast forward non-interesting parts of such meetings and listen to the parts that I like. I underestimated the effectiveness of listening to a recording until I organized a few meetings as podcasts and listened to them during my commute. Most fascinating part of this approach, other than an ability to fast forward, is being able to listen to a meeting as an information session without having to worry about understanding all details and anxiety to make decisions.

If everything else fails, multitask

I believe it is somewhat rude and distracting to others when people bring their laptops/tablets to a meeting and keep working on it and not pay attention to the meeting. But, this isn’t true when the meeting is an audio conference. I don't work on my laptop or tablet when I am in a meeting room; I am fully committed to the meeting and completely present. However, for certain meetings, when I know that I don't have an option to opt out and it is going to be a waste of time, I dial into the meeting instead of being there in person. I do continue to work on my laptop while participating into the meeting. This is not to confuse with remote meetings that I participate in or lead when all people are not at the same location. I am fully present for those meetings.

Before you ask, yes, I did meticulously measure the time I saved. I had a simple spreadsheet that did a great job. I was a little hesitant in the beginning to push back for meetings but l became more comfortable as I started saving more and more time. I would highly encourage you to follow these rules or create your own and save yourself some quality time that you can use do other useful things.

Photo courtesy: Ho John Lee

Saturday, August 31, 2013

Purple Squirrels

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 stories. But, even if not bizarre, by and large, interview practices have been quite unscientific, inconsistent, and highly subjective. Most companies don't have a good way to objectively conduct interviews and identify the right candidates to hire. This sounds silly but unfortunately it's true.

If we are really serious about talent we should focus on our ability to attract, acquire, and retain talent as opposed to whining about it.

Always be sourcing

Cultivate hiring culture; always keep looking for people in your network even if you have no immediate plans to hire. In many cases, the best hires are the ones that are not actively looking for a job. The references from your best current employees are the right ones to get started with. Go to conferences and talk about your company and projects. Use this as a learning opportunity to calibrate your understanding of the market and seek out an outsider's perspective on what might be the right hiring strategy for your organization. You are constantly making an effort to attract talent. Treat this as an ongoing task as opposed to one time hiring activity.

Pulse has redesigned their technical hiring process by introducing a "try before buy" model where the prospects can get to actually work with Pulse's team on a real project as part of an interview process. Hiring someone is a critical decision and this approach is a win-win situation. This is also the reason why interns make good hires as both sides get enough time to check each other out.

Treat interviewing as an important skill

Most employees are trained to do their work but they have a little or no training in interviewing other people. I find it astounding that we hire social scientists, ethnographers, and user researchers to meticulously and scientifically interview users to better understand their behavior and eventually design a product that meets or exceeds their expectations. But, we don't spend anytime training our own employees to better understand the prospects and hire the ones that would actually design these products.
"Years ago, we did a study to determine whether anyone at Google is particularly good at hiring. We looked at tens of thousands of interviews, and everyone who had done the interviews and what they scored the candidate, and how that person ultimately performed in their job. We found zero relationship."
I have seen interviewers either rejecting interviewees in the first few minutes of an interview solely relying on their hunch and intuition or mistaking interviewee's confidence as his or her competence without any kind of objectivity. I find it strange that the technical as well as the business folks who believe in science, have been trained to trust empirical evidence, and possess great analytical skills fall for subjective interpretations based on their pre-conceived biases. Interviewing objectively is hard because it is boring to follow an objective approach leaving your subjective smartness aside. Very boring and very hard.

Look for behaviors and not just skills

Have your interviews designed to measure past behaviors and not skills alone. Skills are easy to learn, but behaviors are hard if not impossible to change. Start with your most successful employees and identify what behaviors they exhibit and how these behaviors have made them successful and valuable to your company. I cringe when I hear words "chemistry" and "cultural fit." These are actually behaviors that people find it hard to describe and evaluate. There's a way to break down this chemistry and cultural fit into measurable behaviors that you could look for during an interview. Don't judge people based on what they can do during an interview because it does not represent a real working life scenario. Asking people to solve a puzzle or draw something on a whiteboard during an interview doesn't prove much. Infamous for ridiculous interview practices Google has confessed them to be complete waste of time.
"On the hiring side, we found that brainteasers are a complete waste of time. How many golf balls can you fit into an airplane? How many gas stations in Manhattan? A complete waste of time. They don’t predict anything. They serve primarily to make the interviewer feel smart." -- Laszlo Block, senior vice president of people operations at Google.
Unless you have designed a consistent interviewing process that focuses on asking questions to objectively assess candidates based on the behaviors they have exhibited in their previous jobs you will become a victim of your own biases and subjective interpretations.

Retaining talent is as important as attracting and acquiring talent. A separate blog post on that topic some other time.

Photo courtesy: Harvard Business Review

Sunday, June 30, 2013

Celebrating Failures

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 could go wrong by imagining that the project has failed. This gives the team an opportunity to proactively look at risks and prepare to prevent and mitigate them.

Failures just like successes become nothing more than events with different outcomes

A failure or a success is nothing but an event. Just like sports you put in your best effort and still fail because you control your efforts, dedication, and passion but not the outcome. While it is absolutely essential to analyze mistakes and make sure you don't repeat them but in some cases, looking back, you would not have done anything differently. When you look at more failures more often they do tend to become events with different outcomes as opposed to one-off situations that you regret.

It changes your attitude to take more risk because you are not afraid of outcome

When failures are not a one-off event and you are anticipating and celebrating it more often it changes how you think about many things, personally as well as professionally. It helps you minimize regret and not failures.

I don't want to imply failure is actually a good thing. No one really wants to fail and yet failure is the only certainty. But, it's all about failing fast, failing often, and correct the course before it's too late. Each failure presents us with an opportunity to learn from it. Don't waste a failure; celebrate it.

About the picture: I took this picture inside the Notre Dame in Paris. I see lights as medium to celebrate everything: victory of good over evil as celebrated during the Hindu festival Diwali and a candlelight vigil to show support and motivate people for a change.

Wednesday, May 22, 2013

Lead, Follow, Or Get Out Of The Way

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 out of the way." In any situation I ask myself whether I should be leading in this situation or following someone's lead and extend my full support to do so. If neither make sense I simply get out of the way and let people do their job. Building, selling, and supporting software, like many other things, require a loosely-connected (to put it in software terms) organization where there are leaders who lead and follow other leaders at the same time. This gets more and more complicated as the size and portfolio of an organization grow over years. People draw artificial boundaries and lose sight of the mission and the big picture.

Leading is hard, following is harder, and getting out of the way is the hardest which requires a conscious attempt to empower people to do their job without getting into their way. But, it is an approach that does work and I encourage you to try it out and share it with others.

Photo courtesy: Pison Jaujip 

Monday, March 31, 2008

Research labs and innovation priorities in an IT organization

Earlier this month HP announced that HP labs is going to focus on 20-30 large projects going forward instead of focusing on large number of small projects. If you compare the top 10 strategic priorities for 2008 that Gartner announced late last year you would find a lot of similarities even though HP's projects are not necessarily designed to address only the short term priorities. Quick comparison:

HP : Gartner
  • Sustainability: Green IT
  • Dynamic Cloud Services: Web Platform & SOA + Real World Web
  • Information explosion: Metadata management + Business Process Modeling
“The steps we’re taking today will further strengthen Labs and help ensure that HP is focused on groundbreaking research that addresses customer needs and creates new growth opportunities for the company.”

The role of a traditional "lab" in an IT organization has changed over last few years to focus on the growth and value projects that strategically aligns with company's operational, strategic, management, and product innovation priorities. The researchers have been under pressure to contribute significantly to the efforts that are directly linked to the product lines. There are pros and cons of being research-oriented versus product-oriented and it is critical that researchers balance their efforts. I firmly believe that labs should be very much an integral part of an organization and anything that they do should have a direct connection to the organization.

“To deliver these new, rich experiences, the technology industry must address significant challenges in every area of IT – from devices to networks to content distribution. HP Labs is now aligned to sharpen its focus on solving these complex problems so HP and its customers can capitalize on this shift.”
Traditionally labs have been perceived a cool place to work where you can do whatever you want without any accountability towards company's strategy and this poses a serious credibility issues for some labs regarding their ability to contribute towards the bottom line. I agree that the research organization should be shielded from the rest of the organization or incubated to a certain extent to protect the disruption in the ongoing business and allow researchers to focus and flourish in their efforts but eventually the efforts should be integrated well into the organization with the stakeholders having enough skin in adopting, productizing, and possibly commercializing what comes out of a lab. Credibility of a lab in an organization goes long way since the product development organizations largely control what customers would actually use, at least in IT organizations. Many innovations that come out of a lab may not even see the light of day if the research organization does not have credibility to deliver what customers actually want. Innovation by itself is not very useful until it is contextualized with the customers' and users' needs to solve specific problems.
<acronym id="uye6a"><small id="uye6a"></small></acronym>
<acronym id="uye6a"></acronym>
<acronym id="uye6a"><center id="uye6a"></center></acronym>
<acronym id="uye6a"></acronym>