#13: Hiring for “lightning-bolt” mentality ⚡️🧠
Reviewing customer segments as an investor would assess their portfolio, being intentional about leading asynchronous teams, and the particular builder’s rigour to spot in early engg. hires.
Hi there,
Welcome to the thirteenth edition of The Baton. A fortnightly newsletter that brings you three, hand-curated pieces of advice drawn from the thoughtful founder-to-founder exchanges and interviews taking place on Relay and the interwebz. So, stay tuned!
In this edition, you’ll find instructive and inspiring pickings from the brains of Geocodio’s Michele Hansen, Chameleon’s Pulkit Agrawal, and Blissfully’s Aaron White.
#1. Michele Hansen, co-founder of Geocodio, on a tedious yet much-loved, semi-annual, investor-like analysis she runs on customers, which constantly proves indispensable in weighing up market risks. (Source: Software Social)
So basically, I look at our customers, as a portfolio, as an investor might look at, say, a mutual fund portfolio, for example. And I split it on a couple of different metrics. So I basically take the top 90% of revenue, and I look at the customers from it within that space. And I look at them by industry. So there's like Fleet Management, but also say Real Estate or Insurance, Healthcare, things like that.
By industry, I try to get a rough sense for company size. So that I can just kind of, you know, have a little bit more understanding there.
And then just really trying to understand, okay, based on these different industries, like how much of our revenue is dependent on anyone given industry, and should we think about diversifying whether we want a you know, a higher percentage of revenue in a particular category, we want new customers there, or do we want to purposefully pull back from a certain industry or simply just not emphasize it as much if we feel like there’s too high of a concentration there.
And also making sure that we don’t have any high customer concentration or anyone given customer, so something an important metric for me is, you know, what are our largest customers, what percentage of overall revenue are they? And basically making sure that that number is below 1%.
And again, this also comes out of sort of investor-style thinking where, you know, for example, if they’re analyzing a company, and they see that a company has, say, 40% of its revenue coming from one particular customer, that’s a huge red flag.
Versus if it’s highly diversified, then that’s less of a risk. And yeah, that’s something I do about twice a year. And, and that’s kind of one of those things, we sort of had to create for ourselves, you know, I’m obviously not creating the concepts, but I think applying them in this way, is because, you know, as we’ve talked about a lot of the content out there on running a SaaS is very much focused on growth.
And, you know, more well-funded approaches to business that don’t necessarily emphasize stability or profitability, or things like that. And so, rather than managing for growth, we manage for stability. And I find that this customer portfolio analysis is a really helpful tool for me. And, and for Mathias [her co-founder], too, in sort of like us communicating, okay, what are our priorities? And how do we create a more stable business and just kind of giving us a high level of that.
…
One of the great things about being in B2B SaaS, but especially in the kind of space we’re in, is that we’re so diversified across industries, that we have tons of other verticals, in addition to fleet management and asset tracking.
And it makes me really glad that I do that semi-annual customer portfolio analysis, because I know exactly how much of our revenue is from [a given] sector. And looking at this now and knowing, okay, there’s this huge, well funded, competitor [Amazon, in this case] coming into the space; I can see pretty clearly how much revenue that directly puts at risk.
#2. Pulkit Agrawal, co-founder and CEO of Chameleon, shares specific ways in which they’ve gotten intentional about enabling an asynchronous culture, all rooted in trusting that “people on your teams want to do their best work.” (Source: Relay)
Initially we decided to have Chameleon distributed but with everyone in the same time zone (Pacific Time). This was because we had heard that managing different time zones was amongst the hardest things to solve for remote teams.
We had folks in Seattle, Portland, SF Bay Area, SoCal and Vancouver. However a couple people on the team wanted to relocate to other places (East Coast, Australia) and we wanted to continue working with them. We also ended up finding someone in Europe that we really liked… so we were almost forced to give up the goal of sticking on the same time zone.
And that means that if anyone gets blocked waiting on input from someone else then it can waste half a day. Therefore we had to be intentional about creating systems that allowed more asynchronous work and avoid the “shoulder tapping” culture that can exist in offices.
Some specific ways that we establish this:
Clear Google Drive structure so anyone can find documents they might need
Providing updates on tasks within Trello so anyone can see status and progress
Clear assignment rules for who is responsible/owns what, so it’s clear when tasks are thrown over to the next person
Clear that Slack is not the place to manage or assign tasks – that happens in Trello; while Slack is for conversation. Ideally discussion about a specific task happens in its Trello card
Giving clear guidelines around expectations for availability on Slack; we shouldn’t assume the other person will reply immediately, even when tagged, so plan accordingly
Making sure there are multiple threads of work so that if one is waiting, you can continue with other items
Recording external calls with Zoom (and recently, transcribing with Grain) and making those shared so that folks can access key content
From my experience the most important aspect of a healthy remote culture is trust. You have to trust that people on your teams want to do their best work. Your goal is to encourage, enable, and empower them. Avoid micromanaging or doubting effort.
#3. Aaron White, founder and CTO of Blissfully, on what he considers “the right stuff” in early-stage engineering (~product) hires, those who’ve experienced the uncomfortable excitement of shipping anything, no matter the scope, for REAL users. (Source: Code Story)
I think in the early days, if you can find people whom you trust and have worked with, who share that lightning-bolt mentality. Those are the folks you want to work with. So, I have always tried to look for folks with a demonstrated track record of ideating their own product, building it, shipping it, and getting users for it.
Whether that’s an iPhone app they made or an open source library for some new technology they have. That’s always been my go-to proxy for people that are really fantastic team members for an early-stage tech team.
The reason being, you’re just going to be building a ton, not all of it is going to survive the test of time, you certainly don’t have the whole product team specking stuff out for you or deciding what’s important, what’s not. Talking to customers on your behalf or setting that up.
It’s really that the engineering team is kind of also the product team. This is something, I believe is true at all scales. Which is that, every engineer, in some capacity is a product person. They’re always making trade-offs about what matters and what doesn’t matter. Either the experience of their fellow coders who’d be building on the infrastructure they’re making or for the end user.
Because nothing is ever fully specified, otherwise your product people will be your engineering team. So I’ve always had a bent for folks who’ve had that product mindset. That urgency. Had demonstrated it in some way. And, then, preference to folks who I had worked with previously. Because you know you’ve got a rapport, you know how much you can drive them, or how to work with them properly. You know when to let people be and put their heads down and start running.
Liking this fortnightly assemblage of founding heuristics and what-I-know-nows? Forward it to your SaaS peers, and let them know they can sign up here.
Also. Any subject you’d like to hear more about? Respond to this email and let us know. As always, we’re all ears. :)
Until next time,
Astha and Akash