Evolution of Analytics – Understanding, Predicting, & Acting

With the advent of unprecedented data  at enterprises (internal as well as external) & advances in machine learning, analytics is going through rapid evolution. The nature of questions we are answering using analytics, as far as the enterprise is concerned is changing. I describe the three stages of this evolution.

Analytics 1.0: What happened?

This was the era of descriptive analytics. Enterprises were sitting on vast amounts of data had no insight into it. This era of analytics helped create ways of describing and understanding this data.

Applying this to Sales (as a department), for the first time, sales leaders had a way of understanding the nature of business they had closed. They used this to make decisions about what kind of customers to target, or what price points to offer. This also allowed sales reps to manage their pipelines. From what I hear, this was the 1st use case of Salesforce.

This understanding led to Analytics 2.0, which was a desire to forecast the future.

Analytics 2.0: What will happen?

This is the era of forecasting based on analytics. Here, straight forward multi variate linear regression models were used to predict what the future would look like, based on past trends.

In Sales, this gave sales leaders & reps a view of where they would land by the end of the month or the end of the quarter. As a result, sales leaders can now influence sales activities while they still have time. Products like Insight Squared leveraged data that was collected, and unlocked it to provide this ability to forecast.

Once you can forecast the future, there is desire to control it and influence it, not just react to it. This is leading to what I believe will be the future of analytics in the next 5 years.

Analytics 3.0: What should I do?

This is the era of using data and machine learning to characterize a current event, such that it can be influenced favorably. At it’s core, it’s an analytics system that has precognition, and tells you what to do.

In Sales, this would be a system that tells you the likelihood of a lead converting into a deal, and the size of the deal. Further, it would tell each sales rep what kind of questions to ask, and develop a “talk track” that is specific to the nature of a lead at hand, such that the rep can continuously increase the likelihood of a close.

I believe we are just scratching the surface of stage 3. The applications of such analytics are far reaching, well outside marketing, or sales or recruiting or people growth.

Analytics 3.0 will address areas where human beings fail at a very fundamental level, intuition-based decision making in irregular environments.

Evolution of Software Development Teams

tl;dr: I’ve seen “agile” software development teams (2-8 in size) that took ~ 100 days to ship features to teams that ship everyday, at times with the same team members. This post is about the journey & ingredients of such teams in product orgs. Feel free to call out mischaracterization as you see suitable 🙂

The “once a quarter” team

This team generally has a cadence where it ships something “big” every quarter, typically 60-90 days. It has some version of biweekly planning with daily stand ups for updates. It does “estimation” as a means of de-risking projects, but given that it is shipping on a ~ 100 day cadence, it frankly doesn’t matter because it isn’t “learning” from the real world fast enough. In fact, a 100 day cadence results in slips, regressions, & all kinds of vicious outcomes that come with deploying significant chunks of code.

The tech stack for this team ends up becoming coupled. Members develop “expertise” in parts of the tech stack, and the interchangeability of members becomes impractical.From a process perspective, this team looks like a “once a day” team to outsiders.

This team feels good about their “lack of process”, feels that it is shipping “big meaningful things”, and celebrate big milestones in terms of output. These teams rely heavily on “opinions” and “experts”.

Generally, this team has poor outcomes despite “big milestones”, & painfully slow pace of validated learning about the world.

The “once a month” team

This team has adopted some version of SCRUM successfully. It is using “estimates” to determine how much it can commit to. The “tickets” are approximations of end to end value delivering features. The estimation ceremonies for this team is excruciating & dreaded by all engineers. The stigma of not meeting the “Commitment” is painful, and retrospectives can end up becoming an exercise in scapegoating.

While painful, the journey of a once a quarter to a once a month team makes tech stack as well as cultural challenges visible. Some engineers who were previously “experts” in parts of the tech stack start complaining, and some leave. The technical coupling becomes obvious, and the team starts to attack that coupling pulling apart the dependencies.

From a process perspective, this is the most process heavy stage in the evolution of a development team.  This is what our journey from a once a quarter to a once a month team at Sefaira looked like.

Days to ship tickets

It was troublesome and our team worked hard to maintain morale, despite obvious challenges. The best way to maintain morale was by showing our ability to ship faster.

Number of releases per month

