2013, my personal reflections…

2013 had two highlights for me. First one was the realization about the game changing nature of cloud/SaaS both from business and technical perspective as well as how similar/different it is from the internet boom. Second one was experiencing entrepreneurship by bootstrapping a venture from scratch, utilizing the full potential of my Babson MBA to create a magical team and to create an experience of a lifetime for all.

Last year at the velocity conference while interacting with the leaders from the likes of Netflix, Google, Facebook, I realized how the cloud ecosystem really works and what makes it successful. The cloud apps ecosystem for a company comprises of loosely coupled open source services, services from vendors such as Amazon along with philosophies such as DevOps, complex adaptive systems, Agile that create a rich, real time, fully elastic/scalable experience across a diverse array of devices in a most economical fashion. It sounds too complex and almost impossible, till you get your hand dirty, which is what I was doing at CA Technologies. Being at the center of the Internet boom at Razorfish and now at the center of Cloud at CA, I was noticing the similarities between the two. Like the Internet boom, there is some mystique to it, till you get into it. You start with the low hanging fruit with simpler apps, like search/email during the internet boom time and Photo sharing (Dropbox) and Backup (Carbonite) in the Cloud. With time the focus is shifting to more mainstream applications. In summary, the key to success seems to be:

  1. Drastically simplify application and design with a large number of customers in mind.
  2. Make it fully automated (DevOps) so that any updates can be fast and low cost allowing you to learn and react.
  3. Make it economical by substantially reducing all costs, such as hardware, licensing, manual labor so you can compete.
  4. Culture and mindset of continuous delivery and continuous improvement.

Couple of years back, New England community signed up to host the BMM 2013 convention and chose me the Convener for this convention. For those not familiar with BMM, it is a cultural convention with some business networking for people from the state of Maharashtra, in India, held every two years at a different city in the US. We started with a core team of 4 of us and $40K in seed funding and over the 2 year period built a team of over 200 volunteers, raised $1.5M and delivered an experience of a lifetime for 4,000 attendees over 3 days. Almost no-one of from our team had done anything remotely similar in size and scope, so it was truly an entrepreneurial effort for all of us. We built 22 teams for marketing, fundraising programming, facilities, food, registration, business conference and other activities. We had to work with several hundred sponsors, speakers, performers and donors from all over US, India and other countries. We ran into several serious challenges, made several rookie mistakes but in the end we delivered one of the best conventions in the BMM history. The lessons learned from this experience run the entire gamut of a startup lifecycle, starting from working with people such as team building, working with global stakeholders with significant cultural differences, negotiating, influencing to project management, finance, marketing, sales. Being a non-profit, the best reward for all of us was being part of this magical team and the overwhelming positive feedback from all who experienced it. It was truly a spiritual experience and we all will cherish memories of this for the rest of our lives. The key lessons from this experience were:

  1. If you design organization with a purpose for each team, trust and respect them, and delegate effectively, they can do miracles. Teams are watching the actions of its leaders for cues on culture and motivation.
  2. It is good to have a plan but more important is continuous monitoring and reacting to changes both to exploit new opportunities and minimize risks.
  3. Setbacks, obstacles as well as seemingly impossible tasks can be achieved incrementally if you are persistent.
  4. Risk taking is fundamental to achieving a grand vision and hairy goals.
Posted in Uncategorized | 1 Comment

Can Power and Politics be ever good?

Power and politics have always been a mystery to me. I have seen few people do it well,  but like anything interpersonal, it is hard to learn and master. I recently attended a workshop by Lisa DiTullio on the subject that helped me understand it and it get few tips on how it can be good when done for the greater good rather than for personal gains.

Let us start with politics. Politics has negative connotations because we often hear about situations in which people use it for their personal gains or to win rather than for the greater good of the company or the group they represent. At the most basic level, politics is about understanding the differences of opinions of various parties involved and aligning them towards the common goal. This alignment is critical to any change initiative or an initiative where a diverse group of people have to work together. The person who makes this possible (often called a political animal) has the social skills to:

  • Intuitively read people and their perspective
  • Position the goal or objective to their context
  • Influence people in aligning towards the common goal
  • Understand the games being played

