Making bad decisions under-stress

Sometimes people get stressed out about their job and want to quit. The stress is real and can consume their waking thoughts and keep them up at night. That lack of recuperation is as a death spiral, their body and minds don’t rest and they end up in an even more stressed state. In most cases, when in this state of mind they probably don’t even end up doing their best work.

Many are able to realize that it’s hurting their ability to function, either socially or professionally. They snap at their colleagues and family. They know it isn’t healthy, they want it to just stop. They might give off hints that they’re stressed, ask for less responsibility, start getting sick. In the end, they usually submit a resignation.

Making a decision to resign is a cry for help. To a manager, it definitely raises the alarm bells, especially if you believe that person to be worth saving.

As a leader, I try to help them see a bigger picture, take a step back from the ledge and see there are other options available to them, usually options that I can offer to them that they might have thought impossible. A sabbatical, a change of team, a different working arrangement, additional resources, etc. Offering additional compensation is not the solution, it will not solve the cause of the work-related stress. I usually present a few options, tell them to take a weekend or an evening to think things over. Sometimes taking in the options to consider can be stressful too. Ask them, if working at the company is something they still want and if so, in what capacity. If they come back and they still insist on resigning, it’s probably something else.

Understand that people in stressed-out states usually only see a limited set of outs, they put it all on themselves, work harder, longer or quit. They become hyper-focused but myopically so, seeing the wider gamut of options is difficult, as a leader, we can help them see this and that it’s solvable.

It doesn’t scale

“It doesn’t scale” is something I say often. How do we know something doesn’t scale? Software and organizations are systems; systems have inputs and create outputs. The amount of output in relation to the inputs gives an idea of the throughput of the system. It’s not necessary to get super scientific or mathematical about this, just understand the thought process. If we increase one of the input variables and the system can’t keep up, this is a failure to scale.

It’s the role of a manager/operator to understand the bottlenecks in a system and devise solutions and to have the foresight to plan for addressing future scaling bottlenecks.

A simple exercise is taking each of the input variables and increase each individually by the next order of magnitude (e.g. 10x customers, 10x the page requests, or 10x transactions, etc), then work out what would happen to the system. Then identify the parts of the system that would need to compensate for the increase in input and determine if the compensation is linear.

Parts of the system that scales linearly in relation to the inputs are the constraints of the system. Perhaps, your input is “customers” and you discover that scaling customers requires a corresponding linear increase in employees (e.g. each customer requires 5 additional staff). If you want to 10x the number of customers it would require a corresponding 10x increase in employees. To illustrate why this is not a good relationship, let’s assume you have 10 customers and 50 employees. Would you be able to hire an additional 500 employees to support 100 customers? Maybe you could, but what’s the lead time to that, what systems and processes would you need to put in place for that to happen? Growing from 50 employees to 550 employees is fraught with problems you have never encountered before. That’s for you to determine if it’s reasonable, or if there’s a better solution.

Solving for bottlenecks involves understanding the fundamental relationship between parts of the system. Merely doing something faster may not yield the increase in output desired. I often seek leverage, leverage occurs when effort has a multiplier effect on the output.

Bespoke things generally do not scale, but if those bespoke things can have leverage then there’s a multiplier effect. Let’s take a tailor on Saville Road, a tailor that creates bespoke suits might produce a product of very high quality, but it relies on his singular skill to design a suit for that client. It requires hands-on measuring, fitting and re-fittings. The only way they can grow their business is either by charging more for his services or by working longer hours, this has limits and is a real-world bottleneck. Technology has always provided avenues to solve bottlenecks, it can help decouple parts of the process, introduce parallelism, or automation. As an exercise, think of how you might scale this business. Determine what you trying to solve for and what are you willing to compromise on to get a result that meets those objectives.

Becoming a leader

Being a leader is a lot different than being a manager.  A manager is an operator, they follow processes and are expected to produce the desired output.  

A leader is not necessarily a manager.  Individual contributors can be great leaders.  Leaders are people who have strong values, exemplify those values, attract a following or inspire others to do the same.  People work for a manager because they are expected to.  People follow a leader because they want to. 

Leaders are inspirational people, have a vision, the will and ability to make it happen.  Of course, they can’t do it alone.  In a casual conversation, Mike Katchen mentioned to his friend that I got a slew of people at the office to start doing HIIT workouts and intermittent fasting.  His friend noted, “you’re like a cult-leader!” I chuckled and replied, “being a CTO is kind-of-like a cult-leader, but it’s also good for them”.  Post, I realized there’s some truth to his statement, people follow because they want to, I didn’t have to force them to.  

