From "TO DO" to "DONE"

What does it take to get things done? Why do some tasks get done quickly while others drag on forever? Is there a science behind it? Or just philosophy?

Here, I present my thoughts on these topics. This is largely based on my first hand experience in software industry as well as academia, working in small and large companies, collaborating in small and large teams, and observing wide range of things getting or not getting done. 

What is needed to get things done?

First, here are the elements needed to get things done: incentive, aptitude, knowledge and belief. 

Fig. 1 - What elements are needed to get things done?

Items that fall in the intersection often gets done quickly. Different types of work need different amount of these elements. For example, in research and academia, belief often outweighs the visible incentive. Whereas in industry, incentives in the form of compensation, bonuses, equity is pretty compelling to get things done. Aptitude is the ability to do the task, and knowledge covers the experience and/or text-book understanding of a similar task. 

Unlike academia, belief or conviction is often sidelined in software industry especially at the leaf employee level such as for a software developer. Things are different for the founders or C-level folks though.

These four elements are self explanatory. However, sometimes these get confused or intermingled in a way that is not useful. Software companies often hire developers for their aptitude and/or knowledge, but usually have hard time differentiating between the two during the interview process. Knowledge is what the candidate knows and/or has done in the past, possibly related to the task he is asked to do. Aptitude is more about what the candidate is capable of doing, including learning new things and applying knowledge to build new things. 

Think of these as - knowledge is about the relevant courses taken by a student, and aptitude is about the grades. A person with mechanical engineering degree with no courses in computer science discipline may not have knowledge for a software developer role, but if her grades in mechanical engineering were excellent, then it shows good aptitude to learn new things and apply them. 

Once the candidate is hired in a company, the belief is usually thrown out of the window, and often times the company assumes that the incentives are enough to keep the software developer engaged!

In my humble opinion, belief is the most important element for high productivity at the leaf employee level. How else can we explain so many amazing open source projects far better than their commercial counterparts? And hiring a candidate with the belief not inline with the core company values often causes friction and struggle - both for the employee and the employer. 

The belief can be at different levels, e.g., Sam believes that JavaScript frameworks are evil, and should be avoided, and Henry believes that Angular JS is the best thing that happened to web. None of them are right. None of them are wrong. But if Sam is asked to work on an Angular JS driven project, things might not get done as good as they should be, even if Sam has the knowledge and aptitude to work with Angular JS along with five other frameworks. Similarly, if Henry is asked to rewrite an existing Angular JS project into React JS, because the company decided to invest in that new technology, there will be friction and struggle to get things done. Not the optimal path in any case!

It is prudent for companies to identify the four elements for their employees at the individual level, and apply them judiciously, to get things done faster and with high quality. Not doing so wastes resources, delays timelines, and over time, builds up frustration.

It turns out that these four elements have scope far beyond the software industry or work environment, and apply to anything that needs to be done. For example, getting a drivers license or renewing a passport is a task. If the person believes that it is not necessary, because she is going to live in the city with metro trains all her life, the drivers license task will keep getting postponed on one excuse or the other. But if there is a good incentive to save in cost of living to move out to suburbs, they changes the equation. 

In practice, one element can compensate some for another, but may have other subtle and undesirable effects. For example, doing software development unrelated to person's existing knowledge space will need to account for a learning curve; giving a task to person with lower aptitude in that space, will need to plan for extra quality assurance and testing time; and so on.

What are the roles to play?

In software industry, people often talk about doers vs. talkers (or thinkers). Usually when such connotation is used, it is often derogatory to talkers or thinkers. In my opinion, both doers and talkers are needed for successful projects. Traditionally, four traits or types of jobs have been identified - think/learn, trade/sell, fight/argue, work/perform - aka - thinker, trader, fighter, worker. 

In the past, these traits have been associated with different types of jobs or people, but it turns out that every individual needs these traits to evolve, survive and flourish. A software developer ought to wear these hats at different times!