When you see someone good in politics, it almost feels like that person is a chameleon or does not have his or her own opinion and gets influenced by others too easily. Key is to find the right balance between providing some flexibility to interpret goals in the context of the other person while staying firm on key aspects of the goal.

There are seven types of games that can be played. It is important to be able to recognize when someone plays these games or if others will perceive you to be playing these games.

  1. Resist and Revolution game – This involves bucking the established system. You can use this to establish leadership, get some new ideas into the system and break the status-quo. It can be perceived as negative if it is used just for arguing against the existing system without any concrete proposal.
  2. Smash the revolution – As the name suggests, this can be effective if used to remove the trouble makers in the way but can create the perception of heavy handed management.
  3. Favouritism – This involves favoring people you are most familiar with or have good relationships with. It can help in expediting work but can create resentment and be divisive to the team.
  4. King of the Castle – This involves building your powerbase based on resources such as budgets, staff, functions, etc.
  5. Gang Game – This happens when you have more than one king of the castle.
  6. Knowledge and skill Game – Played my experts who use mystery of the their skills and knowledge to hold power over others
  7. Promotion and position game – This involves bringing in candidates to bolster your power and position.

Power is the ability, to mobilize resources, to get things done. The true sign of power is accomplishment. It is about perception – of our own and others. If you and others perceive you as powerful, you can get things done.

Sources of power are:

  1. Authority – based on position
  2. Expert – person possessing knowledge and skills
  3. Resource – ability to supply/withhold resources
  4. Interpersonal – working with others
  5. Networks – associating with others that are powerful

It is important to periodically assess others’ perception of your power and work on improving it.

This seminar provided a good framework to analyze critical situations in personal and professional life as well as assess and improve your and other’s perceptions.

Posted in Uncategorized | 1 Comment

MIT Sloan CIO Symposium – New IT Innovation Models – Panel Summary

MIT has always been associated with innovation and hence this panel had a special place in the Symposium. We put together a panel of experts from diverse backgrounds to get the full perspective. It included, Roy Rosin, Chief Innovation Officer at Intuit, Prof. Cusumano from MIT, who recently published a book on strategy and innovation, Alan Trefler, Founder & CEO of Pegasystems maker of BPM software that helps companies innovate and Arthur Filip, VP & GM of technology consulting at HP, who helps customers innovate. The moderator for the panel was Roger Roberts, a partner at McKinsey for IT Strategy service helping clients conceive and apply technology solutions to enhance innovation and productivity.

The discussion in the panel was structured around few open ended questions around innovation. Here is the summary of the insights that the panelists shared during the discussions.

What is innovation? What does it mean to you in your context? How do you know it when you see it?

Innovation is the marriage between invention and pragmatism propelled by the ability to iterate and continuous improvement. In the IT context, it means the business people come up with an idea, work with IT to implement it, deploy it at a massive scale and continually refine it working with customers. You don’t get innovation if the mechanics, the pragmatism and the ability to change is not intrinsic part of your strategy.

Innovation simply is the creation and capture of value from new ideas. Innovation is about how quickly can people test and validate the new ideas. As a Chief Innovation officer, the gift I got from Intuit was the time to sit back and study to see the patterns. Innovation is not about making few big bets but making lot of small bets and refining it based on the learning from them.

What leads to great outcomes? Can conditions be created – or is some extra catalyst needed – a blinding insight, a special person, a disruptive technology? Does methodology matter?

Most of the Agile people are quite rigid and religious about the mechanics/methodology and not about results. Majority of the organizations were using some form of agile on their projects. World has been moving towards a more flexible approach, where the teams are moving fast, which is very good for innovation because it allows for lot of experiments and trial and error. Designing experiments and analyzing data from experiments is important but the key is monetizing these experiments after the analysis.

What is the role of platforms in enabling innovation? What are the necessary characteristics? Can “bad platforms” constrain innovation?

Platform is a set of common components that solves a particular problem in ways that brings multiple parties together and covers various aspects of people, process and technology. Historically people thought of platform as a way of building siloed apps. Innovative companies come up with conceptual platforms such as customer platforms and organize the entire company around platforms. This leads to creating an ecosystem around the platforms.