Eventually, this team reaches a state where all tickets land in the same 2-3 days window towards the end of the sprint, which results in bottlenecking. Interestingly, the deadline of the sprint end date which served to impart urgency originally, now serves to destroy it. As this team reaches the cadence of the “once a week” team, there is “horse trading” in priorities. It takes a while for the team & business to understand how rapidly it can respond.

The “once a week” team

This team has adopted some form of “Kanban”. It has a lean backlog. The “estimation” done here is super lightweight (10 minutes for ~ 5 day estimate), and done mainly for learning about the health & awareness of the code base (if estimate is off, code is marshy).

This team pairs aggressively, and usually has no individual ownership of “tickets”. This team understands that it is driving certain outcomes (measured in some value delivered to the customer). Daily standups start to become less important. It reviews progress once a month, and reviews “failures” only when there is some major blow up (e.g. work takes 3x longer than expected).

The biggest change in this team is its shift from focus on meeting commitments to minimizing elapsed time.

Work profile of a “Once a quarter” team

Work profile of a “once a week” team

Culturally, this team has very little scapegoating. While afraid of failing, the stigma associated with failure is low. This team’s pace of learning is also very solid. Such a team can reasonably go from idea to an incremental revenue generating feature in 1 month. The bottle neck at this points shifts other parts of the business (sales, marketing, etc).

The “once a day” team

This is the zen like state for a team. The talent, mutual trust, shared values, and goal orientation of such a team is self-reinforcing. This team is relentless in its pursuit of an outcome. This product team is more like a swarm than an individual. There is very little “individual ownership” but very high “collective ownership”.

For this team, there is very little separation between discovery & delivery. UX, Engineering, and Product attain mild-meld, and to outsiders, these teams are enigmatic. Outsiders don’t understand these teams. There is very very little visible process.

At this stage, the team’s culture & practice are in complete unison. You can feed these teams the greatest of challenges, and this team will annihilate it. This is a team Yoda would be proud of 🙂

So, ask yourself, where are you in this journey & will Yoda be proud of you? 🙂

Speed Über Alles

tl;dr: Speed is sometimes seen as a virtue mainly in engineering. While I think it originated in fast moving engineering culture, here I share some thoughts on why its important in all areas of tech organizations.

Speed enables learning

In product development, where we don’t know how our users will respond to what we build, speed allows us to learn rapidly. This allows us to build better products.

We can apply the same lessons to sales. Focussing on driving down sales “cycle time” allows us to learn how our customers perceive our offerings. This ranges from needs discovery, product positioning, price discovery, and to many other aspects of selling. Further, it also enables us to evaluate what techniques of selling work & what don’t very quickly.

Speed increases capacity

I define capacity as the work accomplished per unit time. The driving phenomena here in software development is that our cognitive capacity stretches as we try to keep a lot of un-deployed code, and associated artifacts in our head. However, again there are applications outside engineering.

In sales as in recruiting, managing a large pipeline has serious cognitive implications. Technology (like recommendation systems, alerts, etc) can certainly ease the cognitive burden. However, movement through the pipeline allows reps to handle more accounts in the same amount of time.

I’ve worked with business leaders who emphasize pipeline volume but at times, neglect pipeline speed. This often led to teams getting buried and losing sight of their goals as they try to dig themselves out of their pipeline. Worse, in business, pipeline rot is a real thing. Deals rot in the pipeline.

Speed increases luck

If we consider luck simply as odds of success given a certain number of attempts. The more attempts we make, the greater the likelihood of success in a given window of time.

Speed in building products gives us more shots at success with our customers. The same applies to sales & recruiting where you never quite know when a client or a candidate would be available, or more amenable (don’t get them before lunch or before coffee because they’ll hate you) to buy or move forward.

I’ve worked with sales leaders where their repeated message to the reps was “call them again”. I can’t under appreciate the importance of this as long as you add value in every contact with the customer or the candidate.

Speed delivers more value

In engineering, this is well known. Our customers only get value when they use our product. This idea is easy to extend to sales and recruiting quite directly. The sooner we close deals, the fewer sleepless nights & reduced likelihood of stomach ulcers we all have 🙂

On “Working from Home”