Unfortunately, many organizations treat software developers as workers, because there are other folks for other roles, such as product/project managers for thinking, sales people for trade, and so on. This is not right in my opinion. Thinking and learning is crucial for individual growth. This may be in the form of learning a new technology or a programming language or a new framework or tool. This may be in the form of having weekly or bi-weekly seminars where folks from different groups share knowledge about topics of common interest or emerging field. 

Short sighted companies often see such forms of thinking and learning as an overhead that can be avoided. This causes the individual to find time to do those anyway, but in topics unrelated to what could have been useful for the company, such as in the form of a new hobby or spending time in discussion forums or chat room, say, discussing a new game! 

The trade/sell and fight/argue traits are often mixed together, e.g., in modern scrum practices of software process, arguing for a point of 8 vs 3 or 5 for a task, or trading one task in favor of another in a sprint. However, this is not the right example of the trait the individual ought to do, in my opinion. The right example would be fighting or arguing for doing a refactor now, instead of taking a new feature first, so that the software becomes cleaner for future projects, or spending time to create presentations of a new idea or direction that the person wants to work on, and conveying or selling the idea to the team mates or stake holders. 

Such examples have subtle differences between trader vs fighter role. If the person is persistent on the idea, and won't give up, then he is wearing the fighter's hat. If the person presents the tradeoff and let the stake holders make the decision, i.e., buy the idea to invest the time in that project, then he is wearing the trader's hat.

What is the doer's space?

So, how does this fit into the doers vs. talkers discussion? Here is a one way to look at it. It shows the sets of work that the individual wants to do, can do and is asked to do. The red overlay shows the work that he actually does in this example. That is the doer's space - what pieces of work does he do and where do those belong? Is he doing what he wants to do? Is he doing things that he is asked to do but does not want to do? And so on. 

Fig. 2 - An example doer's space is in red overlay

Individual motivation for doing work can be understood by following this doer's space. A person who is asked to do what he wants to do is naturally motivated. A person who is asked to do things that he cannot do (yet) but wants to do, gets the learning opportunity to try something new. On the other hand, a person who is asked to do things that he cannot do and does not want to do, feels more frustrated at work. A person who does things because he can do that, even when not asked to do, may be viewed as a leader or a rogue programmer, depending on the situation. But if the person does not do things that he is asked to do, will likely be let go. 

Fig. 3 - R&D type work with little or no ask

Fig. 4 - Disconnect between belief and incentive

A natural thought could be to ask every person to do things that belong to the intersection of what he can do and what he wants to do, so that the productivity can be maximized. Unfortunately, this strips off the learning and growth opportunity for that person, and also limits the resource usage for that company. 

There is also a co-relation between this and the four elements to get things done described earlier. For example, the aptitude bucket defines the type of work that he can do, the incentive bucket roughly says what he is asked to do, and the belief bucket corresponds to what he wants to do. The actual work that is done then contributes to the knowledge or experience bucket for that person for any future work.

As a closing thought -- for an individual, it is a good idea to identify the doer's space, and carefully take new tasks based on the individual aspirations, e.g., if you want to do something, but the company does not provide opportunity or actually discourages it, then it may be the right time to look for a different company or to start fighting/arguing for what you want to do within that company. If you are asked to do something that you cannot do yet, but want to do, that makes for a good opportunity to think and learn at the company's expense. 

For a company, it is prudent to encourage good amount of exploration projects to strengthen the long term vision, while keeping the focus also inline with the short term goals. A small amount of flexibility in allowing a developer to do things that she wants to do, even if it is not asked yet, goes a long way in improving the morale and productivity, not just in that project, but in general. Different successful companies find different ways to cater to such needs, e.g., R&D projects at work, or 10-20% own project time, and such.

In any case, each individual ought to find the optimal doer's space, where he or she is comfortable, growing as well as happy. When the individuals at the leaf level are productive, the product growth is fast!