Recently I built a website that used beta version of an open source software. Obviously, I ran into problems and I had to contact the community to get help. One response I got was that the software is in beta and should not be used in production. I replied back, “my site is in beta version too!”

A lot of changes have taken place in the past few years. Traditionally software solutions were born in academic and research institutions and then brought to commercial and enterprise space. Once it is established it was adopted or made accessible to individual users or mass consumers. For example, email was born in research labs, which found its way into academic institutions and then to enterprises. Today it is accessible to everyone. Another example could be business intelligence and analytics which were researched in the academic world and found its way to enterprises. Today it is available to everyone in the form or different analytic applicaitons and tools such as Google Analytics.

Coming back to the subject, it is a new world out there today. Innovations are now born is communities, who typically constitute of mass consumers. It is then matured and stablized in communities before enterprises adopt. It is a common practice to distribute beta releases early so that the software is well-tested and moreover understood by end-users.

Strangely, academic institutions come last in the new world of software engineering. They tend to analyze how the solutions or phenomenon evolved, detect and understand patterns and provide best practices. Purists may question this widespread use of beta software and applications, and even term as a compromise to quality. But amateurs and beta are conquering new heights in online landscape.

Time is money. It’s much more than that. Money if not invested shrinks over a period of time. Time vanishes.

Like money, time is another resource which is limited and cannot be accumulated. Investment typically converts a resource into another form, which can be preserved, accumulated and grown - look at how money is invested. In the same way time can be invested by converting it into something that can be preserved.

To me investing time is to best utilize time to build up knowledge, skills, relationships etc. Now the economy is down. There is little money to invest, and there is a lot of uncertainty too. But strangely when the economy is down I see people having a lot of time - without many projects at work and not engaging in many activities outside. This time can be invested into something that builds up, that can be grown later, which can be converted into money. And yes! Time is money (and much more than that).

Here is Google’s Marissa Mayer, how she went on building her team. “I like to hire people who have two traits. They’re smart, and they get things done.”

That comes from Joel Spolsky’s The Guerrilla Guide to Interviewing. Today I just asked myself again - am I getting things done smartly?

It has been a long time since I posted last. These were busy days with a lot of changes happening in the personal and work lives. I have written about changes earlier, but this time I observed something different. A change unsettles, it creates uncertainty, ambiguity and at the core of it these uncertain, ambiguous times and situations makes people difficult to accept change.

Some of us dealt with changes from young ages - changes in school, friends, house, cities - especially those who moved around a lot. But some of us did not. Whether we faced changing situations or not, most of us were not much exposed to ambiguity and uncertainty. Our parents took care of it. As we grew we started facing these situations more and more and we were not taught how to deal with those. We resist, oppose, fight every change, because we do not know how to deal with uncertainties. 

Then at some point we give in, we reconcile with the changes and it takes a while to adjust and start enjoying the changed life. Another change is on the way, and then the cycle repeats. What I observed during these days is that as we go through a series of changes we build experience, we build tolerance to uncertain times and ambiguous situations and we learn to walk independent of the hands that were holding us through.

As we walk, as we learn, we become mature.

The early bird gets the worm! Common wisdom suggests to get things done as early as possible. Everyday I see people - tuned to this wisdom - rushing on the road, into the elevators, around the vending machines, fretting and fidgeting about the seconds lost. I used to have a manager who was obsessed about every minute in the schedule which ultimately caused huge reworks and led to exhaustion of the team in all sense.

As late as possible is not a new strategy. It is well-known, documented, implemented and practised. However, many of us do not see it as an option because we are not taught to delay work. We all know procrastination is the thief of time!

There are times when delaying is the best course of action. It could be during a negotiation, dealing with uncertainties, or even when booking a flight ticket! This may seem adventurous, but with careful judgement of circumstances, acting as late as possible will be eventually beneficial.

So, next time before you step into a crowded elevator, before booking that off-season flight ticket, before ramping up the team when you think requirements are not clear, consider the strategy - As Late As Possible.

During a recent discussion on risk management, I suddenly realized that we tend to see risks too negatively. We were trying to enumerate risks and it was easy for everyone to come up with negative risks (threats) and not so in exploring positive risks. May be we do not want to call it risks; we prefer the word opportunities - it sounds a lot more positive.

But, isn’t there an inherent threat in every opportunity? Isn’t there an opportunity in every threat? There is, and this is not something new! A little search in the internet gave me some food for thought. Risk management is not just avoid - transfer - mitigate - accept strategies to deal with threats, its also exploit - share - explore - ignore to work on opportunities.

What struck me most is that there are two sides to every risk - positive and negative. In other words, every risk is an opportunity and a threat, however small each may be. Clinching that opportunity wisely is the road to glory!

The two basic questions in any project/task are - are we doing it in time, using the estimated/allocated effort? Most of the important metrics are then derived out of these parameters - time & talent, as I like to call it. Time & talent are curiously unique while being the very basic parameters of any project.

The most intriguing aspect of time is that we cannot save time. We may be able to - in the most simplistic sense - if our project does not have any dependencies on anything in the world, which is not real. The other option to save time is to underestimate - estimate very stringent timelines, which is not a good practice. If we attempt to do a project under normal circumstances, pushing for an early completion of a task creates wastage of time down the line. The best way to save time is by spending it wisely, by creating and sustaining a flow, a rhythm in work.