A phenomena that seems to be raging across the knowledge sector in general, is the notion of “working from home”, usually for a day/week. While a blue-collar point of view might hastily dispel this notion as being “lazy” or “unethical” or a modern tech worker might lean on “autonomy” & “freedom” to favor this notion, I think it deserves deeper reflection.

LET’S DEFINE WORK

Work for most of us is solving problems that require creativity & collaboration. Very little of what we do goes from conception to concrete reality, based solely on individual pursuit. Yes, we spend quite a bit of time coding or doing solitary activities, and yes, that’s when rubber meets the road, the difference between being successful & failing is often deciding what problems to solve, or what approaches to take. Therefore, work today is about decisions we make, and the seemingly disparate dots we connect. This was a big reason why coffeehouses in Oxford in 16th & 17th century were a hotbed of innovation.

WHY COLLABORATE?

Most of us are fairly smart, and capable of independent thinking. So why collaborate when deciding? Several studies have shown that problem solving capabilities of a diverse group (eng, PMs, designers, analysts) is greater than a non-diverse group (eng, eng, eng), & far greater than individuals (eng). This n-dimensionality of diverse groups results in the best ideas, which are almost always emergent in nature, i.e. they are not one of but emerge from a collection of independent individual ideas.

BEYOND PRODUCTIVITY

The value of great ideas follows a power law distribution, i.e. most ideas are destined to fail & some ideas have disproportionate pay off. Working collaboratively doesn’t just make us more “productive”, it increases the likelihood that, collectively, we will have the next breakthrough idea.

BUT OUR COMMUNICATION TOOLS ARE AWESOME

Many argue that our communication tools are very sophisticated. I think they are right. Unfortunately, as human beings we have evolved to understand physical cues & in person communication. Face to face communication with a white board, is not only a richer channel (conveys a wider spectrum of information), it is also a more efficient channel (less effort to convey same amount of information). This adds up to an exponentially greater likelihood of arriving at a better solution to a problem, or more importantly, arriving at a better understanding of the problem, & prioritizing the right problem

WHEN IS “WORKING FROM HOME” DESIRABLE?

There are problems where one needs uninterrupted hours to arrive at a solution. I remember trying to write my own code for occlusion culling for a solar insolation calculator (what a dopey idea that was!). It is fair to say that I lost track of time, and needed a lot of uninterrupted time to think through the math & code. Even for a problem of this nature, it would have been great if someone interrupted me to caution me about my approach.

I’ve seen programmers (real ones, unlike me) take time off and work from home, when working on problems that require uninterrupted time. On this note, I think using quiet spaces in the office is the right way to go, so you can be face to face when you need a team mate to discuss something. You also don’t know where your next great idea will come from, so you should maximize your likelihood of chance encounters that give you that breakthrough.

EVEN THEN, YOUR TEAM NEEDS YOU

On many occasions, you decide that working from home will allow you to get more work done. However, we need to remember that our team depends on us for discussion, ideation, complex pattern matching, & thinking through ideas. Given the nature of work, we must lean towards optimizing for the team instead of optimizing of individual productivity.

In summary, I will say that while “commute” & “interruptions” might seem less optimal on surface, the benefits of collaboration & serendipitous connections result in more breakthroughs and greater responsiveness to the needs of the world.

On Carrying a Number

I think there are two kinds of jobs in this world – those that carry a number, and those that don’t. Let me define what I mean by “carrying a number”

1. You have a measurable goal
2. A non trivial part of your livelihood (& eventual tenure) depends on this goal

All sales reps carry a number. All engineering jobs strictly don’t while some management jobs do.  Having written code, and hit the road to sell, & worked closely with sales managers & reps, I’ve had the privilege to observe what the number does to your behavior & mindset.

The good stuff

YOU LEARN TO FOCUS

A number as cold as “sales” will bring significant clarity to what you do, literally. For everything you’re about to do, you can ask if it will help you make the number, and have a clear answer.

YOU LEARN TO LIVE WITH VOLATILITY

Budget charts are wonderful straight lines. The reality is anything but. 90% of the time you get bad news, and for the last 2 weeks of the quarter, you make your number (for the most part). You will definitely learn how to deal with uncertainty.

YOU LEARN TO FIND A WAY

