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.