Category Archives: Project Management

A key leadership challenge is to initiate and lead systemic changes that will set the organization up for success in future. Indeed, nothing else perhaps sums up why we need a leader in the first place. However, the odds are brutal – the pace of change is already furious and it only seems to be accelerating with each passing day, and that pace brings an ever-increasing amount of complexity and uncertainty. There are no guarantees that the chosen direction and pace will lead to a better situation, for the changes are too complex for any one to understand and discern, let alone predict and assure.

In this context, any change can basically be boiled down to individuals in the organization, for every other non-human change is simply a matter of updating processes, or bringing up new policies or introducing new technologies, etc. For example, a company might decide to replace manned customer care by introducing the latest chatbots, or might decide to introduce robotic manufacturing. The reasons behind this might go beyond the direct economic advantages – they could introduce consistency in quality, flexibility in deployment, and scalability in operations that might introduce new opportunities that are simply not possible today.

This leaves a leader to essentially lead the change among people. I consider all change to be ultimately human at the fundamental level, with very high social context. If a leader can’t excite and motivate her team members to embrace the change and play their part in making it happen, there is no way the leader can succeed by herself. In a 2015 article in Forbes, the author Mark Murphy shared the #1 reason why CEOs get fired is for “mismanaging change”. The #4 and #5 reasons were “denying reality” and “too much talk and not enough action” respectively, and they also seem very close to the #1 reason.

 

Surely, a leader might have power and thus control over the team members to make them accept the changes, but in today’s employee-centric market, there can’t be any such guarantees. The days of a CEO or a leader doing a town hall in a trendy city hotel or sending a nice email and hoping that the change would happen are over. With change, there is no such thing as autopilot. A leader must walk on the floor and get down into the trenches, and work with the rank and file to make the change happen.

However, how does an individual contribute to change? While everyone expects them to simply participate in the organizational change, we mostly fail to recognize why they would be motivated to participate and how can we influence them appropriately to see the change as something that helps their own careers? Should leaders simply insist on individuals delivering the results, or their charter should go beyond the mechanics and instead play the central role in enabling conditions where individuals rise to the occasion and proactively lead the change instead of simply participating in it?

In my experience, I have seen these five key behaviors that can set any individual into what I call as “individuals leading the change”. These are simple behavioral changes that any individual in the organization, irrespective of their role, can adopt without needing anyone’s permission or support, and not just improve his participation in the game but also eventually raise the game itself. They kind of build on top of each other, so I don’t recommend skipping any of these – you might benefit best by starting from the first and building the rest of those behaviors on top of it. So, here we go:

1. Growth Mindset

Why is it that some people remain content with what they know, and even developing an arrogance that whatever they know is the best and they don’t need to learn anything new or put in any further efforts to hone their skills? On the other hand, some people seem to be undaunted by their seeming lack of knowledge about a given area – they simply dedicate themselves to learning new things, never mind how many times they fail in that process?

The work by Carol Dweck on “Mindset” is perhaps the best explanation of these two types of mindsets – Fixed Mindset and Growth Mindset. People with fixed mindset almost deny any opportunity to improve themselves or get involved in exploring newer ideas, and eventually become a deadwood. However, people with growth mindset are constantly seeking new challenges that stretch their physical or cognitive skills, and even if they fail in their efforts in the short-term, they don’t seem to give up and ultimately develop a mindset of continuously reequipping themselves. Needless to say, those with growth mindset will find a great opportunity to participate in a change.

2. T-shaped skills

In a traditional team, each team member brings his or her strengths, which could be key knowledge, skills and capabilities about a given area. In a functional team, it might end up being a “birds of a feather” team thus creating a high-density of experts with similar skills, while in a cross-functional team, it might bring people with complementary skills that help accomplish a given project task better. However, a functional team might have limited effectiveness, as they must collaborate with other similar functional teams in other areas to complete a task, thus bloating up the overall team needed to own and execute a project task.

However a cross-functional team might be more effective in bringing together a small team of experts who can truly own a project task much more economically. Unfortunately, a cross-functional team composed of individual islands of excellence is simply a very weak and low-energy container with passive players. However, when individuals move away from their comfort zone and acquire capabilities in adjoining areas, they create shared competencies that allow them to operate with much higher shared empathy about other team members, and also improve their own problem-solving because they are thinking of additional aspects other than their own, and eventually allows the team members to collaborate much better. Acquiring growth mindset enables an individual to become a more well-rounded T-shaped individual who understand a much bigger picture, which allows them to help others.

3. Help others

Most organizations mimic the arena where the gladiators fight each other, and the only way for one to survive is to kill others! While this might seem like a very gory analogy of what seems like a nice innocuous workplace, our outdated performance management systems actually make us do just that. A bell curve for a team engaged in knowledge discovery will only end up destroying the team spirit. While an individual might not (yet!) have the clout to change the performance systems, the least they can do is to challenge the myth of competition by choosing to collaborate. Helping others would be a great way to get started.

Helping others also creates an obligation to reciprocate, which is a key weapon of influence per Robert Cialdini, the leading expert on this subject. When we help others, especially when that help is offered without being asked for, it builds an expectation on part of the receiving party to reciprocate the gesture in future. This sets a system of gifts and reciprocation, which is the essence of social relationships, and helps foster trust, respect and collaboration. This sets the foundation for winning teams.

4. Make the team win

Imagine you are part of a football team. Each player has been hired due to his skills – striker, defender, goalkeeper, etc. Based on the opponent team’s strengths and potential game plan, the coach might come up with field formation at the time of kick-off. However, as the game progresses, new facts will emerge that might invalidate some of the assumptions that the coach had about the best possible team formation. He might rotate players; he might even redeploy them in a different way. If the team members continue to play per their fixed role or position, can the team win?

While the team might be formed based on individual strengths and configured in a fixed formation, in the real world, a winning team would adapt itself by those very individuals playing in a fluid formation, i.e., play where the game is. Their T-shaped skills allow them to be useful to the team in more ways than one, and their trust and respect among each other enabled them to leave their fixed position and help play a winning game.

5. Take initiative

Each one of us is sitting on a treasure of strengths. Even we don’t know what we are capable of! We come up with hundreds of ideas everyday about making things better. However, most of these ideas die a silent death because we don’t take any initiative in making or validating them, or simply lack the courage to bring our ideas to life. In my experience, more people fail (and ultimately get fired) because of not taking initiative than because of making mistakes. When you have a great team that wins, it also builds the right environment where people are not afraid of taking initiative. They know that if they fail, their team members have their back. However, a big question invariably comes up – how do I know if I am taking enough initiative or not, and how can I improve it?

A few years back, I had blogged about a scale of initiative that was introduced to me in the 90s, and has served me well. Those interested could refer to the blog post “How do you measure Initiative” available at http://managewell.net/?p=1100.

Conclusions

In today’s world, a leader can’t simply demand change from her team. She must build the right conditions where team members are constantly encouraged to participate in changes in a non-intimidating environment, and build relationships that allow them to harness the social energy that is needed to make any change successful.

Also, a leader must change the mindset that individual are there simply to follow the change. If the leader recognizes that each individual has immense power to lead the change at their respective levels, the leader can not only lead to more successful change, but create a long-lasting and self-sustaining culture of participation, ownership and engagement.

(A shorter version of this article was originally published as an invited article in PMI’s Manage India magazine, and is available online at http://pmi.org.in/manageindia/volume6/issue12/invitation.html)

What’s your agenda?

We have all kinds of people around us – some people seem to have no agenda, while some seem to have hidden agendas. Most people don’t seem to know what their agenda is, though some lower-form of materialistic agenda might always be on their mind! Some people seem to content with others setting their agenda, while some very exceptional minds among us are so influential, they might help others set their agenda. Do people have the same agenda always, or it change with time (it does seem logical that agendas must change with changing priorities, but how?). If it changes with time, would it help to understand its shades just so we can know where we are at a given time, and potentially, set a goal around where we want to be next?

While thinking about all this, I got wondering if there was a way to “measure” people on what their agenda was? Would it be possible to create some scale that allowed us to understand where were we, not necessarily to compare against others, but just to know where do we stand, if we at all wanted to move further, could there be some kind of roadmap to it?

img_6133

My quest for some answer (and not necessarily a right answer) led me to some interesting reflection, and I came up with the following perspective. Treat it like evolutionary stages of one’s agenda –  if one looks at any meaningful and logical slice of one’s professional (or even personal) life as a single unit, than it might appear to live its journey in an iteration. For example, when one starts their career, or when one starts their new job as a first-time CEO, maybe there are similarities among them as far as the stages of agenda is concerned, even if the scope and scale of their agenda might be substantially different. Surely, this isn’t any heavy scientific theory or some social experiment data – this is simply based on my anecdotal data and some logical thinking, and might very well be untrue, incomplete, inconsistent or simply useless! Time will surely tell me that :). Anyway, here I submit my reflection for your suggestion and feedback.

