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.”

Hiring a technical leader

One of the most challenging things for startups is hiring a really great technical leader. 

Early-stage tech companies that don’t have a technical founder are often pressured by investors to land this crucial hire.  Investors know that hiring this individual is like finding and capturing a proverbial unicorn; they’ve seen this play out across numerous companies.

A great tech leader will guide the team in terms of architecture, operations, engineering practices, employee growth, retention, etc.  All these things allow for the product and company to grow and scale.  This person is generally well-respected within the engineering community, this, in turn, attracts top talent to the company. 

They are rare because there are several forces at play. In years past, technical leaders at startups typically spent a few years in software development or middle-management at large tech companies and decided to seek out the startup life.  The last few years have been really good to large tech.  Their middle-management and senior engineering talent have been rewarded handsomely, usually not enough to retire, but enough that they’ve grown complacent.

Someone who’s spent considerable time at Amazon, Google, Netflix, Facebook, etc have likely gotten used to their internal tools, the support infrastructure, their peculiar ways of doing things and that work-life balance.  When one finds themselves outside that ecosystem, they can suddenly feel lost at sea.  Some may even feel entitled and not willing to do things they feel are beneath them.  What they don’t realize is how good they had it, many of the problems were already solved for them years ago at these companies.  They are cogs in a machine.  They are just expected to operate.  Life is very different at startups. 

Startups the past few years have also been doing quite well.  Some are startups only in name (Uber, AirBnB, etc).  These people aren’t likely going to leave a rocket ship or don’t really want to rough it out again, they’re waiting for their payday.  The rate of new startups being created has actually slowed down in past years, of course, many have failed.  Developers and engineering leaders find it a lot less risky (and lucrative enough) to join an established company. There are many engineering leaders that have failed, the really great ones that can execute and build engineering teams are an elite few.  This makes for a very tight talent pool for experienced senior technical leadership.  

Many teams make the mistake of not hiring this individual and they make lots of engineering mistakes, eventually, they fail to execute.  You can’t expect a developer with 2-3 years experience to fill this role, without years of making mistakes and mentoring.  Technology is a very expensive place to make mistakes.  Many startups have mountains of technical debt, monolithic codebases and no rational plan or experience for managing it.  Investors push founders to hire someone with pedigree (i.e. has a big name on their resume) because it’ll make other investors at ease that they have someone experienced at the helm, but often this person is not the right person for the all the aforementioned reasons. 

Finding this talent is hard. When they do, startups should be prepared to pay for it in cash and equity.  If you’re early stage and cash-strapped, perhaps tie create a year-end bonus correlated to company metrics.

In any case, good luck!

Lack of meeting rooms

At Wealthsimple’s Toronto office we have a serious lack of meeting rooms.  We have 2 large rooms that can accommodate up to 20 people.  Four smaller meeting rooms that are good up to 6 people and then four cabins which are only good for 2 people.  We have about 170 people at our Toronto office.  The ratio is not good.  

Needless to say, we have a supply & demand problem when it comes to meeting rooms.  1-on-1 meetings became walks in the park.  Sometimes people use the stairway to conduct meetings.  I’ve even once sat in the accessibility bathroom to do a video call.  Eventually, I had to explain why there was toilet sounds every so often interrupting the call. 

Let me say, tough times, tough times…

Jetlagged

It’s been a few years since I’ve been to Asia.  I’ve never handled jetlag well, when I go to the west coast, I don’t bother switching time zones, I just wake up at 4:30am every day and go to bed at 8pm. 

I recently got back from Hong Kong on a Sunday evening and went to work the next day.  First day back at the office was fine, but the rest of the week was beyond horrible.  I powered through and stayed up till 11pm but I’d wake up at 3am and find myself unable to sleep and eventually giving up hope.  I took short power naps in the office to get through the rest of the day, but also slept through a meeting.

By Friday, I finally had a good night’s rest.  But that night I stayed out late, woke up early the next day.  By 1pm I couldn’t stay awake anymore, so I figured I’d take a short nap but then didn’t wake up till 8pm.  Now I’m re-living my week of jet lag hell all over again.  

Technical Debt

Technical debt shares many similar characteristics to financial debt.  Financial debt can be responsible; borrowing money responsibily can enable individuals and companies to achieve their goals (e.g. home ownership, transportation mobility, education, mergers, equipment purchase, etc). Typically, financial debt is often slowly paid off, amortized, consolidated, rolled over, or paid down in lump sums.  As long as the financial debt can be serviced without undue hardship to cash flow and provides a positive cost-benefit utility, the debt is deemed being used responsibly.  Financial debt can be debilitating, unpaid balances with high interest rates can quickly pile on more debt.  For many people, financial literacy is low and understanding the nature of debt and managing it effectively is often confounded with emotion and stigma.

