Category: Startups

Cross-Functional Squads

A few years ago, Spotify popularized the idea of organizing engineering teams into squads and guilds. This isn’t actually a new concept, it’s an old one given a new name; Amazon has been organizing development teams into two-pizza teams along the same principles at least as far back as the early 2000s. Organizational design is something that most engineering managers need to tackle with at various points in their careers.

When teams are small, they often index for hiring full-stack developers (i.e. jack-of-all trades developers). This often serves them well, especially considering when all they can afford is 2-3 developers. As teams grow, individuals tend to specialize. You’d be really hard pressed to find a developer that’s good at mobile, web, backend, distributed systems, devops, data engineering, systems engineering, etc. I’ve never actually met a developer that was actually excellent across all these engineering areas. I’ve met some that were fearless and willing to dive in and learn, but in most cases, they’re just average in the areas that aren’t their main areas of expertise.

The purpose of a cross-functional team is to outfit the team with the right tools to complete the job without the need to depend on outside help. The more a team needs to collaborate and coordinate externally the slower they get. Decoupling teams gives the team autonomy and the ability to own the situation.

Analogy time! Let’s take a basketball team, everyone on the team should be able to dribble, rebound and perform layups, these are basic skills. But individual players will have their areas of expertise, some will be excellent 3pt shooers, some excellent at posting-up under the net because of their size, and others great at play-making because of their speed/agility. A team with 5 centers in the starting lineup would likely be a pretty bad team, they’d be slow to move down the court, have their passes constantly intercepted, and balls stolen whenever they dribbled against a smaller more agile player. Each person on a team is filling a position, a good team is a team of complementary players that help each other be effective at what they do best.

We want developers that in a pinch could debug a web form or look at why an API is suddenly slow, this isn’t necessarily a full-stack developer, that’s just a willingness to do something when called upon, a lot of it just basic debugging skills and understanding of how software works. In a pinch, a center can shoot a 3-pointer, but you probably don’t want them to do that all the time; if you want your teams to be effective, get folks to focus on what they do best.

Thinking Distributed

The best analogy I can think of for how to think about scaling an organization to think distributed is the contrast between communism and capitalism methods of government.  Objectively speaking, one is not necessarily better than the other, but in practice one scales better in our current world.  

Communism is centralized command-and-control, it is a non-distributed organization.  In theory, if you had perfect knowledge and ability to react in real-time, there would be minimal waste and demands would always be met with the right amount of supply.  In practice, it hasn’t played out this way, probably because we don’t live in a world of perfect data and instantenous data processing abilities.  Capitalism in contrast, relies on that invisible hand, it argues that in efficient markets, supply-and-demand will balance itself through price discovery.  There might be some degree of loss in the beginning but it will come to an equilibrium fast and the overall oversupply or undersupply will be minimized.  

In capitalism, when the government wants people to spend money, they lower interest rates.  Instead of directing, they guide.  They create incentives for the market to move in the desired direction but they don’t direct.  In communism, there’s a required a feedback loop to central command so it can process the data and tell each type of producer the next steps.  This often leads to either over-production or under-production because it’s easy to have incomplete information or data processing delay. 

Leading a distributed organization is similar to working with monetary policy.   We want to create the right incentives, we want the default thing to be the obvious thing.  We want to build the necessary tools and safety-nets so that people can focus on their objectives and not worry about duplicating work.  We want teams to operate independently, instead of relying on upper-management (central-command) for next steps. 

Leadership cannot scale to have perfect knowledge of everything teams do, otherwise the leadership team ends up having massive reporting apparatus just to track work output and teams will end up idle waiting for the next instructions. Instead leadership needs to empower teams to want to act in their own best interests because those interests.  Leadership can guide teams by helping them clearly define KPIs, but how they go about achieving those KPIs should be left in their hands, doing anything differently will only disempower.  

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…

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.

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.