Let’s go.

Stage 1: You don’t have an agenda!

When you start your journey, you are the obedient learner, the humble follower, the curious child who gets attracted to the unseen, the unheard, the unknown, the unexplained, the un-understood…anything new, bizzare…and you may have no real agenda as to what exactly you want to do in life (or in your most immediate journey). You might travel from city to city, jump from adventure to adventure…but mostly you have no real end-goal in mind. This is the formative stage where your only agenda (if I can say that) is to absorb anything and everything without any motive, ulterior or not. You just “do it” without any particular reason other than possibly simply learning things, or doing it for the sake of doing it. Some people also might simply while away their time with either “busy work” or just a way to pass the time, and appear to be “living dead” in this stage, but more people are likely to live this stage with a bit more energy and enthusiasm even when there is no real agenda.

Stage 2: Others set your agenda

At some point, you find something that sets your agenda, or at least starts the process. It could be anything – an idea that inspires you, an obstacle that fires you, a friend who motivates you, a parent who pushes you, a manager who forces you, a guru who liberates you…whatever! The key thing is that you are not directionless, rudderless anymore but you have this big purpose dangling in front of you. At this stage, it is more likely that others are setting this agenda for you as you don’t have any real agenda of you own. You are still learning from others as to what might be some way to build a pipeline of activities that leads to the nirvana. Or, at least you believe that might be the nirvana!

Stage 3 You set your own agenda

For a seeker of truth and self-made goals in life, this is the moment when you discover your purpose. You discard what others have set for you (perhaps you think that’s not the real you, or you simply have a change in plan, or are attracted to something else than what you initially started out with, etc.). You have also become more knowledgeable, competent, mature, confident and perhaps even resourceful to write your own agenda – whether ready or not, right or wrong, high or low, realistic or ambitious – it doesn’t really matter. What matters is your belief in what you really want to do, and your desire to go for it. This could be the phase when you really start taking risks, learn something new, become an entrepreneur, take up a significantly challenging assignment much above your current level of training or experience, and so on. The key is to start somewhere so long as you actually gets started to create your own agenda!

Stage 4: You set other’s agenda

This is the pinnacle of peer and social recognition – you have fans who look up to you, you have peers who worship you, leaders who cherish you, and even have competitors who respect you (and not just secretly)! In some cases, like the legendary Guru Dronacharya who was not there physically for the archer-enthusiast Eklavya so he simply made his statue and “learnt” from it, you might not be physically present to (help) set other’s agenda but your thought, ideas, words and deeds inspire people across the time and space. And for those who have the fortune to interact with you – be as your team member, or colleague, friend, teacher, leader or anyone else – you are trusted and respected to the extent that others feel they can count on you for help in setting their own agenda. It is also possible that some people in this stage do it because of the hierarchy or the title, e.g., they might be a manager for a team. We are not really interested in this, but more interested in what kind of unofficial or the informal power, or rather influence, do you really wield in those situations. Very few among us get to this level, though a significant larger among us already believe we are here 🙂

Stage 5: You don’t need an agenda!

This is the nirvana. You have finally arrived to the point of self-actualization when you not only don’t need any social proof or endorsement from the society at large about who you are or what you do, you also don’t care for it! Not in an arrogant manner (though some rare eccentric geniuses are known to have gone to that point) but in a self-assured manner that your identity is not defined by how others measure you. Life comes a full circle for you, but not before having grown you as an individual, as a professional in your chosen discipline and certainly not before you have had an opportunity to influence people and help the world become a better place. At this stage, nothing really matters because you are that self-assured person who doesn’t need to derive “power” from even influencing others as in Stage 4, but you want to be like the sage or the heretic who goes into deep meditation and is on the path to become an institution by himself or herself, and doesn’t care whether people accept or reject his ideas. You may not even be known or become famous, but that doesn’t matter anymore – what really matters if whether you know who you are without necessarily knowing where you want to go next.

So, this is my reflection on the journey of an agenda – like all deep reflections, it ends exactly where it starts, and when you look superficially, a person with no agenda might look the same as a person who doesn’t need an agenda (because to you, it still appears that he has no agenda – but only he knows in his mind that he doesn’t have an agenda because he doesn’t need one!). However, when you look deep inside, you find a journey of a lifetime that starts with exploration and ends with self-discovery. Very few among us make it, though.

What’s your agenda?

Do you read the second line?

I was booking movie tickets online, and when it came to payment, the BookMyShow payment offers were clamouring for my attention. In the past, I have learnt to carefully disregard and safely ignore those smartly camouflaged shady offers like the “Citibank World Debit Card – Buy One Get One Free” or the “ICICI Buy 1 Get 1 Offer” because they were basically designed to fool the customers. At least from my point of view!

Oh, this offer is only for the weekdays

This offer is only for the movie tickets below Rs. 250

and so on. I mean why even go through all the efforts when you don’t want your customers to be able to avail of all those sexy offers? Surely, there are many other ways to lose customers. So, I have now given up trusting on the credit card offers (as if I ever trusted marketing!).

Speed limit...!

This time for a change, I decided to try the mobile wallets, hoping they will offer some new snake oil.

And I wasn’t disappointed!

The PayTM offer said 50% off….and it took my breath away for a moment! Imagine being able to enjoy two movies at the cost of one! I mean, just do little bit math, and you can actually have two Porsches for the price of one…it just doesn’t get better than this, does it? My life was made!!!

One click later, I got closer to the truth! I discovered the fine bold print – Every 10th customer gets 50% cashback upto a maximum discount of Rs.100. Of course, the smart marketing did get me for a moment…but only to make me a even more of the very-suspicious-shopper-of-PayTM-marketing-gimmickery-in-future!

Pass.

At that time, my wife rightly reminded me that since the times immortal, it has always been the second line that’s been the most crucial one – rather more important than the first line. I am sure you remember this famous line from Yudhishtara to Dronacharya from Mahabharat, “Ashwathama mara gaya..(pause, and then almost an inaudible whisper)…par nar nahin kunjar” (Yes, Ashwathama is dead…but the elephant, not the man”. Unfortunately, Dronacharya was not able to hear the second line (or rather, Krishna’s grand plans ensured that was indeed the way it had to be!) and dropped his impregnable armour just for a few moments, which was enough for Dhrishtadyumna to kill him. Obviously, not reading the second line cost him his dear life.

Thankfully, our lives is not at stake, most part of the day. And not reading the second line does give some much-needed comical relief in the otherwise tense days. Imagine being re-told the joke of “buy one get one free” so sincerely, it makes you smile everytime you see it :).

But, not reading the second line could also potentially land you some genuinely spurious deals, and eventually leave you shortchanged. Other names for this have included “the fine print”, and so on, but I think it is as simple as reading the second line!

Do you read the second line?

How to go faster than you can?

How to go faster than you can?

 

Speed is a key skill in today’s fast-moving and forever-changing world. However, most companies are not designed for speed – instead they are designed for efficiency as they typically need to cover a long distance. They end up wasting a lot of time in simply waiting for decisions, or some critical resources, or approvals from management, and so on. On the other hand, startups are designed for speed and don’t (need to) care (so) much for efficiency, because they must perform on a very short runway. They have a limited amount of time and money, and while they still have the funds to keep them going, they must make the best of it and keep experimenting till they discover repeatable, scaleable and sustainable way to make money.  Speed is important to make the kill today, and if we survive to tell the tale, the efficiencies can always come tomorrow. Good or bad, that’s the way it works.

However, have you thought what exactly is the relationship between distance covered and the speed attained? Logically, it seems clear – we can always go fast over short distances, and must lose speed over longer distances. But is there any data to support this? And if yes, is that a straight line, a curve,…? Further, are there variations to it? Over the same distance, can we still go faster than what seems to be physical limits of a human being? For example, could working in teams make it faster?

I thought of examining the data.

The longer you go, the slower you get

Of course, you always knew it. But, do we have any data to support it? And, even if this were true anecdotally, is there any math behind the data?

