Software Engineer's Guidebook - Gergely Orosz

16 Apr, 2025

Note: These are my own notes and observations upon reading the book. They serve as a reminder, when I need to rehash some content. I own none of the content. All rights are reserved to Gergely Orosz. You may find the full book (which I strongly recommend reading in depth!) at https://www.engguidebook.com/.

Part I - Developer Career Fundamentals

"... what a difference it makes when a developer takes ownership of their career path -- which also greatly helps their manager to advocate for them."

"Most engineers I met assumed their manager would take care of most things career-related."

Career Paths

1. Types of Companies

• Big tech
• Medium to large tech companies (Dropbox, Snap, Uber) -- tech first companies with software as core of business. Similar to big tech, but smaller.
• Scale ups (Klarna, Notion) -- venture funded, late stage with product-market fit. They usually move fast under high pressure to justify company valuation
• Startups -- venture funded, with smaller rounds of funding, aiming for product-market fit. Most freedom to software engineers, but also the least stability.
• Traditional, non-tech companies with tech divisions (IKEA, JPMorgan Chase & Co, Pfizer, Toyota, Walmart) -- overall, lower compensation. Tech is a cost center, rather than profit center.
• Traditional, tech-heavy companis (Broadcom, Cisco, Intel, Nokia, Mercedes-Benz) -- archaic, with less compensation than big tech. Usually hardware heavy.
• Others

2. Typical Software Engineering Career Paths

• Single-track career path -- IC to manager (compensation increases transitioning to manager path)
• Dual-track career path -- IC track and manager track (roughly same compensation amongst both tracks)

All career paths are unique, there's no one "right" path. To each his own.

3. Compensation and "Tiers" of Companies

• Tier 1 -- Local Market
• Tier 2 -- Top of the Local Market
• Tier 3 -- Top of the Regional/ International Market

4. Cost Centers, Profit Centers

• Profit Center -- directly responsible of generating revenue
• Cost Center -- necessary for business (ex. GDPR compliance), but not generating any revenue

Differences between the 2:

• Promotions -- always easier in profit centers, after staff, most likely want to have impact at platform level
• Performance reviews and bonuses -- same up to staff, from there tilts towards "money-maker"
• Internal transfers -- usually folks lean towards exciting new, not yet revenue generating cost centers. Profit centers are boring and archaic most of the times
• Attrition -- cost centers have > turnover as most employees want to move to profit centers due to career advancement
• Job security -- cost centers < profit centers

How to tell if you're in a Cost or Profit center? A few questions to ask:

• Is revenue reported every period? If yes, profit center.
• How does the company make profit? Is tech involved? If so, which parts? Is your team part of it?
• Look at org chart. How many VPs are there for engineering, compared to other roles?
• Is your team amongst the org/ teams the CEO calls strategic during all hands? Is it credited for increasing revenue?
• Is your company publicly traded? If so, read the quarterly reports to see the focus -- that'll be profit centers.

5. Alternative ways to think about career progress

Other than compensation, title and company name, here're a few things to consider:

• Free time
• The people you work with
• Professional growth
• Health (physical & mental)
• Flexibility of work (time, place)
• Disconnecting outside of work

"It's not uncommon for long-serving prrofessionals to take a pay cut i norder to get an 'upgrade' in one or more of these areas."

Owning Your Career

1. You're in Charge of Your Career

"Take ownership of your career path if you want to be successful." "There are plenty of ways to own your career, such as telling your manager and peers what you care about, sharing work that you do which they might not notice otherwise, and creating opportunities for people to give you feedback."

2. Be Seen as Someone Who "Gets Things Done"

• Get Stuff Done "Finish the work you're assigned, and deliver it with high-enough quality and at a decent pace. [...] 'shipping' means shiping code in production which works, and launching features, services, and components."
• Get Plenty of Impactful Things Done "Where to start with this? It's just a matter of understanding your team's priorities and the business's. So find out!"
• Make Sure People Know You Get Stuff Done "If what you do is impactful, measure the business impact and share it."

"Finisht the work you commit to, focus on important tasks, and let others know when you get things done. Then your work won't go unnoticed."

3. Keep A Work Log

"...record key work each week, including important code changes, code reviews, design documents, discussions and planning, helping out others, postmortems, and everything else which takes time and has an impact."

Example Log Template

Why it helps:

• Priorities
• Feeling good about stopping work at the end of the day
• Saying "no"
• Performance reviews, promotions and quantifying impact

At start, it may feel silly. "I've yet to hear someone regret doing it, after resolving to stick with it!"

4. Ask and Give Feedback

Ask for feedback

• Code Reviews
• Ideas and Suggestions
• Design Documents
• Peer performance reviews

Asking feedback from others

• Could you help give feedback on my coding approach, based on my last few PRs? Are there areas you think I could change in my approach, or where I'm not following unwritten coding guidance?
• How do you think this architecture planning meeting went, which I facilitated? What did you like about it, and do you have suggestions on how it could've been more productive?
• The outage last night which I commandeered: how do you think I did? This was the first outage I took charge of; what could I change next time to mitigate things more effectively?

"Feedback is a gift because it's always much easier to simply not give it." "It's a fact most people don't give feedback when it's not sought." "Asking for feedback is especially helpful when doing something for the first time, or when still figuring things out in a new group or environment"

Give feedback to others

• Call out good work!
• Be specific.
• Only give positive feedback when you mean it.

Giving critical feedback

• Focus your observation on a situation and its impact.
• Avoid saying "you should do this".
• Give negative/ constructive feedback in-person.
• Make it clear from the start you're on their side. ("make it clear you want this person to become an even better professional, and that it would be easier for you to stay silent and not say anything, but your goal is to help them get better")
• Make it clear it's just your observation, which they can ignore if they wish.
• End the discussion positively.

"Decode" poorly delivered feedback

• Insist on specific examples of what the feedback applies to.
• Clarify the impact.
• Ask for suggestions.
• If you disagree: explain why this is the case.

"Feedback is a gift, both given and received. Poorly delivered feedback is also a gift, but some work is needed to turn it into something useful you can act on."

5. Make Your Manager an Ally

• Have regular 1:1 time with your manager
• Tell them, don't assume they know
• Understand your manager's goals
• Deliver what you agree on, and give updates when you cannot
• Establish mutual trust with your manager
• Get your work recognized

What a good engineer looks like from a manager's POV

• came prepared to our 1:1 meeting, and ensured I knew what they'd done, the challenges they'd solved, and where they needed help or feedback.
• completed agreed work related to their career.
• were clear about their professional goals by stating what they wanted to achieve
• were interested in team challenges and those I faced as a manager, and considered solutions that also benefited their career goals
• asked for specific feedback on their work.
• kept a log of their work in some form, which was shared with the me
• asked for help when they were stuck on something and understood how I or my network could help them get unstuck

6. Pace Yourself

"Athletes pace themselves to optimize for peak performance, and for the longevity of their career."

Stretching

"If doing stretch work comes with overtime, then you'll become physically and mentally exhausted." "If being stretched means falling behind in parts of your work, then this can cause anxiety."

Executing

"You keep learning new things at a normal, not accelerated, pace."

Coasting

"This means doing less and lower quality work than you're capable of."

Mix the above for peak performance.

Performance Reviews

1. Start Early: Gather Context and Set Goals

"Every company is different. What's important in your workplace, and what is rewarded? How is impact measured?"

• Identify and understand the most important factors
  • Ask your manager
  • Ask tenured people on your team
  • Listen to the company's leaders and executives
  • Ask people with influence
  • Understand how the performance review system works
• What performance review system is in place?
  • Unstructured/ ad-hoc
  • Manager-only input and feedback -- "[...]likely to achieve better reviews by having a good relationship[...]"
  • A peer feedback-based performance review process
  • A formal, heavyweight process
  • Once answered, figure out:
    • Who makes the final decision?
    • Who has major input in your performance review?
    • When does the review happen?
    • Advice to ensure a fair performance review.
• Discuss your goals with your manager -- "some should support team and company goals -- and perhaps your manager's, too"
• Agree goals with your manager

2. The Power of Habit

• Record your wins
• Keep a work log
• Share progress with your manager
• Get things done
• Help others
• Capture work you do to help others
• Ask for specific feedback, every now and then
  • Facilitating meetings
  • Resolving and outage
  • Presenting in front of a larger group
  • Proposing a new initiative
  • Leading a project
  • Criticizing someone else's code
  • When doing something new

"Take feedback seriously, but remember that it's opinion and not a directive. Just because people give you feedback, doesn't mean you need to act on it."

3. Before the Performance Review

• How much can you rely on your manager as your champion?
  • Seek what's your standing with your manager
  • Figure out how you stand compared to your peers
  • What is the level of trust with your manager?
  • What is your manager's standing in the organization? -- "If you have a new manager, one who doesn't have much influence or tenure, or one with whom trust is low, then expect it to negatively affect your performance review and prepare for this outcome. You might need to overcompensate and make it hard for your manager to give unfavorable feedback."
