How design (generally) works at tech companies

In my seven years as a designer, I’ve worked across a lot of companies — this wasn’t my intent, and so it’s not necessarily something I’m particularly proud of. That said, life’s full of all sorts of unexpected twists!

It is certainly true that there are things that aren’t great about constantly switching jobs (which I can reflect on in some other opinion, if there’s interest). Nonetheless, while I wouldn’t necessarily recommend job switching for every early career designer (particularly for ones who are lucky enough to land at top tech companies early on), I might broadly recommend it for the majority of them (i.e., the ones who don’t).

Putting the downsides of job hopping to one side, there is an upshot to having worked at a ton of companies over the years: I’ve gotten a lot of experience figuring out the patterns across a great deal of companies, and I can, therefore, more readily impart reflections on this topic on readers and mentees.

In this opinion, I’ll reflect on this very topic: how digital products are made across tech companies — big and small, with a brief mention about what it’s like to build digital products at non-tech companies.

Real quick: definitions

What’s a “big company”?

Understandably, a discerning reader may want a clear barometer from the author around what a “big” tech company is, compared against a “small” one. For instance, a certain Face social app has 70,000 employees, a certain googly search engine company has 150,000, and a certain Bird application had 7,000 (at the time I worked there, anyway). Which is the “big” company in this situation? Which is not?

Is it based on employee size, or DAUs (daily active users)? For example, a certain Gradient Picture app (by the Face app company) has 500 million DAUs and around 3,000 employees. A certain Bird application has 300 million DAUs and 7,000 employees. Which company is the bigger company in this situation?

I’ll leave it up to the reader to decide on this question. I think, for most people, all of these companies would be considered in the “big company” bucket, with some big companies being bigger big companies than other big companies. This definition feels satisfactory enough for me, personally.

What’s a “tech company”?

That said, readers may also be wondering about what I mean by “tech” company versus “non-tech” companies. In my view, I believe there is a distinction to be made between software companies. For expediency, I’ll quote myself from a previous opinion, What’s a tech company, anyway?:

Consider this question: which company feels more like a classic example of a “tech company” to you? Tata Consultancy Services, or Stripe? … Despite that both of those companies listed above make software, I think we all know the answer to that question. It seems that there are traits about companies that would make some software companies “tech companies,” while other software companies are not. I think most people have a sense for this, but simply haven’t formalized these thoughts. Consider the following:

- All “tech companies” are software companies, but

- Not all software companies are “tech companies.”

This is best illustrated by the comparison above (between Tata Consultancy Services and Stripe) — both of these companies make software, but few people would say that Tata Consultancy Services is a “tech company” (more correctly, most would probably say something like it’s an “IT company”).

Giving an example to more concretely describe what I mean, seven years ago, in what was my very first design job, I worked at what I would today call a company that makes software, but that is not a tech company. It was quite a dated company, even by my own standards at the time.

Non-tech companies and organizations can be big or small in size, can be agencies or product companies, can be government or private, and so on, but the common denominator between all of them is that they operate nothing like tech companies do.

It’s difficult to provide the reader a surefire, absolute way to define which software companies are and aren’t tech companies. As I write in that same opinion:

I don’t mean to suggest that this is some kind of scientific system — there’s something inherently fuzzy about all this, as it requires one to consider a company’s internal culture and make judgments about it.

But I think that the most meaningful, distinguishing factor between tech companies and non-tech software companies is the work culture, as well as the product worked on. To give some concrete examples:

In an example that holds some real emotional value for designers this week, I propose that Adobe is a software company, while Figma is a tech company. I would also say that Disney+ is a software company (more accurately, a team that makes software inside of a media company), while Netflix is a tech company. Best Buy is a software company (they do actually make software!), but Amazon is a tech company. U-Haul is a software company (they also make software!), but Uber is a tech company.

What’s more, tech companies build digital products, and those products are their business — which is why they are called SaaS (software as a service) companies. Non-tech companies maintain and offer software services (e.g., Bank of America), but that isn’t usually their core business.

I wouldn’t try to come up with an overly complicated system of taxonomy — just go with your gut. A lot of tech companies feel “hip” and “cool” and “tech forward” (e.g., Stripe), which is often enough to signal to you that it’s a “tech company.” When the companies are somewhat more dated and stodgy, or don’t have software as the main focus of their business model, then it’s probably not.

With definitions to one side, on to what the reader came here for!

Great, back to regular programming…

In my experience, design at big tech companies doesn’t feel much different to design at small tech companies.

