Void

Startup Hiring

Hiring is an area which is usually given a lot of lip service but neglected in practice. Especially in a startup, where there is a shortage of workforce, hiring at all levels has a profound impact on the future of the organization. When compared to a big organization, the value proposition of a startup to its employees is concerning speed, freedom, and responsibility. But, when it comes to hiring, startups adopt the cookie cutter hiring strategy of big companies.

The regular interview process is biased toward extroverts and people who can speak well. In my opinion and observation, this does not correlate to someone who is good at what she does. I have been observing this since my college days. During campus placements, flamboyant and boisterous students made their way into companies while the quiet ones who were good at studies and who could get along with others were often overlooked. The same thing happens to a lesser extent with the regular interview process too.

Taleb says the following of doers.

For those who do things, it is harder to talk about what they do. Reality doesn’t care about talk. It is full of pauses and hesitations. Clear, non-hesitant speech is the domain of non-doers.

Interviewing is an intimidating experience, and not a lot of people excel in this, especially people who are good at what they do. Also, the kind of questions that are asked during an interview has hardly any resemblance to the day to day work. I have written about this before too. A big step in this direction is to craft an interview process that mimics your organization’s day to day tasks. The best way to do this is to have an assignment based interview process. You can create assignments that resemble tasks that you do on a daily basis and ask candidates to work their way through this. An approach of this sort takes the whole adversarial, and interrogative tone out of interviews and makes it an enjoyable experience.

An important aspect to take care while creating an interview process is to take subjectivity out of interviews. Who conducts the interview should not have a bearing on the outcome of the interview. Another thing to keep in mind is to subject all candidates of a particular level to the same questions. Following the above ensures that you are evaluating every candidate on the same yardstick. It is essential to do this to create a quantitative interview process. This sort of standardization also helps in creating a checklist of what you expect in answers to questions. If you have these covered, anyone can take anyone’s interview and evaluate candidates. Is it not ironic that startups claim to be data-driven, but when it comes to interviews, the whole data-driven approach takes a corner seat.

hiring-3531130_640

An example interview template would be to have an assignment that closely resembles a task related to work. Try to keep the assignment practical yet straightforward. A good candidate should not take more than 3 to 4 hours to complete the assignment. On submission; evaluate the assignment on code quality, conventions, comments, instructions to run, test cases, boundary condition handling, error handling, and documentation. Post that, have a phone screen with a bunch of questions that mostly have a one-word answer. Make this as practical and broad as possible. Try to touch all aspects of work from data structure choices to computational complexity to databases, web servers, etc. The idea here is that if someone is good at what they do, they should be able to answer these without any preparation. Then invite the candidate for face to face round where you ask the candidate to expand on the take-home assignment. Add a bit more complexity and see how the candidate fares. Finish off the entire process with a design round. I have presented a very rough template, tweak it, add more rounds and improvise to fit your needs; every organization is different.

Along with all the above, soft skills are critical. The sad fact is a lot of people do not know how to conduct interviews. I have heard of instances where interviewers were rude and outright obnoxious, not punctual, candidates not kept informed in advance of the interview schedule, candidates not being adequately attended during the face to face rounds, etc. All these play a significant role in shaping the image of the organization in the candidate’s mind.

In the talent market, big companies, as well as startups, are competing for the same piece of the pie. By adopting a hiring process similar to big companies, startups are not going to get an ace up their shoulder. What startups should be focussing on is coming up with a flexible hiring process that is unique to their organization. It is not easy to execute this in a big corporation but very much doable in a startup. Starting from how you engage with a candidate for the first time to the interview to the offer rollout process, everything is ripe for disruption. Differentiate yourself from others. An interview is a big opportunity for you to make a mark on the candidate, seize it right there.

Deviation From Expected

Someone sitting at a distance asks for the water bottle near me. I pick up the bottle and throw it at that person. Surprisingly, the cap is not screwed. Water splashes all over. When a bottle has its cap on, we usually expect it to be tightly screwed. When something deviates from the expected, unless there is an indication saying so, it creates trouble and confusion.

arrows-1834859_640

The same principle applies to systems and application design. For example, let us say that you have a development server where someone is running a production cron job. Since this is a development server, someone might take it down for experimentation. No one expects the non-availability of a development server to have untoward consequence.

Whenever you deviate from the expected, ensure you scream from the top of your voice so that no one misses it. Documentation, common conventions and putting in the right processes are some of the ways to mitigate this. The best is not to do it. Whatever you are doing, it always helps to ask, is this a deviation from the expected? If I am not part of the inner circle, would I expect it to be like this?

New Feature Efficacy

You have an established product, and you introduce a radically new/different feature. You are very enthusiastic, but the metrics show users are hardly using this.

There could be two reasons:
1. Users do not see a value.
2. Could be resistance to newness.

