The neurodivergent Big Tech survival guide

Editor’s note: This was the last internal document I wrote at Amazon. It was written with the mentees, mentors, and friends I left in mind. But the response was really positive, and it seems to have resonated with peers all over the industry, so I decided to re-title it, and share it here. That said, the rest of the content is unchanged and so naturally refers to Amazon, not Big Tech.

The best manager I’ve ever had likes to say:

Amazon is where over-achievers come to feel bad about themselves.

It resonates with everyone who hears it, because so many are relieved to find out that they’re not the only ones who feel this way. It’s liberating to realize that your struggles are not unique, relatable, but also (maybe?) manageable. This doc is an attempt to scale out advice I’ve given to AuDHD mentees lots over the last several years, and leave an artifact for posterity.

tl;dr

• Advice 0: The only way to get better at writing is practice. Writing is thinking. Don’t delegate either to an LLM.
• Advice 1: It’s better to be over-ambitious than over-pragmatic.
• Advice 2: Fake it til you make it. This feeling never goes away.
• Advice 3: Be wary of personal productivity tips, but especially backlogs and TODO checklists.
• Advice 4: Don’t swim against the current with your own brain.
• Advice 5: Impostor Syndrome is Good Actually. Embrace it.
• Advice 6: You know that what you chose to work on is the right thing to work on, because you chose to work on it.
• Advice 7: Pay attention to your hits, not just your misses.
• Advice 8: Learn this. Internalize it. Then give it away, and teach it to others.

Me

As I’m writing this, it is December 2025. I’ve been at Amazon for 12.5 years, but I’m leaving at the end of the month. I’m doing so in good standing, without any bridges burnt, and for reasons unrelated to anything in this doc. But if you have any questions about it, I’m not around to answer them, and whatever tool you’re reading this probably anonymized and scrubbed my personal details. They say the key to people thinking you’re a good writer, is to never let them see your first draft. Amazonians say I’m a good writer. We’ll see if they do after this doc, since this is my first-and-only draft.

Advice 0: The only way to get better at writing is practice. Writing is thinking. Don’t delegate either to an LLM.

My name is Nikki Pinski, I started in AWS in 2013 in YVR as an SDE2, spent 2 years on EC2 AutoScaling, relocated to the EU, spent 5 years building Pan-EU Inventory Fulfillment services, became an SDE3, moved back to YVR, spent 4 years on AWS EventBridge, became a PE, and have been on AWS Lambda for my last 2 years.

I’ve burnt out every year I’ve worked at Amazon. This is not a flex or a humblebrag. But this is where we start to tie my personal experience to our opening quote. I’ve had undiagnosed AuDHD my entire life, and I constantly struggled to adapt and find balance. The only way I found a path to career success is to go through burnout and recovery cycles. This is a familiar concept, we’ll just focus on it here through a neurodivergent lens.

I finally got diagnosed and medicated for ADHD in 2023, which stopped the cycle for me. The expression we neurodivergent people hear is we need “skills and pills”, and it’s true, I needed both. This doc is about the skills, the pills you’ll have to sort out for yourself. In 2024, my 6-year old son was diagnosed on the Autism spectrum, and in another cliche experience for parents with autistic kids, I realized “oh no, the call is coming from inside the house”. So we’ll talk about skills for both.

Thesis

Another quote that floats around here:

At Amazon you will be asked to do 100 things. 20 are actually important. You will have time to do 5.

This feels like a trap. When you’re new here, you probably confront and accept the first half of this message quickly. We hire people with high judgement and empower them with autonomy. So it makes sense that part of the job is to identify this list of 20, and one may even delude oneself for a long time that this procedure is objective and data-driven (it’s not, but we’ll get there).

It’s the second half that gets ya. How to pick the 5? (hint: it’s not whichever are the most urgent, though that’s not a bad starting point). More importantly, how to accept letting go of the other 15? Most importantly, what to do when you don’t — when you keep a longing somewhere in your heart for those other 15 — an awareness of all those things that are “just below the line”, that you hope to bring up above the fold when the time is right?

Dealing with Ambiguity & Autism

Note: Section still useful even if you’re not on the autism spectrum. If only to gain some empathy for your peers that are.

“Dealing with ambiguity” is a core competency for Amazon engineers that we still evaluate SDE1 candidates for. But this company embraces this idea way beyond just giving employees undefined tasks and empowers them to figure them out. A large number of cultural practices are designed to be flexible in a way that surprises and challenges particularly those of us on the spectrum.