What’s usually different between big and small tech companies is the team composition — the availability of extra hands. At almost every single tech company, there is usually one PM per designer, and multiple engineers supported by these two. This is usually the minimum composition of most product teams, but I’ve also worked at companies where I was the only designer, and we had no PMs. Below are a smattering of examples from my work history, to give the reader an idea of team compositions at variously sized tech companies.

An extremely small company

At an 8 person tech company, I was the sole designer, but also a front-end developer. Our CTO, also a developer, was the one who most often behaved like the PM, but this was never explicitly stated. We had broad ideas for what to work on, we might talk about it as a team and decide what we wanted to work on each week, and I would often design right in the browser and push commits to the codebase and get the features built myself. We only had one designer (myself), and the rest were developers, with the exception of the CEO. I would say this product had product-market fit, but the market was not financially viable (especially in the way we were monetizing it). Regardless, the features we chose to build were mostly based on a culture of debate and back-and-forth — in other words, just, like, vibes.

This startup was fortunate to have 150,000 unique sessions a day in some parts of its product. We could A/B test to a very high confidence interval (“statistical significance”) in just a few weeks due to this. For most startups at this size, they’d be lucky to have a few thousand DAUs. We would A/B test whole new flows in features, and whichever one performed the best would be the one that shipped.

A pretty small company

At a tech company of 80 employees, I was one of three designers, and each designer owned one of the three main problem areas in the product (we had a plugin thingamajig, a text editor, and this native app, and so there were teams formed around each of these products). Likewise, there were three PMs, and each designer was supported by their respective PM and, together, they presided over their problem area. We had a bunch of engineers, and they tended to pick up similar areas of work, and so the same engineers were always in our calls. These were what many refer to as “feature teams” (other words for these might include “product teams” or “pods”), but it was the same designer, PM, and set of engineers working on the same product areas all the time. We had one copywriter who supported all three product areas, and you could walk her through the feature you were working on to solicit her perspective.

The roadmap and strategy was mainly decided on by the three PMs and their manager (who carried a title some of you may have heard of before: “VP of Product”), and the work distributed among the three feature teams accordingly, based mostly on focus. It often felt like you could just pitch an idea to your PM and get it on the roadmap without fuss (provided it was a decent idea that made sense with the product’s strategy), so the roadmap was frequently flexible and you could sort of do whatever you wanted if your reasoning was good enough — that said, sometimes the idea would be pushed to another quarter, or prioritized relative to other, higher priority efforts in the business. PMs often liked writing PRDs (other words for this: product spec, brief) and have those ready for designers to reference when building. Sometimes they were made after the designer had already started. It just depended on the situation.

We had a part-time researcher who would help out when you felt you wanted to test a feature you were building with users and get a sanity check in terms of its usability, or desirability. Before it was acquired by Adobe, this product never found product-market fit. This product had no users at all, and our product strategies were also determined through a culture of debate (read: vibes).

I was the one who built our design system, as I thought it would be helpful to have a bunch of shared components as we onboarded new designers on to the team. It was super helpful. There was no specific design system team, I just made it on a weekend myself.

We also had a brand team (sometimes called a “creative team”), which was made up of two brand designers. They didn’t do product work — they worked on marketing materials (like the product’s website) and general branding. They often consulted with the copywriter for some brand writing, as far as I saw. They were often in our critiques and always had fun things to say.

Still a pretty small company

I worked at a dev & design shop of 150 people that sold feature teams to tech companies of various sizes. For example, Houseparty might approach this dev & design shop and buy a feature team to come in and build an MVP of a new product or feature they might be looking to build.

We would often come on board for 6 months and be directly embedded in their company to figure out what they had in mind, help with strategy, and then build the full MVP of a new product or feature they were looking to build. They often had a PM on their side — if it was a very small company (they often were), it was often just the CEO or CTO. If the founders were very inexperienced, the designer on our side would behave like a PM, but it was never an explicitly stated role. They just needed us to build an MVP of their idea to go to market, so we’d help them with whatever they needed to help get some validation as early evidence of potential for product-market fit for the product we were building.

These small companies were often bootstrapped (raised their own capital) — they’d reach out to us to buy a ready-made feature team to build the feature (a designer and multiple engineers). Designers at this company were expected to perform both as designers, but also front-end developers, so everything we designed, we also built ourselves.

The designer and the engineers usually decided what to work on together, week over week. Sometimes, the clients had special concerns, and we’d consider those concerns. Other times, they were very hands-off and we just prioritized as we saw fit (read: vibes). We never made design systems, and there weren’t brand teams (unless we were helping build a product at an established company).

A large company