sparkler-839831_640

 

It is essential to zero in on the above to decide whether to put in more effort into the feature. If this is indeed resistance to newness, there might be multiple ways to nudge your users towards the feature gently.

A straightforward way to figure this out is to measure the stickiness of the feature. Of the small percentage of your users who do interact with the features, how many of them come back to it subsequently, i.e. once people are acquainted with the feature, do they come back to it later? If you see stickiness in this cohort, it is a good indicator that the feature is of value, you are doing a lousy job in educating your users and leading them to it. If not, it is time to cull the feature and invest that time and energy in something else.

Resolving Disagreements

When you disagree with something, either you do it because you think your idea is better or you want to keep your ego intact. Let us ignore the latter and focus on the former where the intention is to let the best idea win. When a group of people sit down and try to resolve disagreements, many a time, it goes nowhere. Sometimes you get this strange feeling of things going around in a circle. This is due to whataboutery and shifting goal posts. You start with an objective, as the discussion progresses, statements lead to counter statements and at the end, no one knows what they are trying to resolve.

antagonism-1940188_640

A straightforward hack to keep discussions on track is to write things down. Project a shared document where you note the objective and the point of contention. Whenever matters go awry, point people to the shared document; this helps everyone involved to stay focused and not to shift goal post as the discussion progresses.

Irrespective of how rational and mature one is, when someone disagrees with something that one believes to be true, one tends to become defensive and shift goal post without truly being aware of it. Writing things down makes one aware of this and helps course correct.

My View

I was looking at Jimi wallets online. Someone peeked at my laptop and asked what it is? I explained it is a rugged waterproof wallet. The other person’s immediate reaction was – Why would anyone need this? This person has never faced the fury of rain while cycling outside.

paint-2985569_640

Whenever I explain startups spending marketing dollars to acquire users even when they are not generating any profit, I get a stunned look from people coming from a traditional business background. It is difficult for them to grasp the concept of betting on explosive future growth at the expense of today.

Phil Knight, in his book Shoe Dog, writes a lot about how his bank was asking him to preserve capital when all he wanted to do was grow Nike at all costs during its fledgling years.

A lot of prolific US citizens opinionated that Trump had a naught chance at US presidency. The same goes for Brexit.

What is common in all these situations is a difficulty in viewing the world from a lens not tarred by our own experiences. Even if you want to do this, it is tough to implement because you do not know where to draw the line. Tomorrow, if a person tells you that she has invented the perpetual motion machine, what do you do? Do you dismiss it outright or be skeptical of this person’s claim?

In all these scenarios you have to suspend your rational mind and view things from a radically incongruent perspective. It is easy to write this but extremely difficult to implement.

Ingratitude

Zoho’s domain was inaccessible for a while. This is an embarrassing event for a software organization.

Whenever I hear of events like this, I am reminded of a couple of pages in “The Black Swan“. Taleb calls it “A new kind of ingratitude”.

The idea presented by Taleb essentially boils down to a person who takes steps to prevent something catastrophic from happening. Since that person has taken steps to prevent the catastrophe, the catastrophe never occurs. Thus the person never gets his due and dies a silent hero.

 

This is a very fascinating thought that keeps repeating in all aspects of life. Whenever it floods, we make a big deal of politicians who fold their sleeves and get into action. What about that politician who took the necessary steps to prevent flooding?

Whenever there is a production issue at work and a team goes out of their way to put out the fire, that team is lauded. What about those teams that took steps to prevent something like this from occurring in the first place?

Software security is one big area that falls in this category. If you have a great security team, life would go on humming silently. You need to have the right tech leadership to recognize this otherwise it falls bang into ingratitude category.

This is a very obvious thought but Taleb has done a great job of giving structure to this idea. If you keep your eyes open, you see this happening around you all the time.

Micro Versus Macro Solutions

Imagine a person who walks from her home to office. Frequently she is late to work as she takes time to cover the distance. She wants to improve her pace. She goes to a walking expert to get tips on increasing her walking speed.

thought-2123970_640

One solution to the problem is to use some other means of transportation instead of walking. If you go to a walking expert, you are going to get tips on improving your walking speed. The expert is not going to ask you to forego walking and use a different mode of transportation. Also, if you are deeply attached to the idea of walking, you might not think of a solution beyond walking. Improving your walking speed is a micro solution whereas using some other means of transportation is a macro solution.

The above is a contrived example but something we come across in our professional and personal lives, both as solution givers as well as ones facing a problem. Programmers sometimes try to optimize the hell out of a piece of code while the right approach might be to chuck the code and use something else. Organisations seek to nail down a process to the last mile while a sensible solution might be to do away with the process entirely.

We lean towards micro solutions when we are either deeply entwined in a problem or are the domain expert in that particular area. In these situations, we tend to think within the bounds of a problem and not outside.