In non-revenue functions, you have an out because the problem is too hard or out of your control. You can throw a fit about unreasonable goals. When you’re carrying a number, all of this ceases to matter. You have a goal, & you have time. You will find a way to impose your will on externalities & make things happen.

The bad stuff

At the same time, there are some negatives that come with carrying a number

YOU BECOME SHORT TERM FOCUSSED

Because you are measured by a quarterly goal, you frankly stop caring about what happens the day after the quarter ends. As a result, you lose sight of the longer term goals, as an individual or as an organization. The good thing about sales is that there aren’t many equivalents of “bad architectural decisions”, though you could drag in roadkill and pass it off as a “good customer”.

YOUR ABILITY TO THINK CREATIVELY SUFFERS

When you are under the gun, there is simply too much pressure to think creatively. I remember being on the road for most of half of 2011 and all of 2012, selling. If I had some time to think, I would have made some decisions very differently.

YOU OPTIMIZE FOR INDIVIDUAL GOALS AT THE COST OF TEAM GOALS

When your income depends on you hitting your goals, you start to become very comfortable with snaking deals from your co-workers. You’ve learnt that you don’t want to be at the bottom when the quarter ends. This is common in all kinds of sales & recruitment, and managers often set up territories & rules of engagement to discourage this. However, the broader point is that you care less about making your team better.

In summary, all I’d like to say is that if you get an opportunity to carry a number, do it. You might not be very good at it & you might even hate it, but you will develop a lot of respect & empathy for those who carry a number for a living.

5 Elements of Effective Thinking

I recently finished reading The 5 Elements of Effective Thinking. Before you roll your eyes, the book doesn’t attempt to convince you that you can be the next Einstein. On the contrary, its claim is that most people aren’t anywhere near their “total addressable smarts”, and it provides a framework for how to think in order to realize that potential. This is a short summary of the 5 key ideas in the book.

Understand simple problems deeply

Understanding simple problems, deeply, reveals a lot of details about relatively simple concepts. Very often, complex phenomena is created by applying simple concepts. For example, the original treatise on calculus was a handful of pages, and a high school calculus textbook today is ~ 1000 pages. This implies 990+ pages are merely applications of the same fundamental concept. From my personal experience, I still haven’t found a complex problem that can’t be broken down to its essential elements, given enough time. I try to explain concepts to others because this reveals a lot of gaps in my understanding. I have seen enough complex problems (hello statistical thermodynamics) that couldn’t break down to fundamentals, and hence they escaped me (Don’t ask me to explain statistical thermodynamics)

Embrace failure as a way of learning

Instead of trying to find a perfect answer, get started with an approach. If you fail (which you most certainly will), study failure closely. This method allows you to learn more about the nature of the problem. Once more detail is revealed by your review of failure, modify your solution. Keep going till you aren’t failing anymore.

Ask a lot of questions

Walk into a new problem or a discussion on an old problem pretending you know very little, and with the most basic of questions. Culturally, we have swung too far on the spectrum of having all the answers, and the illusion of knowledge stops us from becoming better thinkers. Asking naive questions forces us to push the boundaries of what we know revealing new insight.

Understand the arc of knowledge

Try to learn where concepts come from, with the intent of knowing where we are going. A simple example here is the light bulb. The fundamental technology that led to a light bulb pervades our life today. Computer monitors, televisions, car ignition are all variants of a light bulb. It would have been difficult for most to imagine this arc but its important to use this context when imagining the future.

Great thinkers are able to visualize such a trajectory. They often uncover universals, and then look at technology from the lens of that universal. For Jeff Bezos, the universals are the customer’s need for the best deal and faster delivery. For Mark Zuckerberg, it is the need to share and connect with friends and family. Mark, therefore, examines technology from this lens to understand where future is headed.

Change is the constant that brings insight

Great thinkers are capable of changing the way they think about a problem. A lot of smart people understand problems deeply but fail at imagining new ways to think about the same problems. The latter requires us to stay plastic & imaginative. As the book says, great people don’t do the same things better, they do different things. A great tennis player isn’t trying to hit the ball perfectly by timing his shot, he is observing the ball way better than an average tennis player. Everything else follows from his superior ability to “watch the ball”.

Here is an experiment which shows what the great Cristiano Ronaldo is doing differently.