At a certain Bird app company of 7,000 employees, I worked on three, separate teams (I team transferred once, and then that team got re-orged, and dissolved into another team, making it three teams I’d worked across). On one of the teams I’d worked on, there were three PMs, and I supported all three of them across three different product areas they owned. We were looking to hire one designer per PM (and their attendant problem areas on the product), but it was just taking some time.

On another team I’d been on while there, there was only one PM, and he supported all three of us designers. None of the teams I was on had dedicated data scientists, but we did have a researcher on one of the three, and copywriters in two of the three.

On teams where we lacked one or more cross-functional partners, we often made requests to the respective orgs (where needed) to see if we could get those resources reviewing our work on one-off bases — as if on a consulting basis. Each of the three teams, however, had their respective set of engineers (web, iOS, and Android, as the products across all three teams required implementations across all three codebases), at least one designer, and at least one PM, at any given time.

Each team was formed by directive of product people higher in the chain — someone in the organization decides that an opportunity is worth pursuing, giving the team its broad charter (“build a consumer-facing subscription app in the Bird company app,” or “build group-like functionality into the Bird company app,” etc.). From there, all cross-functional members of the team could decide together what our specific strategy would be, though PMs were most often the deciders on how to prioritize the order of the work to be done.

The entire Bird company was broken up into three, main teams, with smaller and smaller teams flowing from these segments:

• Internal tools (e.g., lots of engineering teams, internal performance tools, etc.),
• Premium products (so directly revenue-generating products, e.g., the ads platform, etc.),
• Freemium products (e.g., the home timeline, the search surface area, growth teams, etc.).

Within the “freemium” products, there were further segmentations (often called “pillars”):

• Core products (e.g., the home timeline, search, DMs, etc.), which were the products with obvious product-market fit, sort of “bread-and-butter” products, and
• Horizon products (e.g., “group-like” functionality, audio calls, “Patreon-like” functionality, subscription services, etc.), which were bigger bets the company was making that were “on the horizon,” or ones that didn’t quite yet have obvious product-market fit.

So, if I was working on the Bird App Consumer Subscription Product TM, that was on the Horizon pillar (it was frequently confusing to people on this product why it wasn’t directly orged under the Premium org), and there were a bunch of sister teams on this pillar, like a certain Bird App Audio Calls TM team, and a Bird App Groups Team TM, etc.

These were all teams that focused on finding product-market fit to prove to leadership to keep investing in them. They were autonomous teams that operated in whatever way made sense for them, so some people could conceivably have wildly different experiences at the same company — even on teams on the same pillars.

The objective of all these teams is to increase DAUs (daily active users) for the entire product as much as possible, and/or acquire new users (bring on new users) to the product. If a team can demonstrate that its product is driving key metrics (these depend on each company, but for most companies, DAUs and user growth are both a common key metrics to go by), then there’s stronger signal that customers want that product — which indicates product-market fit. At that point, the team tends to receive more investment (in the form of greater resources, like staffing), and is often moved to a “core” product area, and out of the more speculative areas of the organization.

Product strategies are mostly vibes, and we did them roughly quarterly, but we could add and remove work from the roadmap as we saw fit. At this company, there was a culture of debate on most of the teams I was on (between all of us — PMs, designers, and engineers, though the PMs would often be the deciders), and then we’d agree on the work we’d want to do, and in what order. We’d release features and sometimes have basic analytics we’d pull, so as to check for any regressions in any key metric. If there weren’t too many serious regressions, we’d just keep the feature. We often just shipped without any holdouts (e.g., A/B testing), though, and just went with vibes, especially on smaller product areas with no (or few) established users yet.

There was a design system team, but they weren’t embedded in any specific product team — it was more like a standards committee, and they mostly enforced usage of the design system, often through product reviews (particularly if you were working on a totally new product area). I wasn’t able to meet one designer that enjoyed using the provided component libraries, so they mostly copypasted from themselves in their own, outdated files. Developers still got the gist, and it was fine.

Also, this Big Bird app had a very robust brand team (internally referred to as the “creative team”) — there were art directors, illustrators, and more. Illustrators, as I understand, were separated into people who made product imagery (so spot illustrations in marketing pages, or fun error imagery, etc.), and people who made iconography, etc. There were people who made time-based work, too, I’m sure. Also, there were general “visual designers,” and these people tended to be the ones who worked on marketing pages (the website-y elements of the product), and then they’d work with illustrators and others to get assets for the pages they’d work on.

None of the listed people above were involved with product work. They helped with creative services, and product teams could consult with them to get new icons (and stuff) if we needed any for our new product areas, if any.