When you come up with a solution, bracket it as micro or macro. Being aware is the first step towards becoming better at anything. Also, an outside view helps. Find someone who is not an expert in the domain or one who is not acutely aware of the problem. Run your solution through them. They might lead you to a macro solution or make you aware that what you have is a micro solution. Taking time and mind off a problem helps too like how Archimedes had his eureka moment.

Last but not the least, take a walk.

Ode To Queues

If you have a producer with an uneven rate of production and a consumer which cannot keep pace with the producer at its peak, use a queue.

If you have a workload which need not be addressed synchronously, use a queue.

If your customer-facing application is riddled with workloads which can be deferred, move these to a queue thus making the customer-facing application lean and mean.

duck-3217049_640

Think of a queue as a shock absorber.

There are workloads which need to be processed immediately with sub-millisecond latency, and then there are ones where you have the luxury of taking time. It is advisable not to mix these in an application. The second kind of workload can be addressed by moving it to a queue and having a consumer process them.

For example, consider a scenario where you are consuming messages and persisting them in a data store. These messages are coming in at a variable rate, and at its peak, the data store cannot handle the load. You have two options. Scale the data store to meet the peak load or slap a queue in between to absorb the shock. Queue solves this problem in a KISS manner.

Queues enable applications to be highly available while giving enough room to maneuver. As long as the queue is highly available, the chance of message loss is almost nil. Since a queue is durable, you need not perfect your consumer’s high availability; you get leeway to manage.

With applications embracing microservices paradigm, there is a lot of API back and forth. Not all API consumption has to be in real-time. Whatever can be deferred should use a queue as the transport mechanism.

Queue introduces a bit more complexity into an application but the advantage it brings to the table makes it a worthwhile investment.

Process Introduction

Whenever a new process is introduced, there is always going to be some discomfort. The cause can be categorized into:
1. Uneasiness due to newness.
2. There is a problem with the process itself.

idea-1876658_640

Category one is due to human nature. Deviation from an established routine causes queasiness and a yearning for the old way. It takes over-communication, repetition and sometimes “just giving it time” to tide over this initial phase; this is usually a short-lived phenomenon.

Category two is the troublesome one. When someone complains about a newly introduced process, it is essential to get to the source of this discomfort. Prod as to whether the reason for disapproval falls into category one or two.

A suitable process has to roughly follow the Libertarian Paternalism idea popularised by Behavioural Economist Richard Thaler. The process should be a nudge towards better behavior rather than a dictatorial dictum. A process whose intention is to police people does not end up well.

A new process introduces some amount of friction, but this friction has to be local, not global. This friction should not slow down the task at a global level; instead, it should aid speed, agility, and stability.

Take the checklist process as an example. It nudges people towards being more aware and aids better behavior. It does introduce friction at the local level, but on the whole, globally, the task speeds up with a much better result on an average.

It always helps to think along these lines to figure out whether a new process is worth its salt. Instead of introducing a new process and then reneging, put in the effort to evaluate the efficacy of a process beforehand.

Checklist

Checklists have been in vogue for quite some time now. Probably Atul Gawde’s book The Checklist Manifesto kickstarted this. I have been late to the party but once I arrived, I never left. A checklist is an amazing tool to organize personal as well as professional life.

checklist-1266989_640

 

Hospitals have figured out that by following simple checklists they can reduce the surgical mortality rate by a big percentage. The airline industry, which is an epitome of the highest possible standard in safety and training, relies on checklists for fail-safeness.

Who does not forget daily chores? Who has not kicked themselves for being late on bill payments? A to-do list solves this problem. There are tons of to-do apps out there, just pick one to start with. Apart from solving daily trivial problems, a checklist is a great way to keep track of long-term goals too, be it saving more, losing weight or adopting a healthier lifestyle.

Professional life requires one to regularly follow-up. A checklist is a great way to list down the follow-ups needed. On the flip side, no one likes doing follow-ups. If you want to be one of those rare people who respond without requiring to follow up, use a timebound to-do app to keep track.

Checklist brings efficiency to project management. Having a checklist of all the tasks to be accomplished before taking a project live leaves little room for ambiguity, misses and last minute scurrying.

A short-term or throw away project may not justify the time spent in automating disparate tasks related to the project. In this scenario, a checklist is a great substitute.

automation

All organizations have an onboarding process. Make a checklist out of it and hand it over to employees on the day of joining. All software projects have some common alerts and metrics needed. Checklist them. Once you do this, you do not have to bother about this for every new project. View checklist as a temporary substitute while you scout for software to automate these.

In short, a checklist can be used as a Swiss Army knife to organize and automate life. A checklist institutes repeatability eliminates ambiguity and improves efficiency.

PS: Link for the above comic from XKCD.