We live in an inter-subjective world.  Values are what we as individuals deem to be valuable.  As a leader, we create a narrative around why we value a way of doing things, why something is worth doing, and communicating potential benefits in the far-off distance.  We don’t have all the solutions.  As a leader, we want others to be inspired by our vision, follow us and come up with solutions that aid in achieving our vision.

As a technical leader, we live in a world where there’s endless chaos, no matter where we look there’s the opportunity for things to be better.  The most important aspect of being a strong leader is to acknowledge this chaos, embrace it and provide a vision and plan for how to achieve the end-goal.  I remember a quote from Bruce Lee, “A goal is not always meant to be reached, it often serves simply as something to aim at.”

Running an Interview Debrief

The art of running an interview debrief is a skill in mediation, time-management and quick decision making.  My interviewing experience comes from being a bar-raiser at Amazon and from Who (Geoff Smart).

Learning to control all the egos in the room is the initial challenge.  A negative or loud voice can drown out the group and derail the entire debrief.  There’s a lot of competing psychological biases at play that you need to keep in check.  At times, you might feel like you’ll never hire anyone because of the cynicism, hypothesis, or conjecture.  The safest choice is to err on the side of caution, decline to hire instead of making a bad hire, but if this happens all the time you’ll never build a team and your frustration will only mount.

Ideally, you are the hiring manager or someone who has hire/no-hire veto power, like a bar-raiser.  The two roles seem diametrically opposed but really they’re more alike than you think.  A bad hire is a pretty bad headache for a hiring manager.  There’s really only three questions you need each interviewer to answer and one that you need to answer for yourself.

Each person in the interview loop should be assigned a different competency beforehand, therefore they should only speak to what they observed around that competency.  For each question, go through the entire group before moving to the next question:

  1. List the things that you admire about the candidate
  2. List the ways in which this person will make your team better
  3. List the circumstances needed for this person to be successful in this role

You’ll get differing opinions, some factual observations and some subjective opinions.  Keep them as objective as possible.  Ask for clarification if you need to understand better some observations or opinions.   If people go off on tangents, remind them to just list things relevant to the question at hand.  After collecting all this information, you now need to make a decision.

Geoff Smart defines an A-Player as a candidate that has at least a 90% of achieving the expected outcomes that only the top 10% of candidates could achieve.  If it’s clear this candidate doesn’t meet the competencies needed to achieve the expected outcomes, pass.

  • If you don’t have anything you admire about the candidate, pass. 
  • If this individual doesn’t make the team better by filling in the missing skills or experience gaps on your team, pass.  
  • If the circumstances needed for this person to be successful in the role do not exist on the team, pass.  Without the right circumstances in place, they will not have a 90% chance of achieving the expected outcomes.

You do not need 100% on everything to make a hire decision.  On the basketball court, if you have a slam-dunk opportunity, of course, take it.  Running a great hiring debrief and hiring the right person for the role is not always about slam-dunks but identifying high-percentage shots and when to take them.  That’s it.

The road you leave behind

The other day I updated my LinkedIn profile.  Many people congratulated me on my promotion to CTO.  The most interesting one was from someone who ended up doing the job I last had before I left Amazon.  I decided to reach out and see if he wanted to have a coffee.  I was curious how things were going.

I used to manage the software dev teams responsible for sortation systems across all of Amazon’s warehouses.  This problem space was operationally intense, the software had to be highly available and robust.  If these systems went down or misrouted packages, they affected a fulfillment center’s ability to meet throughput SLAs.  In operations, this is a big deal.

I wasn’t sure what to really expect.  Turns out he’s a super nice guy; he recently left the role for another within Amazon Fulfillment.  I was surprised, the first thing he did was thank me.  He thanked me for all the wikis and blogs that I wrote when I was on the job.  All this documentation really helped him understand the space, the evolution of the systems, how to actually do the job and the challenges he would face.  This got me thinking, I should start blogging again!

It also got me thinking about how important it is for startups to document processes.  At Wealthsimple we have a decent culture of documenting in Quip, but it’s not 100% universal.  I recently lost my sole technical recruiter.  To be honest, I wasn’t entirely familiar with the end-to-end workflow around how we used our third-party recruiting software.  I noticed many different teams were using it differently, inconsistency drives me a little crazy.  When I asked around if there was any documentation on the official HR process, I got blank stares.  Turns out there wasn’t any!

There’s no time like the present.  I sat down with one of my colleagues to use the software through the most common use-cases.  Along the way, we identified any potential process bottlenecks.  He then spent time with one of our recruiters to refine and document the process.

Documentation is the road you leave behind.  It’s also a high-leverage task.  Once written, it keeps on giving each time a new person reads it and it’s low maintenance.  If the reader finds a mistake, they’ll correct it.  It’s important to document so other’s don’t have to guess, rediscover or reinvent.  Someday, they might even thank you.