A ginormous company

At a certain Gradient Camera app of 3,000 employees in a larger Face social app of 70,000 employees, I’ve so far worked on two teams. One, just for a few weeks, as the entire pillar my team was on got re-orged (I was subsequently moved on to another team). As mentioned earlier, re-orgs are fairly common in tech companies, and tend to increase in likelihood as market situations change. These are opportunities for leadership to define their visions for the pillars that they respectively own and, in turn, respond to directives from some of the highest leadership in the company.

For example, if leadership feels that the market has shifted, and that the org needs to focus on bringing up DAUs, and they notice that most DAUs are using specific products, they tend to remove investment in the underperforming products in the portfolio, and more strongly invest in more promising parts of the product, or kick up entirely new product areas to focus on, instead, if they believe an untapped area in the product exists. Leadership will resource these teams as they see fit, and those teams have to build the strategy that concurs with the team’s provided (and often somewhat broad) charter, and prove to leadership that their strategy for the half is sound.

At a company of this size, both teams I’ve been on thus far only ever have had one designer and PM, an EM that behaves more like a technical PM, a bunch of engineers, and we always have a copywriter, researcher, and data scientist — but these roles are usually shared across multiple teams. For example, my researcher might also support a sister team on my pillar, too — same with the copywriter and data scientist. If leadership sees fit, they might also staff very specific and special roles on your team, too, like a “growth data scientist,” which is a special kind of data scientist that very specifically focuses on and can help with growth metrics and strategies (as an example).

Designers, PMs, and engineers are only ever (with few exceptions in my career) staffed on to one team at a time where, by contrast, researchers, data scientists, copywriters, and other roles tend to support multiple teams simultaneously, usually in the same pillar.

At this company, designers are expected to drive product strategy, but with input from their partners on the team. It’s recommended that you work with researchers to pull information from user interviews (mainly) to evidence problem areas to focus on, and then use that as evidence in meetings with leadership to get sign-off on your proposed roadmap. You can ask data scientists to pull analytics about target cohorts and associated behaviors, churn rates, and other metrics, to further evidence your product strategy. This is done in “halves” (or two quarters, meaning a “half year”), but most of the companies I have worked at have done strategy and roadmap planning quarterly.

Ultimately, the goal is to get approval from leadership to execute on a vision for the half, mainly led by the designer, but in collaboration with partners. After this, the entire team goes into execution mode for the entire half — as things come up, the team can adjust, but generally you want to work on what you say you will.

While researchers and data scientists can help designers and PMs evidence their suggested strategies and roadmaps for each half, there’s no expectation that these strategies are going to work out exactly as planned — it’s understood that building these plans every half is purely evidentiary (read: vibes), rather than a reflection of perfect reality. Research is used to bolster intuition-based arguments about the direction to take the team in (read: vibes), and designers are expected to use whatever evidence they have at their disposal to persuasively argue for the visions every half (also read: vibes). The team also has to define what their key metrics of success are on their team, and what metrics they want to move, specifically. Features in their roadmap should ladder up to that metric goal.

There is a culture of debate here (read: vibes), and not every idea makes the cut after extensive discussion with leadership. When things do ship, they always ship as A/B tests against very small portions of the population, usually in target locations in the world. If the variant performs well and causes no significant regressions to key metrics, the feature can ship to bigger populations in more locations, and the test is often repeated again. If there are ever significant regressions, the recommendation is automatically a “no-ship.” If there are slight regressions, but some positive changes, then a ship may be recommended.

From what I’ve seen, no matter how persuasively you’ve argued with research for a feature earlier in the half, if a feature is tested and performs poorly, it will not ship. Actual user behavior measured via extensive analytics are the deciding factors here. Research and other information is purely evidentiary, helping to guide strategy and vision.

What’s more, this product, specifically, is a very complicated one. We use a prototyping tool called Origami very extensively to model very complicated, canvas-based interactions. Where most products (e.g., Medium, LinkedIn, Twitter, etc.) work by using simple tap targets on things like buttons, causing simple modals and page refreshes to occur, this particular product has an enormous amount of asynchronous and complicated gestural interactions and animations. Given that it’s a canvas, complicated properties (X and Y positions on a canvas) are set by user input, for example, via drawing tools users can use, or tools to add fun stickers to one’s images that be repositioned and resized with two-finger gestures, or filters set via drag and pull gestures, and other complicated interactions.

