So you left a startup to work at a big company
First, congratulations. I hope you’re excited about your new role and teammates, and the area you’ll be working on.
The following is general advice for people who have spent many years of their career in startups or small companies, and have now joined a big company. By “big company”, I mean a company of several thousand people at the very least — large enough that you couldn’t possibly know even all of the executives there. I assume that you’re also several years into your career: much of this advice may be invalid if you’re less than ten years out of college.
I’ve worked at three small startups — one of which I founded — and three big companies in my career so far. That has given me a good look at how startups and big companies are different, and how you — startup veteran you — may want to modify your behavior and expectations as you enter the strange new world of big companies.
Relationships, not products
Startups are often in a state of moving quickly, even frenetically, to get a product out the door. Even when the startup is later-stage, and some degree of product-market fit has been found, a similar company culture may exist — the emphasis may be on shipping a product, even at the expense of work-life balance, and at the danger of fraying relationships within the team.
At a big company, products come and go, and there are generally established products built over years that are still bringing in revenue. There are exceptions to this rule — notably game companies that work in a hit-driven, high revenue drop-off industry, and therefore have a constant pressure to ship new games (I’ve written about this before). But at many other big companies, there is less urgency to ship a product in the shortest possible time. As a result, the focus is much more on building strong teams, with good interpersonal relationships, than on getting any single product launched.
Your goal should be to build healthy, collaborative relationships with the people in your direct team, partner teams, and your management chain. Shipping meaningful products will come as a consequence of, not before, these relationships have been created.
Resist the urge to jump directly into the “getting things done” phase. Your first few months should be spent just understanding the lay of the land: which areas are of high strategic importance to your organization, and building relationships with key people. That understanding will be helpful to channel your effort into the areas that have the most impact. Recognize that simply shipping products is less important than working on things that actually move the needle.
You may be seeing this effect in action if: you find yourself thinking how slow the pace of work is at your new big company employer, and why people seem to spend time on so many activities beyond building the product.
What you should do: You should set aside time every week to meet people and grow relationships. Have informal lunches with people, take people out for coffee, and be friendly and helpful. The effort will pay off in the long term.
Specialists vs generalists
For many people, one of the most attractive aspects of working at a startup is the ability to take ownership of broad areas of the product or company. When you come to a big company, you should recognize that you are entering an environment where deep specialization is valued. You may find that some of your co-workers have relatively narrow areas that they know a lot about, but what you may consider to be huge blind spots — areas that you think are important but they know nothing about. Worse — at least from your perspective — they may not consider it important to understand those areas. So a backend engineer may have no knowledge of, and no interest in, user personas, A/B testing the UX design of your product, or the technologies used to build rich client-side web apps. They may not even know about common open-source backend technologies in their area of expertise.
At first glance, it may seem that this narrow range of knowledge is a failing of the people working at big companies, but it makes sense for the environment. There are multiple possible reasons for what you’re seeing.
Established, popular products — the sorts of products that many people in big companies work on — are often the work of many, many teams, none of which has authority over the entire product. Even seemingly small features may have hidden complexity that comes from having to serve millions of users: having to work on a variety of user systems of different computational power, screen size, and supported input methods, for users in dozens of countries, timezones, cultures and languages, and at high scale. Deep specialization is often the solution to this problem of enormous complexity: it allows people to focus on doing a small set of things very well, rather than many things moderately well.
Another reason for specialization is that many people in big companies never actually work on an external product: they work on internal products, or infrastructure services that are consumed by internal and external products. In such projects, a broad set of areas that are necessary for external-facing products — product positioning, marketing, competitive analysis, excellent UX — may be less relevant, or not relevant at all. People who have been working on these sorts of products for years may be deep experts in their domains, but they may not know or care about many areas relevant to external products. Conversely, they may have deep insight into internal technologies and team structures that may be helpful for your growth in the company.
You may be seeing this effect in action if: you find yourself thinking how your teammates could possibly not have known about that incredibly well-known topic that any well-rounded person working in technology should have known about.
What you should do: You should re-calibrate your understanding of what topics are necessary to know for people in a big company. A secondary activity may be to identify topics that you yourself need to know more about — such as how a coherent large organization functions — and work on deepening your understanding of them.
Building for iteration vs building for scale
Startups are often exploring a large solution space in search of product market fit. This is a highly complex problem, written about extensively at places like the First Round Review blog. I’ve written a series of posts discussing how startups can organize themselves to more effectively search the solution space in their domain.
The primary purpose of the technology at a startup is to enable rapid iteration while exploring the solution space. Building for scale is probably not necessary immediately, and even when it is, scaling can be accomplished quickly with well known techniques. The key measure of success is whether some degree of product market fit is found before the money runs out.
At your new employer, most teams are more likely to have a “build it and they will come” mentality. They may be working on a new feature for an existing, established product, or they may be working on a new product, but the expectation is that whatever they are working on is likely to be successful. This belief may be warranted based on the company’s historical ability to launch successful products.
The people you work with, then, are likely to be more concerned about building a scalable system that anticipates long term needs from the very first version rather than a system that can be quickly modified as new market needs are uncovered.
Whether this attitude is justified or not depends on the context of your team and product. If your team does work on an established product, or one for which it is known there will be significant demand and well-understood customer needs, the methodical approach of designing for scale and long-term requirements from day one makes sense. Many teams in big companies work on products that fit this profile. But big companies also work on many speculative projects where long-term customer needs and demand is unknown, and a typical startup attitude may be more appropriate there.
You may be seeing this effect in action if: your team creates (what appear to be) over-engineered solutions that have no immediate customer applicability, rather than shipping an MVP and iterating.
What you should do: Consider which type of area your team works in. It may be that your team’s approach is actually well-suited to the type of product you work on. If you are working on a new product, it could also be that an iterative, startup-like approach may be more appropriate. If the approach your team follows seems ill-suited to the problem space, use the relationships you’ve built previously to advocate for change.
Working in a big company can be challenging, exciting and rewarding. Modifying your expectations and behavior to match your new environment will help you be successful and happy there long term. Good luck!
