Skip to main content

Seniority/Maturity

Moving towards seniority/maturity in work.

Resources​

  • Startup CTO Handbook
    • Targetting devs growing into CTO role. How to manage a tech team.
    • People: management, coaching, hiring, etc.; Tech: debt, roadmap, DX, DevOps, testing, security & compliance, etc.
  • Engineering Management | GitHub @charlax
    • List of resources related to (engineering) management (something like this Wiki)

Sites​

  • 3 Mistakes I made as an Engineer, but had to Become a Manager to See (HN)
    • People problems are important, hiring well saves time, and getting to know your coworkers
    • This feels like things to get right after getting the basics right, i.e. code is working
  • Stop Being a Junior | Kent C. Dodds
    • Tech is fast, take it as an opportunity to quickly catch up to the frontier
    • Try to be at the level of the seniors, and eventually will start to feel like one
    • Volunteer to participate and talk about accomplishments but do not overstep
  • On Being A Senior Engineer | Kitchen Soap
    • Mostly focused on software engineer role, but the skills and practices are transferable to any "senior" or "mature" role
    • These are observations, not rules. The goal is to internalize the principles. Some of the inspiring ones are:
      • The non-technical areas: self-awareness when it comes to communication. Be assertive, not passive or aggressive.
      • Anticipation of the outcome of a decision/design, how will things unfold in the future?
      • Sponsorship: provides opportunity and exposure for others, e.g.: suggesting someone to lead a project
      • Make trade-offs explicit: every project cuts corners, and mature engineers know how much is cut
      • Empathetic: the ability to view the decisions from others' perspective
      • No empty complaints: always provide at least 1 suggestion to improve before complaining
      • Aware of biases: confirmation, self-serving, fundamental attribution, hindsight, outcome, planning fallacy
      • Understand the importance of (sometimes irrational) feelings people have: objectively the best might not be subjectively the best for this group of people
  • An action plan for engineering career success | GitHub The ReadMe Project
    • Technical skills, connect the dots between engineering & revenue, demonstrate understanding of the business domain
    • Brag document: records of completed projects, professional development, feedback and recognition, etc
    • Communicate well, mentor others, write documentation, and continue to learn
  • The Curse of the Senior Software Engineer
    • The curse of staying too long at a senior role
    • Too senior to be considered as a senior but too inexperience for leadership role
    • Either play the corporate game and climb the ladder, or quit the game and do something that doesn't care about the titles
  • Try to Take My Position: The Best Promotion Advice I Ever Got (HN)
    • Not to wait and be told what to do
    • Understand the goals and constraint to show that you are capable to handle your boss job
    • Solve problems that your boss is solving, make proposal that your boss is going to propose
  • 21 Lessons From 14 years at Google
    • Lessons mostly focused on a software engineer, but largely applicable to other roles
    • Approach to work:
      • The best engineers are obsessed with solving user problems, not using cool technology
      • Take action and ship, iterate and learn from real feedback
      • Prioritize clarity over cleverness, optimize for comprehension
      • Favour boring technology not novel innovations
      • Best code is the code never had to write, question the purpose
      • At scale, bugs have users, understand the cost of compatibility
      • Abstractions don't remove complexity, understand how things work underlying
      • Work that enable other work is priceless but also invisible, do it when needed
      • Most performance wins come from removing work, not adding clever optimization
    • Teamwork:
      • Being right is cheap but getting right together is the real work
      • Slow teams are usually misaligned teams, clarify direction
      • Winning every debate probably means accumulating silent resistance
      • Process reduce uncertainty and failures, not to be bureaucratic
    • Growth and mindset:
      • Code doesn't advocate for you, but people do
      • Focus on what you can control and ignore what not
      • Writing forces clarity, the fastest way to learn is to teach
      • When a measure becomes a target, it stops measuring
      • Admit what you don't know, stay curious
      • Your network outlasts every job
      • Eventually, time worth more than money, make the trade deliberately
      • There are no shortcuts but learning compounds

Managerial Role​

  • What you give up when moving into engineering management | Stackoverflow blog (HN)
    • Managers give up focus time, have to deal with longer feedback cycles, more conflicts and interpersonal issues, make fewer technical decisions, and less time acquiring tech skills
  • Promoted from Dev to Team Lead: 8 Things They Didn't Tell Me | Dev Interrupted
    • Quite an easy read with good examples
    • Skills don't translate: skill sets of a dev vs a team lead is different
    • Keep your instincts but change your behaviour: sometimes just asking the right question can unblock people
    • Communicate "why" more than "what and "how": let the team see the bigger picture
    • Culture is a real thing. Team leads are responsible for it
    • Clear a path for the team: unblock people. Generally three types of blockers: technical, dependencies and priorities
    • Spend 50% of the time on priority setting and estimation
    • Invest in the ecosystem: build relationships with other teams, sales, product owners, ops, etc
    • Translate engineering to executives with data: provide data and metrics
  • The way that Jensen Huang runs Nvidia is wild
    • Direct reports, no status reports, everyone has context, no formal planning cycles
  • What it's like to start a job as CEO?
    • E.g.: learn quick, be curious about the details but not micromanage, big decisions with bizarrely little context
  • The most important skill in a startup engineering leadership
    • Pacing, the leader pace and the member pace
    • Be honesty and transparent, constant measurement
    • Set goals, make incremental changes and carefully name the repercussions
  • What Your Job Ad Says About You
    • Competitive salary and years of experience means nothing
    • Instead of listing lengthy requirements, put what the candidate is expected to do in the first year
  • Mistakes as a new manager (HN)
    • Delegation: learn to delegate work and empower the team
    • Dopamine: changes from shipping to giving feedback, reports, etc.
    • Quality v.s. quantity: learn to build high quality team not a bigger team
    • Engagement: too much means micromanaging, too little means disengaging
    • Perception: how to show your work as a manager, clarity and visibility of effort
    • Success metric: Is the team shipping? Is the team happy?
  • How I've run major projects
    • Focus and set the project as the top priority
    • Maintain a detailed plan to success, observe and keep iterate quickly on the plan
    • Over-communicate, both 1-1 and broadcast updates to get everyone aware of what's happening around
    • Break off subproject and delegate to others to manage a goal
    • Project managers are laser focus and highly organized person, expect their IC ability to take a hit
  • Compensation as a Reflection of Values | Oxide (2021)
    • Also, Oxide's Compensation Mode: How is it Going? (2025)
    • Oxide pay almost everyone equal amount of salary, from founder to all employees, except some sales roles
    • Explained why they do this, how that reflect the values and benefit the company
  • Stuff I learned at Carta | Will Larson
    • 2 years as CTO of Carta
    • On strategy, culture, LLMs, managing seniors, managing costs, explaining eng costs to execs, etc.
    • Many links to previous blogs
  • Advice for New Principal ICs
    • 30+ advices for principal ICs
    • E.g.: teaching the org to value something it doesn't care about yet, sponsor project that won't happen without you, connect the dots, the title comes with an aura of credibility even if it shouldn't
    • 50% time owning projects, 20% time sponsoring projects, rest consulting and mentoring
  • What "The Best" Looks Like
    • Hire the best by noticing hidden potentials from candidates
    • Discover non-obvious talent to build a high-leverage team on a startup budget
    • 11 traits listed: hunger, self-driven, humility, detach from one's work, high EQ, etc.