• Find out the important deadlines -- "[...] it's pointless to give your manager extra context after decisions are made. [...] Offer your manager a summary of your work which they can use before the performance calibration."
• Gather feedback from peers -- "I suggest privately seeking feedback from peers; ask what you're doing well, and also areas for growth. I strongly suggest writing down what you're told. Depending on the level of trust with your manager, you could show them this feedback."
• Create a self review
  • the "what" -- results you've deliver over time
  • the "how" -- qualitative examples
  • original goals and outcomes
  • example of competencies
  • feedback from peers
  • praise and positive feedback
  • "I suggest you write your own assessment of your performance unless there's a good reason not to."

4. The Review

• Remember performance reviews are snapshots of a point in time
• Know the dynamics of the performance review
• Avoid being too dependent on the outcome
• Biases are very real
  • Recency bias
  • Strictness bias
  • Leniency bias
  • Horns bias
  • Halo bias
  • Similarity bias
  • Central tendency bias
  • Contrasting bias
• Be open to negative feedback and don't dismiss it -- "I suggest pushing back on vague feedback which neglects specifics. Your manager should give feedback that's specific enough for you to reflect on."
• Remember, you and your manager are on the same side
• Play the long game
• Don't forget the big picture

Promotions

1. How Promotions Are Decided

• Performing at next level
• Impact at next level
• Business case for a promotion
• Opportunity and space for a promotion
• Raise the bar at next level

Other things required for promotion:

• Perception
• Support of others
• Internal politics
• Promotion process mechanics

2. Types of Promotion Processes

• Informal promotion process -- ad hoc, being visibile to managers/ people in the room who decide promotion is an advantage
• Lightweight promotion process -- favors people with tenured, well-connected managers
• Heavyweight promotion process -- favors professionals who work on high-impact projects that are easy to quantify and folks who express themselves effectively in writing
• Hybrid models

3. "Terminal Level"

The final level where you need to get in time, or get out. Usually peaks at senior engineering level. Note there are other levels above, but you're not expected to fight for it.

4. Promotions at Big Tech

• Compensation and promotions
  • Pay for performance is a common approach
  • Rules for promotion eligibility
  • A promotion moves compensation to the bootom of the next band
  • A top-performing employee at a lower level can make more than an average performer at the next level
  • Promotions are not the only way to reward impact
• Expectations for promotion
  • what -- impact of the work
  • how -- measuring against competencies
• Promotion-driven development

5. Advice for Getting Promoted

• Organize your work
  • Produce, organize, publish framework -- the more senior, the more you work on the end of the framework (publish > organize > produce)
  • Keep track of your achievements
• The importance of your manager
  • Get your manager on your side
  • For staff-and-above promotions -- get your skip level manager on your side.
  • Make an actionable plan
  • What if your manager changes?
• Be realistic
  • Be realistic about promotion rates
  • Prepare to not be promoted
  • Help others so they help you
    • Mentor someone a level below you
    • Mentor people outside your company
    • Support others whom you know are working towards a promotion
    • Volunteer for things that help the team which colleagues ignore
    • Share that you're working towards a promotion with some teammates

6. A Long-Term Career View

1. Don't let promotions and titles define your self-worth
2. Avoid "elbowing" people out of the way
3. Many career investments only pay off much later
4. Happiness shouldn't be defined by titles and career levels

Thriving in Different Environments

1. Product Teams and Product-Minded Engineers

• Product-minded engineers
  • Proactive with product ideas and opinions
  • Interest in the business, user behavior, and relevant data
  • Curiosity and a keen interest in "why?"
  • Strong communicators with great relationships with non-engineers
  • Offering product/engineering tradeoffs upfront
  • Pragmatic handling of edge cases
  • Quick product validation cycles
  • End-to-end product feature ownership
  • Strong product instincts through repeated cycles of learning
• Becoming a product-minded engineer
  • Understand how and why your company is successful
  • Build a strong relationship with your product manager
  • Engage in user research, customer support, and related activities
  • Bring feasible product suggestions to the table
  • Offer product/ engineering tradeoffs for projects
  • Seek regular feedback from the product manager

2. Platform Teams

• Focused on a technical mission

• Customers are usually internal

• Used by multiple teams

• Upsides of working in a platform team

  • Engineering complexity
  • Wide impact
  • More engineering freedom
  • Less day-to-day pressure
  • Seniority

• Downsides of working in a platform team

  • The business impact is harder to define
  • Frequently seen as a cost center
  • More distant from customers

• Thriving in a platform team

  • Build empathy for customers
  • Talk to engineers using your platform
  • Work side by side with platform customers
  • Do a rotation working on a product team
  • Aim for some urgency and focus

3. "Peacetime" vs "wartime"

• Thriving in wartime
  • get things done quickly with good enough quality
  • be unafraid of disputed if they help you move faster, but don't take them personally, because they're not
  • focus on getting things to work, rather than making allies
  • have a good relationship with your manager/ skip manager
  • work on things that the business needs right now
  • work like your job depends on it, because it might
  • pace yourself -- constantly sprinting can end badly
  • careful on burnout
• Thriving in peacetime
  • get things done with high quality
  • avoid disputes
  • make allies across teams
  • internal politics -- important for career advancement
  • work on long term initiatives
  • slow and steady can become too slow; make sure you switch gears
  • avoid becoming bored at work
• Alternating between modes -- companies usually alternate between the modes
  • founding -- wartime
  • fundraising -- wartime
  • post fundraising -- brief peacetime
  • between fundraising rounds -- brief peacetime
  • year before IPO -- wartime
  • after IPO -- depends (successful IPO -- peacetime; not great IPO -- wartime)
  • public company -- mostly pulled towards peacetime

"The sooner you figure out how to be effective in both modes, the better off you'll be."

4. Types of Companies

• Big Tech and larger tech companies
  • most investment in platform teams
  • mostly peacetime mode
  • advice
    • keep track of your individual impact
    • build allies and a network
• Mid or late-stage scaleups
  • mostly focused on product teams
  • mostly wartime mode
  • advice
    • tenure (inside the company) is a big differentiator
    • hiring and onboarding is a focus
    • are you in a cost or profit center? Figure out what leadership cares about and tell whether you're in a profit or cost center
    • high growth phases end
• Early-stage startups
  • product team is all that's out there
  • mostly wartime mode
  • advice
    • figure out how you can help the company achieve product-market-fit
    • know that startups are risky
    • take advantage of the autonomy you have -- "At most startups, doing stuff without getting permission first and then seeking forgiveness later, is an accepted way of working."
    • tell the founders about your work
    • don't forget the most important thing about working at a startup -- get things done!
• Approaches to thrive at any type of company
  • do standout work -- different companies value different things (speed, quality, etc.) -- figure out what your company values
  • help others around you
  • don't burn bridges

Switching Jobs

1. Exploring New Opportunities

• Actively looking for a job
• Passively open to opportunities
• When you're happy in a job

2. Waiting on a Promotion vs Switching Jobs

• Promotions are typically backward-looking
• The more senior you are, the riskier a new job is -- "[...] doing well requires good political standing."
  • Tenure becomes increasingly important as you get more senior.
  • Before quitting, consider what you'd leave on the table.
• The more senior you are, the harder it is to get promoted

3. Preparing for Tech Interviews

• Initial screening -- sample resume here
• Technical screening
  • Synchronos coding challenge
  • Take-home coding challenger
  • Different format (i.e. debugging session)
• Onsite interviews
  • Coding interview
  • System design interview
  • Domain deepdive
  • Hiring manager interview
  • Bar raiser interview
  • Other interview types (i.e. interview with PM)
  • Staff+ engineers might have extra rounds:
    • Domain deep dive
    • Product manager interview
    • Director level interview
    • Second system design interview

4. Down-leveling

"Down-leveling is especially common when joining a Big Tech company for the first time because expectations are typically high, onboarding takes longer than at smaller places, and companies often aim to hire people who 'raise the bar' at a given level."

5. Up-leveling

"A word of caution, after you secure a higher level, be aware that expectations will be raised from day one."

6. Onboarding to a New Job

