Frequent questions I get around tech companies
For those who may be familiar with me, they’d know that I’ve been working at tech companies (ranging in the size of eight people to eighty thousand) as a product designer for most of my career. But they also might know that I had an extended foray into mentoring of (mainly) designers—probably north of eighty. I mention this because mentoring’s been a lot of things—including really interesting, mainly because it’s impacted my thinking on various matters. But it’s also been a source of interesting and fun questions from mentees!
To this end, I would like to discuss common questions (or, perhaps more appropriately said, misconceptions) I frequently receive about what it’s like to work in tech—especially FAANG companies.
1. Any company that makes software is a tech company
This one’s of particular interest to me, and I’ve written previously about it at quite some length. Quoting from myself in a previous opinion:
It seems that there are traits about companies that would make some software companies “tech companies,” while other software companies [would not be]. 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”).
To put this another way: one may work on some software, but that does not make the company that owns said software a “tech company.” For example, Penske makes software, but most wouldn’t call it a “tech company”—most would say that it’s a moving truck and trailer rental company. They may also know that it uses (and even makes) software as part of its operations, particularly e-commerce software to allow consumers to more easily purchase their services (the aforementioned trailer and truck rentals).
But the fact that it uses (and makes) software in its operations does not make it a “tech company.” For another example, the FBI uses (and makes) software, but it’s not a “tech” organization (in fact, it’s a common point of discussion among national security specialists—such as our very own Condoleezza Rice—that attracting talent from tech companies, specifically, is a serious challenge for governments across the world, as private sector roles offer the best compensation, which is hard for government to compete with).
This isn’t because it’s a government organization. For example, ByteDance (the company behind TikTok), despite being partially owned by the Chinese government, would best be described as a tech company. This can be said for a few reasons: it makes and “sells” (so to speak) software, which is the company’s sole business model. This kind of company is frequently referred to as a “SaaS” (software as a service) company.
As I write in that same opinion:
[… T]ech 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.
Importantly, though, TikTok operates in a way that is culturally similar to other tech companies, too. As Chandra Gnanasambandam, Janaki Palaniappan, and Jeremy Schneider write over at McKinsey:
[… B]uilding a software-centric business means building a software culture. This goes way beyond adding a few software veterans ... It requires building a culture that deeply values the creativity and artisanship of great engineering, elevates product leadership and a customer-first focus, and empowers a leadership team with a strong understanding of software business models and tech. [… C]ompanies might already accept the importance of software [but] they still tend to look at software as a capability that they can bolt onto their existing business. That just doesn’t work. Becoming a software business requires foundational change with different skill sets, practices, leadership, and organizational structures.
Certainly, in addition to the business models of these companies (SaaS), the cultural characters of these companies can be said to be of importance in the definition of “tech company,” too. As I write in that same opinion:
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. […] 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.
This is why, for example, despite being totally different sizes and offering completely different products, Facebook (a social media and ads company, at 60,000 employees) would be considered a tech company in the same way that Notion (a company that makes a text editor, at 400 employees) or thoughtbot (a consultancy that sells ready-made teams to founders who want to build their first MVPs, at 100 employees) would be. By contrast, companies like Rockstar (the game company behind hit franchises like Red Dead Redemption and Grand Theft Auto), Penske, or a web design agency would not be.
Tech companies work differently than other companies or organizations do—whether those organizations are private, public, government, or something else. These differences may manifest in many ways:
Compensation (e.g., despite Disney making a streaming service that competes with Netflix, its compensation packages are drastically less competitive than those at Netflix; unbeatable benefits that may cater to all sorts of niche employee concerns; etc.),
Work style (e.g., at game companies, game interfaces are usually considered secondary to the actual product—the game—where, at tech companies, the interface in the software is extremely high priority, as the interface is considered the product users “buy” at these companies; at non-tech companies, there might be “UX designers” on staff, and then “UI designers,” whereas the expectation at tech companies is that designers are evaluated for both the ability to produce functional and professional-looking software; etc.),
Culture (e.g., sprawling, bespoke offices; certain, characteristic styles of speech—for example, tech companies tend to prefer to call designers “product designers,” where other companies tend to like to use the word “UX/UI designer,” or some variation—or dress; etc.).
I would recommend that, for anyone interested in product design, they determine what industry is right for them based on their priorities. If one wants to optimize for the highest possible compensation with the most amount of complexity and focus, then building interfaces at tech companies might be the best match for this individual. If one really likes games, and compensation isn’t a concern, an interface role at an entertainment company (e.g., Rockstar, Naughty Dog, or someplace else) could be a great match. If a designer really wants to make websites rather than products, then an agency might be the best match for this prospective designer, rather than a tech company.
But it’s important to keep in mind that a designer at a tech company is going to cluster around certain roles and responsibilities, and those won’t generally be identical to those that designers at non-tech companies will. Therefore, the expectations around hiring are going to be different, and so the work one gets from non-tech companies may not be of particular interest to tech companies.
It’s all a matter of preference—each individual must decide for themselves what’s right for their lifestyle, and it’s a matrix of compensation, work style, culture, and other qualities.
2. When working at a tech company, you’ll be doing mainly incremental work
This is a common source of confusion for many. It is believed that, at tech companies, designers are mostly myopic, focused on “just increasing conversions,” and can’t “think big.” They can’t “strategize,” as they are simply too concerned with “interaction” or “aesthetic” work. Therefore, career growth can be said to be limited at these companies, as there won’t be as much of a challenge to be had.
One thing I frequently discussed with my mentees was that, firstly, if you’re coming in as a low level design IC,—regardless of whether you work at a small or big company (with a few exceptions, like a bootstrapped CEO that might be looking for a less experienced designer to execute on his/her vision)—you’re not going to be asked to taking on the highest impact work.
So, for example, if you are an early career designer, you won’t be leading new products like TikTok Now, TikTok Live, Twitter Spaces, Github’s Copilot, Notion AI, or any of the entirely new product areas these established tech companies have created as of late. Instead, it will be up to staff and director-level designers to lead these products, where you might be brought on to take on smaller pieces of their larger strategies.
Those experienced designers will be developing a product strategy for these new product areas and going back and forth about it directly with company leadership, and then executing on its hardest, most far-reaching parts—by contrast, less experienced designers may be brought on to take on the more circumscribed, executional aspects of these experiences. (If the inexperienced designer shows promise, then this designer might be thrown into more and more complexity, of course, but it just depends on one’s appetite and output.)
It’s easy to see a brand new product (TikTok, Twitter, Substack, etc.) appear on the market and identify that as what it is: a totally, brand new product—decidedly not an incremental change. It is less easy to understand that there are product offerings within these established products, themselves, that are not incremental changes—and that there are people who are developing complex strategies to develop and steward these within those products.
Great examples of this are companies that can be described as monopolies (and, as a result, frequently attract the ire of regulators in places like the United States), like a certain fruit company, a certain search engine company, and others. These companies regularly build out entirely new businesses to capture and swallow entire markets. For instance: when a certain search engine company makes a browser product that completely destroys an entire browser ecosystem, an ads platform product that completely changes advertising forever (destroying physical advertising in the process), and a search engine product that completely wrecks all available search engines available at the time, regulators pay attention to this seductive combination, and the target company starts to feel the pressure. It starts to build features into its browser to allow users to optionally set a non-proprietary search engine as the default, so as to not trigger severe litigation from regulators who watch for clear and unequivocal violations of anti-monopoly legislation in the States.
Less experienced designers may see a company like this, and say, “well, designers are just optimizing for 2% conversions” and be satisfied with that. I’m sure that some growth designers there do exactly this across multiple mature products at many tech companies, big and small (for example, at a tech company of eight people, I was designing A/B tests to increase conversion rates on our books, and a 2% increase was considered a huge win for us).
However, as mentioned, software companies have enormous propensity to become monopolistic, and some of our more beloved brands today are monopolies—and monopolies routinely obliterate competition with entirely new products. They have to do this to stay afloat. They have to constantly expand into new markets so as to keep investors convinced of their future proofing and relevancy. Some people see this as a bad thing, some see this as a good thing, but, regardless, it means that, if you’re interested in those opportunities those companies create, they do exist for you as a designer.
They also don’t go out of their way to admit any of this. Their marketing completely downplays that their entire business functions as a market-gobbling monster with a thirst for business blood that cannot—and will not ever—be quenched under any circumstances, until their last, bottom dollar is spent. If you’re interested, you can only be so lucky so as to be a founding (or otherwise early) designer on one of these market-gobbling, game-changing products.
From the perspective of the naysayers, though, they might not detect any of these changes, anyway. This is by design—it’s generally undesirable to completely pivot established parts of products and disturb experiences that already are provably already working for users, rather than seamlessly integrate new products in a way that doesn’t disturb disinterested cohorts of established userbases. What’s more, as mentioned, these companies specifically consult with their attorneys to carefully tweak their outward messaging so as to not create surface area for anti-monopoly regulators to build cases on.
Despite this, upon closer inspection, new products within Instagram (and other large products and companies, more generally) are released at very regular cadences. It’s just that less experienced designers may not be so keen on noticing these changes (or understanding why they might be attracting the attention of regulators, should the case arise).
For example, one that most people don’t know about: Instagram Shopping, released in 2020. This is a B2B offering for customers who sell their services on Instagram, of which are many—from small, women-owned businesses that sell nail and hair styling services, to medium-sized, bespoke clothing brands that get most of their leads from posting and advertising on Instagram.
Any designer would be so lucky to be pulled on to lead and steward a totally new product vertical inside of Instagram (e.g., Instagram Shopping, Reels, etc.), providing measurable value to Instagram’s enormous ecosystem of small businesses, generating tens of millions in revenue for the company, helping the company acquire new users, supercharging another Meta product (in Shopping’s case, Ads Manager, a major lever and driver of revenue for the company, and value for their enterprise customers), increasing DAUs, and other hard-hitting, career-making opportunities. Leading a product like this—whether as an engineer, designer, or PM—would be a major addition to one’s portfolio of proven work. With enough experiences leading products like this, one could be poised to take on high level director—or even VP—roles.
What’s more, there are even unbound teams at a certain Face Literature company (e.g., “Studio,” “Sledgehammer,” etc.) that sit outside of specific product teams, dedicated just to figuring out what new areas of opportunities could exist for the company to invest in. But this isn’t just exclusive to Face Literature. At Twitter, “Studio” (or, as they were called, “0→1”) teams existed, too, and designers (and their partners) there were expected to be able to uncover new product offerings specific to Twitter, testing them to see if they had legs with customers, later handing those off to newly spun-up product teams (or existing ones, if there’s a good fit elsewhere).
As one might recall, many years ago, Meta (back when it was “Facebook”) thought to monetize its users by putting ads in front of them—thus, Ads Manager was born. Consumers might not even know that this ever happened, or have any recollection of this—but, today, that product is one of Meta’s largest (and most important) products in its suite of offerings, and has resulted in substantial contributions to industry standards around advertising platform products, and contributions to excellence in the linear regression models needed to provide enterprise customers the customer targeting they need for—sometimes suspiciously too effective!—advertising. New offerings even within Ads Manager are added, too, with focused solutions for enterprises of all sizes, which captures a whole other ads-related market of tooling for smaller (and bigger) companies, alike.
At some point, it occurred to Meta (back when it was “Facebook”) to create a “messaging” product, separate to its webapp (wildly successful at the time). This was a major decision for the company, and marked a time where 1:1 sharing began to become more and more important for the company, especially via mobile devices, where it could provide (and recapture) value for users who wanted to talk privately on Facebook, rather than openly broadcast, as consumer behaviors shifted. The founding designers on this product would later go on to make one of Meta’s most important products (i.e., Facebook Messenger), and become recognized and rewarded for this at the company.
What’s more, the teams that get spun up to work on these new products tend to be small and focused—sometimes, like in Twitter’s case, they might even come through an acquisition of an entire small company that was building the product to begin with, brought on—and otherwise untouched—to continue doing their work. In the words of a PM that came to Twitter that way (while we were building Twitter Communities together), “this is all just like before the acquisition—we just have more runway now.”
But none of this is exclusive to Face Literature company. Twitter was an unusual “FAANG” company in that it had a reputation of “not changing” in many years—new products were not frequently released. Twitter’s offerings (the very Tweet machine itself!) did not substantially expand over time—this was unusual. A few years ago, due in some part to a change in internal leadership (unrelated to the recent change in ownership), this began to shift.
One result of this that might be familiar to a wider audience would be the creation of Twitter Fleets (or what some would call “Stories, but for Twitter”). It was eventually sunsetted (sunsetting can be just as important as creating new products, however!), but it represented a marked change in Twitter’s internal workings: internally, this moment would be frequently referenced as the moment when Twitter began to “move faster.”
As if over night, in short succession, new products began to crop up: Twitter Spaces, Twitter Communities, Twitter Blue, Twitter for Professionals. As mentioned, being a founding (or otherwise early) designer (or any other role) on any of these products might be the highlight of one’s career, as these were major releases that added whole new business verticals, revenue streams, targeted solutions for cohorts, and more, for Twitter.
Being the lead on Twitter Spaces might feel the same as being the lead on Clubhouse—two incredible products that got a ton of well-deserved fanfare, and that had a ton of interesting, new, and refreshing ideas, interactions, and features to explore and build. Certainly, all of these products were later re-orged into what was called “Horizon” products—products that were brand new investments for Twitter, but still not completely validated (which is why these would be called “Horizon” products, incidentally) to the extent that they’d be included in its core product offerings (the Home Timeline, the DM product, the Search product, and so on).
At Google, new products get created (and sometimes sunsetted) frequently. For instance, Google Cloud,—a service for software infrastructure—that competes with Amazon’s AWS. Similarly to Meta, early in the company’s history, Google’s ads platform was created, and later would be integrated into all of its pertinent offerings and acquisitions (e.g., YouTube, etc.).
This is all to say that it is possible to land a role at a tech company that allows one to make the work of one’s career, but these roles are not going to frequently be open to inexperienced designers, and so it can be very easy for these designers to not appreciate or understand that new products—and whole new verticals—are being made, but that it’s happening (sometimes very intentionally) in the background, unavailable to them so early in their careers, and sometimes not even easily visible to general consumers at all (e.g., in the case of enterprise offerings, which every day consumers might not even know exists).
To compare to smaller tech companies, during my time at a certain version controlling company for Sketch (80 employees), I worked on their second product (which was developed as a response to changing market conditions, as designers moved overwhelmingly from Sketch to Figma). Reflecting back on the time I spent building this new product offering for this company, it didn’t feel very differently to when I was helping shape the future of Twitter Blue, Twitter Communities, or defining the direction of Twitter Professional Publishers. This was a delta of 7000 employees, but the day to day just wasn’t that different. Product work is just product work—some products you make sell like hot cakes (hundreds of millions of DAUs every month, e.g., Stories). Some don’t (no DAUs at all, e.g., a text editor with version controlling integrations with Figma and Sketch).
As mentioned, the risks when working on a new product area at a company (e.g., Instagram Shopping, etc.) are very similar to ones experienced in small companies (and sometimes different, see: anti-monopoly legislation)—just ask the people who worked on Google Stadia (as is convention, when products are cut at Google, employees of eliminated teams are expected to find new teams on the condition that, in three months, that team transfer is made—if not, they lose their jobs). Similarly, when Meta was going through layoffs, there was wide speculation internally about the least well-performing investments in its suite of products, and which ones would be the most likely to be cut. What’s more, at its height, Twitter Communities had 40,000 DAUs. The eight-person startup I worked at 7 years ago had 150,000.
As mentioned, unsuccessful new ventures in established products can fail—just as startups do (see: Google Stadia, Twitter Fleets, Twitter’s Vine, etc.). If the product doesn’t show growth, or can’t easily be monetized despite success (see: Vine), etc., it will get its investment pulled—one’s job might go right with it, no more clear today than ever before. This can mean either a re-org (at best), or a layoff—in today’s climate, the reader can guess which is more likely to be the case.
Whether you worked on Clubhouse (100 employees), or Twitter Spaces (7000 employees at the time), you were creating a high-impact product that millions of people loved, were excited about, and was either generating millions in revenue, or attracting billions from venture capitalists. This is the kind of work you do at the height of your career. The employee count makes no difference: the impact does.
Certainly, part of how designers are evaluated at Meta in performance reviews is through proving “impact”—designers are expected to drive product strategies, prove that those strategies worked and had impact (you must do this with the extensive analytics data that you’re expected to pull), and that they impacted more than even than their own, immediate teams, too. The rigorous nature around proof required in these performance reviews can’t be overstated—frequently, when working on a small company with few active users, proving impact is very hard. The more robust a company’s analytics, the more that that burden of proof increases. There’s no hand-waving here. Designers, of course, are incentivized to do this at the cost of substantial bonuses and promotions—cash incentives to make the product better, essentially.
As designers up-level at tech companies (FAANG or not), it’s common to hear that designers “move away from just being executional,” and that we define entire product strategies. In the words of one PM at Instagram: “we don’t even get to do real PM work, designers take most of it off our plate.” At some tech companies, you co-create strategies with your PM—at others (like at Instagram), you are expected to lead it. Regardless, as you up-level, strategy work is increasingly under your domain, and role collision between PMs and designers increases, as mentioned in a previous article.
So, if you want “revolutionary work,” you’ll need to either:
Get lucky and find a Dylan Field and Evan Wallace in the wild and stick with them through the long-haul, or
Be your own Dylan Field/Evan Wallace and build that revolutionary product yourself, or
Compete at an established company (of any size) to get the chance to work on their inevitable, next market-gobbling product.
There’s no guarantee that, if you work at a small company, you’ll be given responsibilities that will push your abilities to its limits, anyway. There’s also no guarantee that the work you do get will be complicated enough—or even have a chance of product-market fit—such that you will be pushed to your upper limits and get career-making work. As it happens, you might be stuck in a situation where you’re merely executing on a founder’s vision (and it might not even be a good one), and you won’t be given any real room to contribute in your own way, as they simply aren’t interested in what you offer (some people call this “design not being given a seat at the table”). I’ve experienced this, myself, particularly early in my career, and is something I frequently help mentees strategize around.
What’s more, working at a non-tech company has no guarantees on this front, either. I’ve worked at “non-tech” software companies before, and my experience is that software just isn’t a priority—which is understandable, because software services are generally just cost sinks for these companies. Their core business models lie elsewhere—and there’s nothing wrong with that. Every business is different, and brick-and-mortar businesses can still provide enormous value to people. Nonetheless, though, designers (and other technical roles) at the companies are frequently considered “second class citizens,” when it’s the opposite at the majority of tech companies.
In one personal example, I recall working at a certain streaming service at a non-tech company—this was already a few years into my career, and I’d grown accustomed to working at tech companies and their expectations. I recall working on my first feature at this non-tech company, and a PM I’d never seen before approached me,—graybox wireframes in hand—shared a presentation he was looking to present to leadership about why this small feature ought to be worked on. He asked me if I could visually make it polished. I was surprised to find that this was a common work style at this company—I simply wasn’t expecting it. My hope for working at this company was that it could be a tech company inside a more dated institution, and so I had certain expectations from how I would work with PMs from my years of working in tech. My expectation was that I’d be embedded on a product area and work with a PM counterpart to co-create a strategy for the product, and the execution that would result from it.
As I pondered the curiosity of this situation, I recalled that it was consistent with the first non-tech company I’d worked at (my first in the software industry!)—“UX designers” would take orders from “POs” (product owners, sometimes they were called PMs) around what it is they were building, and the “UX designer” would figure out how the product would work, outputting that as gray boxes from something like Axure. Sometimes, the PM would make initial wireframes, and the “UX designer” might work to refine that. Eventually, the PM would sign off, and then they’d get approval to send it over to the “UI designers,” who’d transform those gray boxes into its polished form. Then those “UI designers” would make redlines, and send those over to developers.
And what a blast from the past! I hadn’t worked like this in years, at that point, and completely forgot that this setup tends to be quite common at non-tech companies. I’d grown accustomed to co-creating strategies with my PM, embedded on product teams together, and then getting full control over execution, and working directly with developers, who end up becoming more like technical PMs, anyway.
I was so surprised at the level of segmentation at this company but, when I considered that I’d walked myself back in time to where I’d started (at non-tech companies), it become crystal clear to me that these work styles do differ across companies that make software, and that I wanted a specific style. I wanted aggressive and accelerated growth, and I didn’t see that as being possible to achieve when working in a solely executional manner, where there’s no expectation of change, given how non-tech companies tend to organize themselves (e.g., designers and engineers are executional roles—the business people do all the ambiguous strategy work). I also understood why the compensation appeared so markedly low when compared against tech companies that make streaming services—it’s because this company just isn’t one in the first place.
For example, at an 85 year old bank and brokerage company that maintains online services for its users, not only will one be paid less than one’s tech counterparts working on digital products that perform similar functions, the innovation at that company won’t be occurring in the technology, itself: it’ll be occurring in its core, revenue generating business—its brick-and-mortar brokerage services.
By contrast, working on a “new-age bank” (some examples like Chime, Betterment, or related services like the Apple Card come to mind), you’d be working on an internet play—and so investing in its core value prop (its digital product) will be its highest priority. That software is the business—its where they source their users, and the economic activity of those users is their business model. For their business to work, they need users to want to retain and use their interface—they need you.
It is completely reasonable that these “digital transformation” companies simply don’t consider internet services to be as high priority as their core business—because, relative to the revenue generating parts of their business, internet services just don’t produce the same returns. Those famous banks (I will leave the reader to think of some examples on their own) don’t get the lion-share of their revenue from people transacting with their debit cards like the online, new-age “banks” frequently do.
Traditional banks make money via investing other peoples’ money. This is not usually by investing money from people who make salaries, like we do—but from enterprises that invest hundreds of millions, or even as underwriters for enormous loans in M&As. They move money across entire continents, have a whole fleet of people who dig just to find new sectors or opportunities to invest in—near and far. They work to lobby across all sorts of governments for more favorable investment opportunities for the company. Digital services are very low priority in the grand scheme of things for these companies, and understandably so.
They are not incentivized to provide incredible digital interfaces to people who store even a few tens of thousands in an emergency fund in a 3% APY savings account, like new-age banks are, whose business models rely on these people transacting with them. This is exactly why the boom in “fintech” companies have happened outside of these traditional institutions—those institutions have no real interest in consumer internet plays, and so they’ve left an enormous vacuum in consumer-facing finance software wide open for tech companies to innovate in.
What’s more, these “digital transformation” opportunities tend to require simple websites and webapps—they neither require a ton of complex strategy nor interaction work. As a result, one’s gains in these areas will generally be slower when taking on these kinds of projects. So if one desires to be pushed to one’s limits, build product strategies that catch the industry (and even world) off guard, and sort out uncommon, complex interactions, and so on, one may want to look elsewhere—perhaps a designer on a new Apple Card team, or at TikTok on one of its new products, or be the on the focused team on Reels, or a designer on FigJam, and so on. Working on these products is hard—and they’ll push you to the edge of your limits on all fronts: from product strategy to execution.
My advice to pre-career designers would, as a result, be to look for products that you really think some customers somewhere actually want—regardless of whether it’s being built by two twenty year old founders and a few employees (e.g., Figma), or by a focused team at a bigger company (e.g., Twitter’s Vine). Unless you have your own reasons for caring about the employee count, I wouldn’t worry too much about “incremental” versus “revolutionary” work—just find software you really care about, and go fight to work on it.
3. UX and UI design are separate functions at tech companies
I’ve talked about this at length in previous articles, but this is a common misconception—at most tech companies, designers are unlikely to be hired if they can’t produce software that makes sense, and software that is professional-looking. As mentioned earlier, designers are also evaluated on “product thinking” (some people call this “business acumen”)—incidentally, this trait is what PMs are also expected to demonstrate. (This trait is commonly understood to be less common in less experienced designers, and so the requirements around demonstrating it are usually more relaxed compared to what are called more “executional” traits, like interaction and aesthetic work.)
When you’re interviewing candidates on behalf of tech companies, you’re given information about the company’s hiring rubric—how you’re expected to evaluate designers. You are expected to check for competency in numerous areas and, at all the tech companies I’ve worked at over my seven years (from eight to eighty thousand employees), “interaction” and “visual” skills are always on those rubrics. To quote myself from a previous article:
In reality, you do not get to choose whether you are a “UX” or “UI” designer in today’s market. This is an academic discussion about a market that no longer exists — a luxury belief. The reality is that you are going to experience increased difficulty finding — and retaining — customers as a designer if you do not make professional looking work. When [tech] companies hire designers under titles like “UX designer,” or “product designer,” or “interaction designer,” these are all the same jobs: you are planning out how some software will work. But there is an additional expectation — not always explicitly stated — that you will put in the effort to make the product or feature look professional. There will not be an attendant visual designer at your beck-and-call to jazz up your schematics. It’s just you.
This is part of why many pre-career designers have difficulty finding opportunities at their preferred companies (e.g., tech companies), but are more likely to get them at non-tech companies—at non-tech companies, they tend to make simpler software (digitization of an already established, brick-and-mortar business), where tech companies create new and novel businesses that can only be consumed digitally. There is no physical analogue, and so strategies and interactions have less clarity. In addition, cultural expectations that naturally occur in tech tend to result in regard for brand and professionalism being put at comparatively higher priorities to these businesses (and their customers—see: Apple, for example).
Today, a sizable portion of pre-career designers often go through design programs (e.g., bootcamps and product design university programs), which are recent additions to the landscape. For numerous reasons, these programs tend to optimize for non-tech roles. Pre-career designers may not understand these nuances, and may expect that going through these programs may prepare them to be broadly hirable at tech companies, when this is not the case. As a result, they feel their expectations haven’t been met, become frustrated, and can’t figure out why they can’t get tech roles—instead, tending to be stuck with one-off contracts with founders that “don’t allow design a seat at the table,” or at workplaces with what some refer to as “low design maturity.”
What I always recommend to my mentees is that they focus on the jobs they want—as mentioned in the first section, if designers want to work at tech companies, one must understand what those tech companies want to see, and then work backwards from there. Rather than going through a middleman (e.g., a design program), best to do one’s own market research in order to determine what one’s customers want to buy, and then go and figure out how to sell it to them.
Closing thoughts
I have more thoughts, but I’ll stop here, as it’s gone on long enough, I think. For less experienced designers, tech companies (especially larger ones) can feel opaque, and they may be under the impression that “new experiences don’t get made”—that “only incremental changes happen,” and so on. It’s understandable why this misconception proliferates. There are only so many miracle stories of a couple of aw-shucks-to-be-founders kicking around ideas, only to end up starting incredible products that the world’s never seen. There are only so many Figmas and TikToks, and so on—so high impact work is something designers have to aggressively compete for, and have to be at the right time and place for. Like all investment vehicles, discovering them involves some amount of sheer luck.
My experience, however, is that tech companies (regardless of size) are the best places to increase one’s chances of finding that impactful and unusual work where, at more traditional companies where software is not the main product, lower priority gets put on these investments, and so there tends to be less support for them. Nonetheless, some people might want to try to convince these businesses that don’t require software as a core part of their businesses to change their strategies, or place increased importance on it, and I can understand that. They also offer great places for designers to get their feet wet, and learn more about what it’s like to make software—at least at some places.
Personally, I don’t think that every problem can be optimally solved with a technology play, and so I think it would be inappropriate to attempt to convince businesses that fall into this category of anything else. I don’t need every business to patronize my services. As someone who wants to work on software, I will simply refocus my efforts on to companies that want to do the same—where the services I provide can make a real, substantial impact on their user’s lives, rather than bang my head against reasonable suspicion and disinterest from tech-disinterested leadership. I would rather not force technology on to users, businesses, and investors who wouldn’t benefit a ton from it—that wouldn’t be doing right by them, or by myself. Not everything in my life needs to be addressed via some technology play. I’m happy with that.
Separately, I recall that, before I started working at FAANG companies, many assertions I made concerning various topics in various discussions were frequently dismissed on the basis of my immutable characteristics, as well as my work history. More specifically, my lack of experience at the big tech companies I now work at—I’d only ever worked at non-tech companies (or very small tech companies that no one really knew about). I recall specific instances where this fact was used in place of actual content in the assertions from interlocutors—not having worked at big tech companies, I just “didn’t get it.”
I’ve waited a long time to work at these big tech companies so that I could finally “get it,” too. Now that I’ve worked a few years at the very same big tech companies, however, I notice that my assertions are still dismissed based on my immutable characteristics and work history, but now for the opposite reasons: as I’ve discovered, FAANG designers can’t “think big,” don’t work on 0→1 products, and are just “glorified graphic designers” (don’t think I’ve ever been paid to even make one logo in my entire life, so this is news to me). So, just a warning to designers who have not worked at FAANG companies before, expect at least half of your work history to peace out and fade away the moment the muskbucks clear in your account. Them’s the rules.
For any designers who may be experiencing this same thing, and may be so inclined to inquire about when interlocutors will choose to specifically engage with the content of your ideas,—rather than your immutable characteristics or work history—I’ll just have to let you know when I find out!