ROTI: Return on Time Invested

Definition of roti (Indian bread):

Roti is a round flatbread native to the Indian subcontinent made from stoneground whole wheat flour, traditionally known as gehu ka atta, and water that is combined into a dough. Roti is consumed in many countries worldwide. Its defining characteristic is that it is unleavened.

(Source: Wikipedia)

In this article, I contextualize ROTI by turning it into an acronym that helps to check the effectiveness of time invested to see if something is worthwhile. As they say, you need skills to create a good round roti by applying the right skills. Similarly, we will learn ROTI (return on time invested) by applying efficient and effective practices as defined below.

Although the proposed model is being discussed in the context of meetings and discussions, I feel this can be applied by software development teams for any initiative where a time/benefit analysis needs to be performed. We spend a lot of time doing cost/benefit analyzes (CBA) for a business decision. However, in addition to a CBA, we also need to perform a time/benefit analysis to see how a team is effectively utilizing its time.

1. Introduction

Many of us are aware of the term return on investment (ROI), which talks about returns from a monetary investment made in a project or an engagement.

However, I am going to apply a twist to the ROI concept and convert it into ROTI (return on time invested).

In our projects, we spend a lot of time brainstorming, discussing, and having meetings. While doing these things, we tend to overlook how much valuable time this conversation has taken.

I firmly believe that though many of these sessions are needed, as coaches or leaders, we need to clearly prioritize the value of these sessions and calculate ROTI.

As leaders, we need to prioritize our meetings so that only the meetings and discussions that add value are the ones we attend and facilitate.

2. ROTI Model: What’s It All About?

The following model can be a blueprint to identify the return on time invested (either professionally or personally). In this model, I have broken the acronym ROTI into four major sections. For each part, there are a set of three questions that every team should ask themselves. The answers to these 12 questions should be captured for further analysis.

The above set of questions can be framed into a survey, and based on the survey responses, the leader can arrive at a decision on whether the particular meeting or discussion is worth it.

3. Interpretation

Here are some general guidelines to interpret the survey results.

Questions Answered



0 to 4

The team is unable to identify the reason why the discussion/meeting is needed in the first place


5 to 8

The team has identified the reason for this meeting/discussion, however, there is room to improve it further


9 to 12

The team has clearly identified the need for this meeting and has a purpose for it.


The above algorithm provides us with a good reference point to decide whether the time invested by project team members in meetings and discussions or any other sessions is worth its salt.

4. Relevance of This Model: Software Industry

One of the challenges that any software development professional, leader, or manager faces is that there are too many meetings, discussions, and brainstorming sessions scheduled in a project. Most of these consume a lot of time with no real productive outcomes coming out of them. Although Agile approaches have streamlined many of these meetings by reducing and also timeboxing them, we still find software spending teams huge amounts of time in meetings only to generate output without any concrete outcomes emerging out of them.

Every software team should reflect at the end of an engagement and answer the following questions:

  • How productive were the meetings?
  • Which meetings are the most effective? Which ones are less effective?
  • What were the key outcomes generated?

The proposed ROTI model will help teams get answers to such questions.

5. How to Conduct a ROTI Session: Implementation Steps

The ROTI model involves a three-step exercise as described below:

Three-Step Implementation Model

Step 1: Identifying Questions Under ROTI

Required, optimized, time-bound, and information: For each of these categories, the team needs to identify the relevant questions. The above sheet provides three questions that are indicative of each category. However, the teams are free to modify or update these questions as per their project needs.

Step 2: Brainstorming Session

In this step, the entire team comes together and tries to answer the questions for each of the categories. A few recommended techniques here are normal brainstorming, silent note writing, the nominal group technique, the Delphi technique, etc.

Step 3: Decision Box

In this step, team members will collectively try to arrive at a decision on whether the particular attribute of ROTI is being met or not. Different types of techniques like voting, consensus building, dot voting, affinity diagramming, etc., can be used to arrive at this

The objective is that the decision in the decision box reflects the opinion of the team and should be representative.

The three-step approach described above needs to be used in conjunction with the interpretation sheet mentioned in section three to decide which meetings are useful and which are not.

6. Key Benefits Observed

Once implemented, this model offers the following key benefits:

  • Better visibility into the team’s process
  • Helps software teams prioritize their meetings and discussions
  • A clear picture of what’s working and what’s not
  • Helps the team focus on important aspects
  • Enables waste reduction and enhances the value addition activities

7. Final Note

I end this article with a very interesting quote on bread (roti Indian bread):

“All sorrows are less with bread.” ― Miguel de Cervantes Saavedra

Let us all use the ROTI model to end our sorrows and pains of long-winded, invaluable meetings and discussions.


Leave a Comment