Technical debt provides utility.  Let’s remember that software is a means to an end to help achieve a business need or accomplish a task at hand.  As a technical leader, it is important to frame technical debt and understand how you will service it and how it is serving you.  You can pay down the technical debt slowly, each time you’re in that area of code, make it a little better than before.  You can choose to consolidate it and pay it off in a lump sum either by writing a new service or bypassing it strategically.  No matter what the strategy is, you need to be crisp on the plan and the communication around it.  

It’s important to remind ourselves, there’s no perfect piece of software.  We’re always making tradeoffs and these tradeoffs are okay.  What’s great software today is tomorrow’s legacy software.  Learning how to frame, manage and accept technical debt as a means to an end will give you leverage and productivity as you grow.

Amazon HQ2

The Toronto tech scene is hot.  Last year, more tech jobs were created in Toronto than San Francisco, Seattle, and NYC combined.  By making Amazon’s HQ2 shortlist, Amazon essentially vetted Toronto as a great tech hub.  Amazon saved all these companies thousands of hours of research, cities put pitch decks together for all to see, and now tech companies are moving in fast.

In the past few months, Bay Area startup heavyweights and big tech-behemoths have announced they’ll be recruiting large engineering teams in Toronto. Uber announced they’re investing $200M to build an engineering hub in Toronto.  Microsoft announced they’re moving their Canadian HQ to Toronto. If Toronto becomes the site for HQ2, we should rename Toronto to Seattle2.  Amazon already has over 700 tech employees in Toronto working on Alexa, Supply Chain, and Fulfillment systems.  Their footprint here is already sizeable.  The Bay Area heavyweights are all talking about building 200+ person engineering teams in Toronto.  

This will have both positive and negative effects for sure.  It’s going to drive up the cost of talent, poaching talent away from promising startups to join more established companies.  I honestly believe that life as a software developer is vastly different at Amazon vs a startup.  But companies like Amazon and the more established startups serve an important part of this ecosystem, they are finishing schools for new grad talent.  I’m convinced after they’ve worked a few years in a big-tech company, they’ll itch to join a startup and have more impact.  

In the short term, the biggest losers will be early-stage startups that are trying to find product-market fit and have limited funding because the loss of talent will be felt most acutely. Time will tell, but I believe these developments are good for Toronto, but there will be growing pains.

How my brain works

My fiancé complains I never remember anything that she tells me, like the friends she’s meeting, where she’s going, important dates, errands I need to run, etc.  Sometimes I honestly don’t even recall ever hearing it, but most of the time I’ve legitimately forgotten.  I can’t remember, not because I don’t care, but because I actually can’t remember.  I never argue; I’m actually a pretty forgetful person.

I can’t remember how many times I’ve misplaced my keys, wallet or even wandered into a room and had no idea why I was there.  I’ve lost countless pairs of gloves, shown up at an airport without my passport, left my wallet on a plane and my Kindle on a train.  I used to get frustrated looking for things, but now I’ve grown more accepting that I’m just forgetful.  As far as I can remember, I’ve always been like this.  My memory sometimes eludes me in the silliest situations, so I rely on routines.

I could never really learn to read Chinese no matter how hard I tried and wanted to.  In fight-or-flight moments, I can force my memory to serve me on exams, but a week later I won’t be able to recall any questions or the material.  I can’t really remember streets or names of people very well either.

I rely a lot on first principles and tend to reason out things.  I rely on my calendar instead of my memory.  I rely on knowing how to find an answer instead of memorizing answers.  The most important or urgent things always rise to top-of-mind and the less important things usually sink lower.  I think my lack of memory actually helps me compartmentalize and prioritize information.    I know that if a task is important and quick, I do it right away otherwise it might never get done.  I’ve learned how my memory works and learned to cope.

I believe this lack of memory has had some really interesting effects on my personality.  I don’t get too attached to ideas, I’m willing to re-evaluate with the new information at hand, sometimes this manifests itself as being right a lot or forces me to be pragmatic instead of stubbornly hard-headed.   Since I know I’m forgetful, I’m also very understanding of others, especially they forget.  It also means I treat things with high urgency if deemed important, otherwise I might forget to do it!   

At this point, I’ve stopped fretting and I’ve grown to look past the problems associated with my forgetfulness and appreciate the positive benefits it’s had on me.  Honestly, I forget if I ever had a good memory, to begin with.  

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.