I looked the men’s track and field world records (http://en.wikipedia.org/wiki/List_of_world_records_in_athletics) and plotted the speed vs distance for all distances from 100m to 100kms in running. The resulting curve looks like this:

It is interesting to note that the data is fairly consistent when it comes to human limits – there is an inverse relationship between the distance covered and the top speed achieved. In other words, the longer you go, the slower you get – even when you compare world records of different specialist runners. Of course, we might not be able to push it ad infinitum and achieve mach speeds or more by shortening distances to ridiculously low atomic distances, but then, who knows 🙂 – maybe there is some interesting problem waiting to be discovered when do do that!

So, what would be the most logical thing to do if you need to get there faster? No doubt – go short distances. What if the distance covered is more than what one person can sustainably complete – surely, we can’t just travel a fraction of it and stop? Let’s look at relay teams.

A relay team is faster than an individual

What happens when we take numbers from relay race and compare it with a single runner running (or swimming the same distance) alone? I took data from four men’s events and compared them side by side:

The data is limited only for short-distance relay races (and I was tempted to include data from ekidens and Swedish Relays, but maybe another day!). However, in each of the cases, the average speed went up (between 13% and 28%) when a relay team ran the same distance as an individual runner.

Again, is it logical to explain. One runner running the entire 400m will get tired, but each time a new runner comes and does next 100m of the relay race, he/she can put in fresh burst of energy and since they have to sustain themselves only for 1/4th of the total distance, they can be very fast – certainly faster than the individual runner who has already done first or second laps.

So, clearly, if we divide the tasks such that different team members can add value to it at different point in time, we can do the same work faster.

How about if we all did the same job together? For that, I had to leave athletics track and find something else where teams work together on the same task as the same time. Guess any sport that does it?

A simultaneous team gets faster when you add players

In rowing, there are multiple combinations that basically cover the same distance of 2km. Starting with a solo, it can go up to eight rowers, and the data gets interesting. Here is the data for sculls and coxless pairs:

So, when we add the number of people who are simultaneously working on the same problem, even when the problem gets bigger (weight of double scull is 2x of scull and that of quad is 4x, with the length going up by roughly 30% every time), we get faster! This seems like a great motivation for solving large problems as long as the logic of simultaneous players can be applied. Does this go ad infinitum? What about famous snake boat races that have upto 100-125 oarsmen in each boat (and 25 singers and four helmsmen too!). The top speed recorded is 20.8 km/hr, so clearly this speed starts to taper off at some point. But clearly, the speed does go up between 1 and 100+ oarsmen.

Recap

These were my data-backed insights:

  • If you cover short distances, best is to go alone. You can go fastest.
  • For short distances, when you want to go still faster than one individual, working in a relay format seems to be better than a single runner. This strategy might not work for very short distances, because the overheads in coordination and switching might offset any potential gains from relaying.
  • If you cover long distances, best is to work in teams. You can sustain it farthest.

Guess what does it tell us about teams at workplace? Agile teams are small, typically not exceeding 7+/-2 members and they often work in pairs or might even swarm together to solve complex problems. And the data from sports seems to suggest that it work!

I’d love to know if you have data from your software teams – do they have data that supports – or contradicts – the data from sports? It might make for an interesting conversation…

(Originally published at https://www.linkedin.com/pulse/how-go-faster-than-you-can-tathagat-varma) 

Not another diaper-selling app please!

This is the golden age of entrepreneurship, and I think humanity is fortunate that so many bright people have decided to solve some really hard problems of our times. Even when we know that history – and statistics – are not on their side and that more than 90% of the will eventually fail, their efforts need to be saluted, for they are giving up a cushy comfortable job and the opportunity to be with their friends and family or generally pursue their hobbies and interest, and instead have chosen to purse the hard path of experimentation, failures, more failures, frustration, many more frustrations….and hopefully some light at the end of the day!

When all apps start to lookalike, you know that innovation is all dead!

However, a good number of us are getting it totally wrong.

No, we don’t 59th app to order groceries at home.

No, we don’t need 134th app to buy diapers from the net.

And we most certainly don’t need yet another mobile wallet, yet another taxi booking app, yet another bookshop app, yet another food-ordering app, yet another househunt app, yet another app to sell undies on the net, yet another…..

What we do need is something a bit more simple. For example:

  • Help millions of educated unemployed create opportunities to develop our nation
  • Find a way to save millions of tons of food that rots in our godowns
  • Prevent farmers from committing suicide
  • Find a way to raise people’s standard of living by creating opportunities for them
  • Send every child to school
  • Let no child die of preventable diseases
  • Let there be running water in every household
  • Let there be a computer in every home
  • Decongest the cities and redistribute the economic activities back to villages and small towns
  • Clean up nature, air, water and land
  • Make better roads
  • Reduce crimes
  • Improve governance
  • Remove (or at least reduce) corruption
  • Reduce lead time (and preventable delays) in public projects
  • Help people become better people
  • Clean up our nation
  • Make neighborhoods safe
  • Speed up justice

I know there are a few of us who are working on some of these hard problems, away from the limelight, painstakingly changing the world…literally in inhuman conditions. They need to be applauded and supported. More talent needs to go there rather than using their advanced computer science degree and machine learning knowledge to find a way to make more users view online ads and click on the lead-generation links. More funding needs to be made available to solving these important problems that serve the humanity at large.

Selling diapers online is sexy. Saving a child from preventable death isn’t.

No, not another diaper-selling app please! 

Next…!

Learning to Lead Without Authority

In 2007, I experienced a career-altering moment. After being in the general manager role for Sniffer’s India R&D center (subsequently acquired by NetScout) for four years, my new SVP of Engineering asked me if I would accept being a functional manager for my current direct reports. As a good company man, I consulted with all involved leaders and my direct reports, and enthusiastically said yes, while, to be honest, not completely grasping the importance of the opportunity.

What started off as an innocuous query from my leader soon became a chance to explore and grow myself as an individual contributor at a deeper leadership level – what I now refer to as an “Individual Leader” – someone who doesn’t need a hierarchy, department or budget to make an organizational impact. An individual contributor operating at organizational leadership level is like a cross between Greenleaf’s concept of “servant leadership” and Maxwell’s 5th level of leadership. People follow you because of who you are and what you stand for.

True leaders don’t need authority

What happens when you separate leadership from authority? Over the next seven years, I learned a lot about leading without a team. My experiences were in India which is a rather hard place for such radical ideas — as a hierarchical society, we value seniority, and as a successful IT services industry, there is a fair amount of achievement-orientation. So, some of my insights could be very contextual, though I believe most have universal relevance.

1. Leaders are hired for change

Change has changed. In the past, change was mostly large-scale, which meant it was episodic, costly, and initiated by those who wielded “power”. However, most of these changes were about improving efficiency, or the bottom line of an organization. Today’s leaders must raise the game to create a new top line, and bring about innovation, which has more in common with knowledge than traditional power.

In the knowledge era, change changes at a much rapid pace. Even the role of change initiators seems to have been democratized if not altogether reversed. Those with knowledge now have the “power” to initiate change irrespective of their level inside an organization. In a level-playing field, it is meaningless and rather risky for leaders to bring about changes without involving the true power in their organizations, for the boardrooms can’t match what those working on the front-line know. In fact, the visible “symbols of power”, such as a heavy-sounding title or a corner office, stands in the way of a leader being perceived as genuine by employees, thereby reducing a leader’s credibility to effectively lead change. An individual leader offers a great alternative to a more “human” and “humane” face of change by bringing authenticity to the employees, and inclusivity in representing them to the organization in order to raise trust – which is the key ingredient for disruptive change.

2. Leaders are measured by impact

Until now, leaders were ‘measured’ (and ‘rewarded’) by absurd status symbols – large team sizes, additional territories, fancy budgets, executive administrators, or large offices! And these don’t even include the perks doled outside the office such as golf club memberships or annual family vacations to exotic places — no wonder they were called “entitlements”!

None of these status symbols has anything to do with the ability to make impact. On the contrary, they only hide the weakness and incompetency of leaders by making them look larger than life. Real leadership impact is measured by the ability to cut through the organizational red tape and institutional mental models. ‘Leaders’ who hide within the safety of four walls of their glass cave to feel powerful are far too detached from reality to recognize that true power is all about having the humility to learn and bring about the right impact by engaging with employees in the hallways and cafeteria.

3. True leadership is servant leadership

Hierarchical leaders need direct reports to carry out their designs. Paid followers, (i.e., followers receiving a salary to follow the leader) appear to exist to serve the hierarchical leader rather than the organization. The world has seen enough of power-hungry leaders who believe that their position is an endorsement of their ability and that their title gives them unbridled power, and their team exists to solely serve them.

Individual leaders don’t require direct reports to create an impact. They build their networks, and use their passion to recruit volunteers from across the organization. Volunteers are experts in their own field who want to get involved in a community of like-minded peers and contribute to the change. Individual leaders selectively recruit volunteers and develop them into individual leaders.

Developing social intelligence

Plunging into a leadership role not defined by a position of authority gave me a unique opportunity to acquire new set of leadership skills where the only “tool” was persuasion and mutual understanding, and the only “method” was empathy and transparency. Anyone with those skills can be a leader, but any leader without skills will eventually fail to step up when challenged.

Leadership from a place of individual responsibility is not for someone seeking comfort in a familiar and static job description. In all the three companies where I gained invaluable experience, the job description was fuzzy at best and useless at worst – finally I just did what I felt was right. Sometimes it required sticking my neck out to confront the status quo. Fortunately, my peers supported me, and I also kept my communication lines transparent.

It takes a huge helping of professional humility to start on a track where you feel alone. You have to get past the idea that you need an army to report into you to make an impact, and that realization was sometimes painful. Some people saw me as a pushover. Other times they thought I was on vacation with no pressure to deliver. In the end, one simply stops defending and lets the results speak for themselves. Finally, taking on an individual leadership role without a position of authority demands you to accept the social implications. I dealt with that pressure by ignoring it, and just focusing on what was the right thing to do.

Here are three ways to prepare yourself as an individual leader:

  1. Develop your social skills that allow you to succeed without traditional power or roles;
  2. Build your professional network inside (and outside) the company;
  3. Grow yourself in your chosen knowledge area and develop yourself as a T-shaped professional having horizontal knowledge and skills.

Preparing yourself will permit you to take advantage of new opportunities as they arise.

And next?….

Last year, I took individual leadership to the next logical level: I became a solo-preneur. Though more secure options were available, my experience prepared me for taking the plunge and for serving my clients with the benefit of all I learned from my journey as an individual leader.

Are you ready to take the plunge into leadership without the crutch of authority to lean on?

(Originally published at http://www.huffingtonpost.com/great-work-cultures/learning-to-lead-without_b_7883062.html?ir=India&adsSiteOverride=in)

How fast you can change?

In my talks, I often ask a trick question – what is the most important part in a bicycle and a formula one racing car?

I get all kinds of answers – wheels, engine, chasis, tyres, steering, even the driver…. No doubt, they are all right answers.

However, my favorite right answer is the brakes! Why? Because they make us go faster! 

Let me explain.

Imagine you are riding a bicycle without brakes. You won’t be able to go faster because you have an in-built fear in your mind that if you pick up pace beyond some ‘reasonable limit’, you won’t be able to control it lest it becomes important for some reason. Now imagine riding the same bicycle with the best brakes that your money can buy (or, even better, that you can build!). You not only can ride the same bicycle with much more confidence, you can actually imagine going much faster than before. Of course, you can take the analogy much further and argue that you could go even faster if there was a better helmet, a better kneecap, jacket, leather gloves, even the insurance to make the rider free themselves up from the worries of a possible accident…then you might zoom even faster and potentially reach closer to the Peltzman Effect, but we will stop at just having the right brakes in this blog post.

Now the mental model about brakes is that they keep a stationary object at rest (at least on a downslope), or slow down or stop an object in motion, but never make anything go faster. And yet, that’s what they do – they give the courage and confidence to the rider to go faster than without those brakes. In that sense, the brakes are the feedback and the control mechanism rolled into one. Without a brake, you still have access to the same power (or the engine power in case of a formula one car) as before, but your decision to use it judiciously as opposed to using it as unbridled raw power is based on your ability to get that feedback and adapt to it. In general, the sharper the ability to get the feedback, make a decision and execute it, the faster one could go.

Of course, one can (rightly) extend the argument that it eventually depends on the rider/driver of the vehicle – for the real ability to handle a machine lies not in the machine but in the mind (and the hands) that operates it. We will get to that in a moment.

A lot of people think agile is all about faster deliveries, and then they set unreal expectations which often sound something like this – let’s do agile so we can ship the product in 3 months which today takes 9 months. Like they say, you can’t put ten pounds in a five pounds sack, I have a bit of a bad news for them – the quantum of work that takes 9 months to ship can’t be shipped in 3 months without seriously undercutting either the breadth (i.e., the scope or quantity of work) or the depth (i.e. the quality, performance, usability, reliability, etc.) of the deliverables. Agile isn’t quackery (even though it has been oversold as one by some overenthusiastic souls!). 

Speed is not fast you can go, but how fast you can change!

Speed is not fast you can go, but how fast you can change!

For me, brakes are the metaphor of agile. They provide the feedback and enhance the ability to manoeuvre, even more so at high speeds. The more real-time and actionable (i.e., more “byte-sized” than “brick-sized” to clearly understand and identify the cause-and-effect relationships that allow the feedback to be “meaningfully actionable”) a feedback is, coupled with the internal ability of the machine to rapidly absorb and assimilate it, the sooner it can respond and adapt to a potential event. Remember – making a third-stage spacecraft change its position even by a few micro-degrees is much more difficult and perhaps valuable than a car changing its lane on a highway. Just like any serious competitor who will adapt the brakes based on weather and other operating conditions, there is no one-size-fit-all brake here. The term “agile process” is a fairly useless one, for it creates a mental model of a laminated process that will enable people to operate with (guaranteed?) agility out-of-the-box, and yet, it is hardly ever going to be that! If you have already nailed down every single nook and cranny so that the resultant process is a certified “agile” one, than one must only be smoking pot. Neither the creator of that uber-agile process could have anticipated every possible future condition (the last time I checked, I was told that job description was reserved for God!) nor anyone knows enough to prescribe a single templated solution to all kinds of problems. Net-net, everyone must create their own “agile process”. Of course, they can start with what we know today, but remember – what is know today can only be a (better) starting point and not the limiting rate factor for what you must eventually accomplish. In that sense, an “agile process” is like “best practices” – you can’t simply copy someone else’s best practices and expect them to 10x your results. Rather, you must painstakingly solve the hard problems, and evolve your own best practices – to that end, best practices are things that are created as an outcome of a problem-solving activity by smart people, and not really something that others can use as a shortcut. Sure, some of these might be very universal, but I guess most all have been already discovered long back, and we are mostly rebottling and recycling them these days.

So, there you have it. There is no such thing as a universal agile process that will solve all maladies. Like Edison said we are able to see further by standing on the shoulder of giants, we simply take what exists today as a starting point and create our own agile process. Nothing more, nothing less.

And just like the picture in this blog, agility is not something that takes you faster, but it enables taking you to new, unknown and exciting places when you think there might be something interesting there. If you don’t find the cheese interesting, you can always come back to the last stable state, and start another journey, till you find something better!

Speed is not how fast you can drive and deliver. It is how fast you can change and adapt. And life and product development have more hairpin bends than you think… 

Want best impact? Change yourself!

A lot of us want to create an impact, especially the ones that comes in B-I-G font size. Change the world. Stop global warming. Establish world peace. Find cancer cure. Stop wars. Leave a legacy that lasts forever. We want to conquer the world with our ideas, our creation, our accomplishments.

And we want to do it in style. After all, we want to make it BIG! So, we join various causes, we become volunteer and even take up leadership positions in such volunteer organizations without having any understanding of what is needed, and whether we are up to it. I often meet people who claim to help others by organizing various forums, teaching others on how to solve their problems or matchmaking investors with entrepreneurs, and so on. What I find strange is that most of them have themselves never done any of that stuff. Most of them are armchair theorists who have this romantic view of what it takes to change the world, with them, naturally, playing a central role in it.

Changing ourselves is not only the easiest, it is perhaps the best way to make an impact…

Sadly, we don’t want to take up the most immediate problem right under our noses, but take the most complex problem that mankind has ever seen and might even be beyond us. We want to solve world peace problem little realising that the best way might perhaps be simply starting with addressing the problem in our own backyards. We want to make earth a green planet once again without really first trying to make our own abode a green patch, howsomuch small it might be. We want to take care of all the underprivileged children on this planet, and sometimes our own children are deprived of our attention and love.

We don’t find solving the small little problems sexy enough to be taken up. Because they don’t quite fit in our nice little mental model of BIG IMPACT.

Changing the world is sexy. Changing ourselves is not.

Having volunteered for over twenty years now, I have come to realize that we create the best impact when we commit ourselves to continuous change and self-improvement – and not when we go after chasing the big problems. Once you start facing and fixing your problems, fears, uncertainties and vulnerabilities around you, you bring real change and you build tremendous credibility – both are needed to take you to next level. Your credibility helps people discover you, and your work speaks for you so that you don’t need to. Over time, your body of work becomes your referencable work, and people come to you for help. That’s the time you start making bigger impact.

But the trick is to start small…preferably starting with changing yourself.

What 16months of stay at Antarctica taught me?

It’s been twenty years since I went to the magnificent seventh continent (which, ironically, became the first continent that I visited, apart from Asia, where I was born and grew up). I just have to close my eye for a few seconds, and I am still able to teleport myself back to majestic and pristine Antarctica, and the Indian station Maitri which was my home for 16 months during 1993-95. The sailing through equatorial waters, roaring forties, furious fifties and screaming sixties, endless parties on the ship, breaking through the pack ice on our icebreaker ship MV Stefan Krasheninikov, surviving in the summer camp on bare necessities of life, seeing the mesmerising Aurora Australis for the first time, firefighting the whole night to save our station, winter-over with its cold and darkness for two months, fun and parties with neighboring Russians, cleaning the station (and toilets) during galley duty, prepare three meals for 25 men as part of the cooking duty, and on and on…. It was surely the best part of my life, and I was lucky to be there.

Rescuing an Adelie penguin near our station in Antarctica

Over the years, I got chance to reflect upon my experiences through TEDx talk and also various leadership talks. In this blog post, I want to reflect back on things I learnt that have high relevance to the workplace dynamics of today. Hopefully that connection will be valuable for some of the readers.

Satisfaction is extrinsic, motivation is intrinsic but engagement happens when you work for a meaningful cause

When I was at Yahoo!, and Marissa announced free food for all employees, we had situations when some people would simply crib endlessly about food quality. I remember one particular mail on “yblr” (the internal, informal ranting channel for Yahoos! in Bangalore) where someone commented that there was nothing worth eating at the breakfast – the sambhar was watery, the chutney was salty, the dosa was cold, and so on. Some other Yahoo! asked him a very nice question : “you mean, out of those 18 options available for the breakfast everyday, you find nothing worth eating?”.

I think there is a dangerous growing trend of the culture of ‘entitlement’, at least in IT industry (and not singling out any one company in particular). I can’t work because my 15″ Retina Quadcore Mac doesn’t work well with SharePoint! I need some goodies to be given so the people will come for this meeting (my favorite pet peeve – unless you bribe people, you can’t get them to do stuff that they are paid for!). No one called me for our project meeting! Our (free) office buses should have wifi, and yes, the drive should call me just before he reaches my pickup point so that I don’t need to waste time! and so on…(sigh)…

Back at Antarctica, everyone had a different motivation for being there. Some were there for serious work, and even though some among us were working on really important stuff like monitoring glaciers, or Ozone hole, of research on sleep patterns due to polar magnetic activity, etc. strangely, I never heard the fluffy terms that you hear every so often nowadays – like “we are here to change the world” (and boy…it does look so cheap when used in context of companies selling crayons and socks online). Some volunteered so they could save money (and I completely respect their reasons) while some, like me, were there to simply explore life, and learn and do something new. However, one thing that still stands out – everyone was engaged, whether satisfied or not. When people did 24-hour galley duty, patrolling the station the entire night and cleaning up toilets, they couldn’t particularly relate it to their motivation to be there, and definitely not to satisfaction! However, I never saw anyone shirking away from their volunteered responsibilities towards their fellow expeditioners. Everyone had a sense of commitment towards the team and the expedition, maybe in their own different way. And we had ten thousand reasons to crib and bitch about things – every day, but I never saw the feeling of entitlement creep in any of us. I guess we look for engagement in all wrong places…

Leadership is initiative translated into action, executed with teamwork, and delivered with accountability

A lot of what I see at the workplace today – ideas like situational leadership, servant leadership, shared leadership – we lived it first-hand during those 16 months. Every day and every task in Antarctica is kind of new (even though the individual skills needed to accomplish it might not be), and no one person would know all the answers to every situation, least of it any single designated leadership. Out of 25 of us men who came from some ten different organizations and almost no one had worked with each other before, only two had been in a previous wintering-over expedition, and had some prior experience which was better than nothing, but certainly never enough.

  • What’s the best time to start the next convoy to the shelf ice? Who knows? Check the weather forecast, talk to radio officer, ask the engineers. Is the emergency shelter in top shape? How about the food supplies in the emergency stations?
  • What’s the best place to lay the next gensets? Check the ground conditions. What about the interference from the communication equipment? Are there food dumps nearby? Could the ground vibrations affect the station’s foundation and stilts?
  • We had one chopper down with a broken engine and another one down with broken blades. Just couldn’t fly (till Naval HQ would allow). What’s the best options? Ground transport was not possible due to water channels in the summer, so there was a limited about of transportation possibilities. Should we carry food, or medicines, or samples, or people or equipment?

In literally every single instance, I saw how we all came together. Some people took initiative to kickstart the conversations, some took the next step to own up activities, a few came together to be the volunteer, and the work was done. The official leadership was there to provide support so that people could do the stuff. Surely, we had some interpersonal conflicts (to say the least!), but by and large, the real leadership evolved from the trenches, and the credibility was earned through accomplishments (and rewarded through followership).

Self-organization is all about letting the team figure out their own process, tools and even leaders

On our first night in the main station, we had a major fire. We had all moved inside the main station just a few hours back that evening before bidding goodbye to the last sortie that took the old team’s last members back to ship, which set sail promptly a couple of hours right afterwards. Except for the paperwork of taking-over the station, we had hardly had time to really familiarize ourselves with the station, its facilities, and so on. HK and I were on the all-night galley duty and were playing scrabble when HK felt there was some unusual light in the main corridor. HK being a seasoned naval officer, I would always trust his instincts. We knocked at the room where we felt there was a light, and on getting no response, we just barged in. And we were frightened by what we saw. Our fellow team member was bravely fighting the fire inside his room which was full of thick smoke. In the next few hours that ensued, we had the entire winter-over team come together and what no amount of taking-over and familiarization could ever achieve, we were on top of our fire control systems, and we learnt exactly what was the best way to deal with such accidents. One by one, we would volunteer to fight the fire, take a deep breath, enter the smoke-filled room and fight the fire till we could, and then get out of the room to get some fresh air. The best part – there was no designated leader, we didn’t follow any chain of command, no one waited for instructions, why – no one even asked people to come and fight the fire in the first place!. Through trial and error, we quickly learnt how to solve the problem as a team, and also found out who were the best set of people whose judgment could be relied upon. The team not only self-organized itself, it also discovered it own process, figured out its tools, and was able to identify the people who were best suited for the job.

Conclusion

I have many more stories to share but these stand out as the most important learnings concerning self, leaders and teams. In a team where no one had worked with each other before, where competencies (and education) varied so widely, where the resources were limited, and the situation so choppy and unpredictable, it was strange that 25 men could come together for anything! And imagine doing it for 16 months at a stretch.

And when I see workplaces today, I see people chasing satisfaction in the name of engagement (and landing with entitlement). I see old-school managers so insecure about their fragile egos and shallow power that they are not willing to delegate and empower folks working “under” them (whatever that means!). I see organizations insisting on ‘standard processes’ for teams to ‘self-organize’, in what can only be described as stupidity at best and tragedy at worst.

No wonder, I often close my eye and travel back in time and space to get some inspiration…

 

(Originally published on LinkedIn at https://www.linkedin.com/pulse/what-16months-stay-antarctica-taught-me-tathagat-varma)

Three questions every program manager must ask

Suppose you are the new program manager assigned to a program. How would you go about finding your way inside the complex maze of a program, its stakeholders, sponsors, component teams and various vendors? If the program is yet to commence, you might be able to get involved much more deeply, and influence the state of affairs meaningfully. But if the program is already underway, what do you do?

If you take time and ‘learn’ about the program before you act, you might get a deep and thorough understanding of the program but then you might be under time-pressure to deliver results faster. On the other hand, if you straightaway jump into the mechanics of the program, sooner than you realize, you are neck-deep and drowning into the gooey tarpit of unending stream of fires. Yes, you might start delivering the goods that make your program sponsors happy (at least in the short term), but you might not be bringing about systemic change that make you strategic in thinking and approach. Without a more holistic and long-term thinking, you also start drinking from the same well, and very soon, you are also just another ‘manager’ who is fighting fires rather than working proactively to prevent them in the first place. Mind you – if they wanted another firefighter (no offense to the noble profession of firefighting), they would have hired one! So, how do you make a mark?

Over time, I have found asking some simple questions is a great way to get started. Interestingly, these simple questions are very powerful and if the core program team can’t answer them unanimously, it is a pointer that something is not quite right. Here we go:

What are the goals? If the goal is to put out a quick prototype that serves as a placeholder for conversation with customers (as opposed to a powerpoint-laden marketing brochure that no one trusts anyway), then no point in having a complex program management mechanism in place. OTOH, if the goal is to do something like build a skyscraper in two weeks (like this http://www.cnet.com/news/chinese-build-skyscraper-in-just-15-days/), then you will need a very rigorous program governance structure in place with months of advance planning, contracting, timelines, SLAs, and so on. Not knowing the goals is like not knowing where’s the finish line, or not having a clear picture of what the success will look like – we It is the thinking behind questions that matters!might keep pressing on but keep moving in circles, or might misdirect our efforts into something else that looks like success but is not! Kennedy’s vision of sending a man to moon – and bringing him back alive – before the end of the decade is a great example of what is the goal – it fired up an entire nation and aligned everyone to that one single goal.

I once led on a large program (over 190+ engineers in my team developing a complex 3G softswitch). It was an extremely important product for the company – perhaps the most critical endeavor that year, more so because in the previous year, we had blown away millions of R&D dollars building the product that never saw the light of the day, and wastage of money apart, we lost one full year in the market. I recognized the the goals were very clear – deliver an architecturally sound product as soon as possible, and ideally close the year with a field trial. I set up a rigorous program team in place that not only delivered the first version of product in 8 months flat, we did even better than the original goals – instead of closing the year with field trials, we actually closed it with an $18million sales of the product. On the other hand, a few years before in another company, while leading a product development in a very new area of Digital Video Broadcast, I took the risk-first approach and built an incremental development plan (think of the first increment as a simple yet technically complex “Hello World” displayed on your digital set-top box using the entire tech stack for the first time!) that helped us mitigate the technical risks and consolidate knowledge assets at each step rather than build it all in one shot. Even though the result was below par, any other approach wouldn’t have made it any better!

Why are we doing it? Knowing the ‘why’ helps us understand the desired end-state better, especially when the chips are down, a program manager will need to muster up all their energies and tactfulness to negotiate and broker agreements with various components teams (who, for all right reasons, might be more interested in their own line of sight rather than the overarching program goals) or stakeholders in a politically-charged battlefield (e.g. CEO’s pet project ?). On a more positive note, this is also the articulation of the ‘benefits’ of a program, and really distinguishes when a project ends (“outputs”) and when a program delivers (“outcomes”).

We have all heard of the story of the bricklayer, the mason and the cathedral builder. It is the deep understanding of the purpose that helps convert knowledge and skills into passion and an almost obsessions towards the end goal. When Tony Hseih says Zappos is not really into selling shoes online, but rather in the business of ‘delivering happiness‘, it sets the context and direction for everyone in rank and file and aligns everyone’s attitudes and behaviors towards the goal – even if sounds aspirational (and would you really want to pursue any goal that is not aspirational?). Not knowing ‘why’ behind something could be like being given the command to do something without knowing the context behind it, and people might go through the motions and do what is functionally expected of them, but will never be deeply passionate about the cause that might make the difference in the bigger scheme of things. An interesting application of asking why 5 times makes sure that we don’t get stuck as the superficial reasons but actually peel the layers and go to the deep cause underneath.

Where are the biggest pain points today? Are they inside the component teams inside the program, or at the intersections? While a program management approach is a great way to address friction at the intersection, given that technically it is still an ‘overhead’, it might not be the best approach to solve problems inside individual component teams. For example, if the product quality of a component is an issue, perhaps more of TDD or automation or CI or better code review practices might be needed in that team – rather than creating more checkpoints at the program level.  

I recently bought a data card from a very reputed company. The product was absolutely lousy and the service was atrocious. Funny thing is they were too preoccupied in building marketing ads without paying any heed to customer’s pain points. So much so, if you write your grievance on their facebook page, they will delete it no time, but they won’t come and address your grievance. When we shut out ourselves from customer feedback, we lose sense of what’s really making customer driving to us (or driving away from us, as in the example I gave earlier), and then we end up goldplating the requirements that we think the customers want. The end result is a train wreck in slow motion. When Flipkart realized that a major reason people don’t buy online is because they don’t want to pay upfront and then live in the anxiety of waiting for goods to be delivered or low credit card penetration, etc., they created Cash on Delivery, and when they realized they couldn’t own the entire customer experience cycle without really making the last mile of buying cycle – the physical delivery of goods – a painless affair, they literally built their own courier workforce. Acquiring a deep understanding of these pain points will help you prioritize and focus on delivering them with alacrity. 

I have found that these are not just relevant for a program manager but are helpful to anyone – a product manager trying to understand more about why his customers buy (or ignore) their product, or an HR manager trying to create the new hiring campaign, and so on.  

[This blog post was originally posted on LinkedIn at http://www.linkedin.com/today/post/article/20140423015413-3616140-three-questions-every-program-manager-must-ask] 

Hard work is killing people. Literally!

Recently, I was reading an article on how Japanese-style manufacturing isn’t working out quite so well in India (despite having been successfully around since 80s), and that there have been several strifes lately. There was an interesting reference to what the Japanese call as Karoshi and Karojisatsu. Now, unlike many other Japanese words, these are really gross words because they mean

  • Karoshi = Death from Overwork
  • Karojisatsu = Suicide from Overwork (and stressful working conditions)

Curious to know more about it, I chanced upon this graphic from ILO page on workplace safety:

Karoshi and Karojisatsu cases in Japan, 1997-2011, ILO This data comes from Japan, and while the numbers might not (yet!) look staggering to many a folks, the trend is unquestionably disturbing, and our own deniability might only be getting compounded by lack of data from our own respective countries or industries, not to mention the social stigma that might be associated with someone refusing to ‘work hard’ on medical grounds lest they suffer an injury, suffer a burnout or commit suicide!

In the last few years, I have heard of small but increasing number of such sudden deaths among senior IT professionals – not just in Bangalore, but also globally. You can read about them here, here, here, and here.

Burnout is a serious issue for several countries, industries and people, even if we don’t acknowledge in as many words. In our industry, where heroism, cowboy programming and all-nighters are considered cool and an integral part of the software subculture, there has been a (really) small effort to address work-life balance by identifying that software development should be ably to proceed “indefinitely” on “sustainable pace” with XP explicitly advocating 40hrs a week (though some might disagree with this interpretation of “sustainable pace“). However, anyone who has ever done any non-trivial piece of software development will point out how hollow this expectation is in reality. When it is the release time, families learn to deal with their family members coming late or staying back office overnight, or working through the night even if home. Those in startup phase don’t have the luxury of ‘closing the day’, and those who are entrepreneurs actually thrive in such environment. So, is the thrill-seeking behavior at work here? Could it even be the case that we are only unknowingly aggravating the problem by hiring more people who think, talk and work like us – thereby creating a tarpit-kind of environment where there is no escaping it?

It is well-known in manufacturing that we never utilize machines more than 80-90% of their rated capacity (global stats on utilization are more like 80%). And yet, we don’t think twice before ‘loading’ human beings to much beyond their 100% capacity! Unfortunately, the data suggests that working more reduces productivity, as below:

Working hours vs. Productivity

Or, our ‘professionalism’ stops us from admitting that if I put out my case for a better work-life balance, I might be considered a loser and be considered unfavorably in appraisals, promotions and salary raises?  

So, how do you deal with it, or rather, ensure that you don’t get burnt out? Or, if you are a people manager or a leader, how do you ensure those supporting you are not getting burnt out?

Important to call out here that the old harmless joke “Hard work never killed anyone. But, why take chances?” suddenly doesn’t look so innocuous anymore. 

Worth thinking…

Let’s free up agile teams…

Agile in general, and Scrum in particular are all about self-organizing teams collocated for maximum face to face communication that improves agility and real-time collaboration. This was a great utopian idea in ~2000s because of three primary factors back then – economics, technology and psychology. Back then, we were still trapped in the enterprise-mindset – all collaboration happening within the confines of an organizational boundary – be it research or product development because it was much more cost-effective to lead such efforts internally either due to massive costs of R&D or closed IP protection or simply being the sole magnets for top talent.

However, as Henry Cherbrough’s Open Innovation has challenged, and Lafley’s Connect & Develop program at P&G and several others have subsequently demonstrated, there is perhaps more to gain from opening up meaningless and irrelevant organizational boundaries than protect false economics of a closed innovation system.

Globalization, even with all its ugly side effects, has shown us repeatedly in industry after industry that working across a global supply chain is not a zero-sum game after all! So, why are we so parochial in software industry about not recognizing the bigger economic sense rather than limiting ourselves to a singular idea that collocated teams are the best option?

Similarly, the technology to collaborate over the wire is dramatically more potent, even if underutilized in mainstream due to various reasons, than ever before. Collaboration over internet is the most natural thing for the millennials – back in 2007, a good 97% owned a computer, 94% owned a cellphone, a good 74% used instant messaging and 94% of those multitasked while messaging. In 2013, they are spending over 25hours every week online – be it social media or online shopping, or consuming infotainment or what have you. So, it is natural that this generation is extremely comfortable – even prefers – in being connected online and getting its job done. How will you make them sit in the same office day after day, and why? Little wonder that companies such as Automattic, MySQL, 37Signals and Github are starting out as massively distributed teams – not just on day one, but are continuing with their thought process of virtual workforce that still values teamwork but prefers newer ways to stay connected with the mothership – online instead of being their physically. As they say – the technology favors the geek!

And finally, the human psychology. The more specialized the talent, the rarer it is to find than ever before, and the best talent might not always be ready to work in your office even if they are willing to work for or with you. Just like people want democracy but not necessarily politicians, they might want to work with you on specific projects or technologies, but without being part of your office politics or hierarchy. They may not aspire to a long-term career growth with you but still value working with you on that one small problem that really fires them up. However, the very thought of being on your rolls and then moving the family to your location might not make sense to them, especially if you also happen to be in the similar business of delivering services online for your own customers (and who isn’t these days?). So, will you still ‘force’ your agile teams to be collocated inside a single mothership, or take a very large pragmatic leap of faith and explore oasis wherever they are, and build distributed teams around them? To me, a process is a reflection of the social values and norms of the time when they were written. If the world has moved on since ~2000, why should we not revaluate what should ‘being agile’ mean for this world?

Let’s free up agile teams…

 

...and he might be a 'free bird' and work remotely!

…and he might be a ‘free bird’ and work remotely!

I draw upon several ideas for my hypothesis. Authors Ori and Rod give a compelling vision of autonomous teams in “The Starfish and the Spider” – while spider teams are more vulnerable, the starfish teams could be autonomous and perhaps more effective in “VUCA” times. These thoughts are getting echoed in leaderless teams in Holacracy, and are well-grounded in Complex Adaptive Systems. There is a whole new movement of “Office Optional” new-age companies where they work from home or Starbucks, and even the people who probably show up in a physical office have to dial-in for a call from a meeting room so that everyone is equally ‘remote’.

How will the currently established mental models of agile teams – specifically on business people and developers working ‘together’ daily, which is invariably assumed and expected to mean ‘face to face’ – scale up in such a scenario? If the people are changing the way they think and interact, with or without agile, and the organizations are changing the way they conduct business, can we expect our processes to hold out for us? Think about it – when our customers expect work to happen at their convenience when they need it, they are asking for a business model that is distributed in time and space – and all that is already happening around us! So, how could the teams designing and developing such solutions not put themselves in the shoes of customers and internalize such learning environment?

I think there is a strong business case of freeing up agile teams from the physical boundaries of collocation because the collaboration methods are both – efficient and effective – and create compelling business case – even if only a minority at this point. I definitely see a wave building up at the horizon…

Why is your agile still a lot like dogma on steroids?

I still continue to be amazed (thought ‘shocked’ and ‘dumbfounded’ will be more appropriate words here) by the amount of dogma in agile circles. Do this! Don’t do this! Wasn’t agile meant to liberate us from the tyrannies of the so-called big monolithic non-agile white elephant processes, and create a more nimble mindset, flexible culture and adaptive process framework where ‘inspect and adapt’ was valued more than ‘dogma and prescription’? I sometimes think the poor old waterfall, for whatever it was worth (and I do believe it was worth a lot more than most people are willing to give it credit for!), was more open-ended and invited innovation simply because it was not perfect enough, and was very clumsily built for a rainy day, and depending on how sunny your day was, you were allowed (rather encouraged and expected) to pack only that much ration that you felt might be needed for the jungle trip.

For example –

  • You could have had any team size.
  • You could choose to locate your team members anywhere they wanted to be.
  • You could tailor your process in whatever way that made sense for you.
  • You could choose to slice your functionality in any which ways that made sense.
  • You could stagger the releases in whichever way you felt offered better yield.
  • and so on.

In several ways, such innovation required one to master the nuances of software development. And for those who would apportion reasons behind failure of such project on the method, my response would be – when there is so much flexibility in the system, why blame the system for being so ‘rigid’?

I have experimented more with waterfall methods in my career than with agile methods (which also I continue to do, much to purists chagrin :)), and here’s a small list of key exeriments that I remember doing – something that gave me immense joys because I had the liberty to try out stuff to see if that solved my problems better –

  • In 1995, when we realized that we are in a technologically evolving and complex domain (Asynchronous Transfer Mode switches), we didn’t build castles in air with the ‘non-negotiable’ waterfall-based product development process that the company had mandated, but decided to build an early prototype what would allow us to validate some key assumptions about our architecture. Yes, the company’s process didn’t support us, but yes, we broke the rules :).
  • In 1997, when we ‘discovered’ that standard waterfall won’t help us speed up the development cycle while we wait for the previous phase to complete, we didn’t blame the process for it, we simply ‘invented’ sashimi model and kept going.
  • In 1998, when conventional estimations didn’t work out in a domain that was completely new and unknown to us (digital set top boxes), I was not obligated to follow some obsolete standard process (though we were a CMM Level 5 company), but encouraged to try out estimations using complexity weights using methods like PROBE to mitigate the risks in estimations.
  • In the same project in 1998, when the project’s technology was new to us, I was able to home-brew and define a process with five increments that recognized the experimental nature of the problem we were solving and the learning curve of the team rather than sticking to a one-size single-release process.
  • During 2000 to 2003, I liberally experimented with waterfall methods to build teams that delivered large products in telecom and datacom domains with high success rates. At one time, I had 190+ engineers on a single product in my team organized around 14 parallel projects running on a common timeline and delivered on-time product in complex 3G Softswitch space. Yes, all in waterfall :). At that time, we were ranked last in global market. Today that company is global leader in that space, and I can proudly say some of our efforts were behind that turnaround.
  • In 2004-05, I experimented with our conventional enterprise service pack release model by liberally adding the weekly cadence from Gilb’s Evo process to create a weekly delivery model, and by accidentally stumbling on the concept of limiting work in progress to create one of the world’s first kanban implementations without knowing kanban – to be fair, it didn’t exist at that time – all without any prescriptions but just with a liberal dose of enthusiasm and undying spirit of experimentation.
  • …and the journey continues.

And what has been my take on the agile theory and practice? Not so open to experimentation or innovation. Sad, but true. Take some simple things for a start:

  • Agile methods recommend a small team size. That’s good common sense, and backed by scientific studies and acendotal data from ages, and is a generally good advise. What’s no so good is then we insist that agile teams can only be in a certain numerical range, and any team size more than that is blasphemy! In fact, my extreme view is that the best team size is what you have right now and not an ideal something from the literature, howsomuch backed by data that might be! In several ways, it is same as the ideal body weight – most of us will never have it, but what we have ‘here and now’ is the most important number to start with. So, why waste time over building an ideal team and lose all precious learning opportunities in that process? If my team has a true ‘inspect and adapt’ DNA, irrespective of where I start, I will get to the finish line. Somehow. Isn’t’ that more important and being truly agile rather than finding the perfect take-off point?
  • Take user stories. The notion of moving to user stories makes lot of sense give the constant pace of world around us. PRDs could never cope up with documenting such copious amount of details – and if anything, they would only succeed in documenting history of what customer wanted a year back! Now on one end we want our user stories to be ‘negotiable’ (from the acronym INVEST) so that we can create meaningful conversations between product owner and the development team. This again makes a lot of sense in an imperfect world where documenting every single requirement with its myriad corner conditions might be practically impossible, and has diminishing rewards beyond a point. So, if we can create a quick and cheap way to get started and have both, the process and the humility to listen to development team come up with more questions and options, then this premise holds very high promise. However, as a philosophy, something that is non-negotiable might not be so good in the same spectrum. For example, the Scrum process that we want them to follow must be non-negotiable. Why is that? If Fosbury had listened to the best way of high jumping, he might have never broken the proverbial sound barrier in high jumping.

Hey…what happened to the big promise of team being allowed to figure out its own ways and means? Once we ‘tell’ them, shouldn’t we step aside and let the team find its true north? Do I hear you mention ‘Shu-Ha-Ri’ thingy? Do yourself a favor – go and find a student (even better – try it on a second-grader) and then keep telling him/her that they are still a ‘Shu’ and hence must obediently listen to whatever you are telling them. They are supposed to follow your instructions to the hilt and not even think of wavering a bit. Good. Now take a deep look at their reaction. Count yourself lucky if they choose to ignore you and decide to move on, for there are far more violent ways they could have chosen to respond to such dogmas. In short – this is not the time and age for dogmas. Kingdoms, Colonies and Communism are all long dead. Accept it and change your own coaching methods, if you want to be counted.

To me, agile is a state of mind that tells me how to proceed in an imperfect world. Not to somehow make a ‘perfect’ world and then proceed. To me, a successful agile implementation is not about finding the perfect team + perfect process + perfect customer + perfect timeboxing + perfect sprint planning + perfect retrospectives + perfect product owner + perfect scrummaster + perfect

When does experience get ossified into dogma?

When does experience get ossified into dogma?

engineering practices + many more perfections = perfect landing. To me, a successful agile means starting with team that you have at hand, with the process that you have under the constraints you have, with the requirements that you have on a best effort basis and a many such real-world realities that works under a mindset of taking things one after other and improving the journey with the hope to get to the destination better than without such effort. Remember, we are being melioristic, not idealistic. We are being adaptive, not laying down pre-conditions for take-off. And in that pursuit, the most important guide for decision-making is our own judgment. Everything else is just that – everything else, and while it might work at times, it might not work at other times. So, like the Swiss Army manual that says – when there is a gap between map and the terrain, trust the terrain, go ahead boldly and experiment. In the worst case, you will lose some time and dollars, but if your DNA is built on the premise of self-improvement, you will quickly recover and eventually find your own path. If you are not able to ‘find’ it, you will ‘build’ it. Even better…

In many ways, there were no royal guards so zealously guarding waterfall model that made it sexy enough to be experimented with and experimented upon. On that same scale of flexibility, I don’t find agile methods sexy enough. It appears to be a lot like dogma on steroids. And I think that’s a serious problem.

Is your agile still a lot like dogma on steroids?

Is your plan just a placebo?

Plans have a huge credibility problem. For large part of recorded history, they have always had this problem. With all the advancements we have made in estimations, forecasting, scheduling, risk management and planning, our execution still continues to challenge us, at times even confound us. It almost makes one feel that real doers don’t plan, they just do it! Or, putting it in more bluntly, a project plan is at best a reference, a guide, maybe even a map – just like Eisenhower said “In preparing for battle I have always found that plans are useless, but planning is indispensable” – but never the single, eternal source of truth that is much-needed for you to face the battle? If that is true, does it mean that the project gets done irrespective of the plan? Despite the plan? What if your plan was not so accurate and detailed, but more like “just do it” – would you still do just as fine? Does it mean that execution is really the most important part of the whole puzzle?

So, is your plan just a placebo?

Every business school and startup mentoring clinic would tell you that you need to have a business plan, or at least some business plan to get started (well, some of the good ones like Ycombinator will tell you that you don’t need a business plan), and yet every entrepreneur would tell you, as the German military strategist and Field Marshal Helmuth von Moltke the Elder famously said, “No battle plan survives contact with the enemy”. All the romantic visions of a rosy future of millions of customers with wallet full of greenbacks thronging your ecommerce website come crashing down when the first assumptions turn out to a sand castle, and after that, it is just responding to the events, setbacks, challenges and opportunities in real-time, ad nauseam.

Bill Hewlett said this about HP’s early days

When I talk to business schools occasionally, the professor of management is devastated when I say we didn’t have any plans when we started. The idea of having a business came before our invention of the audio oscillator. We were just opportunistic. We did anything to bring in a nickel. We made a bowling alley foul-line indicator, a clock drive for a telescope, a thing to make a urinal flush automatically, and a shock machine to make people lose weight. Here we were, with about $500 in capital, trying whatever someone thought we might be able to do. So we got into this thing not by design but because it worked out that way.

This is from circa ~1937-38. If this story doesn’t convince you because you believe a lot has changed since then, just sample Intel’s business plan from 1968 in this graphic. If no one told you it was Intel’s business plan, you probably won’t give it a second look, let alone fund them. 

Intel Business Plan, 1968It might seem very improbable, but just think about it – they could have written just any other business plan for Intel and yet be equally successful? So, was this piece of paper just meant to sell some dreams to potential investors, or on a lighter note, sell them something that they badly wanted to buy so that we could go out and do what we badly wanted to do without any external interference? Or, is the eventual success all about execution – staying focused on the task at hand and quickly learning what’s working and what’s not while quickly pivoting on stuff that’s working. So, the starting point doesn’t really matter as long as there is a process that allows for being able to get feedback from the market and then quickly iterating through subsequent changes? In that case, the plan becomes a placebo, and because we have been conditioned to believe that a plan is supposed to help us, and hence we end up eventually ‘following’ it in some shape or form? 

Or is the eventual success all about serendipitous luck and a great timing that some are born with, while some others acquire it but most of us don’t have a clue about? It could seem like the case with so many one-trick ponies out there. Take Hotmail. A great success that justifiably rewarded its founders with riches but only never to replicate even a fraction of that original success. People often question if Google is also a one-trick pony? While something like that might/not be a great strategy can only be eventually determined by how the market responds to it. Some might say putting “all woods behind single arrow” is a great strategy because it allows laser-sharp focus, while some other might seek safety in numbers and might want to diversify and have a product for all pockets. However, in all those cases, it is likely that even if there was an initial luck that led to some technological or a market breakthrough, the long-term success only came from systematic planning and methodically executing on what was the most important or business at that time.

So, we come back to original question – is planning, or having the benefit of a plan just a placebo?  Some people might argue that a placebo works only when the subject is not aware of the existence of a placebo agent. If we go by the data by Placebo Research Center, there seems to be data to suggest that a subject could still demonstrate same results even while fully knowing of the existence of a placebo agent. So, it might not be long shot to say that existence of a plan, even if the manager or entrepreneur believes it to be just a work of business fiction, is completely redundant. After all, if writing something on a piece of paper becomes a self-fulfilling prophecy and eventually leads to a success, that seems like a very small price to pay given the rather high odds of success in such an uncertain environment?

I am investing this subject further, but would love to hear back from you if your plan is just a placebo, or something much more methodical and meaningful?

Why user stories make sense?

User story is a popular mechanism used by most agile methodologies to communicate user requirements. Actually, this is only partially true. User stories are meant to be a placeholder to initiate an early conversation between the product owner and the team on key hypotheses so that a quick validation of them could be done to refine/confirm/reject our understanding of what the customer really wants. To that end, user stories are not anything like the requirements of yesterday – they are not even remotely meant to be complete/comprehensive and so on. 

The reason user stories (and not ‘well-formed’ requirements, if that is ever possible) makes sense is because we human beings are not experts in following the written word, and are likely to misinterpret requirements even when they are explicitly written down, especially when the communication is a one-time event and not an ongoing process. (if you don’t believe this, just visit this interesting site http://www.cakewrecks.com/ that celebrates real-life examples of how something as simple as icing on the cake can go horribly wrong despite really simple and absolutely clear instructions!). And we are talking about building complex mission-critical systems that must operate 24/7 with top speed and efficiency. If only the written word could be consistently understood by the receiver as intended by its author… 

On the other hand, if there is a continuous two-way dialog between the product owner and the agile team, such purposeful brevity leads to curiosity which then leads to a constantly improving and better shared understanding that refines as the product gets developed incrementally and gets periodic user feedback. 

User stories reflect the reality that we might not have 100% clarity about the requirements on day one, but with constant dialog, we might be able to improve our shared understanding of customer's wants and needs.

User stories reflect the reality that we might not have 100% clarity about the requirements on day one, but with constant dialog, we might be able to improve our shared understanding of customer’s wants and needs.

The key benefit of user stories is that instead of waiting for weeks (even months!) to get a fully-bloated and rather unprioritized PRD which is supposed to have fully-baked requirements while the development team sits idle all this time, is that identifying highest priority user stories and using them  to develop a prioritized product backlog allows the teams to get started much earlier and start developing features which could then be put out in front of customers to get real feedback (as opposed to individual ‘opinions’ that might/not best guide us in an uncertain environment). This is especially important because in the past, when the world was little less complex and much more underserved. I purposefully use this term ‘underserved’ because it is not that people have suddenly become much more demanding about what they like or not, but were just told there were exactly three carmakers to choose from, or just two operating systems to choose from, and so on. However, with rapid advancement of computing paradigms and constantly lowering cost of ubiquitous communication devices, they suddenly have the opportunity to demand what they want, and hence classical ‘forecast’ models of requirements elicitation, design or production (at least in the manufacturing sense) don’t work so effectively as much as the newer ‘feedback’ driven models that allow for developing key hypotheses (and not hard requirements carved in stone) which could then be quickly and cheaply delivered as ‘done’ features so that customers could tell us if they like them or not. Based on such valuable customer feedback, the team could iterate to either refine the feature, or to pivot, as the case might be. In the past, this might take the entire product gestation cycle, by which time, many, if not most, things might have undergone significant changes, and the entire development costs being sunk by that time, not to mention complete loss of any window of opportunity.

As Facebook says – Done is better than perfect. User stories allows developing a small slice of the product without really perfecting the entire product, but facilitates the process of validated learning that eventually helps develop a product with much higher chances of meeting customer needs.

In today’s world, you probably might not have the luxury of having investors wait multiple years for an exit, or customer waiting several quarters for a perfect product when the competition is willing to serve them faster (even letting them lay their hands on an earlier version and give feedback thus making customers a co-creator of the product), or employees working month after month without getting any meaningful feedback from customers. And we know that absence of any feedback eventually leads to erosion of trust. Incremental product development could help you bridge such trust deficit by delivering highest value to customers early and periodically, and user stories might help you get your project a quickstart.