The debate on open vs proprietary platforms is not quite black and white. There are platforms that are open but not quite open like Microsoft and closed but not completely closed like Apple. Google is almost completely open and Linux is completely open. So there is a spectrum of openness in the platforms and companies have been successful in innovating under both the models. Irrespective of the openness, platforms play a key role in innovations.

 Should we have “chief innovation officers?” How should they be measured? What metrics (if any) make sense in measuring innovation in an organization?

It is important to make sure innovation happens and that’s not just platform and technology innovation. It helps to have someone responsible for it. Innovation is everyone’s job but it is the innovation officer’s job to ensure that the company is good at what it takes to succeed from a holistic standpoint. This means understanding things like:

  • What are the skills you need that are different?
  • How are you immersing your workforce in the realities of the customer’s world?
  • How are you responding to innovation across the portfolio with speed?
  • Do you have the right dashboards for the executives to review?
  • How do you celebrate your wins? (small)
  • What cultural changes do the leaders need to drive?
  • How can people work well in a matrix environment?
  • How can you get teams through the internal governance and process fast?

Innovation officer makes sure the new ideas see the light of the day.  Here are the key attributes/characteristics for a chief innovation officer role:

–        Understand the future of technology

–        Have skills and experience with innovation

–        Can create the culture and environment for innovation

–        Understand the business

There are three different levels of metrics to measure innovation:

  1. Participation metric –ideas generated
  2. Conversion metric – how many ideas get implemented and the speed of conversion
  3. Shareholder metric – impact of the ideas on company’s performance.

The three levels represent evolution as the innovation progresses. Some companies measure the innovation by measuring the revenues coming from not so mature businesses and mature businesses separately.

How do you build the infrastructure for innovation? What enablers can a technology leader put in place to encourage innovation?

Sometimes there can be so much churn in the platform that it is hard to innovate. You need certain stability and that can lead to more innovation. The platform has to evolve but the speed of evolution needs to be manageable.

At the end of the day, the innovation has to make money for the company. Hence in addition to Invention, Innovation companies need to focus on Exploitation. You want to invent periodically but then focus on taking that invention to the market through exploitation. Taking action on the innovation is critical part of the innovation.

Technology leaders need to ensure that governance is there both bottoms up and top down. Need to give teams enough time/resources to germinate the ideas but also set goals for a measurable output.

What is the role of the CIO in catalyzing innovation? How should an IT leader spend his/her time to make an impact on this front?

It is possible to bake innovation in the culture of the company. CIOs need to take leadership actions that create conditions for innovation. One of the innovative companies, took a group of IT and business people, co-located them and had them adopt Agile scrum to facilitate innovation. CIO’s play critical role in creating environment that is conducive to innovation and has become key part of CIO’s responsibility.

Posted in Uncategorized | Leave a comment

Do you feel Dilbert works for your company?

I have heard this comment several times in many of the companies that I have worked for because he is often dead on. The humor in lot of the Dilberts comes from the different mental models we all have of a situation at work. In particular, he harps on the differences in the mental models between management and the people doing the actual work.
Craig Larman in his book on Thinking and Organizational Tools for Large-Scale Scrum talks about the Weinberg-Brooks’ Law which states that more software projects have gone awry from teams taking action based on incorrect system models than for all other causes combined. Because of the shorter iterations and transparency, Agile tends to expose these differences early and often.
As we all know, Software Product Development has complex positive and negative feedback loops and nonlinear behavior. The behavior of these systems defies gut instinct. Hence if we apply incorrect “common sense” and quick-fix solutions without understanding the big picture, it may not yield results.
Larman talks about a technique called “Systems Thinking” that helps teams develop a common mental model that more realistically represents the complex system that they work in and continuously improvise it as you learn more about the root causes and their effects.
There is also a new form of coaching called “systems coaching” starting to emerge that coaches teams not only to come up with a common mental model but also to ensure that everyone is aligned with the new model and that it produces results.
Once Agile teams achieve mastery within their teams, the impediments start to come from the larger system in which they operate. In large companies, teams have to work with lot of corporate bureaucracy and this can become an impediment in their continuous improvement journey. Systems thinking can help you analyze the system issues and continue the journey to realize full potential. I was talking to a friend who recently started to work for a startup after spending several years at a large corporation. He was experiencing an order of magnitude productivity increase and he attributed more than half of it to the non-existence of the internal systems at the startup.

Posted in Uncategorized | Tagged , , , | Leave a comment

Learn “How Doctors Think” to reduce Thinking Errors

Because of the lawsuits, the “technical errors” such as getting the left foot amputated instead of the right, have been significantly reduced. However we continue to hear about the “thinking errors” that cause misdiagnosis and not treating the real illness. Sometimes these errors are small and can be corrected later but in many cases it can be too late by the time they are corrected.

The book “How Doctors Think” by Jerome Groopman is a good read to get into doctor’s mind and understand what role we as patients can play to reduce the probability of a thinking error. He has collected tons of real life stories of patients and doctors that were thinking errors. He uses his wrist illness as an example of how in spite of being a Doctor, he had difficulty in getting the correct diagnosis. He uses a lot of medical jargon, but I did not find it an impediment in understanding his view point. This blog post is my interpretation of the key points from the book.

Here are some of the factors that seem to contribute to these thinking errors:

  • Time pressure on doctors to see most patients to maximize income
  • Pressure not to stray from standardized procedures to avoid lawsuits, satisfy insurance companies and follow what they were taught in medical school
  • Challenges in separating psychosomatic illnesses from physical illnesses
  • Errors in analyzing the symptoms and test results to come to the appropriate conclusion

Coming up with an accurate diagnosis is very much like detective work, similar to what you see in shows like “Dr House”. In several situations, it requires out of the box thinking that takes time. In some cases, it requires a psychological skill of the Doctor to understand and interpret what the patient is saying, kind of like what you see in shows like “Lie to Me”.

Here are some of the typical cognitive biases that may lead to the thinking errors:

  • Anchoring – Quickly and firmly latching on to a single possibility and ignoring other possibilities. If the patient’s blood sugar is high then focus on diabetes.
  • Availability – tendency to pick relevant examples that quickly come to mind. If most recent patients are suffering from flu, then pick flu.
  • Attribution – Base the decision on some personal attribute rather than evidence or symptom. If a patient is a complainer, then assume that it is all in his/her head.
  • Confirmation bias – Selectively accepting or ignoring information to fit the diagnosis.

So what can we do as a patient?

  1. Learn more about your condition, diagnosis and treatment options so that you can understand the thinking the Doctor is going through and participate in the process.
  2. Ask the right constructive questions to prevent the pitfalls in Doctor’s thinking (This forces the Doctor to think and spend more time on your case and encourages him/her to think out of the box)
  3. Get second/third opinion or change the Doctor if he/she does not like to explain you or appreciate you participating in the diagnosis process.
  4. Dont give up – be persistent and hopeful

This book made me realize that Doctors are not much different from all of us. We make so many judgement calls in our personal and professional lives that are not black and white and are subject to errors. Our expectation is that since the judgement calls Doctors make deal with life and death, they need to be perfect all the time. However the complexity of the problem and the environmental factors do not always lend themselves well to a perfect decision every time. By being more proactive and participating in the process, we as patients can significantly improve the odds of making a perfect decision.

Posted in Uncategorized | Tagged , , , | 1 Comment

Is Agile inefficient?

I get this question frequently from teams that are new to Agile. Here are some of their concerns:

1. If you do not have detailed plans up front or if the plans keep changing, is that efficient?

2. How can you be efficient with the overhead of all the Agile meetings?

3. Design/code/test in small increments is inefficient because of constant context switching.

4. Agile recommends that team members help each other out to meet the Sprint goals. We have resources with specific expertise and specialities. It is not efficient for them to do something that they are not expert in.

5. Sprints always end at the same time, but my work doesn’t thus interrupting my flow of work and making me inefficient.

Efficiency is defined as a ratio of the output to the input of any system. To improve efficiency, we can maximize output and/or minimize the input. If our sole focus is  on minimizing the input without regard to maximizing the output, we will miss the boat. Hence it is important to analyze the context for efficiency for each of these concerns and determine which ones offer a better overall value.

In the first concern, the efficiency is in the context of the project plan, how well it represents reality and how close is the execution of the plan to reality. This measures the efficiency of the planning process and how well the team is executing with respect to the plan. The premise here is that we can accurately identify detailed plans up front and they will not change as the project progresses hence measuring plan vs actual is a good metric of progress. If this premise is true, then Agile will be inefficient for the project because Agile is based on the assumption that it is difficult to plan all the details up front and the plans will change during the course of the project. Hence Agile planning is incremental, time boxed, and delayed. Planning in Agile happens at a high level during release planning, and gets incrementally detailed and refined during each of the sprints. This way you get the benefit of planning the big picture without the overhead of maintaining the details as the plans change. During the sprint planning, team identifies the detailed tasks and they may have an overall idea about the sequence in which they will be performing the tasks but they are not putting it on a timeline. This happens during the daily standup call, when each team member tells the rest of the team which task they plan to take up that day. This delayed approach to scheduling allows the team to have more realistic and accurate schedule.

In the second concern, we are talking about the most efficient utilization of everyone’s time. If the tasks for each team member are well identified, they do not have any dependencies on each other, there are not expecting any roadblocks and most importantly they do not need to collaborate with each other to plan or design, then Agile meetings are an overhead. On teams that time box their meetings appropriately, the overhead of all Agile meetings is no more than 10%. This is a small price to pay to improve the utilization of the remaining 90% of the time. Even if you overlook the innovation aspect of collaboration, most teams are able to cut down their effort significantly through dialogue and discovery during these meetings.

In the third concern, we are talking about is the efficiency of grouping similar tasks together. (I still remember my coursework in industrial engineering that talked about optimizing manufacturing tasks with things like time studies, etc.) This industrial engineering approach works well if the tasks are well-defined/understood, repeatable, the components will always work well together in the final assembly and most importantly will not benefit from receiving feedback on your interim work from the customer. If these assumptions are correct, then waterfall approach will be more efficient. Agile believes that by showing smaller increments of work to the customer and rest of the team, you are getting continuous feedback (before you go too far with the implementation), the integration issues will be much smaller and it gives team an opportunity to reflect on the work so that they can improvise. The assumption here is that is more important to get the right thing to the customer even though it may be little inefficient than getting something to the customer in a more efficient manner. With the iterative and incremental approach, many teams are able to deliver what ordinarily would have been a “Release 1.3” version of the feature in the “Release 1.0” timeframe thus improving your odds that customers will benefit from the new feature and in the process improving your competitive advantage.

In the fourth concern, there is a trade-off between efficiency of an individual over the efficiency of the project in getting the most critical feature to the customer. When team members help each other out to meet the goal of the sprint, they are certainly helping the project to get the most critical feature to the customer on time but in the process they are also improving teamwork and morale for the team. In one team, when the developers helped QA in completing their work for the sprint, they developed new respect for the complexity and importance of QA work that significantly improved the collaboration in following sprints.

In the fifth concern, the trade-offs are similar to the third concern. Yes, it is less efficient to interrupt the flow periodically to get feedback from the team and the customer, however if it improves the odds of building and right feature for the customer and reducing integration risks, then it is a good trade-off.

In conclusion, Agile will be inefficient if your project has well-defined and stable requirements, has no risks and will not benefit from continous collaboration with the team and the customer. Agile will help you deliver what the customer wants efficiently under the chaotic conditions that exist in most software development projects. Teams often get too hung up on the efficiency of an individual resource or a process step thus focussing primarily on minimizing the input and ignore the effect of that action on the output.

Posted in Uncategorized | Tagged , , , , , | Leave a comment

Teamwork in Agile

