Skip to content

Instantly share code, notes, and snippets.

@briantliao
Last active January 21, 2021 00:48
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save briantliao/d8b44142f73f6d4a72f1cf2c4c64e2a3 to your computer and use it in GitHub Desktop.
Save briantliao/d8b44142f73f6d4a72f1cf2c4c64e2a3 to your computer and use it in GitHub Desktop.
  • SDE, L6, 5 YOE, 290K TC
  • For SDE3 Promotion, Consider working on self-projects based on impact instead of projects defined by leadership. If a customer ends up using it, it looks good from a Think Big perspective. It is powerful to have management trust you with these side excursions.
  • Don't Switch Teams. If you are happy with your team, work, and manager, having reputation in your organization compounds. Other managers will know your name and that you are good. This is worth a lot at promotion time.
  • Get good at writing narrative prose for each decision you make. Make it visible across the org. If you don't have a document for your feature, it can be misunderstood as unimportant.
  • Become social with your team. Laugh. Smile. Show yourself on camera. Tell jokes. Look for every opportunity to publicly call out your coworkers when they do something good. Defend your teammates. They are going to war with you. When they wake up in the middle of the night because you pushed some shit too quickly they won't care as much. When you leave it will be with a knot in your stomach and a collection of friends for life.
  • When you fuck up, own it like no one you have seen. Drop everything and fix it. Volunteer to write the COE. Don't blame others in the COE, shine a light on how shitty your mistake is.
  • Get a best friend at work. Try to get on the same team as that person. You will enjoy your time and job much more.
  • Answer tickets cut to your team even if you are not oncall. If you are up late at night or early in the morning bored there might be a customer from other time zone who just cut a ticket. They will be super grateful for any after hours response, and you will start to be known as someone who is always there for the customer.
  • Customer obsession is not a cheesy catchphrase. If you are obsessed about customer and shape or create your product to align with their desires, you will be successful.
  • SDM, L8, 20 YOE, 900K TC
  • Learning to empathize with others is an important skill in learning to lead, understand, and influencing people. Understand that everybody has their own perspective on the situation they are in.
  • Becoming an L8 Engineer is about scaling yourself and your team to be better because you are there but able to execute day to day wihtout you. Senior leaders must be broad, but also deep. Establish mechanisms to keep in touch with details while also setting an accessible vision your team can resonate with. An example is program reviews of critical initiatives (S-team goals, demand generation projects) and have your leaders write crisp program review docs with statuses and risks.
  • The idea of frugality is to drive innovation. It forces the trade offs of things that aren’t truly needed to deliver remarkable customer value. Frugal is not cheap. Shipping a car with 3 wheels is cheap. Shipping a fast, fun sports car without flame decals that would have added a month to the schedule and 5% to the cost is frugal.
  • At high level positions, you need to build trust over multiple years with an organization. In the first 10-15 years of your career, you’re building the foundation of relationships and experience that your truly big earning years will come from.
  • Find a team whose values and purpose you really agree with. Try to understand what the big picture is for the team; what they are trying to do over the next 2-3 years, not just what’s happening in the next quarter and whether you can put that in your promo doc. Caring a bit about the bigger picture helps not only with your visibility at that level, but also with your ability to really impact it.
  • Useful skills to be a manager are writing well, being able to resolve product definition ambiguity and give dev teams useful guidance on what to build, and communicate exceptionally well. Second, they recognize where their gaps are (which are usually related to operations and the mechanics of operating a dev team). You need to build trust with dev teams and the team will be invested in becoming successful.
  • To maintain work life balance, learn to manage expectations. Managers don't magically know what your capacity is. If you’re being asked to do too much, reset expectations with your leadership. If you say you can deliver something and then can’t get any sleep, why did you commit to delivering it?
  • One path is going from engineering to management early (5 years in). From there incrementally taking on more responsibility. One key is finding bosses you respect and can empathize with. When you genuinely work to deliver and help your senior leadership achieve through your own efforts, the right things will happen.
  • You don't have to be a ‘yes person’. There is nothing wrong with pushing back regularly when you don’t agree or understand. Building that rapport is critical. And that takes time; over a career length. This allows you to build a huge amount of trust. With that trust comes scope, responsibility, and commensurate remuneration.
  • When a team solves a tricky problem or meets a key milestone, I email a note to my entire org (copying my boss who love to hear about success stories) talking about what we did. When you celebrate the success of your team, you’re also celebrating your own success. Don’t over think it; your boss is successful in part because of your success, just as you are successful because of what your team delivers. Think of how they are reflecting that to their own management. Senior leaders are smart, they know what managers have to do to have their teams deliver.
  • If you are introverted, one area you can focus to scale impact is docs and focus on your writing. What this also does is force you to really think through a given topic, so when you do need to have face to face interactions, you have already thought through most of the likely questions. Design reviews, COEs, PR/FAQs. Getting that good at docs will help your ‘dive deep’ and provide great artifacts for future promo portfolios.
  • Escalations aren’t a bad thing at Amazon, they’re a consequence of our distributed ownership model that we willingly accept. And needing to escalate doesn’t signify weakness or coming up short as a TPM. It's better to premature escalation than showing too much ownership and ending up drowning.
  • Management is a good path for anybody who is passionate about delivering through others and helping them grow. The rest will work itself out. Being an SDM is, first and foremost, about people management. There are other aspects but that is an absolutely non negotiable part of it.
  • SDM, L7, ? YOE, ? TC
  • For new SDMs, (1) Keep things (especially design) simple - engineers are prone to complicating things and solving for edge cases. (2) Build iteratively - push to production very often (at least every two weeks) to prove that your actually making progress. (3) Control against scope creep and requirements changes religiously by communicating well with product/ ux/ business partners and pushing back when necessary. (4) Watch out of dependencies that are not under your L8 - anything you think that can be done in X times will take 2X-3X
  • First thing to being a successful manager is having a high level of empathy and emotional intelligence - you need to sincerely care about your employees like a parent cares for their kids. A common failure pattern I see with ICs becoming managers is not sufficiently empowering their directs and instead micromanaging everything they do. For example, instead of telling your employee they are doing a poor job (which will kill their morale), ask them to introspect on how they think are doing. Help them identify areas of improvement and ask them questions on what steps they can do to become better.
  • Work hard on building a vision for the team (this includes charter, tenets, short term roadmap, long term big ideas). It’s very important to keep people interested in the team - a epiphany I had years ago is boredom is a bigger risk to attrition than anything else (even more to long hours and bad management).
  • Be in the drivers seat with owning your career - most managers don’t have the time/energy to be driving all their directs career and the more interest you show and drive things, the more likely your manager will help you. for example, start a quip doc with your manager to capture his/her assessment against the job role guide and moving to criteria and make sure you do a review every quarter.
  • Work for managers that have had a history of recognizing and growing talent. If they are too new to it, the reality is you take a hit.
  • Ask for feedback often from those you respect on your team (like more senior engineers) and when you get feedback, try to work on it.
  • Get a good mentor and figure out how to use them effectively. it could help to pick someone that took the path you want to.
  • Always be learning/improving - if there isn’t a new skill you are learning every 3 months, you are not learning fast enough.
  • Work on teams where there is opportunity for growth - this is especially important the more senior you are.
  • If you aren't familiar with a tech like AWS, (1) show leadership in areas that don't depend on the tech (process, quality, operations etc. (2) show tremendous curiosity - when you didn’t know something, make sure they stayed a bit later to understand it (3) find other people at the company to talk to and get ideas. This will help you quickly become an org expert in the tech like AWS. If you consistently learn one or new things every day, you are bound to become an expert.
  • To go from SDE to SDM, start small like mentoring others (L4 on your teams or other teams) and determine if you like it and will be good at it. Try managing an intern (learn to define a project, create milestones, giving good feedback, have 1:1s etc) Try managing a small project for your team after speaking your manager of your career goals where you will do part of development but also own the manager aspects of tracking progress, communicating status, negotiating with dependencies etc. If you still enjoy it and your manager thinks you are a good fit, you can slowly graduate you to owning a team.
  • It is important to find the right team. Ask pointed questions to the hiring manager (for example, ask them about the last time they were going to miss a delivery date and what approach did the manager take?). Talk to other ICs and ask them about wlb. Look at ticket queues yourself to get a sense of operations.
  • Switching teams immediately after promo is one of the best times to do it. (No chance of being blindsided by a stealth dev list). Good managers have to pitch you on the team as if you were not on the team. If they can’t give a good answer on the kind of projects you’ll get to work on and how you can continue to grow, you should definitely leave. If you feel that there are key things that you can learn, it might be worth staying.
  • Interview elsewhere every 3-4 years. That way you can check whether you are being competitively paid (more likely no vs yes).
  • Work with your manager to get clear goals and deliver on them. Ask direct questions from your manager if they are not forthcoming with feedback (ask them directly things you are doing well on team/project and things you need to work on). Ask more senior ICs for feedback in person through out the year and work on it. If you are L5 or night, looked at ways to help your team/org beyond just delivery of project work. For example, help with recruiting or being a trainer for a class or a mentor or bringing new tech/methodology:ideas to the team.
  • Applied Scientist Manager, L7, 10 YOE, 650K TC
  • When considering L6 to L7 promo, look for data points across three key dimensions - Tech Depth, Business Impact and Influence. There needs to be multiple (2-3) stories touching on each of these three areas and 1 primary success story which shows the employee is a superstar on all three. Some other questions I ask - is the person a force multiplier, is there a line to their desk seeking their advice/feedback, are they clear and articulate in their communication, do they seek to simplify and scale.
  • PMT, L7, 7 YOE, 400k TC
  • For Product Management Interviews, stick to STAR format and have a lot of stories from your past prepared.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment