Information workers(people who get paid to sit in front of computers all day) start with information as raw material. They get information through emails, interactions with other people, or through other digital information sources. The output they generate is, in a majority of the cases, one or more of the below

• transformed/distilled information(generate report/ppt, formulate strategy)
• a decision(approve/reject the proposal, hire candidate, allocate budget)
• completion of certain defined tasks(send an email, follow up with X, collate data, call Y)

Interestingly, these three things would be theoretically better done by computers. Since the input is information available digitally, it is also available for a computer to consume. Computers are better at information processing, transformation, and decisions. They are also better at reliably doing tasks that can be clearly defined(except maybe the tasks involving human-human communication, but they will get there).

However, to make decisions, computers generally need a lot of data and careful human-assisted training first. And in cases where uncertainty and the cost of wrong decisions are high, it might be a good idea to keep humans involved. Eg. Making the final decision regarding hiring a senior candidate, investing in a new company, or launching a new product.

This still leaves a lot of ripe space. A general strategy you might adopt to identify stuff that can be automated(be done by computers) is to take a step back and break your routine day-day work into tasks generating one of the above three kinds of outcomes. This is an exercise in intellectual honesty because you would first need to genuinely entertain the idea that your job maybe just a series of predictable steps, and is partially or fully automatable. It could be argued that all tasks that fall into 1. and 3. are good candidates for automation. Even tasks involving making decisions(2.) could be fair game if the uncertainty involved is low (lots of relevant structured data available to make decisions) and the cost of wrong decisions is not that high.

Take for example a business analyst whose job is to answer questions from his manager by running ad-hoc queries on the companies database. Over time, this analyst has learned that he/she gets asked the same types of questions routinely and has to write very similar SQL queries against the same database every time and present the results in a standard way(graphs, charts, commentary, etc.). Prima facie, the analyst may overstress the variability of questions he gets asked and maintain the belief that there is no predictability and monotony in the work that he does - each analysis he does is akin to a unique snowflake. But if he can avoid that, he might start to figure out ways to automate the job. The analyst can write a general script with few parameters which account for the several variations of the same questions asked by his boss(how much did we sell x in month y, how much did we spend on z in the time between and b, what is the trend in metric alpha over the last n years). He can also automate the consolidation of this data, creation of appropriate charts, and even generate some automated verbal commentary (this month we saw an unusual increase in sales in product x, which was much higher than all other products).

Now, let’s say you are a recruiter. Your responsibility is to source and shortlist candidates, schedule interviews, gather feedback, and communicate and negotiate compensation. Sourcing candidates generally would happen online by posting the same job description in multiple places and on a few email groups. This can be easily automated. Shortlisting at an initial stage is based on very crude parameters like years of experience, relevant skill set, job titles, educational background, etc. Extracting this information from the CV is an information transformation job(activity type 1.). Shortlisting, or rejecting candidates with no relevant background is a decision(activity type 2). Again, both these are easily automatable and there are already tools in the market which can do these for you. Arguably one part of the job - negotiating compensation - can be thought of as requiring human effort and care. But in a recruitment scenario, each negotiation is very much alike, and you might find yourself in the same situation again and again(candidate has another offer for higher pay, taking a long time to confirm his decision, etc). Even if we cannot automate this interaction, in an attempt to systematise it, we can create a scripts for each kind of conversation. Indeed, highly systematic negotiators have replicable strategies to deal with specific situations that are teachable. Having these scripts reliably assures above-average results without relying too much on human ingenuity, effort, and time. Call centers have done this well for a long time.

Good software developers, generally tasked at automating stuff, themselves routinely automate their own jobs. If you ask a good software developer to build an online website for people to buy and sell toys for pets, they will step back and realize that this is just another version of a 2-way marketplace like Amazon. They will build a generic program that can be used to create any kind of 2-way marketplace for buying and selling stuff. Later, when asked to build a website for people to discover and sell used cars, they only have to press a few buttons. A stark difference between software developers and the rest of information workers is that once developers have solved a particular problem, they can move on to solving others. Their jobs involve breaking complex problems down to smaller problems, solving these problems exactly once, and moving on. This is not true for the rest of us who are not software developers. We might keep solving the same problem over and over again and not look for a systematic solution because that is not part of our job description[1].

From the examples above, it might seem like even if we can break down our jobs into automatable components, we would need someone who can code to actually do the automation. But that is increasingly not true. With no code solutions becoming increasingly popular, a lot of the tools needed to execute and automation strategy are accessible to anyone who is willing to invest time to learn them. These tools which can read and reply to emails, schedule appointments based on availability, shortlist candidates by parsing their CVs, allocate budget optimally, generate reports with relevant data from verbal English queries, etc. are available and will inevitably get better and cheaper with time. It will also increasingly get easier for companies to use these tools without themselves hiring software engineers. However the “breaking down the job into tasks” part is an essential prerequisite. It needs intellectual humility and systematic thinking and does not need you to be, or hire a terrific software developer. Automation is a system design problem, not a technological problem. Technology determines how you could efficiently execute an automation strategy and at what cost. Sometimes the technology available is not good enough to execute the automation strategy in a reasonable way. But unless we do the work, we might not find out. And even if it does not work out, going through this intellectual exercise will give you a sense of what parts of your job are likely to be autoamted in the future and which parts really require human skill. This could change the way you approach your career and inform your choices on what skills to invest time in.

Another trap worth looking out for in your endeavor to automate your jobs is the quest to find the perfect solution. It is almost certain that any automated solution you come up with might at least initially not be able to perform as well as a human would. But it does not have to. As long as it does a passable job that does not get you fired, you have cut down on hours of your effort with little to no downside in your payoffs. You can use this extra time to build a business or taking a nap. In most jobs, the incremental payoff for employees to perform better than average is marginal and starts to plateau very soon. Automating your job could free up a substantial amount of your time and has a limited downside on your career prospects[1]. And if you are entrepreneurial, anything you can automate with even slightly below average human performance will still have a lot of buyers in the industry since an automated solution can be consistently below average at a much lower cost. Hence there is an incentive for everyone to learn how to automate their jobs regardless of their ambitions.

Although talks of automation have been recent, there have always been people who have been good at figuring out what can be automated and what cannot.The people who can actually break down their job into these chunks or repeatable, predictable actions can train other people to do the same without needing them to be especially skilled. And then they become bosses. They have essentially automated their jobs using hired labor. This is a kind of automation that has generated fortunes for people. Today, the payoff could be much higher because you just need to set up a few tools or write a few lines of code to achieve the same leverage.

[1] This might not be true at places where what really matters is the perceived value of your work rather than actual value or where actual value is not measurable/ not measured. Facetime and “hours put in” then become the metrics on which you payoffs are based. Those can sadly not be automated.