The Unexpected Reality of Working in Top Tech
5 bizarre things you wouldn't expect in top tech and how to deal with them
Hi folks,
I wrote a LinkedIn post a few days ago that really took people by surprise.
A few people disagreed.
But a lot of top tech PMs had similar experiences.
Some wrote to me privately to thank me for voicing the same frustrations they had over the years.
And many of the readers who haven’t yet worked in top tech were shocked.
They had an idealized vision of Google and a dream of working there to “finally do things right”.
Maybe this is also your dream.
So today, I want to:
Go deeper into what you can expect as a PM at a top tech company
Give you some practical tips on how to deal with these realities
[Shameless plug] Tell you about a new PM Resume course I’m launching
This will be a long write-up (and one you should re-read when joining a new team, especially at a top tech company).
Onward! 👇
Revise Your Expectations
1. No processes
I mentioned that there are often no project management tools, and people tend to plan and track projects manually in spreadsheets and docs.
Project planning, review and launch processes are rarely actually written down and often passed down “from generation to generation”.
Giant launch checklists and systems do often exist in some form, but these are usually not tailored to the specific product or project you’re working on.
A good PM’s natural inclination here would be to suggest a process for what’s needed.
The problem is that to create a process that works for your org, you have to coordinate it with teams above and below you in the organization (and often sister teams as well).
And working on, or “landing”, such a process will not get you much (if any) promo credit.
So people tend to either push their projects through “manually”, or get lost in the mess of it all.
Practical tips:
Correct expectations are half the battle.
If you join a shiny MAANG company and processes are manual, random or nonexistent, don’t panic.
Don’t spend three months in shock and unable to execute.
Instead: 👇
1. Figure out the lay of the land
As you start, ask your manager, skip manager, PgM, eng lead, eng manager and other key XFN leads for how they see the processes currently in place.
During one of your first 1:1s, ask them to walk you through all the processes that will be important for you and your team:
quarterly and annual planning,
customer and exec escalations,
collaboration with other teams,
resource and headcount allocation,
product and project reviews,
launch reviews, etc.
2. Capture the status quo
If a clear document outlining each process doesn’t exist, write it up, and make it as short as possible (ideally, less than 2 pages).
Identify the inconsistencies and contradictions in these processes.
Propose simple ways of resolving these.
(Notice, I didn’t say anything about finding and resolving inefficiencies, we’ll tackle these later).
Combine related processes into one doc, where necessary.
Ask each one of the people you interviewed for this to confirm you captured everything correctly.
Ask each to confirm or suggest alternatives for your proposed changes.
3. Plant your flag
Combine the docs together or link to other relevant process docs from each one.
Put your name and email on top.
There, you now have processes.
They may be clunky and manual, but at least they’re codified.
Now team members can easily find the next action to take in most situations.
4. Use the processes!
Don’t attempt to find and improve any deep inefficiencies or problems yet.
Yes, your processes are slow.
Yes, they’re often manual and cumbersome.
But you know what to needs to be done and in what order.
Follow those steps for 2-3 quarters to really feel out the inefficiencies.
5. Make changes for outsized impact
Now that you and your team have experienced these processes in all their glory, it’s time to make some tweaks.
Don’t rehaul the entire plan.
Find the biggest process pain points, and stack rank them by smallest effort to address.
You want the biggest improvements in productivity and efficiency you can get by making the smallest possible changes to the processes themselves.
Poll the XFN team for any objections to your top suggested changes.
Reorder your stack rank based on substantiated and reasonable objections.
(This means you will now have fewer total process suggestions that have strong leverage of strong impact for low effort).
Make the changes in your doc; let the team know.
Repeat every few quarters, as needed.
2. Default to NO
In my post, I also spoke about the fact that any idea for a new feature, update or product is likely to face an uphill battle.
As was pointed out by plenty of readers, this is not just a MAANG problem.
This is the status quo for most large organizations that have managed to scale to tens or hundreds of billions of dollars in revenue.
My aim with this observation was to point out the extreme inconsistency between this approach and the hiring philosophy of these companies.
Most top tech companies want to hire “0 to 1” people that are creative and innovative.
But the reality is that almost no products you work on inside have anything to do with “0 to 1”.
Practical tips:
Disclaimer: Innovative teams and products do exist, even in big tech companies.
But they are very much the exception, and not the rule.
For the majority of those joining a MAANG company — if you’re hoping to build “0 to 1” products, you will be disappointed.
You should know what you’re getting yourself into.
You’re not there to break new ground.
Accept it.
This is a tough pill to swallow for a lot of entrepreneurial product people.
Especially those that are used to building from nothing.
Especially those that get caught up in this “Innovator Myth”, perpetuated by top tech companies.
There is opportunity here, if you understand where you really are and why you are really there.
But if you refuse to accept it…
If you continue to push for innovation within a structure not designed to support it: you will continuously struggle.
Don't die on that hill.
Recognize the landscape, and find ways to make meaningful contributions within the framework that exists.
3. Quarterly development cycles
This is extremely important for new incoming top tech PMs to understand:
Agile processes are poorly understood and rarely implemented in these companies.
But at the same time, people take on a huge number of projects and are often pulled in a thousand directions.
Everything must be coordinated between the members of the team and between any teams you are collaborating with.
As a result, people tend to think about “quarters” as the basic unit of development cycles.
Engineers and engineering managers (and certainly directors) have a few key deliverables for each quarter that they “must” hit.
These are called P0s.
Everything else is basically optional and will be done on a “best effort” basis.
Then, there are the reviews.
Depending on which area you work on and how closely it’s tied to the beating heart of the revenue generator of the company, you are going to face a litany of reviews.
Product reviews, design pre-reviews, design reviews, exec reviews, etc.
Oh, and planning for the next quarter is done in the middle of the current quarter.
So you’d better have your product designed and approved by mid-Q2 if you want to make the case that engineers should work on it during Q3.
Practical tips:
This one’s simple:
Learn to think in quarterly development cycles, and plan accordingly.
This is antithetical to running your own business or startup.
But don’t fight it here.
Don’t try to sneak something in, “just this one time”.
Instead, pick your battles.
Make the case that your projects, features, bugs, workflows and initiatives are P0.
Then defend those P0s.
And make sure they are always stacked right on top of the list.
(Because bottom P0s have a tendency of magically converting into P1s as the quarter goes on).
If this pace is too slow for you, just parallelize.
Do more things over a longer time horizon.
Ironically — the faster you adapt to the glacial pace at these companies, the faster you can actually ship products and grow your career.
4. No automation
This area is yet another “catch-22”.
People and teams doing things manually is obviously inefficient and ridiculous for such behemoth companies.
But investing in automation of any kind requires building out infrastructure and systems.
These projects must also be prioritized, planned and developed.
But if you need something done sooner, you can’t wait X quarters for these systems to be built (see #3).
Practical tips:
My recommendations here are going to be largely the same as for #1 above (no processes).
Don’t rush to automate everything and re-create the wheel with your team or product.
Take your time and do the manual stuff (or watch it done).
Make sure you can tell apart the actions which could be automated with those that could be automated easily.
Then make those easy changes that make the biggest impact to the speed or quality of your development.
5. All eyes on the competition
By far, the most important impetus for movement within certain top tech companies is competitive pressure.
The extent to which this affects the company can vary, but it always plays a heavy role.
Here’s where you’ll really be spending your time in big tech:
“What are competitors doing?”
“We invest only if competitor A invests.”
“We develop only if competitor B proves product/market fit.”
“We wait until competitor C makes a decision before we make ours.”
Once again, this completely makes sense from the perspective of risk minimization and profit maximization for the corporate entity.
But does this create one hell of a frustrating experience for an actual “customer-oriented” PM?
Absolutely.
Practical tips:
Don’t pretend that you’re operating in a blue ocean.
Research and understand the competitive environment for your products and company.
Remind yourself of just how much of your VPs net worth is tied up in not making the wrong decision.
If you’ve never thought about it, the VPs and SVPs at top tech companies have a net worth of $5-10-20-100M+, depending on their tenure at the company and previous experience.
Most of that net worth is held in stock at the current company.
So look at it this way:
What feels like a trivial business or product decision for you would suddenly become a very real dilemma if you had to bet $10M of your own money on it.
The very act of making decisions itself would become dangerous.
The safest thing would be to do nothing, and preserve the status quo. 🛑
Enter your competitors:
If competitor A enters the market or drops their prices or takes another meaningful action…
Now your revenue or profitability or growth is at risk, making the status quo (doing nothing) more dangerous.
Then, suddenly, making a decision (right or wrong) becomes the safer option.
So learn how to integrate competitive analysis into your product thinking and help your stakeholders make the right decisions (for their wallet and your product).
That’s all for today, folks!
Let me know what you thought and please share this email with a friend who dreams of working at the top tech companies.
And if you still want to be a PM, check out this new course I’m making on how to create the perfect product manager resume. (There’s a special offer for the first 100 buyers!)
Want to know if YOU will make it in top tech?
In the next email, I’m going to answer this question and share the top personal traits and skills that will make you most likely to succeed and thrive at the top tech companies.
Thank you and I’ll see you next time! 👋
-Alex
If you find short, daily product management tips helpful, then follow me on LinkedIn and Twitter. I post a few short tips each day.
For more in-depth coverage of the product management craft and career, subscribe to my YouTube channel. I post “how-to” videos weekly.
Click here and follow me on LinkedIn.
Click here and follow me on Twitter.
Click here and follow me on YouTube.
Thanks again, and please feel free to write for any reason!