Hi folks,

This is the weekly digest for my blog, Irrational Exuberance. Reach out with thoughts on Twitter at @lethain, or reply to this email.

Posts from this week:

- Do you work at a tech company?
- Crowdsourcing CTO/VPE learning circles.

Do you work at a tech company?

The most unnatural stage of hiring someone is when you’ve extended an offer, know they have other offers, and you are trying to give them advice on which offer to take. The obvious answer is that they should your offer, but you end up in some interesting discussions toeing the line between objectivity and outcome. Typically the offer numbers are already out in the open, so the topics tend to get more abstract. I recently had one of these discussions that hinged on an unexpected question, “What denotes a technology company?”

When thinking about where they’d be excited to work next, experienced engineering candidates often draw from three different buckets of “technology companies.” First are the titans of industry: Facebook, Apple, Amazon, Netflix, Microsoft and Google. Second are pre-IPO and recent IPO companies like Airbnb, Dropbox, Stitchfix, Stripe or Lyft. Third are the sort of companies that appear on career-launching companies lists like Asana, Confluent or Figma. Unioned together, this is a surprising broad set of companies.

What, other than our theoretical software engineer wanting to join them, actually ties them together?

Ben Thompson wrote What Is a Tech Company?, which defined technology companies through the lens of their business:

Software creates ecosystems. Software has zero marginal costs. Software improves over time. Software offers infinite leverage. Software enables zero transaction costs.

Using that definition he argued that Uber, Airbnb and Netflix certainly are tech companies, while casting some question on whether the moniker applies to Peloton and WeWork. This is a useful definition, but I think it’s the definition an investor would rely on, not the definition a software engineer would use to select their new role.

Another potential source of definitions are EU court rulings, which determined that Uber is a taxi company while classifying Airbnb as a technology company. Their ruling depended on each company’s degree of control – Airbnb allowing hosts to set prices, Uber setting price through its marketplace – as well as the availability of alternatives, arguing that Uber riders and drivers do not have the means to match in the absence of Uber. Legal definition are interesting because they converge on specificity over time, but I’m certain this isn’t the sort of definition that software engineers consider during a job search̉. (h/t @ldormoy for EU link)

A third definition of technology company centers on Clayton Christensen’s The Innovator’s Dilemma, suggesting that companies who are creating or leveraging disruptive technologies are technology companies. In this case, only businesses that obsolete a previous generation of businesses deserve the moniker, and only history can ordain whether a company is a technology company. In a future where Tesla successfully disrupts the existing automotive industry giants, they are such a company; in a future where they fail to build a durable business, they are not. This definition, reaching back from the future to judge today’s companies, is interesting but not very useful.

With all of these definitions falling a bit short, I believe the actual definition that software engineers use when considering a company to work at is one proposed by Camille Fournier:

I've thought a lot about this, having worked several jobs where tech was a critical competitive advantage but which were for the most part were still not "tech" companies. I think if I were advising engineers on how to think about it, I'd say look for a tech company culture

A company where engineering has a seat at the table for strategic discussions, where some of the major new business developments come out of ideas from engineering.

Paraphrasing in my own words: in the context of your job hunt, a technology company is one with a strong engineering culture and empowered engineering leadership. Not the business model, not the legal definition, not “pure” innovation, but having a place at the table and being a table you want to sit at.

Equipped with a useful definition, we reach the second important question: how do you determine if a company empowers and supports their engineering organization?

Some of the approaches I’ve seen are:

• looking at the CEO’s background for their presumed focus – what is the job that the CEO would have if they weren’t the CEO?
• looking at the ratio of engineering to total headcount – looking for at least one out of four folks being in engineering roles
• counting engineering representation in the senior leadership team – is there an engineering leader in the executive team? are they greatly outnumbered by folks in other functions? do other leaders have previous experience in technology-empowered companies?
• studying titles and seniority across organizations – are the senior titles primarily outside of engineering? how many staff+ engineers are within engineering? how tenured and engaged are the staff+ engineers?
• reviewing the extent and quality of their engineering brand efforts – do the articles come across as rote or joyful?
• navigate your network to find someone you know, directly or indirectly, who can give you an unvarnished sense of things work – this can be challenging earlier in your career, and even deep in your career remains challenging for smaller companies
• ask questions that get to the heart of their engineering culture to three or four different interviewers, and study the differences in their answers. Some questions to consider are “What are some examples of product or business ideas that came from within the engineering team, and not from the executive, product or sales teams?”, “Who are the most influential decision makers in your company?” or “Who breaks ties when organizations like Sales and Engineering disagree on a decision?”

As you layer together more of these approaches, I’ve found that you get a clear sense of what your experience as an engineering is going to be within it, and whether you’ll experience it as a “technology company” or something different.

Some folks I’ve chatted with argued that making a distinction between technology company and other companies is misguided, existing in the continuum between irrelevant and ignorant. Almost as if this categorization runs afoul of some kind of subtle moral code that I’ve not been able to pick up. This refusal to distinguish doesn’t resonate with me regarding any of these definitions: each distinction is useful within a given context. We should avoid the suggestion of a two-tier class system between whatever we define as a technology company and other companies, but we should be selective in the sorts of environments we want to spend our working lives in.

Crowdsourcing CTO/VPE learning circles.

As part of moving into a CTO role, I wanted to take a stab at putting together learning circles for folks in CTO, VP Engineering and Staff+ Engineer roles. This is the sort of thing I’ve done internally within a company before, but most companies only have one CTO or function-leading VP Engineering, so this sort of learning circle needed to happen beyond the scope of a single company.

I’ve been playing around with the idea that you can use a sufficiently-large Twitter community to unlock operating online in the same way that you would within a company, and so I decided to try to put together learning circles over Twitter, much as I would have in a several thousand person company.

This culminated in a tweet, an Airtable form, some notes on running learning circles, eighty-six folks who filled out the form, and three learning circles containing nine folks apiece. One of the circles had its first meeting last week, and the other two are in the process of scheduling. This left about sixty folks without learning groups.

Composing circles

Once I had a bunch of names, I went through and cleaned the location data to make it easier to filter down to appropriate groups. Folks showed a lot of creativity in various fields, but ultimately it was pretty quick, maybe thirty minutes of data cleaning.

Next, I put together some pivots to figure out where we had the most chronological and physical density. There were good numbers near Montgomary St BART and the SF Caltrain station, and a long-tail of other locations in the East Bay, South Bay, and across the US: New York, Boston, etc.

I've always learned the most within diverse groups, so I started with that as a priority, but ran into the classic challenge of the lazy organizer: building strong representation within a community takes real work, and isn't the sort of thing you can accomplish with a Twitter broadcast.

About one in ten of applicants self-identified as women, and after chatting with several folks, I decided that the best way to make the groups useful and safe for those folks was to form two groups with balanced gender representation that they would participate in. With this approach and limited colocation of applicants, I ended up with one well-balanced circle in San Francisco, and the second well-balanced circle over video conferencing. If I had collected additional identification data, I would have extended this approach further.

Other dimensions of building a good group were easier: each group got a good mix of very senior engineeers, folks operating as CTOs, and folks leading large groups within large companies.

Altogether, I was able to spend about two hours and compose three solid groups, and decided to stop there. I could have "finished" by haphazardly grouping the remaining folks into circles of eight, but I don't think that approach would have worked, so it seemed better to pause.

There is a real challenge here around mass-group formation, and I suspect my approach isn't quite right. Maybe a more scalable approach would be having a signup form for folks to join a Google Group or Slack channel, and then a mechanism for folks to self-organize from there.

Group initiation

Once I established the group members, I emailed each of the folks individually with

1. the proposed time and location for the learning circle,
2. a short code of conduct I pulled together for the learning circles, and
3. the initials, company and pronouns of the other folks in their group.

The email ended by asking their permission to add them to a Google group for coordination purposes.

Once folks gave permission, I added them to a group, and we moved to scheduling the initial meeting.

Folks doing similar stuff

There are a bunch of folks out there doing similar things on a more full-time and less ad-hoc basis. Maia Bittner pointed me towards Jordana Stein, who is the CEO of Enrich and doing something quite similar. Likewise, Jerry Li was doing something very similar with SFELC. I’d even say that Plato is doing something similar albeit on a more one-to-one basis.

Doing this well really is a full-time job, so I hope these companies work out.

What’s next?

Given the overhead of running these sorts of programs, and the added friction of doing them externally, my guess is that these sorts of groups will continue to mostly occur informally for groups of folks who already know each other, as well as within the halls of large companies. I do think there will always be a small – but healthy – business run by companies who specialize in fostering these groups, but ultimately I believe groups like this are so prone to dissolving over time that it’ll be a tricky business to scale.

Personally, the learning circle I joined met last week and had a delightful discussion. We'll have our second meeting in early March, and I hope it lasts for six months or so before it fizzles out. Either way, I've already gotten to meet and learn from some great folks.

That's all for now! Hope to hear your thoughts on Twitter at @lethain!