Building a small team

When starting a new venture, your team is often small due to timing, budget, or uncertainty. Growing a team from a small starting point takes careful thought about both the current needs and the future. When only a handful of people are on the team, each hire has a dramatic increase in the communication costs and cognitive load of relationships. There is a combinatorial jump as N goes from 2 through 6 that is unavoidable.

Photo by Wolfgang Hasselmann on Unsplash

On a small team, each member has to cover a wider spectrum of topics, even if the depth of understanding or time commitment of each topic is small. Someone needs to do all the little administrative tasks but they do not all sum to an amount of work that represents a full position. And that is often the case for many other topics. You do not need specialists yet.

But the software and technology industry is geared towards specialists. The cynic would say it is because it is easier to put people into a box with a label and disregard the other skills someone has. I think it is simply the nature of a tech industry culture dominated by huge players that are assembling large teams that are looking for very specific specialized roles. Those companies’ influence sets the tone of the discussion. When someone might get a job at a 10,000 person company or a 100 person company, which framing are they going to gravitate towards for themselves? It seems the gravitational pull of the big players wins out.

So building a small team is difficult. It is intrinsically difficult to do, and the hiring marketplace is slanted against giving you the information you need.

My advice, and the techniques I use follow.

First, I do my best to look for self-described generalists. If someone is sticking their neck out enough to go against the prevailing demand, chances are they’ve really thought about it. They tend to be well-rounded engineers and designers with a pragmatic view towards getting the job done.

Second, I talk to folks to get an idea of how flexible they are. Are they dogmatic? Do they know how and when to compromise? Have they worked in diverse teams of people with different backgrounds and goals? These are all signs that when something unexpected needs to be dealt with, they’ll be okay stepping up to the plate.

Third, I try to understand how everyone’s paths on the team will interleave and harmonize in the mid-future. What this time frame constitutes is highly dependent on the context, but what I mean is the period between “here is all the stuff we need to do now” and “here is all the stuff we’ll do one day”. When will you need a UX Engineer? When will you need a Usability Facilitator? As dedicated people fulfilling just that role, you will need them “one day”. Right now they might need just half a day each week. How is the role going to be filled by the various members of the team as the amount of work changes? It’s a multi variable optimization problem whose solution changes over time and suffers from unexpected shock events and step functions. Your goal is to keep your heuristic hat on and correct course as needed. This might involve hiring, but hiring is probably way too slow. You’ll need to know your team and who has the interest and ability to pick up something outside their wheelhouse.

You can see that the underlying theme is open and clear communication amongst team members, and that is my single point of advice. Stay in touch with the team – not simply hearing them but actually listening to what they’re saying and what is being left unsaid. Encourage constructive and celebratory feedback as a norm. Set up weekly 1-on-1s to understand where people are and what challenges they’re facing, not what work they’ve done. Create a space for discussion and have regular retrospectives so issues and concerns can be brought up, addressed, and reflected upon. Strive to establish a culture of psychological safety.

Building a small team often goes hand and hand with starting something new: a new project, a new feature, or even an entirely new company. Those are hard contexts for any sized team. But with open and honest communication you can deliver and succeed.

Good luck out there!

Book recommendation: Cathedral, Forge, and Waterwheel by Frances & Joseph Gies

If you’re interested in know “How did we get here?” then I highly recommend Cathedral, Forge, and Waterwheel by Frances and Joseph Gies. It dispels the myth that Europe of 500 – 1500 CE was some mud-filled backwater just waiting for some brilliant Renaissance thinkers to come along.

The cover of my copy

Don’t get me wrong – it wasn’t a glorious time either. But CF&W explains the development of specific technologies and how they changed society in a way that led directly to the (more celebrated) events of the Renaissance.

Probably one of the most important developments was of a merchant class as a center of power that could rival dynastic royalty. These developed into guilds and families that were patrons of those famed Renaissance artists as much as royal and religious wealth.

It also marked some of the first mechanical industry due to the shift of a source of power not dependent on animals (or people).

Is that person making a glass vase or jamming a wicked trumpet solo? Who can say?

The history of technology as recorded by Western historians is usually Euro-centric and that does leave out the larger context of how knowledge was flowing from Asia and Africa. It’s been a while since I’ve read CF&W, but I recall it doing a good job talking about how the origins of many things came from outside Europe. (And the back cover says so too, so I’m probably remembering right.) As you read any history, it’s worth keeping in mind the bias and agenda of the authors.

It’s an approachable and interesting read about a time you might not know a whole lot about. It looks like ThriftBooks has it, too.