• At all companies and levels
  • Consider catching up with your future manager before you start; you can ask for suggestions on how to hit the ground running
  • "The First 90 Days" by Michael D Watkins
  • Keep a work log from the start
  • Keep a weekly journal (write down 3 things you learnt and 3 you don't understand)
  • Clarify goals for 1st month, 1st 3 months and 1st 6 months with your manager
• Onboarding to a smaller company
  • Clarify the work you'll do before you join
  • Connect with the most senior person, early on. They often have long tenure
  • Don't assume how things work: ask.
  • Aim to ship something in week one
• Onboarding to a larger company
  • Get an "onboarding buddy"
  • Keep a "cheat sheet" to record everything that's new
  • Familiarize yourself with company's tech stack
  • Accept that many things don't make sense at first
• Onboarding to a senior-or-above role
  • Connect with senior-or-above peer -- understand how they organize/ measure their work
  • Prioritize being productive on the team's codebase and becoming hands-on with it
  • Clarify 3, 6 and 12 month expectations with your manager
  • Understand current and future projects + team's priorities
  • Find and browse outage documents like postmortems -- it'll help you not get caught offguard
  • Start a list of engineering teams worth knowing. Whenever you hear of a new team, write it down, introduce yourself to a team member and ask what they do.
• Onboarding to a staff-or-above role
  • Meet your team early and make a friendly impression
  • Also meet peer staff+ engineering early.
  • Staff+ roles differ by company, so figure out what's expected and what's not
  • Clarify 3, 6 and 12 month expectations with your manager and ideally with your skip
  • Spend time with product folks to understand their current concerns and plans

Takeaways

"No one cares about your career as much as you do. [...] So figure out how much you care about career progression and put the appropriate amount of work into it."

Part II - The Competent Software Developer

"Keep in mind, every company is unique, and no two have identical expectations."

Getting Things Done

"[...]getting engineering tasks and projects done is far from trivial."

1. Focus on the Most Important Piece of Work

*"Whether you work at a startup or a large company, lots of things are on your plate. Tasks to complete, projects to work on, code reviews to address, emails to answer, meetings to attend... the list goes on. It's easy to get overwhelmed and feel like you're not making progress -- even while working extra hours.

For this reason, it's good to simplify your work life. Ask what is the most important work; the single most important task on your list? No, really; if you could only do one thing this week, what would it be? Answer this question. Your answer is your #1 priority. When you identify it, make sure you definitely, absolutely delivar that piece of work within the agreed timeframe."*

• Make a habit of always completing your #1 priority
• Learn to say "no"
• Unblock yourself
  • Know when you're blocked -- "[...] if you go more than 1 hour without meaningful progress then admit you're blocked."
  • Try different unblocking approaches
    • Rubber-ducking
    • Draw it on paper
    • Read documentation and references
    • Use an AI tool
    • Search online for similar problems
    • Post question on a programming Q&A site
    • Take a break
    • Start from scratch, or undo all changes
  • Get support to unblock yourself -- sometimes you'll be blocked by waiting on somebody
  • Lean how to escalate without ruffling feathers -- aim to not harm personal relationships when you escalate
    • Explain -- what is the ask and what are the stakes
    • Ask -- ask for an update or estimate -- why nothing happens
    • Warn
    • Escalate -- usually involves managers
    • "Aim to make escalation a win-win"
  • "Help I'm blocked" -- a cheatsheet
    • Planning
      • not enough clarity on what to do -- make clear what's missing and escalate to colleagues who can help
      • not knowing who to consult for information in a specific area -- ask for help from your lead/ manager in identifying these people
    • Building
      • new language/ framework -- ask for recommended learning resources, look at the code & talk to authors (if internal) -- start small by learning just enough to solve your problem, before diving deeper in
      • error messages that make no sense -- consider pairing or ask the team who build it (if internal)
      • puzzled about how something works -- decompose by drawing, look at the source code or research; ask for help from colleagues/ manager if you get stuck
      • build problem -- read up on the build tooling and try to figure it out; alternatively, ask the colleague/ team who set it up -- you can be proactive there
      • missing dependency on another team/ service -- let the other party know they're a blocker, escalate and pause (involve your manager) -- look for workarounds, if possible
      • access problems -- your manager is best contact; explain the problem and why you need access
      • misleading documentation -- try to fix documentation, once you figured what's wrong
      • outages, systems being down which prevent you from validating your work -- escalate; there's a chance you're the first person to notice it; wait until it's fixed
    • Testing
      • missing data to test -- figure out how to get the data, might be easy as access logs or might need manager escalation
      • tests are too slow -- always try to make those faster, as it becomes a drain on the long run
    • Reviewing
      • waiting on code review -- ping reviewers, escalate if no answer
      • merge conflicts -- no way around it, make sure to test your changes -- making PRs small is a good way to avoid this
    • Deploying
      • permissions/ access problems -- escalate if needed
      • deployment is too slow -- similar to slow tests
    • Operating systems and maintenance
      • bugs which can't be reproduced -- try adding more logs and ask customers to retry; most of the times waiting on response
      • not enough logs to debug system issues -- add logs, monitoring, alerts, etc then retry issue
      • outages -- alert your manager and team, jump to mitigate if possible

2. Break Down the Work

• Think about stories/ epics/ chunks, tasks and subtasks
  • "The easier it is to understand what needs to be done, the easier it is to estimate how long it will take."
  • "A good time to stop breaking things down is when the tasks are clear enough to you."
• Prioritize work which gets you closer to shipping something
• Don't be afraid to add, remove and change tasks

3. Estimate the Duration of Your Work

• Estimating work similar to what you did previously -- same as previous work
• Estimate work you've not done before
  • Similar work to that of a colleague -- make sure to make your estimate bigger, as it's your first time
  • Refactoring -- reuse previous colleagues experience or timebox it
  • Greenfield work using a technology you know well -- if task is clear, a good rough estimate can be made
  • Integrating with a system you don't know well, using a well-known technology -- try prototyping and once you have a PoC, you can get to a rough estimation; if prototyping is not possible, provide an "ideal" and "worst-case" scenario; ALWAYS try to prototype, as it'll give you enough information for a normal estimation
  • Building something simple with a mature technology you don't know well -- pair with a colleague who knows the technology to speed you up; if not available, time-box the learning part so you can get more information for an estimate
  • Building something simple with a new technology you don't know well -- proof of concept and don't provide an estimate until you're comfortable with it
  • Building something complex and integrating with a system you don't know well, using an unfamiliar new technology -- hard to make an estimate, too many unkowns; reduce unknowns by prototyping or breaking the work

4. Seek Mentors

The tech tribe of mentors

• The dedicated mentor
• The ad hoc mentor
• The internet mentor

5. Keep Your "Goodwill Balance" Topped Up

• Everyone has a goodwill balance
• Regularly top up your goodwill balance
  • make yourself available to others
  • share your expertise to make others' work easier
  • remember to thank folks who helped you (maybe even in a team setting)
• Avoid working alone, when possible

6. Take the Initiative

Approaches to taking the initiative

• Document unclear things
• Volunteer for investigations
• Investigate interesting tools or frameworks your team could use
• Talk to your manager about upcoming projects

"New initiatives help others see you as a productive person, assuming you get your most important and assigned work done, first. If you must choose between doing something new or finishing your current work, I advise you to finish what's needed."

Coding

1. Practice Coding: A Lot!

"Being a competent software engineer begins with being a good coder"

• Code regularly -- "Developing your coding skills is a bit like sports training."
• Ask for code reviews
• Read as much code as you write
• Code some more
  • Build a side project
  • Complete a tutorial/ training with coding exercises
  • Do coding challenges
  • Do regular code katas

"Find a balance between writing and reading code without going overboard on either one."

2. Readable Code

"The biggest risk of unreadable code is that it starts a low-readability spiral."

• What is readable code?
  • Readable code begins with code you find easy to read.
  • The test of readable code is simple: can others understand it?
• Things to pay attention to
  • Naming
  • Well-structured
  • Keep the code simple (KISS -- keep it stupid simple)
  • Single responsibility
  • DRY (don't repeat yourself)
  • Comments -- explain the "why", not the "how"
  • Continuously refactor to maintain readability

3. Writing Quality Code

• Use the right level of abstractions
• Handle errors, and handle them well
  • Have a consistent error-handling strategy
  • When in doubt, use defensive programming
    • Validate inputs, especially from users
    • Expect invalid responses
    • Expect malicious inputs
    • Expect exceptions and errors
• Be wary of "unknown" states

Software Development

1. Become Proficient in a Language

• Learn the fundamental of a language
• Go a level deeper
  • What really happens when you declare a variable, a function or a class?
  • How will the code be compuiled to machine code, and which optimizations might occur?
  • How is memory freed up? Assuming the language uses garbage collection, how does this work?
  • If the language supports generics, are both covariance and contravariance supported?
  • How is generic code interpreted, and how is it optimized under the hood?
• Learn the "main" framework you use with a language
• Learn a second language
  • It's easier to compare strengths and weknesses
  • Go deeper into your first language
  • You shake the habit of only using your "main" language
  • It's easier to learn more languages
• Go broad or deep?

2. Debugging

• Know your debugging tools
  • Runtime tools
• Observe how experienced developers debug
• Learn how to debug without tools
  • Log to the console
  • Paper debugging
  • Write (unit) tests

3. Refactoring

"Refactoring is an important, often overlooked part of coding. Getting good at refactoring is similar to learning to code. You can read all you like about a topic, but without doing it, you'll never truly master it."

• Practice refactoring as often as possible
  • Start by refactoring your own code after it's written
  • Get ideas for refactoring via code reviews -- and act on them
  • Read through the code
    • You deepen your knowledge of the system
    • You will spot many inconsistencies
    • Always get a second opinion before jumping into refactoring
• Know your IDE's refactor functionality -- and use it
• Refactor the tests
• Make refactoring an everyday habit
  • "For every few tasks you complete, make a point to do an important refactoring task too."

4. Testing

Reliable developers ensure their code works as it should:

• They test code before requesting a code review or commiting it
• They care deeply about edge cases
• They use automated testing commonly

Tools of the Productive Software Engineer

1. Your Local Development Environment

Things to have in a modern IDE:

• Refactoring
• Compiling -- 1 click build/ compile of the project
• Running the project
• Hot reload
• Debugging
• Advanced debugging
• Running tests
• Debugging tests
• Creating a pull request

To look for:

• A rapid edit -> compile/ run -> output cycle
• Configure your IDE and workflow
  • Set up shortcuts for frequent actions
  • Configure your color scheme
  • Set up code formatting and linting, if needed

2. Frequently Used Tools

• Git
  • Branching
  • Rebasing
  • Resolving conflicts and merging
  • Cherry picking
• The command-line/ terminal
• Regular expressions
• SQL
• AI coding assistants
• Development tools at your company
• Your "productivity cheat sheet"

3. Way to Iterate Quickly

• Read existing code and understand what it does
  • Ask someone to walk you through the structure
  • Draw out classes/ modules, and how they connect
  • Share your code map with teammates
  • Create a cheat sheet
• Know how to debug the CI/ CD
• Know how to access production logs and dashboards
• Make small code changes when possible
  • Add the "why" and "what" to PRs
  • Use images where UI changes are involved (before/ after)
• Run and write automated tests and checkcs
• Don't just wait for code reviews: ask for them
• Get frequent feedback
  • Get feedback by shipping to production
  • Ask for feedback on your work -- "The best time to seek feedback is when you finish a task or warp up a project. This is when people will give the most specific, most helpful comments."
  • Compare your output with teammates' output

Takeaways

"Competent software developers get things done in projects of reasonable complexity, given their experience level."

"'Practice, practice, practice' is the single best advice for growth."

"Time is not 'wasted' at junior levels if you keep learning and growing."

Part III - The Well-Rounded Senior Engineer

Software development

• Outlining a basic plan
• Coding
• Testing
• Deploying
• Debugging

Software engineering

• Gathering requirements
• Planning a solution and analyzing tradeoffs between approaches
• Building the software
• Shipping to production
• Maintaining the solution
• Extending the solution to new use cases
• Migrating to other solutions

"A software engineer should be invested in the long-term impact of their work, as well as the short-term."

"[...] software engineering is software development (or programming), over a much longer time frame [...]"

Getting Things Done

"More inbound requests, conext switches, and more complex work in general, distinguish a senior software engineer's workload from more junior positions."

Same expectations from Software Engineer applies, but there's a few more that are relevant.

1. Getting Things Done: Perception and Reality

"Two things are necessary to be seen as a senior engineer who gets things done: a) Ability to solve complex engineering problems in a pragmatic way b) Communication of work to peers and managers; including progress, roadblocks faced, solutions to roadblocks, and the complexity of the work"

• Perception and reality may differ
• Communicate what you do
• Under-promise, over-deliver, over-communicate
• Communicate roadblocks early and offer tradeoffs

2. Your Own Work

• Deal with inbound requests efficiently
  • Block out time for uninterrupted, deep work.
  • Say "not right now" when in the zone.
  • Timebox how long you spend helping with something.
  • Turn sync requests to async ones.
  • Redirect requests to a colleague who'd benefit.
  • Know your "#1 priorty work" at all times.
  • Prioritize requests.
  • Create a system for capturing important but not urgent work.
  • For anything unimportant, say no.
  • Purge your to-do list, every now and then.
  • Know it's normal to feel overwhelmed.

3. When It's Done, It's Properly Done

• Have a written specification.
• Have a testing plan.
• Include testing, monitoring, and alerting as part of estimations.
• Don't "throw it over the fence" to QA.
• Work in short iterations -- ship something every day.
• Long stretchs of work -- it means less feedback.

4. Your Team

• Break down and estimate projects
• Document for others
• Unblock your team
  • Pair with others
  • Lead by example in resolving external blockers
• Become better at thinking "outside the box"
  • Broaden your experience
  • Go deep
  • Come up with more than one potential solution to a problem
  • Meet and observe engineers who solve problems creatively

5. The Big Picture

• Become product minded
• Understand the business

Collaboration and Teamwork

"Communication, collaboration, and teamwork are baseline expectations for well-rounded senior software engineers at most companies."

1. Code Reviews

• The tone of the review
• Requesting changes before approving
• Talking to each other
• Nitpick comments
• New joiners and code reviews
• Cross-office, cross-timezone reviews

Google code review practices Gitlab code review practices

2. Pairing

• Situations where pairing can be useful
  • Onboarding to a new team, codebase or system
  • Implementing a feature
  • Debugging a tricky bug
  • Planning and architecting
  • Confirming you're doing things correctly
  • Understanding how something works
  • "Cheat" by observing and learning how another developer works
• Approaches when you're more experienced
  • Define the problem
  • Get a sense of urgency
  • When there's time pressure, solve first while explaining, then follow up
  • Aim to teach your pair partner something, not just give answers -- "It is a low-leverage task if you quickly solve your pair partner's problem [...] pairing becomes a high-leverage activity when you spend time teaching a colleague how to solve the problem [...]"
  • Avoid immediately giving answers, even if you can
  • Give the other person enough space to talk and type
  • Try to learn something from your pair partner
  • Give compliments when due
  • It's natural to go off-track sometimes
• Approaches when you're less experienced

3. Mentoring

• Informal mentorship
• Formal mentorship
• Kicking off mentoring: the introductory meeting
  • background
  • "what's in it for me?"
  • topics to cover
  • cadence
  • communication between catch-ups
  • short-term wins
  • evaluating progress
  • challenges
• When you're the mentor
  • Be clear on expectations from the start
  • Listen to what the mentee has to say
  • Avoid serving up answers on a silver platter
  • Discuss specific situations to dive deeper
  • Leverage your network to help your mentee
  • Let your mentee know you're on their side
  • Aim to learn something new from your mentee
  • Help mentees come up with multiple solutions to problmes
  • Tailor your approach for technical vs non-technical topics
• When you're the mentee -- things to mention
  • Key events
  • Reflections on action items/ guidance/ discussions from last time
  • A recent challenge
  • A recent success
• Long-term benefits of mentoring

4. Giving Feedback

• Better ways to give positive feedback
  • Make it concrete
  • Make it sincere
• Giving constructive or negative feedback
  • Ask questions
  • Deliver corrective feedback empathetically

5. Working With Other Engineering Teams

• Draw a map of teams
• Introduce yourself to other teams

6. Influencing Others

• Ship great work
• Get to know other people
  • Join calls with engineers on other teams whom you work with
• Take part in cross-functional projects
  • Get involved in RFCs/ design docs/ cross-team planning
  • Take part in cross-team projects
• 'Promote' your work -- without boasting
  • Aim to build a strong personal brand

Software Engineering

1. Languages, Platforms and Domains

• Learn an imperative, a declarative and a functional language in depth
• Get familiar with software development platforms
• Become more full stack
  • Get access to other platforms' codebases
  • Read code reviews by team members on other platforms
  • Volunteer for small tasks on the other platform
  • Pair with an engineer working on another stack
  • Do an "exchange month" of working on another platform
• AI helpers can make the transition quicker

2. Debugging

"The difference between a senior and a non-senior engineer is pretty clear in debugging and tracking down difficult bugs."

• Know which dashboards and logging systems to look at
• Make ddebugging easier for others
• Understand the codebase
  • Understand smaller codebases inside out
  • With large codebases, it's good to understand their structure and how to find relevant parts
  • Find out how to search the whole codebase, and learn useful shortcuts
• Know enough about the infrastructure
• Learn through outages

3. Tech Debt

• Paying down tech debt
  • To tackle tech debt purposefully, propose projects with clear impacts
  • Couple tech debt removal with high-impact projects
• Reduce tech debt accumulation
  • Write code that's easy to read
  • Make time to clean up the code
  • Build systems with extensibility in mind
  • Note tech debt and don't seek permission to remove small pieces
• "Just enough" tech debt

4. Documentation

• Design documents/ requests for comment documents -- "[...] have the most value when written before coding starts, and when circulated for feedback, as the goals of these documents are to help build the right thing [...]"
• Test plans, rollout plans, migration plans -- valuable at the start of a project
  • Test plan -- how will the system be tested?
  • Rollout plan -- how will the system be rolled out?
  • Migration plan -- what are the phases of migrations and how will it be validated that the new system works correctly before traffic is moved?
• Interface and integration documentation
• Release notes
• Onboarding documentation
• A team "handbook"
• Oncall runbook documentation
• User manuals and guides
• Documentation is a high-leverage activity
• Scaling best practices across the team
  • Written planning process
  • Automated testing
  • Test-driven development
  • Code reviews
  • Post-commit code reviews
  • Testing environments
  • Staged rollouts
  • Testing in production safely

"Which practices should you put in place for your team? Actually, thi sis the wrong question to start with. Instead, ask what the biggest challenges are to shipping things on your team."

Testing

1. Unit Tests

Desirable traits

• Fast
• Reliable
• Small

"There is a compounding benefit of unit testing code, which grows as the system and its development team do. The tests help validate code changes, force you to separate concerns, and help to document the code's behavior."

• The senior engineer who wrote zero unit tests

2. Integration Tests

3. UI Tests (end-to-end tests)

Drawbacks:

• more brittle tests
• slowness

4. Mental Models for Automated Tests

• The testing pyramid -- backend focus, mostly unit, some integration, less end-to-end
• The testing trophy -- frontend focus, static checker, small on unit, big on integration, some on end-to-end -- facilitate by integration testing frameworks

"There is no single best approach for how to invest in tests."

5. Specialized Tests

• Performance tests
• Load tests -- sometimes you can reduce your fleet 10x instead of increasing your load 10x
• Chaos tests
• Snapshot tests -- used to check pre-recorded (point in time) UI to current UI
• Application size/ bundle size tests
• Smoke tests
• Manual tests and sanity tests
• Other tests
  • Accessibility testing
  • Security testing
  • Compatibility testing

6. Testing in Production

How to do it safely?

• Feature flags
• Canary deployments
• Blue-green deployments
• Automated rollbacks
• Multi-tenancy environments

The biggest benefits of testing in production:

• Confidence
• More straightforward debugging
• Fewer environments; less infrastructure complexity

Challenges to testing in production:

• Infrastructure investment
• Compliance and legal challenges

7. Benefits and Drawbacks of Automated Testing

Benefits:

• Validating correctness
• Catching regressions
• Documentation
• A contract
• A safety net when making large changes

Downsides:

• Time taken to write
• Slow tests
• Flaky tests
• Maintenance cost

Software Architecture

1. Design Documents, RFCs and Architecture Documents

The goal of RFCs

A few approaches with RFCs

• Prototype, then RFC, then build
• RFC, wait for feedback, then build
• RFC, then build while awaiting feedback
• Build, then RFC

Benefits

• You clarify your thinking
• Get important feedback, faster
• It scales your ideas
• It promotes a writing culture

Reviewing RFCs -- pick format based on project

• Asynchronous feedback
• Synchronous feedback
• Hybrid

"Don't roget the true goal of the RFC process. It's to reduce the time it takes to ship a project, by getting feedback early. Ask yourself which approach saves the most time."

Architecture documents

• ADR (Architecture Design Record)
• C4 model
• Arc42

2. Prototyping and Proof of Concept

Prototyping for exploration

• "Many software engineers whom I consider great software 'architects' build throwaway prototypes to prove a point and showcase their ideas."
• "When there are many unknowns or moving parts, use prototyping as an exploration tool."

Build with the intent to throw it away

"To develop better architecture approaches, use prototyping to build proofs of concept as a tool."

3. Domain-Driven Design

• A standard vocabulary
• Context
• Entities
• Value objects
• Aggregates
• Domain events

Benefits of DDD:

• Ferwer misunderstandings between engineering and business
• A better handle on business complexity
• More readable code
• Better maintainability
• Easier to extend and scale

Resources:

• Learning Domain-Driven Design by Vlad Khononov
• Domain-Driven Design by Eric Evans

4. Software Architecture that Ships

• Verbalize the business goal
• Get buy-in from stakeholders
  • meet the key people and describe your approach
  • write a proposal, send it around, gather comments, and get people to sign off on your idea
  • start by writing things down, and end by talking to key people who are "on the fence" "An underrated way to get key people to agree to a written proposal is to seek their input before you write the proposal."
• Beat decision paralysis
  • specify capability requirements
  • appoint a decision maker before the discussion
  • who will do the coding, is the tie breaker
  • prototype
  • get sponsorship from your product counterpart
• Roll out changes properly
  • Quantify what the rollout means
  • Have a rollout plan
  • Define the right 'time to bake'
  • Have a rollback plan
  • Do a 'pre-mortem' exercise
• No decision is final in software engineering
• Reflect on your architecture decisions, here's some motivations
  • Share your learnings
  • Performance reviews/ promotions
  • Help others with your learnings

Takeaways

"It is at senior level where the impact of your work is more important than the effort you put into it."

"It's reasonable expectation that a relatively complex project will be accomplished when a senior engineer is involved. If issues come up, it is the senior engineer who finds ways to unblock things. And if they get stuck, they flag this, ask for help, and bring options to the table."

Part IV - The Pragmatic Tech Lead

"[...] being a tech lead is more frequently a role than a formal title."

"Expectations of tech leads are usually similar to those of senior engineers, with the addition of leading projects. At some companies, tech lead expectations are closer to those of a staff engineer."

"A high-performing tech lead is usually a prime candidate for an internal engineering manager promotion, or transition. At the same time, tech leads often have the opportunity to stay on the individual contributor path, and grow into staff+ positions."

Project Management

1. Companies Where Engineers Lead Projects

A set of companies would be:

• Shopify -- IC Champion
• Amazon
• Atlassian
• Microsoft
• GitHub
• X
• DAZN
• Klarna
• Trivago
• Skyscanner
• Thought Machine
• Big Tech

"You know who the best managers are? They're the great individual contributors who never, ever want to be a manager, but decide they have to be a manager because no on else will do as good of a job as them." -- Steve Jobs.

2. Why Do We Do Project Management?

"'Project' is the word many organizations use to coordinate efforts which move the needle of a specific business goal."

Typical parts of projects management (needed when more people are working together):

• Goals -- being clear what problem you are solving with this project
• Planning -- having some high-level idea of how to solve this problem. In some cases, a more formal specification could come before the plan itself
• Coordination -- being clear who does what
• Keeping everyone on the same page -- as work progresses, keeping all team members informed about how things are going
• Managing risks, changes, and delays -- building software is full of risks because we often build solutions in new, untried ways

"Estimates matter because most people and businesses are date-driven. Publicly traded companies plan and budget based on quarters. They also decide how much to invest in projects and people after asking, 'how long does it take to launch?' Private, venture-funded companies try to get new features out in time to help with the next fundraising round. Yes, some businesses are not very date-driven, but they are rare. Private, profitable lifestyle businesses and public bodies are perhaps the best examples of entities that don't care as much about dates."

3. Project Kickoffs and Milestones

"I've observed that a major reason why projects fail is by starting with a misaligned expectations."

"Kickoffs help ensure there's no misunderstandings at the outset, which can later cause large chunks of work to be thrown out, or redone entirely."

Project Kickoffs

1. Project kickoff -- why? what?
2. Engineering kickoff -- how?
3. Milestones and estimates -- when?

The project kickoff

"A successful kickoff is one in which the project lead asks 'are there any questions about what the project is, why we're doing it, or how we are approaching it?"

"I recommend the kickoff to be a meeting. Dedicate ten minutes to reading the proposal document, or for the project lead to walk attendees through it. If running an online meeting, consider asking participants to turn on video, so the meeting facilitator can get visual queues and spot when people could be disagreeing, and when a little nudge could help these people speak up."

The engineering kickoff

Happens after project kickoff, usually via a design doc.

Establishing milestones

"The goal of this step is to align the engineering team with the 'when'."

"The more granular these milestones, the better. This is because all estimates will be off by some degree, and the only way to really know by how much, is to hit a milestone."

"I prefer milestones to be small enough to be achieved in no longer than a few weeks. If milestones involve lengthy chunks of work, I'd challenge the team to set intermediary milestones that capture smaller parts."

Ensure estimates aren't binding

"Software projects are full of unknowns and risks, and the most anyone can reasonably ask of a team is for a rough idea of how long things should take, based on the best information."

"I always prefer to add some pading, but also to educate the business that there's no such thing as a 'fixed date'. Commit to the business that they will get regular updates, and then as the project passes its milestones, you can give dates with increasing confidence."

4. "Software Project Physics"

Timeline <-> People <-> Scope (meant as a triangle)

"If one of these changes, at least one other also needs to change in response."

"If this triangle looks familiar, it's probably because it resembles the project management triangle, which is a commonly used model to describe the connection between cost, time, scope, and quality. For teams in Big Tech and at high-growth startups, I've found quality is rarely up for negotiation: timeline and scope are much more so."

5. Day-to-Day Project Management

What matters:

• Is everyone on the same page?
• Keep the team and yourself accountable to what's been agreed
• Delegate generously as a project lead
• Iterations and feedback
• Expect the unexpected
• Never forget the big picture and the project's ultimate goal

Taking decisions, as a tech lead

• Don't forget to consult the rest of the team, before deciding
• Inform stakeholders
  • Situation/ problem
  • Potential solutions on the table, with tradeoffs
  • The approach the team has chosen, which you support
• Can you decide, or should you consult first?

6. Risks and Dependencies

Technology risk

Mitigate with:

• Prototype
• Review the roadmap and tooling
• Evaluate "unstable" frameworks and tools
• Consider alternatives to something that's bound to change a lot

Engineering dependencies

Mitigate with:

• Talk with the other team for a sense of what needs doing
• Offer to do the work yourself, assuming there's an internal open source model
• Mock around this dependency to unblock yourself and make progress while the other team builds
• Remove this dependency from the critical path
• Swarm as a team
• Pull in help from above by escalating to managers to help prioritize work on the other team's roadmap

Non-engineering dependencies

Mitigate with:

• Talk with the team and outline what you need, why, and what the impact will be if they don't take action
• Can you work around this team?
• Pull in help from above if needed, such as PM or EM (but share the right context and recognize the difficulties or constraints the team has)

**Missing decisions or context dependencies

"Refuse to start work until you understand the context or have the decisions. [...] It's doing a disservice to the team, the company and yourself, to start work on something about which fundamental questions remain unanswered. Ensure you have a clear picture of what to do, and why. Start work only when this is clear."

Unrealistic timeline

Mitigate with:

• break down with rough estimates, firstly then
  • offer tradeoffs to meet the timeline
  • reduce scope
  • consider adding more engineers

In general, refuse to accept top-down deadlines.

Not enough people or bandwidth

Mitigate with:

• be clear on how many efforts/ projects your team can handle at one time
• offer to drop other, currently top priority projects, but be clear on the impact

A surprise midway through the project

Mitigate with:

• What type of risk is it?
• Can it be worked around or ignored?
• Should the timeline be extended?
• Can you take on tech, architecture or process debt in doing a quick fix, and only do a proper fix at the end of the project?

No true idea how long something will actually take

Mitigate with:

• Figure out what type of risk this really is
• Can you break it down into smaller pieces?
• Prototype, or get more information on the underlying challenge

7. Wrapping Up Projects

Drawbacks of doing it properly:

• the team doesn't get credit for good work; also no celebration
• team members get pulled into work on other projects, and the final stage of the project (typically the rollout) is done ad-hoc
• without a wrap-=up there's no reflection on how the project went; no learnings

A good wrap-up:

• clarity on what "done" means
• consider doing a retrospective with the team
• write a final project update for a wider group
• get feedback on this final update from others, before distributing it
• time the final update for release soon after the project group disbands
• spotlight all team members and anyone who meaningfully helped
• celebrate with the project team

What about projects whcih fail more than succeed?

• close positively
• share learnings
• share small wins

Shipping to Production

1. Extremes in Shipping to Production

YOLO shipping

"YOLO shipping is as fast aas it gets when shipping a change to production. However, it also has the highest risk of introducing new issues into production because there is no safety net."

Thorough verification through multiple stages

Layers:

• local validation
• CI validation
• automation before deploying to a test environment
• test env 1
• test env 2
• pre-production environment
• staged rollout
• full rollout
• post-rollout

2. Typical Shipping Process

There are differences between company types:

• Startups
• Traditional companies
• Large tech companies
• Meta's core product

3. Principles and Tools

• Development environments
  • local/ isolated dev env
• Testing and verification
  • consider edge cases and test for them
  • write automated tests to validate your changes
  • code review
  • all tests pass
• Monitoring, oncall and incident management

4. Additional Verification Layers

• Separate deployment environments
• Dynamically spin up testing/ deployment environemnts
• A dedicated QA team
• Exploratory testing
• Canarying
• Feature flags and experimentation
• Staged rollout
• Multi-tenancy
• Automated rollbacks
• Automated rollouts and rollbacks

5. Taking Pragmatic Risks

• Decide which process or tool it's not okay to bypass
• Give a heads up to relevant stakeholders when shipping risky changes
• Have a rollback plan that's easy to execute
• Inspect customer feedback after shipping risky changes
• Track incidents and measure their impact
• Use error budgets to decide if you can do risky deployments

6. Additional Considerations

• Security practices
• Configuration management
• Roles and responsibilities
• Regulation

7. Selecting an Approach

Questions to ask:

• How much are you willing to invest in modern tooling, in order to ship more iterations?
• How big an error budget can your business realistically afford?
• What iteration speed should you target as a minimum?
• If you have QA teams, what is the primary purpose of the QA function?
• How much legacy infrastructure and code is there?
• Consider investing in advanced capabilities.

Stakeholder Management

"Stakeholders are people and groups with an interest in a project's outcome."

"The best time to figure out the key stakeholders in your project is as soon as possible."

1. The Real Goal of Stakeholder Management

"The point of stakeholder management is for the project to succeed by keeping everyone on the same page. [...] It is just a tool to help a project succeed and to ensure everyone agrees what success looks like."

2. Types of Stakeholders

• Customers
• Business stakeholders
• External stakeholders
• Product stakeholders
• Engineering stakeholders

Categorization by dependency

• Upstream -- teams whose work you depend on
• Downstream -- teams that depend on your work
• Strategic -- teams you want to keep in the loop (oftentimes help unblock upstream dependencies)

3. Figure Out Who Your Stakeholders Are

• Just ask -- consult stakeholders about who else might be interested
• Identify the "usual suspects"
  • engineering
  • product
  • UX
  • data science
  • security/ compliance
  • infrastructure/ DevOps/ SRE
  • legal
  • marketing/ growth/ user acquisition
  • customer support
  • operations
  • sales/ business
  • finance

4. Keep Them in the Loop

"'Stakehholder manangement' is a fancy phrase for ensuring everyone who needs to know what your team is doing, does know."

Ways to keep stakeholders updated:

• Meetings
• Asynchronous updates
• Hybrid

5. Problematic Stakeholders

Based on dependency type:

• downstream -- unreliable/ have trouble collaborating with or trusting them
• upstream -- try to push you and the team
• strategic -- gives you hard times about emerging challenges

"In each case, the biggest issue tends to be communication and trust."

Ways to improve the situations:

• Talk face-to-face
• Be transparent and educate them
• Ask for support

6. Learning from Stakeholders

Ways:

• Ask about their part of the business
• Ask about their challenges
• Ask what they do outside of the project you're collaborating on
• Small talk
• Consider grabbing coffee or lunch
• Ask if you can shadow their team meeting as a one-off

Team Structure

1. Roles and Titles

• The difference between titles and roles
  • titles -- provides expectations on its holder
  • roles -- temporary position
• "Tech lead" can be a title or a role
• Roles can be implicit or explicit
• Decide which roles are explicit

2. Team Processes

"Which processes should a team have in place? This is actually the wrong question to start with. Processes are not the reason why teams exist; they exist to get things done. Processes can aid this, or they can get in the way."

Sample process to try out for your team:

• Planning
  • Brainstorm sessions
  • Planning with other areas (i.e. marketing/ business)
  • Project kickoffs
  • RFCs
  • ADRs
• Building
  • Prototyping
  • Code reviews
  • Automated testing
  • CI
  • Documentation
• Releasing
  • CD
  • Release plans
  • Feature flags and experimentation
  • Signing off with stakeholders
  • Gathering feedback from customers
  • Canaries & automated rollbacks
• Maintaining
  • Oncall
  • Support engineering
  • Incident reviews
  • Improving infrastructure and platforms
  • Periods of non-product development (fix tech debt, improve infra)
• Engineering productivity
  • Team retro
  • Handling tech debt
  • Investing in efficient tooling (CI/CD, scripts)
  • Reducing frequency of meetings
  • No-meeting days
• Tech health
  • Team events and offsites
  • Spontaneous team events (like getting ice cream)
  • Celebrating team and individual achievements

Don't forget to remove processes, those aren't only additive.

"Don't ask which processes your team should have in place, ask how the team can get stuff done better and faster."

3. Boosting Team Focus

"To help the team focus, be clear what their priorities are, or what a project's priorities are, what the most important thing to get done is, what comes next, and so on."

Push back on sudden changes of focus

"Resist abrupt changes to your team's top priorities, even if these come from above. A team that switches focus frequently can easily become unhealthy and a good tech leads protect their teams from it."

How to push back:

• impact -- what's impact of new work?
• written spec -- answer the what and the why
• engineering planning and feasibility
• make the cost of context-switching painfully clear
• offer alternatives to get the work going without disrupting the whole team

Team Dynamics

1. Healthy Teams

Clarity

"In a healthy team, it's clear why the team exists, what its goals are, and how to achieve them."

Execution

"The team 'gets things done'".

Good morale

"[...] people feel positive about coming to work."

Indicators:

• engaged teammates
• mutual support
• low attrition
• positive atmosphere

Healthy communication

"Civilized and constructive communication is a baseline for healthy teams."

An engaged team

"Everyone contributes to the team [...]. Nobody is left out or does significantly less than others."

2. Unhealthy Teams

Indicators of unhealthy teams:

• lack of clarity
• poor execution
• unconstructive conflict handling
• absence of communication/ trust
• unconstructive feedback
• lack of psychological safety
• not all team members contribute

Why teams are unhealthy?

• poor management
• "brilliant jerk" in the team
• lack of skills on the team
• lack of feedback or empty feedback
• unclear direction
• treading water
• excessive context switching
• too much process
• lack of structure
• plagued by tech debt

Structural reasons teams struggle

• too much attrition
• too many new joiners
• junior-heavy teams
• a sudden change in direction

3. Teams with Growing Pain

• silent conflicts and Chinese whispers
• silently-growing execution problems
• good work going unnoticed
• growing attrition risk
• a senior-heavy team without enough challenges

4. Improving Team Dynamics

• Observation
  • start by observing
  • talk privately with team member to get a better grasp
• Improving team dynamics
  • reduce negative interactions in group settings, when possible
  • get team members involved in relevant discussions
  • solve the most pressing health problem, or escalate it to your manager

5. Relationships with Other Teams

• catch up with engineering project leads on other teams
• speak to engineering managers or product managers on other teams
• consider verbal, not written communication for problematic situations

Takeaways

In the tech lead role you need to balance several things at once:

• leading a project or an engineering team
• empowering team members, as well as helping remove blockers
• keeping in the loop stakeholders, product, and perhaps even your manager
• being a role model when doing individual contributor (IC) work like coding, code reviews, and being on-call

"Lead by example"

"The best tech leads don't think they are superior to other engineers"

"A team in which people are more independent will almost always be more efficient than one where everyone waits for the tech lead to decide.

Part V - Role-Model Staff and Principal Engineers

"At staff+ level, expectations vary by the company you work at, and are typically more demanding at higher staff+ levels."

"Staff+ is a partner of EMs and PMs"

"For example, at Uber the principal engineer level (L7) is the same career level as the director of engineering (also L7). Also at Uber, principal engineers are expected to be partners to directors of engineering and product. [...] This expectation is oftentimes unspoken, and it's down to the staff+ engineer to put in the work and invest in strengthening this partnership."

Understanding the business

"As a staff+ engineer, there is often more work on your plate than you can easily handle.

1. North Stars, KPIs, OKRs

"[...] most staff+ engineers are partners to engineering managers (EMs) and product managers (PMs) in defining the team's strategy and roadmap. To speak the same language as EMs and PMs: North Starts, KPIs and OKRs are helpful."

• North Star
  • the vision of a team, product or organization
  • usually ambitious, the ideal end state
  • North Star metrics are measurements which reflect progress made towards the North Star (can be daily users, number of customers, etc.)
• KPIs (Key Performance Indicators) -- most North Star metrics are captured as KPIs; a few examples:
  • Revenue
  • Number of customers
  • uptime
  • net promoter score "A good KPI is measurable, unambiguous, and helps indicate progress and flag up problems [...] and is also very hard to "game": to make the metric go in the right direction without real improvement happening."
• OKRs (Objectives and Key Results) -- it has 2 components:
  • Objective -- high-level goal that is qualitative (not necessarily measurable)
  • Key Results -- measurable outcomes that measure progress towards achieving the objective "Businesses operating with OKRs set them at company level, organizational level, and all the way down to team level."
  • Example OKR:
    • Objective: Improve reliability of our service
    • Key Results:
      • Increase system uptime from 99.8% to 99.9%
      • Reduce by 20% the p95 latency for API responses
      • Reduce by 30% unhandled exception errors

Are the right things being measured?

"A noticeable difference between standout engineering teams and average ones is that on standout teams, engineers question KPIs and even OKRs from product folks. For role model staff-and-above engineers, I consider this practice to be a given."

Questions:

• Are we measuring the right things?
• How can this measurement be gamed?
• What other things should be measured as "countermeasures"?

2. Your Team and Product

"The best place to start figuring out how the business works, is with the product you and the team are working on. Understand how this product works, why customers use it, what the competition is, and how it contributes to the company's bottom line.

• Put on a product manager hat
  • Identify and understand customers
  • Measure customer satisfaction
  • Get input from customers for the team's roadmap
• Put yourself in the customer's shoes "A key difference between senior and staff+ engineers is problem-solving vs problem finding. Both senior engineers and staff+ engineers are expected to solve challenging problems: but staff+ engineers are also expected to find problems that are worth solving. Putting yourself in the customer's shoes is one of the most obvious ways to do so."
• Know why customers use your product
  • Talk to customers
  • Observe user research sessions
  • Read reviews
• Understand the product's business value
  • Profit centers
  • Cost centers
• Create a SWOT (strengths, weaknesses, opportunities, threats) analysis of your product "This exercise forces you to think like a business owner and understand the competition. You'll view your product in a more strategic way after you complete the exercise."

3. Your Company

• What is the business model?
  • How does your company generate wealth?
  • How does it turn revenue into profit and manage costs?
  • If there's no profit, what's the plan to achieve this?
• Have 1:1s with product people
• Talk with people outside of software engineering and product
  • Other tech disciplines (UX, research, data science, etc)
  • Business areas your team supports
  • Corporate communications/ PR
  • Groups unconnected with your team or product
• Have 1:1s with business stakeholders
  • Business teams that are active users of your product, or for whom you build
  • Customer support and operations teams that get feedback from users
  • Marketing and sales teams which might use your product to close customers, or market the business
  • Finance teams that generate reports based on your product's metrics
• Pay attention to leadership's communication
• Talk and listen to customers
  • Volunteer to do customer support
• Get involved in strategy discussions
• Work on cross-functional projects
  • Talk with your manager
  • Talk with people on other teams
  • Look out for projects you can help with
  • Mentor others
• Have 1:1s with your manager and leadership chain
• Carve out dedicated time to read PRDs (product requirements documents)
• Create conditions for serendipitous meetings
  • If you work in office, sit next to someone at lunch that you don't know and talk about job related activities
  • When attending training sessions, make the effort to get to know other attendees
• Why do few engineers meet business stakeholders?
  • "My manager doesn't, so why should I?"
  • They've never seen a fellow engineer do it.
  • Product leadership doesn't encourage it.
  • Engineering doesn't work closely with the business.
  • The company culture encourages silos.
  • Engineers don't have autonomy.

4. Public Companies

Useful information in quarterly reports and investor calls:

• Numbers -- revenue, profitability
• Investment areas -- products/teams/areas leadership choose to highlight
• Questions from analysts -- what areas and what's leadership's answers
• Forward-looking commitments -- revenue generation and spending reduction

5. Startups

6. Your Industry

• Map out key players and key products
• Find and read trade publications
• Follow industry news

Collaboration

"As a staff+ engineer, much of the work involves collaborating [...] in many cases, it isn't you who initiates the collaboration, people come to you"

"The most challenging projects are rarely hard because of the code to be written. Often, the main pain point is working with others [...]"

"Collaboration involves people in your network, while your influence creates opportunities for engineers in your team. It's a differentiator in career success, which is why we're focusing on it."

1. Internal Politics

"[...] Politics and influence often go hand in hand, even though we perceive a 'political' colleague and an influential one differently. Influence is a 'good' form of internal politics."

• The "wrong" type of politics -- perception matters "The label 'political' gets a bad rap because it often describes activities seen as self-serving and for the benefit of one person or group at the expense of others. It's worth avoiding being seen by colleagues as making their lives more difficult in order to benefit yourself, or your 'in group'."
• Problematic perceptions
  • being self-interested
  • elbowing colleagues out of the way
  • being inflexible
  • being two-faced
  • bulldozing their will through
  • distrusts other engineers
  • all talk, no coding
• Giving feedback on "bad" politics
  • if you're a peer of a political person -- give feedback directly (or to your manager if there's no trust)
  • if you're senior of a political person -- give feedback directly (preferably with examples)
  • if you're junior of a political person -- give feedback to your manager

2. Influencing Others

A few situations where being influential can help:

• getting proposals accepted
• pushing back on an initiative damaging to your organization
• making a case for your teammate's proposal
• working on important projects

Earning trust as staff+:

• earn "trust capital"
  • title/authority
  • tenure
  • expertise
  • track record
  • visibility of work "[...] trust as the sum of credibility, reliability and authenticity; divided by the perception of self interest" -- more here
• ask questions and be an active listener
• explain your point of view
  • PRs -- summarize problem solved, notable edge cases and things out of scope
  • proposals -- the problem as you see it; preferred solution; known-unknowns and trade-offs
• take sides in design discussions and explain your reasoning
• roll up your sleeves and get things done
• make your work visible
• take the lead and ship initiatives
• support others selflessly
• become a better writer

3. Collaborating with Managers

• Be clear with engineering managers that you're on their team "Avoid treading on engineering manager' toes. Both staff+ engineers and engineering managers help align teams, and you could be in situations where your decisions override another manager, or feel that a manager is overriding yours. If so, do what you would do if this happened with a peer staff+ engineer; take the discussion private and talk through how the two of you can 'row in the same direction'. It's smart to avoid these differences playing out in front of less experienced engineers.
• Build up trust with other managers -- "your goal is to be a true ally in engineering-related matters"

4. Collaborating with Staff+ Peers

• Get to know staff+ folks, face-to-face
• Join a staff+ community - or create one
• Be aware that collaborating with "staff+ archetypes" is different

5. Expanding Your Network

• Find yourself a mentor in the organization
• Work on cross-team projects
• Attend internal training
• Meet people outside your team
• Network and influence are connected

6. Helping Others

• Mentor others
• Sponsor others
  • Bringing visibility to great work
  • Lending support for promotions
  • Bringing people "in the room"
  • Advocating for projects
  • Speaking up

Software Engineering

"As a staff+ engineer, your role incorporates that of a senior engineer, plus a whole lot more. It's common to be responsible for your team's pace of engineering work and its quality, as well as your own -- and often the outputs of other teams, or a whole group."

1. Coding you still do

"[...] you should make time for coding, but less of it."

• Code in bursts
• Pair during coding bursts - "use coding as an opportunity to mentor, coach, and lead by example"
• Jump into struggling projects
• Adapt your style to the team -- "When not deeply embedded in a team, aim to adapt to it rather than reshape it around you."
• Be strategic
  • Pick up challenging parts of coding tasks
  • Take on coding work with a wider impact
  • Get involved in the early coding phase of a project, then make space for others
  • Use time constraints to do more creative coding

2. Helpful Engineering Processes

• Define "done"
• Coding style guidelines
• Code reviews
• Post-commit code reviews
• Automated testing and testing in production
• Scaffolding new services and components
• Rollouts and experiment hygiene
• Systems health dashboards

3. Engineering Practices to Iterate Quickly

Tools and processes which efficient engineering groups can use:

• Continuous integration (CI)
• Continuous deployment (CD)
• Trunk-based development
• Feature flags
• Monorepos
• Microservices vs monoliths

4. Tools to Make Engineers More Efficient

• Services catalog
• Code search
• Developer portals
• Cloud development environments
• Artificial Intelligence (AI) coding tools
• Buy, build or adopt?

5. Compliance and Privacy

• Regulations
  • PII
  • GDPR
• Logging
• Auditing

6. Secure Development

• Secure coding practices
• Dependencies as security vulnerabilities
• Penetration testing
• Security engineers

Reliable Software Systems

1. Owning Reliability

"You almost always need to partner with engineering managers to move the needle on reliability."

2. Logging

"Logs are meant to help an engineering team debug production issues, by capturing missing but necessary information for future reference during troubleshooting."

Logging tool-set:

• Log levels
• Log structure
• Automated logging
• Log retention
• toggling logging levels

On logging:

• Make your logging practice explicit
• A logging guide that's stood the test of time
  • Best logs
    • when, where, how
    • suitable for manual, semi-automated and automated analysis
    • no need for specific software
    • don't slow the system
    • reliable
  • Events to log
    • Authentication/authorization
    • system access/data access
    • system/ application changes
    • data changes
    • invalid input
    • resources
    • health/availability
  • What to log
    • timestamp & timezone
    • system, application or component; IPs, name/roles of systems involved and local applications
    • user
    • action
    • status
    • priority
    • reason
• Have a framework that makes logging the "right" way easy

3. Monitoring

• 50th, 90th, 95th percentile
• Things to monitor
  • general health
    • uptime
    • CPU, memory, disk space
    • response time
    • error rates
  • backend services
    • https status code responses
    • latency metrics
  • web apps and mobile
    • page load time
    • core web vitals metrics
  • mobile
    • start-up time
    • crash rate
    • app bundle size
• Monitoring business metrics
  • some general examples
    • customer onboarding
    • success and error rates for business-specific actions
    • daily/weekly/monthly active users (DAU/WAU/MAU)
    • revenue
    • usage numbers
    • numbers of support tickets
    • retention and churn

"Monitoring alone isn't sufficient to ensure a system is reliable. Alerts need to be fired when the metrics look wrong, which an oncall engineer must receive, investigate and mitigate."

4. Alerting

Which metrics to monitor? Start with business:

• what does "healthy" look like?
• what outages happened previously?
• what do customers notice when things are not working?

On alerting:

• Urgency of alerts
  • urgent -- paging
  • non-urgent -- non-paging
• Alert noise
  • precision -- percentage of alerts which indicate a real problem
  • recall -- percentage of alerts for which alerts are fired
  • measure recall and precision
• Static thresholds vs anomaly detection
  • use judgement to decide which types of alerts to use, and when

5. Oncall

• Typical oncall rotations
  • Primary oncall
  • Pager application
  • Secondary and tertiary oncall
• Dedicated oncall team vs every team being oncall
  • 6 members in a rotation is healthy cadence
  • consider merging teams to achieve it
• Oncall runbooks
  • Diagnostic steps
  • Pointers to mitigate an outage
  • Relevant previous incidents
• Oncall compensation
  • Regulation
  • Whether being oncall is the only job
  • Is oncall voluntary
• Should engineers do "normal" work while oncall?
  • Combine oncall with support engineering
  • Assume zero project work and only oncall work
  • Assume an engineer has no capacity for project work while oncall
  • Assume the engineer will be at X% of capacity
• Oncall burnout
  • usually happens on a combination of two or more factors
    • engineers go oncall more than once a week per month
    • the oncall rotation is noisy, meaning most alerts are non-actionable
    • engineers are awoken at night more than once a week per rotation
    • many outages happen, with lots of fires to put out
    • engineers are expected to do "normal" work while oncall

6. Incident Management

• Detecting an incident
  • Declaring an incident
  • Categorizing and prioritizing an incident
• Fix it
  • Incident management
  • Mitigation
  • Assessing the root cause of an outage isn't the biggest priority
• Follow-up after an incident
  • Incident analysis/postmortem
  • The incident review
  • Incident follow-up actions
  • Blameless reviews
  • Consider whether your incident review process prioritizes learning from incidents

7. Building Resilient Systems

• Planning phase
  • SLIs
  • Plan for failure
  • Plan for load
  • Plan for redundancy
  • Plan for what to monitor and alert for
• During the coding phase
  • Code defensively
  • Pay attention to error states and error mapping
  • Consider state management
  • Catch unknown states
• Simulate failures and test the system's response
  • Graceful degradation
  • Retries
  • Circuit breaker
  • Data center failover
  • Disaster recovery

Software Architecture

"Software architecture is the baseline for planning complex systems, while good software architecture is the foundation which reliable and maintainable systems are built upon."

1. Keep It as Simple as Possible

"Coming up with complex architecture is often much easier than sketching something simple and efficient."

2. Know the jargon, but don't over use it

• software engineering-related jargon
• business jargon
• internal jargon

"Find a way to organize and learn the jargon for your day-to-day work."

3. Architecture Debt

• Creating standalone services to move faster
• Not breaking up a monolith
• Non-functional issues
• Dated languages or frameworks

4. One-Way Door vs Two-Way-Door Decisions

• Two-way door decisions
  • A/B testing of a feature
  • Naming
  • Whether to split one class into two classes
  • Choosing a CSS preprocessor
  • Choosing a testing framework
  • Choosing a new linter
• One-way door decisions
  • Switching from a monolith to microservices, or vice versa
  • Choice of programming language
  • Choice of framework
  • Cloud vs on-premises infrastructure
  • Relational vs NoSQL data storage
  • A force upgrade strategy of a native mobile/desktop app
  • Changes that lead to a full revert/rewrite
• Two-way doors that become one-way doors
  • Protocol choice
  • Versioning strategy
  • Exposing functionality as a public, stable API
  • Launching a new, customer-facing service
• In-between decisions

5. The Blast Radius of Decisions

"Figure out ways to shrink the blast radius."

6. Scalable Architecture

• Scalability of growth of new business use cases -- you cannot design for scalable business use cases without understanding two things:
  • how the business works
  • the company's roadmap
• Scalability of growth in data, usage, traffic load

7. Architecture Decisions vs Business Priorities

• Align architecture decisions with business's goals and growth
• Tie architecture changes to business initiatives
• Good enough may be better than perfect

8. Stay Close Enough to Where the Work is Done

• Strike a balance in being close to where the work is done and doing the work of engineers
• Keep being involved in architecture decisions and support other engineers to become better architects

9. Software Architect Traits

• Theoretical traits
  • Ivory Tower architect
  • Painfully precise
  • Theory addict
  • The philosopher
  • The superior linguist
  • The walk-away advisor
• Practical traits
  • The coding machine
  • The integrator
  • The approachable one
  • The detailed documenter
  • The new, shiny chaser
  • The old schooler
• Are architecture traits useful?
  • "Pairing engineers with different traits can generate great outcomes."

Takeaways

"The term 'staff engineer', 'principal engineer', and other staff+ engineer titles can mean surprisingly different things at different companies. [...] So intead of just focusing on the title, figure out what the expectations are at your current workplace, and at businesses you want to join."

"At this level, understanding the business is table-stakes, together with working well with a wide range of people, such as EMs, PMs, business folks and other engineers."

Part VI - Conclusion

Lifelong Learning

1. Stay Curious

• Ask questions -- examples
  • Why are we doing this project, who benefits?
  • Why does it work now: what changed?
  • Which alternatives could we use?
  • How does this solution work, exactly?
  • What does this component do under the hood?
  • What would it mean if we built our own solution from scratch?
• Stay curious and be humble

2. Keep Learning

• Pairing and shadowing
• Mentorship
• Self-guided learning
• Share what you learn
• Hoard knowledge
• How you learn changes over time

3. Keep Challenging Yourself

Levels:

• Onboarding/beginner
• Proficient
• Expert

"Once you reach 'expert' level, the learning curve tapers off."

4. Keep up with the industry

Way to keep up with pace of change:

• Through work
• Keep up with tech news
• Build side projects
• Tinker with tech, even at work

5. Give yourself a break