Something like Figma goes underused here. I’ve never seen this before, and I probably will never see something like this again, as there aren’t many products that require this amount of complicated gesture-based interaction work. Some notable examples of this very thing could be TikTok, FigJam, and other more canvas-based products. The prototyping tool we use (as mentioned: Origami) is a node editor, and one can declaratively toggle props on elements in the canvas using these nodes. But it also allows one to use JavaScript to build one’s own nodes, if one should like. This is a tool that, as a result, has a very high ceiling of complexity, and it’s a common topic of discussion among designers here as being incredibly painful to use. But we make it work.

There appears to be a lot of collision between teams across different pillars that sometimes appear to work on very similar problem areas, which can be very disorienting, if I’m honest. Competition between teams for “impact” appears to be encouraged.

What’s more, there’s a strong incentive among designers to come up with lots of ideas to then bequeath to other teams, where those ideas have better roadmap fit. You’re constantly learning about teams you’ve never heard before that work on something slightly similar to the thing you just thought of, and that it went well or didn’t, or that maybe you now have to have calls with them to get the inside scoop.

Performance cycles appear to be rigorous: designers have to prove “impact” by using evidence to argue for their success over that year — designers might use things like product launches that increased DAUs or user acquisitions, or other key metrics. They might also use other things they’ve done that lack obvious measurements to argue this as well (e.g., cleaning up component libraries, organizing stuff for the team that makes working on stuff less annoying, helping with hiring, helping with teaching Origami, etc.).

Commonalities

These are just a smattering of companies I’ve worked at spanning my seven years in the industry, but what’s clear to me are a few traits shared in common:

• Most product decisions are intuition-based, even at the highest level of leadership,
• On product teams, the core teammates are almost always a singular designer, singular PM, and a bunch on engineers (as needed),
• The “feature team” approach (PM, designer, and engineers — and, sometimes, other roles — working as an autonomous unit, and closely together, to build in a specific product area) is a very common setup at tech companies,
• PMs and designers tend to have role collision at various times (e.g., they might work together to build a strategy and roadmap), but it just depends on the company’s style and culture,
• Tech companies do not hire “UI designers” — designers are expected to make good products, and make them look professional,
• Most companies, even ones with several thousand employees, don’t have robust data analytics pipelines set up,
• Roles like researchers, data scientists, copywriters, and etc., are somewhat uncommon, but increase in commonality the larger the tech company gets — even so, these individuals are usually multi-purpose, and support many teams at once,
• Even at a big company, you might never work with a researcher, data scientist, or copywriter,
• Designers are expected to always be significantly ahead of engineers — designers have to move much faster, and generate a large dearth of ideas to help the team shape what it wants to work on,
• Leadership decides which teams and pillars are created, but teams have to work within that initial charter to create their own strategy and roadmap (though some companies may have leadership that provides this, and creates a very top-down approach to product strategy — it just depends on the company),
• Tech companies don’t engage in any formal processes — designers don’t make personas, make site maps, and etc. We just make software, and there’s an expectation that we move quickly and ship fast. When available, the deciding factor in whether a feature launches is analytics and what they say about impact on key metrics — nothing else goes into deciding whether to launch.

A final note

My very first job in the industry was at what I’d call a software company, but not a tech company. We had a “UX design” team, a “UI design” team, a research team, a copywriting team (and probably some others), and they all reported to the product org. There weren’t any feature teams — designers picked up prioritized tasks in a queue, and that’s how work started.

UX designers made gray-box schematics, mainly in Axure, exported them as PDFs, and then passed those off to the UI designers, who sat in Sketch making the gray boxes look good. UI designers also made a lot of “redlines,” which were measurements of spacing in the product (e.g., padding), which would get handed off to front-end developers. Researchers made a lot of personas, presented them to us during our “lunch and learns,” and hung them up in hallways to “build empathy,” and other such things. I distinctly recall a woman in a persona called “Busy-Bee Bethany,” and there were paragraphs about her lifestyle, and bar graphs to measure all sorts of characteristics about her. I recall finding this to be very curious and fantastical.

This was seven years ago now. My suspicion is that this approach might be more common among agencies and other non-tech companies. Looking back, this was a company that made a product that could be called something like “Dropbox for mergers and acquisitions” (legal stuff, don’t ask), and so the product was pretty conceptually simple. But, in true non-tech company fashion, I recall the product being very crowded, with tons of products and features users very obviously didn’t want and were very confused about. We had lots of sales people to argue for why these add-ons should be purchased by our customers. I recall feeling skeptical about whether or not those add-ons were truly helpful.

After I left that job, though, I’ve never seen anything like this setup again. I don’t have a strong reason to believe that I ever will.