Several years ago, I worked for Cambridge Technology Partners (CTP), a consulting company that specialized in RAD (Rapid Application Development). CTP’s hallmark was Rapid Solutions Workshop (RSW), in which, we would build a prototype of a real application in three weeks. Key to the success of the workshop was rapid consensus building between client business & technical teams and extreme teamwork. CTP had mastered the art of teamwork so well that they were mentioned by Ed Yourdon in his book Death March on how a company can manage death-march projects (meaning impossible) through exceptional teamwork. Agile Sprints remind me of the RSWs. Exceptional teamwork is critical to any team that wants to get results with Agile.

How do people work together?

When people work together, they can be in one of the three modes; non-cooperation, cooperation or collaboration.

People can be in non-cooperation mode due to either differences in opinions or lack of communication. This will result in the teams working against each other or doing redundant work. In mathematical terms, this is similar to 1 – 1 = 0. I have heard about a senior manager who would cut staffing when the project falls short. His assertion is that the team is in non-cooperation mode because of its size and reducing its size would change the dynamics and improve teamwork.

People can be in cooperation mode, where they divide the responsibilities and identify touch points (contract). In mathematical terms this is similar to 1 + 1 = 2. This means they are doing what is expected of each of the roles but nothing beyond.

People can be in collaboration mode, where they build off of each other’s strengths and knowledge to create something that is exceptional and beyond their individual abilities. In mathematical terms this is similar to 1 + 1 > 2. In this mode, there are lot of negotiations, challenging assumptions and learning/building on each other’s perspectives. Several of our competitors suffer from the same collaboration challenges; hence by collaborating we can get a competitive advantage. At the basic level this could be as simple as dev and QA collaborating to determine what and how to test, resulting in reduced testing effort and earlier discovery of defects.

On the subject of leadership, thought leaders value collaboration so much that they do not want to call people working together without collaboration a team but just a group.

What makes collaboration so difficult?

We are a society that values freedom and democracy. This means I have the freedom to do things my way and you do it your way. This approach gets us into the “throw over the wall” mindset in which, we complete our part per the agreed upon contract (such as requirements document or design document) and let the person on the other end take it from there. This approach allows us to maintain our freedom and work in our own siloed environment without interacting with anyone, avoiding any conflicts and needing to learn anything beyond our own skill set. Toyota believes that this does not work even in an assembly line environment where there is a repeatable, well defined process. Collaboration can be hard because we will need to explain others patiently what we do and why we do it that way, be open to criticism or change the way we do things. Similarly, we will need to take a keen interest in others and how they do their work with an eye for improvement.

Other possible barriers to collaboration are the biases and hierarchies we have in our head based on our background and skillset. This can be an asset if we respect/value the diversity of opinions or it can be a liability if it prevents us from learning and respecting others that come from different backgrounds and skillsets. To collaborate, we will need to suspend some of the biases and not only understand the viewpoint of others, but build on it to create something exceptional.

How does Agile help with teamwork/collaboration?

Agile forces people from different backgrounds to work together on the Agile team. By creating a self-managed, empowered Agile team, all barriers or departmental silos naturally go away.

Agile practices such as release planning, sprint planning, standup meetings provide the time and space for teams to collaborate and build relationships with each other. Daily standup meetings help teams identify potential collaboration opportunities that they can then followup on. Sprint and release planning provide more structured and extended opportunities for collaboration.

Through retrospectives, a team periodically reflects on its collaboration experience and provides feedback to each other to improve it. Teams also evaluate results from the sprint to determine if collaboration could produce better results.

The end of the sprint review or the demo gives a sense of accomplishment and meaning to the team’s work, motivating the team and reinforcing the value of collaboration.

Teamwork is something that most people take it for granted. As a coach, when I observe Agile teams closely, it does not come easy at least initially. It is especially harder for people who have been working in silo-ed environment for a long time. There is a natural tendency to go back to the old way of doing things. It gets better with every sprint. It is a wonderful thing when developers, product managers, testers and writers build off of each other to create something unique and drastically simple. Any team can be collaborative but it takes lot of motivation and effort from everyone. Reason Agile promotes teamwork is not an accident. One of the Authors of the Agile manifesto, Alistair Cockburn specialized in teamwork.

Posted in Uncategorized | Tagged , , , , | 2 Comments