Talent fulfils the allocated effort in a way that completes the task. In practice, talent is not generic, it is very specific - everyone cannot do every job. That brings out the uniqueness of this parameter - unlike other inanimate parameters. Everything remains the same, the best way to get the most out of a talent pool is to give. Give information get better interpretation/implementation, give training get better productivity. It does not stop there - recognition, empowerment, compensation etc. - there are many variables in this equation. The challenge is to balance the equation - across variables, across the team.

Many a times we try to meet the challenges in managing time and talent using unintelligent, inanimate processes and tools. But managing is both art and science. A little art, a little creativity in these areas will make the manager, the team and the project distinct.

As today’s professional world is adopting a knowledge-intensive culture, it is tough to find a right combination that covers the depth and the breadth of a specific area of knowledge. Conventionally, we relied on deep, explicit, documented knowledge as in the case of research and development projects. But in recent times knowledge acquisition has become broader because of mainly two reasons.

Firstly, technology has helped distributing information wide and far and power of knowledge has become evident in activities beyond research and development. People then needed to acquire knowledge from more than one domain and were restricted in the depth while expanding their breadth of knowledge. Secondly, people who followed the rapid advancements in technology made shallow impressions everywhere while spreading over larger area.

We have two sets of people now: the specialists and the generalists. Generalists existed even before the above-mentioned reasons forced many and that was because of personal traits - some people find it easier to deal with multiple subjects while others like to dig deeper in one subject. I find J Scott Armstrong’s description of specialists and generalists very striking. According to him a specialist is the one who knows more and more about less and less until eventually he knows everything about nothing! A generalist is the one who knows less and less about more and more until eventually he knows nothing about everything!

Today’s world needs both specialists and generalists, and the challenge is to find the right balance between the two. Certainly a team of generalists is not going to be of much help. A team of specialists may lack creativity or may miss out the inter-relationships between multiple parts.

There are various hypotheses and propositions on structuring a team with specialists and generalists. But I like to draw an analogy from sports in this matter. In all the team-sports, there are some people who are all-rounders or playmakers; though they are not many. A generalist holds this position in a project team. This is especially true when the environment/scope is not too small. Obviously in a very small team/project, specialists always dominate.

Howard Artrip - a manager in Toyota - knows what he does. He knows when he gets up, how long he takes to get ready and get to work. He smiles when he says “I’ve maximized my sleep time”. Toyota’s philosophy of continuous improvement is his personal statement.

Sometime back, I was talking to an engineer from a highly capable and mature company about what he thinks about quality. At the end of a very colorful description about the practices and processes, he confessed that it is difficult to follow them all. It was a burden on him, and in his opinion an overhead to the system.

It is a fashion to adapt and implement the processes and techniques that are proven in some organizations. In a frenzy to implement and report the return-on-investments, most managers fail to get the spirit - and most importantly the thinking - behind these processes. One of the common mistakes is that we try to replicate the processes without understanding the context and culture in which these were set and became successful.

Value addition is the promise of most processes and techniques. At the end of the day we search for added value in the process, in the end-product, in the pile of documentation, reports, and presenations. What I find often is that we miss out in searching for the added value in our people. It may be that we think they are just techies or skilled workers, we think they appreciate the processes themselves, we think the processes have nothing to do with people and vice versa!

People need to understand the reason behind every activity, the benefits and a bit of history to enjoy their work. It is important to infuse the spirit behind the process into people, so that value is first added to them - and they realize it. They will in turn add value to products and even back to those processes.

It is a very old saying of Aristotle - well begun is half done. We find this true in many fields, especially when it comes to accomplish a certain goal - whether it is in studies, sports or projects.

We have developed and mastered many techniques and processes to execute a project. But we deal with project initiation with a bit of laxity. In the height of dramatic events involved in realizing a project, we sometimes fail to see the fine cracks that are being developed - in terms of missing out details, under-estimating functionalities, setting aggressive timelines etc. It then becomes a fight for the team to hold the project from falling apart during its course to completion.

It is good to estimate, and it is better to re-estimate. There are many techniques which are developed to encourage multiple estimates - quick/detailed estimates, optimistic/pessimistic estimates, low-confidence/high-confidence estimates and so on. It is also important to work out estimation parameters from the final estimate that is used to win the project. One aspect which is overlooked frequently in estimation is dependency. The project dependencies normally drive the schedules and idle-times and it is crucial to understand it early on. A good work-breakdown-structure can solve this easily.

It is also good to create a visual representation of the project and its environment, something like a map. Words can be hazy; numbers can become tough to follow; visual representations are easy to comprehend and remember. It is good to note that all military operations start with a study the area to be conquered, usually represented by a map. It is good if the project map includes not only the deliverables, but also other details such as schedule, size, assignment, risk etc.

Training and team-building are some aspects that are taken lightly. It is important for the team to understand the terrain - environment, existing systems, work-flow, domain knowledge, business rules, tools, techniques, limitations of technology - before starting a project. Building a knowledge-base is a best-practice in most of the execution frameworks. The earlier and faster we build it, the easier will be the project execution.

If we take Aristotle’s words literally, it is fine to devote half the project duration just to initiate. If you are worried about a possible time-crunch, return to some past projects and see the productivity during the last few weeks.