A ubiquitous but unwritten rule is that teams/orgs are only supposed to meet 70–80% of our goals every year. If you meet more, you didn’t set your goals ambitiously enough. Extend that down to the 2-pizza team level, and you’ll see a fairly frequent dance: teams overcommit to a rigorous schedule. We “work hard, have fun [citation needed], make history”. Dates set before Q4 always slip. Always. Until we get to re:Invent (if at AWS), and finally comes a date that we simply cannot miss. And so we don’t — we descope a few things and call them post-launch “fast-follows”; we escalate to our leadership to help with dependencies that had become risks. Against all odds, we ship. Every re:Invent launch I’ve ever been a part of, at some point in the late summer or early fall, its team members believed that it had no chance of launching in December. All of them did.

How is this possible? I’m only lightly exaggerating when I say that every single Amazon project launch gets delayed, except every single re:Invent launch, which ships. It sounds like we have a lever that we’re able to pull when we need to, but choose not to most of the time. We can debate whether this is a healthy way of delivering software, but what’s important is to accept that all of this is by design. I find that neurodivergent engineers, especially early in their career, really struggle with this. Society says things like “it’s better to underpromise and overdeliver”. Yet working at Amazon feels like a constant exercise in the reverse, which can easily start to feel like delivering here is an exercise in constantly disappointing your managers, your organization, and your customers. But if this is how it works every time, it isn’t a bug, is it.

Advice 1: It’s better to be over-ambitious than over-pragmatic. Which means it’s better to cut scope at the last minute than add more. And that means delaying for the sake of that ambition, until it’s time to finally hit the date. Cutting scope at the last minute feels bad, but somehow even that almost never becomes the most important thing to build next once the software is in customer’s hands. And escalations are not failures. A director’s entire job from October to December is effectively dealing with escalations. Remember the quote from our Thesis — everyone has too much to do and not enough clarity with how to choose it (we’ll come back to that under Judgement & Responsibility later). Leadership escalations is how these things get sorted out when it’s time to hit the date. The rest of the year, leaders tend to not get involved, instead optimizing for the autonomy and agency of individual teams to make these judgments. This is liberating when it’s given to you, and infuriating when it’s given to a team you’re dependent on. But if you remember that you’re being treated equally, it’s less painful.

Discovering unexpected problems that add more time to the project is not unexpected — the level of ambiguity all of our engineers are expected to handle necessitates this discovery regularly. Everyone is challenged at every level here. This is where career growth happens. Thriving in this environment means accepting that it’s normal. I speak to SDEs who will say “My manager gave me this task, but it’s so much harder than we expected. I don’t want to have to tell them I’m behind because then they’ll think less of me and wish they’d given it to someone else.” I retort with “Invert the mindset. How lucky is it that your manager gave you this task to someone who was able to discover all the unexpected reasons for its complexity. You get to now educate them and your team about all the interesting challenges and ways in which you’re actually doing something novel and off the beaten path.” Advice 2: Fake it til you make it. This feeling never goes away. My entire career here from SDE2 to PE, I’ve been given ambiguous tasks that I had no idea how to start, and became much more complicated than me or my manager ever intended. The only thing that changed is my confidence in knowing that I’d figured things out before, so I’ll probably do so again.

The hard part is always in the getting started…

Bias for Action & ADHD

Note: Section still useful even if you don’t have ADHD. If only to gain some empathy for your peers that are.

When you have ADHD, Motivation comes from one of only four things: Interest, Novelty, Challenge, or Urgency. I’ve seen Belonging get added to that list recently, which also resonates. It’s why mirroring is an effective tool for productivity and dealing with executive dysfunction. It’s also why we are motivated not just by personal goals, but some notion of a greater good — to not let our team down, to delight customers, etc. It’s obvious that Amazon offers plenty of Interesting, Novel, Challenging, and Urgent work. What’s less clear is how to choose between these if given the opportunity, and not devolve into analysis paralysis.

Some Leadership Principles are innate, like Ownership is to me — I like to care a lot. But I had to learn how to apply Bias for Action after going through a particularly bad rut of analysis paralysis. This gets only harder the more senior you get at Amazon, so figure out a few things early. Here is some advice for executive dysfunction struggles at Amazon:

Advice 3: Be wary of personal productivity tips, but especially backlogs and TODO checklists. Those instead become demands, and priorities shift all the time anyway. Instead, keep a loose document of “important things” that you probably should be doing — 2–5 items, and review it regularly (weekly), as well as after every time you finish something on your list. Re-sort it based on a mixture of what’s Interesting, what’s New, what’s Challenging, and what’s Urgent. How? Listen to your brain, and listen to your gut. It’ll tell you what it wants to work on. Don’t fight it. When it tells you it doesn’t want to work on that thing anymore, switch to something else. Trick yourself into productivity by procrastinating on the most important thing you have to work on with the 2nd most important. The priority is not objective anyway (again, see Judgement & Responsibility later). In this mode, everything on your list takes longer than you think it should individually, but the combined list gets done in record time. If you have a manager that understands how we ADHD monkeys work, they won’t be surprised. If you don’t, they’ll figure it out after the first couple of times. This is a stressful way to operate, but IMHO it’s the only way to thrive — don’t fight your brain. Medicate it, then listen to it. When something new arrives that needs to be done, don’t try to remember it, and don’t try to prioritize it yet. Just make one decision: Is it the most important thing? If yes, drop everything and hyper-focus. If not, write it down on your fluid document, and put it right at the bottom. When you next review the list you can decide where you actually should prioritize it.

Deadlines also help. Luckily those will happen whether you want them to or not, (we’ll talk later about Amazon’s relationship with goals & deadlines under Dealing with Ambiguity & Autism). The worst thing for all of us with ADHD is The One Task — the one that’s so much more important than anything else, that you really really can’t justify procrastinating on it for the sake of something else. My recommendation? Procrastinate on it for the sake of something else. Advice 4: Don’t swim against the current with your own brain. The preceding paragraph still applies, but just make sure to pick something that is distracting but not energy-draining. It can be something non-work related but dopamine-generating like a sudoku, or it can be work-related but constrained (like reading a wiki, watching a PoA talk, or doing a code review). The key is this: Don’t try to lie to your brain by getting it to do something too far before the deadline. It won’t cooperate because it knows the truth. If you have 4 days to do something that you know will take 1 day, don’t start it on Day 1 trying to “get it out of the way”. Start it on Day 3, and only do the outline, the bullet points, the highlights. Once the pieces are fleshed out, go finish it on the last day.

This sounds risky, and it is. Every successful neurodivergent Amazonian I know does something like this.

Self-awareness

Learning to understand your own strengths and weaknesses is not something I can help you do with this guide. What I can do is tell you about the strengths and weaknesses of many successful Amazonians I know, and hope you believe me. Most procrastinate. Most learn how to trick themselves into productivity. A tenured AWS L8 I used to know liked to get his EA to lie to him about the dates of doc reviews with his VP, so that he would write the doc ahead of time with urgency (and not actually the night before the real review). Lead with Empathy is not a PE Tenet aspirationally — PE’s tend to be highly empathetic to the struggles of our engineers, because we go through them too.

A huge one for this is Impostor Syndrome. Whole TED Talks exist about how to get over impostor syndrome, and most of the discourse I’ve always heard about it is all about “how to get over it” (usually via a form of self-confidence, or “fake it til you make it”, which I already covered). I’m going to zag again here and say Advice 5: Impostor Syndrome is Good Actually. Embrace it. Instead (a pattern emerges), accept it, and recognize that it is ubiquitous at Amazon.

I once had lunch with a friend at another Big Tech company you know. He said “I work with the smartest people in the world, and they really know it too. Their confidence inspires me.”. I said “That’s funny. I work with the smartest people in the world, and they are riddled with impostor syndrome. Their humility inspires me.” Maybe both have their place, but I certainly prefer Amazon’s way. When I first got promoted to Principal, and joined their slack room, someone else from the newly promoted cohort asked if other principals feel impostor syndrome about being in this community. James Gosling (this is a wikipedia URL, not a phonetool one) spoke up and wrote about how often he feels impostor syndrome. Another Distinguished Engineer (who is still here so I won’t embarrass them by tagging) wrote at length about his experiences with the same. These people weren’t being performative. They were highlighting that we are a team, and we all have something to learn from one another. Does an L10 have better judgement than an L7? Probably. Are they more of an expert on the project the L7 spent their year on and the L10 spent 20 minutes reading a 6-pager about? Certainly not.

Most escalations result not in decisions or overrides, but empowering an existing subject matter expert to move forward without road blocks. Most leaders when asked for help will ask questions, and ask what you want to do, not tell you what to do. Because the default path forward is to find a reason to trust the judgement of one of the people accountable for delivery.

Judgement & Responsibility

“OK”, you say, “You all have impostor syndrome like me. But that doesn’t help me actually know how to use my judgement. You started all this by saying I have to pick the right 5 tasks from a list of 20. You said I shouldn’t fight my brain on what it wants — picking from some miso soup of Interest, Novelty, Challenge, and Urgency. But how do I actually know if I’m working on the right things?”

OK. This next part is targeted more towards the L6+ cohort (if you’re more junior, you can still just ask someone more senior than you). Forgive me in advance, this is probably going to be the most infuriating part of this doc for a neurodivergent.

Advice 6: You know that what you chose to work on is the right thing to work on, because you chose to work on it.

I know, I’m sorry. Yes, it’s tautological. That doesn’t make it any less true. You are where you are at Amazon because of your accepted strong sense of judgement. You wouldn’t have gotten this far without having been Right a Lot. Whatever area you’re working in, you probably understand it deeper and better than your manager or your nearest L+1 IC. If you are getting a lot of feedback on what you should be doing, then you’re not asking the question that started this section. If you are asking this question, it means people have stopped giving you feedback or stopped asking you to justify your decisions.

I’m so sorry, it appears that you’ve Earned Trust. This can actually be terrifying the first time you really notice it. Technical seniority is lonely. People give you less feedback. People don’t even tell you if they would’ve done something different from you, even if they would have. (Usually thinking some version of “Well, that’s not how I would’ve done it, but that doesn’t mean it’s wrong.”). “Trust but verify”, yes. But they verify your process, not your conclusions. People want to know your tenets, your mechanisms, your criteria. The final decisions are yours alone. There is no one to ask except yourself.

Failure

That doesn’t mean you’re never going to be wrong. It’s Are Right a Lot, not Are Right All The Time. You just probably won’t know for a long time. Having a ton of responsibility, no safety net for judgement, enough empathy and self-awareness to be constantly vocally self-critical, and goals that over-index on ambition is a recipe for noticing more of your failures than your successes in the rear-view mirror.

Advice 7: Pay attention to your hits, not just your misses. There are probably some people who need the opposite advice, but whatever, I’m not writing this for them. People will rarely come back and tell you when you gave good advice and it led to good outcomes. But you will also rarely hear back from people when you gave bad advice and things went badly. After all, that feels punitive, and we have a blameless post-mortem culture, don’t we. Instead I find you will only get future feedback about your decisions when you were right about something but people didn’t listen at the time. For some reason people feel safer sharing that, even if the only lesson to take is seemingly to “increase backbone”.

That means you have to take active steps to verify your choices. Feature adoption, service metrics, team job satisfaction scores. Ask your peers for the outcomes of the feedback you provided. Note and celebrate your successes in influence, and in judgement separately. Note the failures too (but again, you’re probably already doing that).

Leadership

The best leaders are doers not talkers. This doc is doing a lot of talking, with the goal of tricking your brain into cooperating so you can Deliver Results. All Leadership Principles are equal, but some are more equal, and we all know it’s that one. AuDHD people can get a lot of stuff done in crunch time, but it can be very easy to fall into the trap of being the engineer that everyone relies on before launch, that everyone goes to with questions for every design review, but not actually be perceived as a leader. The perennial SDE2 on a 2-pizza team, or the SDE3 that people wish we could promote to SDE4 instead of PE (a conversation for another day). There are many parts to avoiding this that can be its own doc, but in the context of the advice here, I want to come back to our thesis quote: “You will be asked to do 100 things. 20 are actually important. You will have time to do 5.”

My personal “TODO” text file has bullet points on it accumulated over a decade. OP1 Ideas I want to write up. Small bugs or feature ideas in my services that I could do at a moment’s notice that may already be in a SIM backlog somewhere, but just as often are not because they will never get prioritized. Unless I show up with a code review, in which case they would be happily merged. This may sound reckless, or that I’m abusing the trust I have. I don’t agree. Every SDE at every level can do this on their scale. The important thing is to learn (through time, practice, and careful management of one’s regulation via this doc) when to pull something from that list and just do it.

And just as importantly when to pull something from that list and give it away. This isn’t supposed to be a hoard of knowledge to make you look good. This is a personal collection of trinkets ready to be turned into gifts. When you talk to engineers more junior than you who are looking for ways to differentiate themselves, to find something to drive and own, you share these ideas, and see what resonates with them. Use them to seed discussions, to remix, to own. This is how we exemplify Ownership, and inspire it in others. Advice 8: Learn this. Internalize it. Then give it away, and teach it to others. IMO Leadership is modelling this for others once you master it yourself. The best output of senior engineers is more senior engineers. If someone mentored you to get you promoted, you better be mentoring others to pull them up behind you. If anything in this doc helps you cope, survive, then thrive at Amazon, augment your own personal stories, and see who you can help next.