charlax/engineering-management

Table of Contents

• About this list
• Books
  • Turn the Ship Around!: A True Story of Turning Followers into Leaders
  • Other generalist books
  • Book reading lists
• What is engineering management?
  • General management resources
  • Articles
  • Tools
• Engineering Management Topics
  • 1-1
  • Antipatterns
  • Biases
  • Brainstorming
  • Career growth and job ladder
  • Change management
  • Code reviews
  • Communication
  • Conflict resolution
  • CTO (Chief Technical Officer), VPoE and other levels
  • Data organization
  • Culture
  • Decisions
  • Delegation
  • Delivery
  • Developer productivity and devexp (developer experience)
  • Diversity and inclusion
  • Employee handbook
  • Employee retention
  • Escalations
  • Executives
  • FinOps (cost)
  • First-time manager
  • Feedback
  • Hands-on
  • Hiring
    • General
    • Hiring: interviews
    • Hiring: interview questions
    • Hiring: job postings
    • Hiring: process
    • Hiring: résumé review
    • Hiring: sourcing
    • Hiring: take home exercises
    • Hiring: quotes
  • Incident prevention and response (on-call, outages)
  • Learning, retro, postmortem
  • Management style
  • Meetings
  • Mentoring
  • Mindset and attitude
  • Motivation
  • Onboarding new team members or yourself
  • Organizational structure
  • Performance management
  • Personal productivity
  • Planning (roadmap, goal setting, KPI, OKR, etc.)
    • Goals
    • OKRs
  • Presentations, design and public speaking
  • Prioritization
  • Problem solving
  • Processes for engineering
  • Product management
  • Production and productivity
  • Project management
    • Estimating work (project management)
  • Quality
  • Release management
  • Remote teams
  • RFCs (request for comments)
  • Scaling an organization
  • Second level manager (2LM)
  • Security
  • Soft skills, Emotional Quotient (EQ)
  • Storytelling
  • Strategy
  • Survey
  • Talent management
  • Team vision
  • Technical strategy
  • Team culture
  • Team dynamics
  • Training
  • Trust
  • Work ethics & work/life balance
  • Workshop facilitation
  • Writing
• Other sources
  • Other lists
  • Movies
  • TV Shows
• Keeping up-to-date: blogs and newsletters
  • Newsletter
  • Blogs
  • Podcast
• My other lists

About this list

Items:

• 🧰 : list of resources
• 📖 : book
• 🎞 : video/movie extract/movie
• 🎤 : slides/presentation
• 🎧 : podcast
• ⭐️ : must-read

Books

More than any other field, management is full of fluffy books that could be summarized in one 100-word article. That being said, there's a number of excellent books, listed below.

Turn the Ship Around!: A True Story of Turning Followers into Leaders

📖 Turn the Ship Around!: A True Story of Turning Followers into Leaders is hands down my preferred management book.

This book made me truly understand what empowering local decision means. In particular, I liked how the author explains that the usual chain of command requires information to go up the chain, and decision to go down, which is insanely inefficient.

It provides great tools for managers to help their team members come up with their own decisions, in particular the notion of deliberate action. There's a also a presentation that talks about the main concepts the author developed.

There are numerous cheesy management books and this is not one of them. The narration is great as well and the explanations are short, and to the point.

You can find a short summary in video here

“Control without competence is chaos.”

— L. David Marquet, Turn the Ship Around!

Other generalist books

• 📖 The Advantage, Enhanced Edition: Why Organizational Health Trumps Everything Else In Business, Patrick M. Lencioni.
  • The only way for people to embrace a message is to hear it over a period of time, in a variety of different situations, and preferably from different people. That’s why great leaders see themselves as Chief Reminding Officers as much as anything else.
  • The best way to do cascading communication is face-to-face and live. Seeing a leader and hearing the tone of his or her voice is critical for employees, as is being able to ask a question or two.
  • But then again, most organizations are unhealthy precisely because they aren’t doing the basic things, which require discipline, persistence, and follow-through more than sophistication or intelligence.
• 📖 Managing Humans: Biting and Humorous Tales of a Software Engineering Manager: "Read hilarious stories with serious lessons that Michael Lopp extracts from his varied and sometimes bizarre experiences as a manager at Apple, Pinterest, Palantir, Netscape, Symantec, Slack, and Borland. Many of the stories first appeared in primitive form in Lopp’s perennially popular blog, Rands in Repose."
• 📖 Oren Ellenbogen, Leading Snowflakes: the Engineering Manager Handbook: some truly great content and concrete ideas to move from maker to manager mode, code reviewing your management decisions, delegating tasks without losing quality or visibility.
• 📖 Adam Grant, Give and Take: Why Helping Others Drives Our Success: "This gem is a joy to read, and it shatters the myth that greed is the path to success.", Robert Sutton.
• 📖 Ken Blanchard, Lead Like Jesus: Lessons from the Greatest Leadership Role Model of All Time.
• 📖 Andrew S. Grove, High Output Management. A landmark book by Intel CEO Andy Grove. Introduced many of the management best practices such as 1-1, OKR.
  • Managerial leverage measures the impact of what managers do to increase the output of their teams.
  • You need to plan the way a fire department plans. It cannot anticipate where the next fire will be, so it has to shape an energetic and efficient team that is capable of responding to the unanticipated as well as to any ordinary event.
  • Every hour of your day should be spent increasing the output or the value of the output of the people whom you’re responsible for.
  • A common rule we should always try to heed is to detect and fix any problem in a production process at the lowest-value stage possible.
  • A genuinely effective indicator will cover the output of the work unit and not simply the activity involved. Obviously, you measure a salesman by the orders he gets (output), not by the calls he makes (activity).
  • A manager’s output = The output of his organization + The output of the neighboring organizations under his influence.
  • League standings are kept by team, not by individual. Business—and this means not just the business of commerce but the business of education, the business of government, the business of medicine—is a team activity. And, always, it takes a team to win.
  • Your decision-making depends finally on how well you comprehend the facts and issues facing your business. This is why information-gathering is so important in a manager’s life.
  • The lack of a decision is the same as a negative decision; no green light is a red light, and work can stop for a whole organization.
  • Delegation without follow-through is abdication.
  • Any decision be worked out and reached at the lowest competent level. The reason is that this is where it will be made by people who are closest to the situation and know the most about it.
  • Self-confidence mostly comes from a gut-level realization that nobody has ever died from making a wrong business decision, or taking inappropriate action, or being overruled.
  • A successful MBO [management by objective] system needs only to answer two questions: 1.  Where do I want to go? (The answer provides the objective.) 2.  How will I pace myself to see if I am getting there? (The answer gives us milestones, or key results).
  • The one thing an MBO system should provide par excellence is focus. This can only happen if we keep the number of objectives small. In practice, this is rare, and here, as elsewhere, we fall victim to our inability to say “no”—in this case, to too many objectives. We must realize—and act on the realization—that if we try to focus on everything, we focus on nothing. A few extremely well-chosen objectives impart a clear message about what we say “yes” to and what we say “no” to—which is what we must have if an MBO system is to work.
  • Alfred Sloan summed up decades of experience at General Motors by saying, “Good management rests on a reconciliation of centralization and decentralization.” Or, we might say, on a balancing act to get the best combination of responsiveness and leverage.
  • I would like to propose Grove’s Law: All large organizations with a common business purpose end up in a hybrid organizational form.
  • When a person is not doing his job, there can only be two reasons for it. The person either can’t do it or won’t do it; he is either not capable or not motivated.
  • That variable is the task-relevant maturity (TRM) of the subordinates, which is a combination of the degree of their achievement orientation and readiness to take responsibility, as well as their education, training, and experience.
  • When the TRM is low, the most effective approach is one that offers very precise and detailed instructions, wherein the supervisor tells the subordinate what needs to be done, when, and how: in other words, a highly structured approach. As the TRM of the subordinate grows, the most effective style moves from the structured to one more given to communication, emotional support, and encouragement.
  • The responsibility for teaching the subordinate must be assumed by his supervisor, and not paid for by the customers of his organization, internal or external.
  • At all times you should force yourself to assess performance, not potential.
  • A manager generally has two ways to raise the level of individual performance of his subordinates: by increasing motivation, the desire of each person to do his job well, and by increasing individual capability, which is where training comes in.
• 📖 Patrick Lencioni, The Five Dysfunctions of a Team: A Leadership Fable.
• 📖 Work Rules!: Insights from Inside Google That Will Transform How You Live and Lead, Laszlo Bock. A pretty interesting description of Google's processes. A bit long at times.
• 📖 The Manager's Path , Camille Fournier. A very practical book with lots of down-to-earth advices.
• 📖 Team Topologies, from ITRevolution Press. Discusses the intricacies of managing Engineering Departments, and especially patterns for improving team interactions.
• 📖 The Effective Executive by Peter Drucker, Seminal Work in Management. Discusses challenges of management, especially managing Knowledge Workers. Proposes principles for effective decision-making and continued improvement of one's organization
  • May also serve as grounding for growing beyond Engineering Management, as well as working with other departments.

There are some other more specific books quoted below.

Other books I haven't read:

• Engineering Management for the Rest of Us
• ZachGoldberg/Startup-CTO-Handbook

Book reading lists

• Jason Evanish's list (Lighthouse founder) is quite comprehensive.
• Holiday Book Recommendations for Engineering Managers, Software Engineers and Product Managers, Gergely Orosz
• Most Recommended Books to Make You a Better Engineering Manager
• 10 Must-Reads for Engineering Leaders
• Your 12-month engineering manager MBA reading list

What is engineering management?

Here are some generic resources:

• Unintuitive Things I’ve Learned about Management
• Lars Dalgaard, Thoughts on Building Weatherproof Companies: while originally aimed at startups CEOs, this article from Andreessen Horowitz's blog is a very inspiring read on what it takes to scale your team.

General management resources

• 14 Points for Management by W. Edwards Deming.
• Keith Rabois on the Role of a COO, How to Hire and Why Transparency Matters includes some nice management nuggets.
• 🧰 ksindi/managers-playbook: Heuristics for effective management
• The Evolution of Management, Kate Matsudaira, ACM Queue. A great compilation of advices for all management levels.
• Principles of Management a nice introduction for all management aspects for new managers.

Tal Bereznitskey's awesome definition for managing engineers:

Hire motivated people. Trust them. Set high standards for everything. Lead by example. Get out of their way and let them be the heroes of the day. That’s it.

Articles

• The Quiet Crisis unfolding in Software Development
• Mistakes of the First Twenty-five Years, in which Warren Buffet describes the "institutional imperative", or how an institution will amplify (not resist) a bad manager's irrational decisions.
• 44 engineering management lessons from the cofounder of RethinkDB. Very high-level, a pretty good summary.
• 21 management things I learned at Imgur
• The Rands Test, Rands in Repose. The equivalent of The Joel Test for management.
  • Do you have a 1:1?
  • Do you have a team meeting?
  • Do you have status reports?
  • Can you say No to your boss?
  • Can you explain the strategy of the company to a stranger?
  • Can you explain the current state of business?
  • Does the guy/gal in charge regularly stand up in front of everyone and tell you what he/she is thinking? Are you buying it?
  • Do you know what you want to do next? Does your boss?
  • Do you have time to be strategic?
  • Are you actively killing the Grapevine?
• What are the signs that you have a great manager? : great discussion on Hacker News
  • A great manager is at the service of their team.
  • You don't really notice a great manager.
  • Communicate context as high level and as complete as possible.
• Managing people
  • As a manager, everything is your fault
  • You manage processes; you lead people
  • Processes are expectations made explicit
  • Trust through transparency
  • Don't confuse autonomy and abandonment
  • Avoid drive-by management
  • Explicit > Implicit
  • Expect to refactor your company every few months
  • Chaos is felt less by the people creating it
  • Expect more from managers that report from you
• 37 Years Ago, Steve Jobs Said the Best Managers Never Actually Want to Be Managers. Science Says He Was Right
  • "If your boss could do your job, you're more likely to be happy at work"
• Group Dynamics: The Leader's Toolkit (Ed Batista)
• Some mistakes I made as a new manager
  • The trough of zero dopamine
  • Staying on the critical path
  • Managing the wrong amount
  • Procrastinating on hard questions
  • Indefinitely deferring maintenance
  • Angsting instead of asking
• How to grow as an Engineering Manager, Srivatsan Sridharan
  • Create new opportunities for your learning
  • Choose an archetype:
    • Inspirational leader
    • Tough coach
    • Business strategic
    • Tech innovator
    • Master orchestrator
    • Savvy politician
• Numbers To Know For Managing (Software Teams)
  • 4 - the number of minutes to spend on chit chat in the beginning of a meeting
  • 5 - the number of comments on a document before you should ask to talk about the issue
• Unexpected Anti-Patterns for Engineering Leaders, Will Larson
  • Unexpected anti-pattern #1: shying away from micromanagement
  • Unexpected anti-pattern #2: pushing back on measuring flawed metrics
  • Unexpected anti-pattern #3: serving as the umbrella for your team
• Categories of leadership on technical teams
  • Overall direction
  • People management
  • Project management
  • Technical leadership
  • The “tech lead manager”
  • Engineering manager / tech lead
  • Product manager / tech lead
  • People manager / research lead
• Expert Generalists, martinfowler.com, proposes an interesting take on the "T-shaped engineer". See the summary on my repo professional-programming

Tools

• devtomanager.com: first-hand advice from seasoned experts

Engineering Management Topics

This is a list of inspiring articles related to engineering management. Those are usually short and concise articles that are packed with inspiring and concrete ideas. They have shaped my own management practice, and I hope they will inspire you as well.

I don't necessarily agree with everything listed here. Actually, you'll see that some of those articles have diametrically opposed opinions. I do believe those thought-provoking resources will help you in your manager journey.

1-1

• On 1-1s
• How to have an honest one-on-one with an employee
• Tool: Hold effective 1:1 meetings
• 21 Reasons You Should Start Having One on Ones with Your Team
• What is an Inquiring Leader?
• HBR, How to Ask Better Questions
• Mentor vs Advisor vs Coach
• How To Be Someone People Love To Talk To
• 🧰 Mega list of 1 on 1 meeting questions compiled from a variety to sources
• 130+ One on One Meeting Questions Great Managers Ask
  • Building rapport & trust
  • Talking about career development
  • Giving and receiving feedback
  • Talking about ways to improve your team or your company
  • Checking in on their general happiness
  • Special questions for remote employees
  • Leading your team through difficult times
  • Being a coach to your team
  • Skip level meeting questions
  • The one on one meeting questions you need to ask every time
• Why Your One-on-One’s Should Probably Be Longer
  • The “30 minute One-on-One” Anti-Pattern
  • Change the day
• 5 Questions Every Manager Needs to Ask Their Direct Reports, HBR
  • How would you like to grow within this organization?
  • Do you feel a sense of purpose in your job?
  • What do you need from me to do your best work?
  • What are we currently not doing as a company that you feel we should do?
  • Do you have the opportunity to do what you do best every day?
• One on One Meeting Format Ideas

Antipatterns

• Seven Deadly Diseases of Management, Dr. Deming. Great video as well. I don't necessarily agree with everything but Deming is still one of the great management thinker.

Biases

• 📖 Thinking, Fast and Slow by Daniel Kahneman and published in 2012 is already a classic. It offers a whirling tour into our biases and the limits of human judgment. Truly amazing read.
• You're not going to believe what I'm about to tell you, The Oatmeal (comics) about the backfire effect ("given evidence against their beliefs, people can reject the evidence and believe even more strongly", confirmation bias - Wikipedia).

Cognitive biases don't only apply to hiring... They can impact performance reviews, 1-1, team meetings, even small talk with colleagues.

• Cognitive bias cheat sheet
• A flowchart of cognitive biases
• The Cognitive Bias Codex

Brainstorming

• Extreme questions to trigger new, better ideas, A Smart Bear
  • The following prompts jostle you out of tiny thinking
  • If you were forced to increase your prices by 10x, what would you have to do to justify it?
  • If all our customers vanished, and we had to earn our growth and brand from scratch, what would we do?
  • If you were never allowed to provide tech support, in any form, what would have to change?
  • If our biggest competitor copied every single feature we have, how do we still win?
  • What if we are forced to ship a full, completed (at least MVP) new feature, in just two weeks, that would delight and surprise some fraction of our customers.
  • What if you were forced to charge customers in a completely different manner?
  • No more synchronous meetings, ever again?
  • If we could never talk to our customers again, how would we figure out what to build?
  • What if it didn’t matter how unprofitable you were?
  • What externality has the potential to kill the entire company?

The dangerous man is the one who has only one idea, because then he’ll fight and die for it. The way real science goes is that you come up with lots of ideas, and most of them will be wrong.

— Francis Crick

Career growth and job ladder

Also check the charlax/professional-programming's Career Growth section.

• Square’s Growth Framework for Engineers and Engineering Managers
  • Have two tracks
  • Becoming a manager is not a promotion
  • Organized into two major sections: Scope & Impact and Behaviors
  • No strict minimum requirements for years of experience at any given level
  • Promotions are descriptive not prescriptive
  • Promotion decisions are structured and rigorous
• Titles are Toxic, Rands in Repose. A pretty interesting take on titles.
• Thriving on the Technical Leadership Path
  • I’ve chosen to cultivate a path for myself that enables me to dig into complex technical and product problem spaces and help lead technical and strategic direction for my organization, as an engineer but not a manager.
• Refactoring Our Engineering Skills Matrix
• How to waste your career, one comfortable year at a time
• 🎤 Creating a Career Ladder for Engineers
• Medium Engineering Growth Framework
• Engineering levels at Carta
• Things We Learned Creating Technology Career Steps (Spotify)
  • Behavior Versus Achievements
• Engineering levels and progression, Foursquare
  • A pretty concise description of what's expected at different levels (L3, L4, etc.)
• On Being A Senior Engineer, Kitchen Soap
• Keith Rabois on how to identify great talent
  • “What you want to do with every single employee every single day is expand the scope of their responsibilities until it breaks… and that’s the role they should stay in.”
  • If you see people frequently going up to a person's desk, it's a sign that that person can help them. Promote these people and give them more responsibility as fast as you can.
• An impact-based level system for engineers
  • Level 1 — Scoped Tasks
  • Level 2 — Scoped Projects
  • Level 3 — Unscoped Projects
  • Level 4 — Team Force Multiplier
  • Level 5 — Group Force Multiplier
  • Level 6 — Company Force Multiplier
• Nobody Gets Promoted for Simplicity has some good ideas for rewarding simplicity in designs (promotions, celebrations, etc.).

Curated examples of job ladder/career development matrix:

• ⭐️ RentTheRunway's Software Development/Leadership Ladder
• Songkick: concise, clear and includes examples.
• Gitlab
• Medium, Engineering Growth Framework, Medium pulls back the curtain on how they do career growth.
  • Medium's skills spreadsheet: mixes all rubrics regardless of role
• Khan Academy
  • Skills: maximise impact, be open, empathise and respect, have conviction, seek engineering maturity.
  • Levels: beginning skillful, skillful, more skillful, super skillful, ludicrously skillful
• CircleCI: detailed and complete
• Dropbox
• progression-framework/frameworks/engineering
• jorgef/engineeringladders
• Fog Creek Professional Ladder – Joel on Software
• Square (competencies)
• career-ladders

List of lists:

• 30+ Engineering Career Ladders
• Another list of career pathways by a Progression, a tool to define and measure career growth

Concepts:

• Four stages of competence, Wikipedia

Change management

• 🎧 At The Table with Patrick Lencioni: 50. Let the Haters Hate
• Nemawashi (Wikipedia): "an informal process of quietly laying the foundation for some proposed changed".
• Why the status quo is so hard to change in engineering teams
  • Process-related Learned Helplessness
  • Complexity-related Learned Helplessness
  • Resignation by a thousand cuts
  • Declare process bankruptcy

Code reviews

See my professional-programming section about code reviews

Communication

• Tough News: We’ve Made 10 Layoffs. How We Got Here, the Financial Details and How We’re Moving Forward: a great post by Joel Gascoigne (CEO & Founder of Buffer) sharing some pretty tough news to the team and to the world. Great transparency, great message, great ownership. A model to follow.
• How To Pitch A Product, AVC.
• Ken Norton’s Discipline of No. #attitude #habits.
• Nonviolent communication (Wikipedia)
• Mental Models I Find Repeatedly Useful
• Breaking Bad News
• Operations and Internal Communication Strategies For Effective CEOs
  • Narratives (not facts) are what move people
  • The why always before the what
  • Alignment is not one-way only
  • Repeat, repeat, repeat
  • Consider writing a personal weekly newsletter
• Tools for better thinking
  • Decision matrix
  • Ladder of inference
  • First principles
• How To Say No. Templates for saying no to written interviews, going to an event, doing free work...
• 🎧 At The Table with Patrick Lencioni: 59. Don't Make Me Repeat Myself
• How to Disagree, Paul Graham
  • Disagreement hierarchy 0: name calling
  • DH1: ad hominem
  • DH2: responding to tone
  • DH3: contradiction
  • DH4: counterargument
  • DH5: refutation
  • DH6: refuting the central point
  • Analyzing your own level of disagreement can help with unintentional intellectual dishonesty.
  • When you have something real to say, being mean gets in the way
• Apple Pie Position, Shreyas Doshi
  • A statement that instantly elevates the person who is saying it and is simultaneously hard for anyone else to push back on, and so everyone avoids the personal risk and just nods “yes”, even though its actual value in this specific situation might be relatively low, zero, or even negative.
  • E.g., "We need to define the success metrics for X"
  • E.g., "We need a better go-to-market motion to improve product adoption"
• How to Communicate When Trust Is Low (Without Digging Yourself Into A Deeper Hole)
  • Acknowledge it is hard
  • Speak tentatively
  • Try to sound friendly, take a breath
  • "The story in my head"
  • Engineer positive interactions (the magic ratio for healthy relationships is at least five positive interactions for every one negative interaction)
  • Communicate positive intent
  • Give people the opening to do better
  • Value the effort
• Why You Should Send a Weekly Summary Email

Conflict resolution

• 🎞 Disagree and commit

CTO (Chief Technical Officer), VPoE and other levels

See also the section about Organizational structure

• Martin Casado, Hire a VP of Engineering on the Andreessen Horowitz blog
  • The most important function of a VP of engineering is to build out the engineering team and set a startup’s engineering culture.
  • Competent engineering management should therefore be able to push the team towards more practical, incremental designs that can garner useful external feedback quickly — without compromising the long-term generality of the system. The VP’s role here is not producing the architecture, but ensuring that incremental release is a real requirement in the design process.
  • Strong engineering management tends to give their teams enough ownership and latitude that they are happy and fulfilled in driving the product forward.
• AVC, VP Engineering Vs CTO
• Mark Suster, Want to Know the Difference Between a CTO and a VP Engineering?
• 🎤 CTO vs VP Engineering Balancing Innovation, Bryan Cantrill, Jason Hoffman
• Will Larson, Your first 90 days as CTO or VP Engineering.
  • Durable improvements depend on creating systems that create changes, not performing tactical actions that create the ephemeral appearance of improvement.
  • Figure out if something is really wrong and needs immediate attention.
  • Shadow customer meetings, partner meetings or user testing.
  • Find your business analytics and how to query them.
  • Shadow existing interviews, onboarding and closing calls.
  • Kickoff engineering brand efforts.
  • Build a trivial change and deploy it.
• The 7 roles of a CTO
  • Executive
  • Representative
  • People manager (sometimes)
  • Hands on developer (sometimes)
  • Owns security and IT
  • Salesperson
  • Does whatever it takes
• Advice for new directors
  • A lot of your job is training managers
  • Biggest skill to learn: sensing your organization
  • You’ll need a new perspective
  • You should focus on systems
  • Beware the distortions of power
  • You’re judged by the difference you make on your organization.
• Your CTO Should Actually Be Technical
  • Exceptional technical ability is the only way for CTOs/VPEs to be true judges of quality.
  • It allows them to make highly educated tradeoffs
• 5 Things Founders, Investors and Recruiters Should Know about the CTO role
  • “The CTO’s primary job is to make sure the company’s technology strategy serves its business strategy” — Eric Ries.
  • As a CTO, you don’t work in the box, because your task is to examine the box and make it better.
  • The CTO might code, but only on POCs and prototypes.
• What It Really Means to be a Manager, Director, or VP
  • Managers are paid to drive results with some supports
  • Directors are paid to drive results with little or no supervision ("set and forget")
  • VPs are paid to make the plan. (no "get-out-of-jail-free" card because "the CEO approved the plan")

Data organization

• Building a data team at a mid-stage startup: a short story
• Building The Analytics Team At Wish (a four-part series of articles)
  • Rebuilding The Data Pipeline
  • Building The Data Warehouse
  • Deploying Business Intelligence Tooling
  • Data engineering should build a system that allows analysts to produce their own pipelines.
  • Strong interviewers need to have flexible questions that react to signals from the candidates.
• Engineers Shouldn’t Write ETL: A Guide to Building a High Functioning Data Science Department
  • You Probably Don’t Have Big Data
  • Nobody enjoys writing and maintaining data pipelines or ETL. It’s the industry’s ultimate hot potato.
  • Give data scientists ownership of the ETL end-to-end
  • Engineers design new Lego blocks that data scientists assemble in creative ways to create new data science.
  • It is absolutely essential for platform engineers to stay ahead of the data science teams
  • Engineers should see themselves as being “Tony Stark’s tailor”, building the armor that prevents data scientists from falling into pitfalls that yield unscalable or unreliable solutions.
  • We [should be ok with] sacrificing technical efficiency for velocity and autonomy

Culture

• The maze is in the mouse lays out how Google's culture impeded its results and execution.
  • "It is a soft peacetime culture where nothing is worth fighting for."
  • Google employees get very little done because they are trapped in a maze of processes.
  • The culture focuses on consensus ("respect each other") and risk-avoidance at the expense of heroism or value-creating ideas/bets.
  • Each employee's mission is not about the customer but about serving a VP or a technical belief/process.
  • Most managers are peacetime managers and lack a sense of urgency.
  • There is a general lack of humility regarding the internal tech stack. The delusion of exceptionalism means that employees believe everything they do is perfect.
  • "Strategy is rarely articulated clearly (that would be career risk)"

Decisions

• Square Defangs Difficult Decisions with this System — Here’s How
• How to simplify complex decisions by cleaving the facts, Jason Cohen.
• Mental Models: The Best Way to Make Intelligent Decisions (113 Models Explained)
• How to Make a Big Decision, the NYT.
• Principles for Decision-Making in a Flat Organization
  • We risk more when we delay decisions in an attempt to reach total consensus.
  • If there is a good enough solution X, don’t ask people what they think about it. Instead, ask everyone if they can live with it and if not, why.
  • Consensus is the path, not the destination.
• Principles.dev - Software Engineering Principles
• Guiding principle: consent over consensus
• Tools for better thinking: Situation-Behavior-Impact, conflict resolution diagram, Ishikawa diagram, Einsenhower matrix, second order thinking, decision matrix, etc.
• Balancing Engineering Cultures: Debate Everything vs. Just Tell Me What To Build
  • To get out of "debate everything"
    • Help people operate in the "gray area"
    • Introduce the "FG" scale to streamline debates
    • Incentivize outcomes
  • To get out of "just build it"
    • Incentivize outcomes and feedback
    • Provide context and venue to discuss
    • Codify expectations (product and eng)
• Ask Questions, Repeat The Hard Parts, and Listen, Rands in Repose: a good framework for letting your team make decisions autonomously. "My job is to teach you not to need me"
• Be good-argument-driven, not data-driven
• Second-order Thinking

Arguments you should avoid using - that are logical fallacies “Because it’s always been done this way.” “Because we tried it before, and it didn’t work.” “Because company X uses this.” “Because {important person} said so.”

Reason on tradeoffs, constraints, opportunities instead.

– Gergely Orosz

Delegation

• The Counterintuitive Art of Leading by Letting Go
• Against micromanagement: "After you plant a seed in the ground, you don’t dig it up every week to see how it is doing", William Coyne, Head of R&D at 3M.
• Your Small Imprecise Ask Is a Big Waste of Their Time

The 70/10/80 Principle of delegation: “Find someone who can do what you do at 70% the success rate. Teach them the extra 10% and be okay with 80%.”

Delivery

• A primer on engineering delivery metrics
• Engineering productivity can be measured - just not how you'd expect. Interesting take.
  • Non-measurement unfairly rewards people with charisma while productive but less-persuasive engineers wallow in frustration.
  • Measure Blockers at the Team Level

Developer productivity and devexp (developer experience)

See also the "Personal productivity" section in this page.

• DevEx: What Actually Drives Productivity, ACM Queue. Defines the components of developer productivity, as well as metrics.
  • Flow state
  • Feedback loops
  • Cognitive load
• How To Get Buy-in for DevEx Initiatives: Strategies From GitHub, Notion, and More
  • Categorize projects into themes that resonate with leadership
  • Play the long game: avoid having a single-minded agenda
  • Start by identifying “the thorn” in your leadership’s side
  • Quantify the business value of projects
• Measuring Developer Productivity via Humans, Martin Fowler
• 2024 DORA report

Diversity and inclusion

• 📖 Breaking Through Bias: Communication Techniques for Women to Succeed at Work
  • Most men believe that they have no biases against women and that the organizations in which they work treat women and men equally. If senior-level men read this book, they will realize that neither of these beliefs is correct.
• 📖 Thinking, Fast and Slow, Wikipedia
  • 🎞 2 Minutes Book Summary: Thinking Fast and Slow
• Guess Who Doesn’t Fit In at Work
• List of cognitive biases on Wikipedia
• 🎞 Making the Unconscious Conscious (Google Video)

Hiring:

• Why Hiring for "Culture Fit" Hurts Your Culture
• Xavier Niel explains 42: the coding university without teachers, books, or tuition: a thought-provoking take on CS diplomas.
• A Quick Puzzle to Test Your Problem Solving... and a great way to learn about confirmation bias (which is not only applicable to hiring but also to testing).
• 🎞 Hiring women at Klarna

Employee handbook

• Clef's employee handbook has been open sourced on Github.
• Gitlab's handbook
• Valve's handbook
• Inaka's handbook
• Basecamp's handbook
• Mattermost's handbook
• Strapi's handbook

Employee retention

• Theory-building and why employee churn is lethal to software companies
  • "The death of a program happens when the programmer team possessing its theory is dissolved." Programming as Theory Building by Peter Naur, 1985.
  • Software is the insights of the development team made manifest.
  • Most code documentation becomes useful after you have built the theory in your mind
  • The most reliable method a programmer has for building an accurate ‘theory’ of a piece of software is to have been there when it was first written ("first generation programmer")
  • Too many second-generation developers and the first generation gets overwhelmed, and work stalls.
  • Too few second-generation developers and there is no renewal—each developer that leaves the team is a potential catastrophe.
  • Team stability is vital for software development

Escalations

• Learn how to escalate issues
• Mental frameworks for making decisions: how to handle escalations as a manager.
• Inspection and the limits of trust

Executives

• The One Key to Dealing with Senior Executives: Answer the Question!

FinOps (cost)

• Efficiency: Managing Infrastructure Costs

First-time manager

• How to Ensure a New Manager Succeeds
• Six Recipes for Software Managers
  • 1-1
  • Team surveys
  • A safe environment
  • An informed department
  • Resilient teams
  • Self improvement
• The Problem with Tech Leads
• Trained Engineers - Overnight Managers (or, The Art Of Not Destroying Your Company)
• A Manager’s FAQ
• This 90-Day Plan Turns Engineers into Remarkable Managers
• The New Manager Death Spiral, Rands in Repose.
• Learnings from six months as a first-time manager
• How to fail as a new engineering manager
• Choosing the Management Track
  • You won’t code anymore.
  • Management forces you to care more about everything.
  • Management creates an unavoidable power hierarchy.
  • You need to be technical enough to intervene.
  • Companies ultimately succeed or fail by their coordinated execution, culture and leadership.
• The best leaders are great individual contributors, not professional managers, an insightful thread on Hacker News
• 17 Reasons NOT To Be A Manager

Feedback

See the Performance section too.

• 📖 Radical Candor — The Surprising Secret to Being a Good Boss
  • Here's a good summary from the author (with videos): What Is Radical Candor? Meaning & Examples
• 📖 Amazon.com: Crucial Conversations Tools for Talking When Stakes Are High by Kerry Patterson.
  • So the first step to achieving the results we really want is to fix the problem of believing that others are the source of all that ails us. It’s our dogmatic conviction that “if we could just fix those losers, all would go better” that keeps us from taking action that could lead to dialogue and progress. Which is why it’s no surprise that those who are best at dialogue tend to turn this logic around. They believe the best way to work on “us” is to start with “me.”
  • Respect is like air. As long as it’s present, nobody thinks about it. But if you take it away, it’s all that people can think about.
  • “One dull pencil is worth six sharp minds.” Don’t leave your hard work to memory. If you’ve gone to the effort to complete a crucial conversation, don’t fritter away all the meaning you created by trusting your memories. Write down the details of conclusions, decisions, and assignments.
• A Primer on Giving Critical Feedback
• Feedback goes both ways: Tool: Try Google’s Manager Feedback Survey
• Negative feedback antipatterns
• The Open Feedback Circle (OFC), a great idea by Padmini Pyapali.
  • We met once a month, sat around a table, and shared feedback with each other in front of our other teammates. This gathering took feedback exchange from being a biannual activity we dreaded to a monthly ritual we looked forward to.
  • Vulnerability Cultivates Trust
• Simon Sinek: Purpose should be prioritized over metrics
  • Targets are great. But how targets are reached matters too. A team that would meet its target two months later should be rewarded more than a team that reach its target at the expense of morale and quality.
  • SEALs measure performance and trust. They would rather have a medium performance high trust person on the team than a high performance low trust person.
  • Simon's team runs team peer reviews. One person shares their top three weaknesses, the team can comment but they can only say thank you, then they do the same for their strength.
• The manager I hated and the lesson he taught me

Hands-on

• Should managers still code?
  • If you mean being the primary implementer of features, then probably not. If you mean being an integral part of how your team produces code, then yes, absolutely. I recommend it highly.
• Being in the details
• Why I Still Write Code as an Engineering Manager

Hiring

General

• 📖 Hiring The Best Knowledge Workers, Techies & Nerds: The Secrets & Science Of Hiring Technical People, Johanna Rothman. A solution-oriented book.
  • Train your interview team to apply a limited-consensus approach to hiring. When groups use limited consensus, not everyone may agree with the decision, but each person should be satisfied enough with a particular candidate’s suitability not to block the decision to hire him or her.
  • What if the vetoer is someone I don’t want to keep in the organization?” The answer to this is simple: In the interview process, only involve employees whose work you respect and value. If an employee isn’t successful in his or her technical position, don’t make that employee part of the interview team.
  • Make sure members of your team interview an internal candidate the same way they would interview an external candidate.
  • Know why you’re hiring more people. Define your problems to define your hiring strategy.
  • Sometimes, the main reason a hiring manager doesn’t hire a candidate is that he or she has a gut feeling that the person just won’t fit well with the culture. But a “gut feeling” is not a good reason not to hire someone, so train yourself to articulate culture-fit differences.
  • I personally do not consider certification to mean anything much when I am hiring someone for a technical position. Because the knowledge tested is functional-skills book knowledge, make sure you understand what the person must do to maintain his or her certification and the value of that certification to your environment.
  • Too often, internal recruiters look for tool and technology expertise or for advanced academic degrees, rather than for functional skill or for product-domain experience.
  • If you feel the need to take notes, take them on paper, never on a computer. My reason for this is that when you use a computer, you have to sit behind a screen, which creates a barrier between you and the candidate.
  • Promising an unconditional promotion is not just risky; it is stupid. Circumstances within the company can change; the employee may not perform up to expectations; the economy may tank.
• A good example of offer letter from eShares.
• We Hire the Best, Just Like Everyone Else, Jeff Atwood.
• ⭐️ How to Hire: one of the best articles about hiring.
  • Hire for Strength vs Lack of Weakness
  • Hire for Trajectory vs Experience
  • Hire Doers vs Tellers
  • Hire Learners vs Experts
  • Hire Different vs Similar
  • Always pass on ego
• ⭐️ The hiring post: another truly awesome post about hiring by Thomas Ptacek.
• This is why you never end up hiring good developers
  • Many interview techniques test skills that are at best irrelevant to real working life;
  • You want somebody who knows enough to do the job right now;
  • Or somebody smart and motivated enough that they can learn the job quickly;
  • You want somebody who keeps getting better at what they do;
  • Your interview should be a collaborative conversations, not a combative interrogation;
  • You also want somebody who you will enjoy working with;
  • It’s important to separate “enjoy working with” from “enjoy hanging out with;”
  • Don’t hire assholes, no matter how good they are;
  • If your team isn’t diverse, your team is worse than it needed to be;
  • Accept that hiring takes a really long time and is really, really hard.
• Engineering Management - Hiring explains why hiring should be your top priority.
• When we only hire the best means we only hire the trendiest
• How to Hire, Patty McCord (built HR function at Netflix).
• Trouble hiring senior engineers? It's probably you.
  • When hiring senior engineers, you’re not buying, you’re selling.
• I've been an engineer and a recruiter. Hiring is broken.
• 🎧 How to Get the Ideal Team Player
• 6 qualities that make a great engineer
  • Ambitious and determined
  • Habitually simplify
  • Can debug anything, quickly
  • Help others be great
  • Know what’s valuable
  • Are creative and positive
• How to hire low experience, high potential people
• Dumb and gets things done
  • Joel Spolsky says that the ideal programmer is someone who is smart and gets things done. But what about people who are dumb and get things done?
  • Leaders need to make things happen. Teachers need to teach. Programmers need to write code. These basic skills are necessary, but they are not enough.
• The Quarterback Paradox
  • "Tom Brady was drafted in the sixth round, did not stand out physically, and entered a stable organization that allowed him to learn and develop gradually."

Hiring: interviews

• Vanquish whiteboard interview puzzles with test-driven development, Jocelyn Goldfein.
• Joel Spolsky, The Phone Screen
• 🎞 The pursuit of happyness' interview scene
• Real talk: the technical interview is broken
• Finding a Tech Leadership Job in Silicon Alley (interviewing seen from the candidate experience point of view).
• How I Interview
• What if companies interviewed translators the way they interview coders? - a great counter example of how interview can be disconnected from one's actual job.
• 🎞 Monthy Python: a terrible candidate experience
• Your interviews shouldn’t be spoilable
  • How much should you share with the candidate? As much as an ethical person would share with a friend who they referred for the job.
  • If an interview can be spoiled, it means that the answers can be memorized.
  • Your spoilable interview is going to get spoiled. Some referred candidates are going to get the answers from their friends.
  • If foreknowledge doesn’t reduce the quality of your interviews, it means that you have to change your questions less often
• Becoming a good technical interviewer - Dashlane Blog
  • Interviewing should always be a pleasant experience for the candidate
  • The fine balance between guiding and giving the solution
  • I’m interviewing someone much more senior than I am. What if I don’t understand their solution?
• 6 red flags I saw while doing 60+ technical interviews in 30 days
  • Your interviewer is only open to solving the problem ONE way
  • Undue pressure to accept an offer letter
  • Not enough clarity about your role
  • Consistent lack of interest or low morale from interviewers
  • Your interviewers aren’t prepared for the interview
  • Lack of a clear direction on where the company is headed
• How to hire engineering talent without the BS
  • Antipatterns: memory, speed
  • Best practices: upfront, realistic, structured, guided, empathetic,

Specifics about hiring engineering managers:

• Cracking the Engineering Manager interview — Part 1
• Hunting for Rock Star Engineering Managers
• VP of Engineering interview
  • What is the reasonable interaction between PM and Engineering?
  • How do you increase your team’s throughput?
  • How do you scale an engineering team?
  • How does engineering support sales?
  • What’s interesting to you about this company? What do you think you can add to the team?
  • What can you do to accelerate product delivery?

Hiring: interview questions

• 45 sample behavioral questions for interview with developer
• Behavioral interviews
• 🧰 MaximAbramchuck/awesome-interview-questions: a list of list of interview questions.
• 40 Favorite Interview Questions from Some of the Sharpest Folks We Know, First Round Review
  • What do you want to do differently in your next role?
  • Imagine yourself in three years. What do you hope will be different about you then compared to now?
  • Among the people you've worked with, who do you admire and why?
  • What are you really good at, but never want to do anymore?
  • How did you prepare for this interview?
  • What do you believe you can achieve with us personally or professionally that you can't anywhere else in the world?
  • When was the last time you changed your mind about something important?
  • What’s one misconception your coworkers have about you?
  • What was the last thing you nerded out on?
  • What are 10 ways to speed up Domino’s pizza delivery?
• How to create a good problem-solving interview
  • What to look for: methodology, communication, programming skills
  • Don’t aim for complexity
  • Interview your coworkers
  • Standardize your interview
• 5 coding interview questions I hate
  • Trivia
  • Specifics
  • Obfuscated questions
  • Unspecified behavior
• Bug squash: An underrated interview question

Hiring: job postings

• Software Engineer Job Descriptions that Attract the Best Developers
• How to communicate why your startup is worth joining
  • Lots of great ideas.

Hiring: process

• Medium’s engineering interview process: Medium open sourced their hiring process.
• Gitlab, Hiring Principles. Their whole process is also open sourced.
• How Firebase Interviewed Software Engineers
  • We looked for candidates who were friendly, smart, and motivated
  • We looked for generalist, pragmatic problem solvers
• No engineer has ever sued a company because of constructive post-interview feedback. So why don't employers do it?
  • Be clear that it’s a no-go.
  • When you give suggestions, be specific and constructive.
  • Make recommendations. Is there a book they could read?

Hiring: résumé review

• When Is Short Tenure a Red Flag?
• What we look for in a resume

Hiring: sourcing

• How To Hire Engineers: Step 1, Sourcing
• The Case For Language-Agnostic Hiring
  • Good Programmers Can Adapt to Any Language
  • Hire Broad-minded Devs- Not Ones Boxed Into a Specific Language
  • Encourage Knowledge Sharing Among Devs

Hiring: take home exercises

• How GitHub does take home technical interviews
• guardian/coding-exercises
• Take-home vs whiteboard coding: The problem is bad interviews
• Live Coding Interviews describes ways in which a live coding interview won't give you accurate signals.

Hiring: quotes

If you can 'hire tough,' you can 'manage easy'.

Sue Tetzlaff, The Employee Experience: A Capstone Guide to Peak Performance

I am convinced that nothing we do is more important than hiring and developing people. At the end of the day you bet on people, not on strategies.

Lawrence Bossidy, GE

I hire people brighter than me and then I get out of their way.

Lee Iacocca, Ford

You can dream, create, design and build the most wonderful place in the world... but it requires people to make the dream a reality.

Walt Disney

Hire character. Train skill.

Peter Schutz, Porsche

In technology, it's about the people. Getting the best people, retaining them, nurturing a creative environment, and helping to find a way to innovate.

Marissa Mayer

I'd rather interview 50 people and not hire anyone than hire the wrong person.

Jeff Bezos

Talent wins games, but teamwork and intelligence win championships.

Michael Jordan, American former professional basketball player

Often the best solution to a management problem is the right person.

Edwin Booz

Somebody once said that in looking for people to hire, you look for three qualities: integrity, intelligence, and energy. And if you don't have the first, the other two will kill you. You think about it; it's true. If you hire somebody without [integrity], you really want them to be dumb and lazy.

Warren Buffet

One cannot hire a hand; the whole man always comes with it.

Peter Drucker

If you think it's expensive to hire a professional to do the job, wait until you hire an amateur.

Red Adair

Incident prevention and response (on-call, outages)

Also see my professional-programming list

• Handling Incidents and Outages
• When the Sky Falls, Rands in Repose
• 🎞 Incident Analysis: How Learning is Different Than Fixing ([slides](https://speakerdeck.com/jallspaw/incident-analysis-how-star-learning-star-is-different-than-star-fixing-star?slide=8
• Why LFI is a tough sell – Surfing Complexity
  • Interesting comment: "The funny thing to me is that RCA and LFI both suffer from a seemingly unsolvable problem when evaluating return on investment: you can count the customer facing outages you have, but you can’t count the ones you don’t have because you’re practicing either method. I’ve heard Allspaw refer to this as the “missing denominator” problem or something similar. It’s frustrating when orgs are looking for quantifiable reasons to invest in LFI, when they can’t quantify the benefits of RCA — and I think that’s exactly because of what you describe here."

Learning, retro, postmortem

See my professional-programming section about incident-response

• This is How Effective Leaders Move Beyond Blame
• A great description of what blamelessness actually means: How is team-member-1 doing? (team-member-1 is the name of the person that "gave the unfortunate command to delete our primary database" during the global Gitlab outage in Feb 2017.
• Debriefing Facilitation Guide: Etsy's guide to debriefing & incident review.
• General James 'Mad Dog' Mattis Email About Being 'Too Busy To Read' Is A Must-Read: "by reading, you learn through others’ experiences, generally a better way to do business, especially in our line of work where the consequences of incompetence are so final for young men."
• You can increase your intelligence: 5 ways to maximize your cognitive potential: forgive the clickbait link, it's actually a good article.
• Startup Graveyard – History Shouldn't Have to Repeat Itself
• Design critiques at Figma
  • Pick the right format: standard, brainstorms, small groups, silent, printed, etc.
  • Use smaller rooms
  • Buy a timer and keep diligent time
  • Remember to critique OUTSIDE of weekly meetings

Quotes:

• "Excellence is achieved by the mastery of fundamentals", Vince Lombardi, considered to be one of the best coaches in NFL history.

Management style

• Humane Development: "we are humans working with humans to develop software for the benefit of humans."
• Leadership is making a comeback : interesting article that proposes a model where the leader is neither a servant nor a hero, but a host.
• Management Philosophy
• 12 "Manager READMEs" from Silicon Valley’s Top Tech Companies
• 🎞 What is your philosophy on leadership? How do you inspire your team to do their best?: beautiful sequence between Nelson Mandela (played by Morgan Freeman) and François Pienaar (Matt Damon).
• Why Software Development Requires Servant Leaders
• Andreessen Horowitz, Peacetime CEO/Wartime CEO
  • Peacetime CEO knows that proper protocol leads to winning. Wartime CEO violates protocol in order to win.
• Excerpts from One From Many, Dee Hock, Zack Kanter on Twitter.
  • Your first responsibility as a manager is to manage yourself: your integrity, character, ethics, knowledge, wisdom, temperament, words and acts.
  • The second responsibility is to manage those who have authority over us.
  • The third responsibility is to manage your peers: without their respect and confidence, nothing can be accomplished.
  • The fourth responsibility is to manage those whom we have authority.
  • You can't manage your bosses, peers, regulators etc. But you can understand them, motivate them, influence them, forgive them.
  • "It is from failure that amazing growth and grace so often come, provided only that one can recognise it, admit it, learn from it, rise above it, and try again. True leadership presumes a standard quite beyond human perfectibility and that is quite alright, for joy and satisfaction are in the pursuit of an objective, not in its realization."
• Managing Staff-plus engineers
• An Engineering Team where Everyone is a Leader, Gergely Orosz.
  • One project, one engineering lead
  • Mentoring, then coaching the first few leaders
  • Transparency and accountability via weekly, written updates
• All You Need to Become a Servant Leader
  • Examples of servant leaders and book recommendations
  • You need: empathy, self-awareness, active listening, trust, transparency
• Developing leadership styles, Will Larson, Includes mechanics and examples.
  • Leading with policy
  • Leading from consensus
  • Leading with conviction
• From good to great: A capability framework for building exceptional product engineering teams
• Accountability Sinks

Quote:

If you want to build a ship, don't drum up people to collect wood and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea.

– Antoine de Saint-Exupery

Management is doing things right; leadership is doing the right things.

– Peter Drucker

The people who work for you have three resources: time, energy, and give-a-fuck. Time is the cheapest. It replenishes one hour every hour. Energy is more expensive. When you're out you need lots of time off to recharge. Once give-a-fuck is burned, it's gone forever.

– @leftoblique

Meetings

• On Better Meetings: Lara Hogan shares tips about ensuring efficient meetings.
• 🎞 Almost Live! - Middle Management Suck-Ups: a great example of a terrible ineffective meeting.
• Run Better Meetings with This Expert-Level Advice, First Round Review
• Engineering Team Meeting: Format & Topic Ideas: lots of great ideas to start it.
• The Document Culture of Amazon
  • Documents help eliminate many biases, for or against, the person who wrote the document.
  • There’s no “can you see my screen”, background noise, or call audio disconnects while understanding the main content for the meeting.
• Cancel your meetings if you can live with the outcome
• "My new favorite team ritual: A weekly meeting called "Fight Club" where you meet with your leadership team with the intention of having a conflict.
• Meetings are the work.
• Embrace Silence
• Simple Sabotage "A Modern Field Manual for Detecting and Rooting Out Everyday Behaviors That Undermine Your Workplace". Covers anti-patterns of collaborative behavior, and provides specific recommendations for fixing these when they occur in meetings.

Mentoring

• The Conjoined Triangles of Senior-Level Development looks into how to define a senior engineer.
• 30 questions to ask your mentor
• Advice is Cheap — Context is Priceless
• Developers mentoring other developers: practices I've seen work well, Gergey Orosz
  • Provide context and perspective
  • Leverage your network to help the mentee
  • Be supportive
  • Avoid giving answers on a silver plate
  • Tailor your approach for technical vs non-technical topics
  • People learn best when they help themselves
• Your Strengths Are Your Weaknesses
  • The qualities we celebrate in our team members are usually the same ones causing our biggest headaches.
  • We want self-aware engineers who understand their natural tendencies and can adjust them based on what each situation demands.
• Managing strong personalities
  • "If you are not able to coach the big players, you are not able to coach anyone. It is very important for a coach to understand that you are not going to teach them how to play football. You're not going to teach Ronaldo how to take a free kick. You’re not going to teach Ibra how to hold the ball on his chest. You’re not going to teach Drogba how to attack the first post and score in the air. You are going to teach them how to play football in that team." – Jose Mourinho
• Jeeps, Ferraris, and Other Engineers

Mindset and attitude

• Taking Ownership Is The Most Effective Way to Get What You Want
• Shreyas Doshi on Twitter: "Good managers, what they do, how they think & act
  • Good managers are skilled at asking questions that give their team members a new perspective on the problem and reach the right solution on their own.
  • Good managers address context first, then content.
  • Good managers know that, above all else, they are agents of their company. Their default mode is to make and facilitate company-optimal choices.
  • Good managers know that fixing broader company culture is an important part of their role as a designated leader within the company.
  • Good managers understand that the long game is all about people.
  • Good managers don’t have just one go-to management style nor do they have a notion of “THE ideal employee”.
  • Good managers can discern good intent from bad.
• Nvidia CEO Jensen Huang: "you can’t show me a task that is beneath me." Do what is required not what is desired

It's only when the tide goes out that you learn who's been swimming naked. – Warren Buffet

@farbood: Doing the right thing, is direction. Doing things right, is speed.

@jasonfried: You don’t get to call yourself a leader. That’s up to other people.

"Only three things happen naturally in organizations: friction, confusion, and underperformance. Everything else requires leadership." – Peter Drucker

Motivation

• 🎞 Drive: The surprising truth about what motivates us (summary of Daniel Pink's book).
• The two-factor theory (Wikipedia) "states that there are certain factors in the workplace that cause job satisfaction, while a separate set of factors cause dissatisfaction."
• Bored People Quit, Rands in Repose
• The Development Abstraction Layer, Joel on Software

Quotes:

• "The best time to plant a tree was twenty years ago. The second best time is now", Chinese proverb.
• "A ship in harbor is safe, but that is not what ships are made for.", John A Shedd.

Onboarding new team members or yourself

• How to quickly (and successfully) onboard engineers, GitLab
• 🎞 5 Onboarding Fiascos From the Movies
• Onboarding - Mattermost Handbook
• Gitlab's engineering onboarding list
• How To Use Your Unfair Advantage To Create an Unforgettable First Day For New Hires, Oren Ellenbogen
• Engineering Onboarding Processes at Medium, Medium
• A Career Cold Start Algorithm, Andrew Bosworth. How to run your first 1-1s on a new team.
  • For the first 25 minutes: ask them to tell you everything they think you should know.
  • For the next 3 minutes: ask about the biggest challenges the team has right now.
  • In the final 2 minutes: ask who else you should talk to. Write down every name they give you.
• Onboarding, MartinFowler.com
• Ask HN: How to onboard yourself to a new product/industry in a new job?

Organizational structure

See also Data organization

• Martin Fowler's Team organization articles
• Conway's Law, Martin Fowler
  • "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.", Melvin Conway
• Conway’s Law in Team Topologies
  • The Reverse or Inverse Conway Maneuver implies that we should design our teams (not the software yet) to “match” the required software architecture.
• Spotify’s Failed #SquadGoals
  • Engineering managers in this model had little responsibility beyond the career development of the people they managed.
  • There was no single person accountable for the engineering team’s delivery or who could negotiate prioritization of work at an equivalent level of responsibility.
  • Autonomy requires alignment. Company priorities must be defined by leadership. Autonomy does not mean teams get to do whatever they want.
  • Business units, departments, teams, and managers more effectively communicate organization structure roles and responsibilities than Spotify’s synonyms and are not attached to a way of working that failed their creator.
• Independence,autonomy,too many small teams
  • Every autonomous team is expected to generate direct business value all by itself, without a lot of overlap with other teams.
  • The team should be able to meets its goals independently (i.e. without reliance on or interference from other teams).
  • Coordination, also known as alignment, communication, shared roadmap, Gantt chart and many other positive sounding names, is the arch-enemy of the autonomous team.
• 🎞 Monoliths vs Microservices is Missing the Point—Start with Team Cognitive Load by the authors of team topologies.
• Organizing software teams (Team Topologies Book Summary)
  • There should be no shared ownership of components, libraries, or code.
  • If you have microservices but are still waiting to do end-to-end testing of a combination of services, you have a distributed monolith (a distributed monolith is when all changes in a service require updates to other services).
  • Use software boundaries defined by business-domain bounded contexts
  • Teams composed of only people with single functional expertise should be avoided at all costs.
  • Four fundamental team topologies: stream-aligned, enabling, complicated subsystem, platform.
• Structure Eats Strategy
  • BAPO: the B (business) should define the A (architecture) which is the starting point for the P (process), on which the O (organization) is based.
  • Most companies are not BAPO but instead they are OPAB: the existing organization is used as a basis for the definition of convenience-driven processes, which in turn leads to an accidental architecture.
• Infrastructure Platform Engineering Organizational structures and models: an incredible article about how to structure the infra team.
  • Describes the 4 canonical org models and their pros & cons:
    • Product org with embed infra teams
    • Shared cloud engineering team
    • Infra org
    • Infra-platform org
  • Concludes that in the end expertise should be encoded in software solutions & automation
• Architects, Anti-Patterns, and Organizational F*ery
• Team Topologies, great book summary by Martin Fowler.
  • The primary benefit of a platform is to reduce the cognitive load on stream-aligned teams
• Beyond the Holacracy Hype
• Organizational boundary problems: too many cooks or not enough kitchens?. A lot of useful resources to design organizations.
• How and why we built our startup around small teams
• Bad idea: Platforms automatically improve productivity
  • Platforms as products improve productivity; “because I said so” platforms do not.
• Small teams, Posthog Employee Handbook
• Infrastructure Gravity & Domain Engineering argues for the value of having a "Domain Engineering" team.
• Unpopular Defaults for High-Performing Tech Organizations
  • Unpopular Defaults for High-Performing Tech Organizations
  • No Nano Teams
  • No Hackathons
  • No Hard-Set “Engineering Time”
  • Don’t Coddle Engineers’ Time Too Much
  • Aim for Healthy Turnover
  • Break Over-Specialization
• The magic of software; or, what makes a good engineer also makes a good engineering organization: thought-provoking.
  • "It’s not always as simple as starting with a vision and then using the resources available to build it. They often emerge together or in an intertwined way, and things continually leap forward over and over."
  • "In complex ecosystems like computing, there just seems to be some kind of ongoing relationship between deep understanding of how the tools we use to create things function and the quality or creativity of the output we get as a result."
  • "Many of today’s “best practices” have been drawn from long-established internet companies like Google. However, the problem with copying their current practices on the basis of their success is that most of those companies found near-invincible business models that basically printed money, and so almost any organizational or management practice developed or selected at random likely would continue to be “successful” to some degree."
• Startup Engineering Team Organisation

Performance management

• Firing people: Zach Holman's talk about his experience being fired from Github offers some great insights into a process that is rarely talked about.
• It’s Never Too Early to Fire, Andreessen Horowitz.
• Performance Reviews Are a Waste of Time: a good contrarian take on formal performance reviews
• The How and Why of Performance Review Calibration
• 9 Box Grid: A Practitioner’s Guide
• How to Effectively Manage Low Performers: The CARES Framework: Communicate, Accountability, Roadmap, Execution, Support.
• Unlocking performance management for start-ups and scale-ups
  • Team performance = f(results, behaviors)
• Hey, wait – is employee performance really Gaussian distributed??
  • Article argues that it's Pareto-distributed instead.
• The Worst Programmer I Know: don’t try to measure the individual contribution of a unit in a complex adaptive system, because the premise of the question is flawed
• Managing Underperformers

Personal productivity

See also: Developer productivity section

About productivity in general:

• 43 Folders Series: Inbox Zero: how to get and maintain your email inbox at a sane level.
• CannotMeasureProductivity, Martin Fowler (about how you cannot measure developer productivity.
• 🎧 How to Change Your Behavior, Coaching for Leaders
  • It’s a myth that it takes 21 or 66 days to create a habit. Repetition doesn't create habits. Emotions create habits.
  • Create a tiny habit through an ABC process: anchor moment, a tiny behavior, and instant celebration.
  • Avoid raising the bar on the tiny behavior. Do more if you want to, but don’t change the standard.
• 'Touch it once' method for tasks can boost productivity
  • As soon as you touch something, you immediately act on it.
• The Ultimate Guide to Personal Productivity Methods, Todoist
• Evidence-based advice on how to be successful in any jobs: most self-help advices are not research-based. The ones listed in this article are.
• The Complete Guide to Deep Work
  • The ability to perform deep work is becoming increasingly rare at exactly the same time it is becoming increasingly valuable in our economy.
  • Choose Your Deep Work Strategy
  • Build a Deep Work Routine
  • Discipline #1: Focus on the Wildly Important
  • Discipline #2: Act on the Lead Measures
  • Discipline #4: Create a Cadence of Accountability
  • Our Ability for Deep Work is Finite
  • The Craftsman Approach to Tool Selection
  • Stop Using Social Media
  • Get Your Boss on Board With Deep Work
• Every productivity thought I've ever had, as concisely as possible
  • Context intentionality as the key difference between home and every other place on planet earth
  • Rules are about exceptions
• 100 Tips for a Better Life
  • Deficiencies do not make you special. The older you get, the more your inability to cook will be a red flag for people.
  • History remembers those who got to market first. Getting your creation out into the world is more important than getting it perfect.
  • Discipline is superior to motivation. The former can be trained, the latter is fleeting. You won’t be able to accomplish great things if you’re only relying on motivation.
  • You do not live in a video game. There are no pop-up warnings if you’re about to do something foolish, or if you’ve been going in the wrong direction for too long. You have to create your own warnings.
  • Cultivate a reputation for being dependable. Good reputations are valuable because they’re rare (easily destroyed and hard to rebuild). You don’t have to brew the most amazing coffee if your customers know the coffee will always be hot.
  • Compliment people more. Many people have trouble thinking of themselves as smart, or pretty, or kind, unless told by someone else. You can help them out.
• The Top 9 Productivity Myths That Just Aren't True, Todoist
• Build tools around workflows, not workflows around tools
• Rethinking Best Practices
• The Cult of Done Manifesto
• Asking questions the right way
• How to Be Great? Just Be Good, Repeatably

@shreyas: Don’t be fooled by Best Practices. By the time something is labeled and advertised as a Best Practice, it is just average. Following these practices only suggests you won’t be left behind, not that you will lead the pack. Best Practices are actually Average Practices.

Automation:

• Focus by Automation

About GTD:

• 📖 David Allen, Getting Things Done: The Art of Stress-Free Productivity: while it could be much shorter, this book is probably the best way to learn about the GTD methodology.
• Productivity 101: A Primer to the Getting Things Done (GTD) Philosophy: a great summary of GTD.
• Zen Habits: a blog you can follow to get productivity tips and tricks.
• Zen To Done (ZTD): a simpler productivity system.
• 🏙 2011 GTD Getting Things Done

About calendars:

• Maker's Schedule, Manager's Schedule, Paul Graham
• Why Are Maker Schedules So Rare?
• Busy to Death: a good story involving W. Edwards Deming.
• Makers, Don't Let Yourself Be Forced Into the 'Manager Schedule'
  • Research shows that it takes as long as 30 minutes for makers to get into the flow
  • Use maker-manager office hours
  • Communication can happen at a quieter asynchronous frequency in the form of thoughtful, written discussions rather than soul-sucking meetings or erratic one-line-at-a-time chat messages
  • Build a team knowledge base to minimize repetitive questions and allow self-onboarding.
• Your non-linear problem of 90% utilization, Jason Cohen: why constantly running at 90% utilization is actually counter-productive.
• Your Calendar = Your Priorities
• Advice for time management as a manager

About distractions:

• How to stop being "terminally online"
  • Determine why you're terminally online
  • Examine your biases
  • Rationalize your FOMO
  • Accept yourself as you are
  • Stop being so ironic
  • Take it slow
  • Find other ways to contact people
  • Expand your definition of the Internet
  • Find other news site
  • Use an RSS feed
  • Find ways to help
  • Find a hobby
  • Limit to career usage
  • Have faith

"Do what you love until you love to Do" I often think about the “Read what you love until you love to read” comment from @naval, and this is a good generalization. My experience has been that it is easier to educate a Do-er than to motivate the educated; you have to believe you can Do before you embark on an effort. – John Carmack

In terms of task management software, I can't recommend Things enough (macOS and iOS only). It is a delightful piece of software that gets out of the way and lets you focus on your tasks.

Planning (roadmap, goal setting, KPI, OKR, etc.)

• Top 10 Reasons for Slow Velocity
• The Heilmeier Catechism: a crafted a set of questions to help DARPA officials think through and evaluate proposed research programs.
• The Fundamentals of Roadmapping
  • With constant innovation, new market entrants and potential black swans like a global pandemic, the best a leader can do is set a 12–18 month strategic plan that is directionally aligned with the company’s true north. That plan should be broken down by quarter with the assumption that the degree of confidence in achieving goals within each quarter will decline over time.
  • Expect each team across the organization to cascade their operational roadmaps from these strategic foci. Operational roadmaps should identify key initiatives and milestones.
• How to measure and improve success in your engineering team
• “Stories” Don’t Tell a Story: Good Sprint Planning Uses Milestones
  • Manage Through Milestones
• Rituals for hypergrowth: An inside look at how YouTube scaled
  • Planning cadence: 6-month strategic planning and 6-week sprints
  • Strategic planning had two key outputs: (a) a list of Big Rocks and (b) the matrix of project allocations
  • Our process was designed to avoid the “just in time” ad-hoc meetings
  • Many of our meetings included a long “bullpen” period (i.e. unstructured multithreaded discussion time)
  • Replace read-outs / meetings with broadcast emails
  • Pre-reads (”Come prepared and expect others to be prepared”)
• Dear PMs, It's Time to Rethink Agile at Enterprise Startups
• When Everything is Important But Nothing is Getting Done
  • Step 0: Create Consensus That There is a Problem
  • Step 1: Create a Unified View of All Existing Work
  • Step 2: Create and Implement Criteria for Comparing Projects
  • Step 3: Sequence The Projects & Commit to that Sequence
  • Step 4: Getting Work Started
  • Step 5: Identify and Fix Your Organizational Constraints
  • Step 6: Create A Clear Finish Line (Definition of Done)
  • Step 7: Keep It Going
• The practical application of "Rocks, Pebbles, Sand", A Smart Bear
  • If you schedule little things first, you run out of time for the big things.
  • Rocks maximize Impact
  • Rocks: Beware: “Maximizing impact” is harder than you think
  • Execs decide, but ideally PMs are in command
  • Sand maximizes Throughput
  • Beware: Administrative overhead destroys throughput
  • Sand: Prioritize with intuition and desire, not math and metrics
  • Self-managed teams schedule their own Sand
  • Pebbles maximize ROI
  • Beware the surprisingly high impact of estimation error on ROI
• Key Performance Indicators Infographic
• Measure what matters. Even if you don’t fully control it
• Leading and Lagging Indicators: How to measure Product OKRs. Very clear treatment of the topic, with lots of references and links.
  • OKR ideally measure outcome, not output.
  • Lagging indicators are easy to spot, unresponsive and hard to change, definitive results of the past
  • Leading indicators are difficult to uncover, responsive to team actions, predictors of future success
  • Whether it's lagging or leading depends on the team/context
  • Prioritize leading indicators to avoid lagging decision-making
• How to plan?
  • Do fewer things.
  • Bottom up processes don't work.
  • Planning is the wrong time to introduce anything new.
  • You must provide frameworks and constraints.
  • Project planning has an inflection point.
  • Don't wait to kill bad ideas.
  • Minimize dependencies.
  • Headcount planning won't map to your plans.
  • What if money is no object?
• How-to Evaluate a Product Roadmap, for Engineers
  • Does the roadmap clearly connect to the higher-level company or product mission, vision, and strategy?
  • Is the roadmap intuitive, and can it be easily explained without jargon?
  • Is the roadmap outcome-oriented or aligned with customer value?
  • Is the roadmap flexible or iterative?
  • Are the roadmap initiatives scoped and prioritized based on evidence?
  • Does the roadmap identify major dependencies or risks?
  • Does the roadmap feel aggressive but achievable?
  • Is the roadmap easily referenceable later?
• Stop inventing product problems; start solving customer problems
  • The build trap is when organizations focus more on shipping and developing features rather than on the actual value those things produce. — Melissa Perri, Escaping the Build Trap
  • When low-maturity product teams start engaging with outcome goals, vanity metrics such as "number of queries" or "email send rate" predominate.
  • When you ask “what features do users want the dashboard to have” you’ll never hear “users don’t need a dashboard” unless you’re really good at reading between the lines.
  • Project teams tend to fix the problem of "missing features" rather than "customer unable to reach their goal"
  • Shipping the MVP can quickly evolve into incrementally working out interesting coding problems, at the cost of making measurable improvements to the user experience.
  • “Working backward from customer needs is a huge amount of work. But it will save you even more work later.” — Jeff Bezos
  • In reality, no products are desirable to customers. Customers have desirable outcomes, which products can help them reach.
• Why most product planning is bad and what to do about it provides a thought-provoking take on OKR and a different approach focused on problems.
  • Good critique of the OKR model: (1) objective are not super useful to prioritize work on an unlimited objective like "grow the business" or "improve conversion rate (2) they're inflexible.
  • Also: OKRs rely on the whole organization to be great at goal setting, which requires a lot of teaching.
  • My note: OKR do lead to over-discussing KR, under-discussing KPIs
  • Their approach: only pitch and prioritize problems worth solving with a simple P0 (existential risk), P1 (must do), P2 (nice to have)
  • Over 4 days every quarter with public commitment.
• Welcome to the Room
  • “Does our resource allocation actually support our theory of success?”
  • “What signals will tell us whether our theory is plausible or not and how long will it be before we get those signals?”

Truth emerges more readily from error than from confusion. Francis Bacon

Goals

• With Goals, FAST Beats SMART: goals should be embedded in frequent discussions; ambitious in scope; measured by specific metrics and milestones; and transparent for everyone in the organization to see.

A goal without a plan is just a wish. Antoine de Saint-Exupéry

OKRs

• How to Use OKRs for Quarterly and Annual Planning
• 🎞 Startup Lab workshop: How Google sets goals: OKRs
• How to Make OKRs Actually Work at Your Startup, First Round Review
• 🎞 Why the secret to success is setting the right goals, John Doerr
• A Modern Guide to Lean OKRs (a three-part series)
• OKR: The Ultimate Objectives and Key Results Resource
• OKR Examples (And Tips for Creating Your Own)
• Manager OKRs, Maker OKRs: How Early Stage Startups Should Think About Goal-Setting
• Objectives and Key Results, GitLab Handbook
• 10 Tips For Using OKRs Effectively
  • Objectives must be Big and Motivating
  • KRs must be measurable
  • Use binary KRs sparingly
  • All Key Results must have dashboards
  • Key Results must be exhaustive
  • Pair Metrics with Counter-Metrics
  • Distinguish between Committed and Aspirational OKRs
  • Cascade OKRs up, down, and laterally
  • Personal OKRs are powerful
  • Prefer a small number of tightly focused OKRs to a long list
  • Effective OKR usage takes years

Presentations, design and public speaking

• 🎞 Garr Reynolds, Presentation Zen Talk (Talks at Google)
• 📖 Garr Reynolds, Presentation Zen book
• Garr Reynolds, Top Ten Slide Tips
• 🎤 You suck at PowerPoint
• 📖 Edward Tufte, The Visual Display of Quantitative Information, a classic book on how to present data.
• 📖 The Non-Designer's Design Book - despite its clickbait title, it's actually a great book with a very memorable acronym to learn about how easy it is to design great documents.
• 📖 William Lidwell, Kritina Holden, Jill Butler, Universal Principles of Design.
• A Five Minutes Guide to Better Typography
• Presentation Zen: Living large: "Takahashi Method" uses king-sized text as a visual
• How to tell great spoken stories
  • Limited memorization
  • Hook
  • Mystery
  • Climax
  • Hero’s perspective
  • Relive the story; blow your own mind
  • Charisma is confidence, joy, and love for your audience
  • Vary your speed, volume, energy, and rhythm
  • Lean into silence
  • Picture yourself as being happy and excited to tell this story
• Death by PowerPoint: the slide that killed seven people (see Edward Tufte's article on this topic)
  • See also Edward Tufte's The Cognitive Style of PowerPoint, which includes an incredible analysis of this slide.
• How to present to executives, Irrational Exuberance
  • Never fight feedback
  • Don’t evade responsibility or problems
  • Don’t present a question without an answer
  • Avoid academic-style presentations
  • Don’t fixate on your preferred outcome
• 1 Trick to Finish Your Next Talk in Style
  • “Okay I am going to take a few questions before I make my conclusion.”
• How to tell a great story, Julian Shapiro
  • Blow your own mind
• How to Create, Structure, Design, Prepare and Hold a Great Presentation, iA, provides a great summary for how to approach and deliver a presentation. It follows Quitilian's Five Canons of Rhetoric:
  • 1. Inventio: developing and refining an argument.
  • 2. Dispositio: organizing an argument for greatest effect.
  • 3. Elocutio (style): presenting the argument.
  • 4. Memoria: learning and memorizing the speech.
  • 5. Actio (delivery): gestures, pronunciation, tone, and pace.

Some great examples of presentations:

• 🎤 How Google Works

Prioritization

See also the Prioritization section on my entrepreneurship-resources list

• How To Do Less
  • Ordering a todo list vs. only doing the top item in the list
  • Two meta-priorities: (1) keep the lights on, and make keeping them on cheaper, (2) cut the entire roadmap down to one thing at a time
  • How to handle disappointment
  • Say no, early and often
  • How to say no
  • How to correct distractions
  • Maintaining flexibility: default to iterate, but be willing to invest
• Prioritization is a Political Problem as Much as an Analytical Problem
  • Does not work: Asking exec teams to collectively prioritize long lists of things
  • Does not work: Lectures about algorithms, development processes, and staffing shortages
  • Does not work: Expecting spreadsheets to prioritize for us
  • Helpful: Set an explicit top-down allocation of effort across a few broad categories
  • Helpful: Push every exec-level stakeholder to provide a very short, fully ordered list of their group's needs
  • Helpful: Briefly recap top 3-4 products or projects every week
  • Helpful: Use Now/Next/Never to frame upcoming choices
  • Helpful: Define in advance what kinds of work can be realistically outsourced, and actively recruit external partners
• TBM 245: The Magic Prioritization Trick

Problem solving

See my professional-programming section about problem solving

Processes for engineering

• The Joel Test: 12 Steps to Better Code
• Simple Rules Set You Free, from the Friction podcast with Bob Sutton
• Constructive Chaos vs. Clusterf***s, from the Friction podcast with Bob Sutton
• Bureaucrat mode, Andrew Chen

@samkottler: No amount of process will ensure the right work is getting done.

Product management

See also my entrepreneurship-resource repo.

• The most important thing Dropbox did to scale Product Management: a very simple model for stating the stage a product is in.
• How Amazon Web Services (AWS) Achieved an $11.5B Run Rate by Working Backwards: explain Amazon's product management process.
• Bottleneck #03: Product v Engineering, Martin Fowler
  • Signs you are approaching a scaling bottleneck
  • Identify and reinforce your “First Team”
  • Define and communicate how your scaleup delivers value
  • Create multidisciplinary stream-aligned teams
  • Negotiate a balanced product investment mix

Production and productivity

• The Toyota Way, Wikipedia
  • Base your management decisions on a long-term philosophy, even at the expense of short-term financial goals.
  • Create a continuous process flow to bring problems to the surface.
  • Use "pull" systems to avoid overproduction.
  • Level out the workload
  • Build a culture of stopping to fix problems, to get quality right the first time
  • Standardized tasks and processes are the foundation for continuous improvement and employee empowerment.
  • Use visual control so no problems are hidden.
  • Use only reliable, thoroughly tested technology that serves your people and processes.
  • Grow leaders who thoroughly understand the work, live the philosophy, and teach it to others.
  • Develop exceptional people and teams who follow your company's philosophy.
  • Respect your extended network of partners and suppliers by challenging them and helping them improve.
  • Go and see for yourself to thoroughly understand the situation
  • Make decisions slowly by consensus, thoroughly considering all options; implement decisions rapidly
  • Become a learning organization through relentless reflection (hansei) and continuous improvement (kaizen)
• The LinkedIn DPH Framework
  • Goals, Signals, and Metrics
  • Developer Personas
  • Common Pitfalls When Designing Metrics
  • Their example: Developer Build Time (DBT), Post-Merge CI Duration, CI Determinism, Code Reviewer Response Time.
• The Napoleon Technique: Postponing Things to Increase Productivity

Project management

• 📖 The Mythical Man-Month by Frederick Brooks is a classical book about software project management.
  • Now I do not think software managers have less inherent courage and firmness than chefs, nor than other engineering managers. But false scheduling to match the patron's desired date is much more common in our discipline than elsewhere in engineering.
  • The boss must first distinguish between action information and status information. He must discipline himself not to act on problems his managers can solve.
• Jason Yip, It's Not Just Standing Up: Patterns for Daily Standup Meetings: standup are a pretty controversial topics. This article on Martin Fowler's blog provides a good list of patterns and anti-patterns to ensure they're a good productive use of everybody's time.
• 15 Fundamental Laws of Software Development
• How we structure our work and teams at Basecamp
• Will your project be a success? Find out in five minutes.
• Project Smart, Project management tools
• How should deadlines be used in software engineering?
• My 20-Year Experience of Software Development Methodologies: includes a great poster about different project management methodologies.
• JIRA is an antipattern, Jon Evans.
• Agile Lite: Agile without all the burnout
• Who are you trying to impress with your deadlines?
  • Deadlines set wrong expectations for what's good
  • People are going to cut corners if you put them to tough deadlines.
  • No one is going to experiment with new ways of doing things if you fetishize finishing under deadlines. We'd still be doing MVC in frontend apps if someone at Facebook didn't miss a deadline.
  • Have deadlines, but fuzzy. How fuzzy should be decided by your goals. If missing a deadline could potentially lose you a million dollars, the fuzziness factor for that should be zero.
• WaterfallProcess, Martin Fowler
• Efficient Software Project Management at its Roots
  • The key for a successful kickoff meeting is the interactivity.
  • With good milestones in place, it makes no difference whether the team uses story points, engineer-days or any other way to measure progress.
  • Having a regular, no-BS update on where the team really is
  • Dependency and Risk Management in a pragmatic way
  • Celebrate after completion!
• How to Lead a Project - as a Software Engineer, Gergely Orosz
  • Setup a framework for collaboration
  • Communicate status to stakeholders
  • Help the team focus - and don't be afraid to delegate
  • The article includes a short checklist for first-time project managers: kickoff meeting, milestones, design process, weekly update emails, daily standups, weekly goals, demoing progress.
• Directly Responsible Individuals
• Software Estimation Is Hard. Do It Anyway
• Great engineering teams focus on milestones instead of projects
  • Milestones should be small, high-quality, understandable, valuable
  • We can estimate 1-3 weeks of work
  • Breaking down projects helps with delivery incremental business value.
• 6 Principles for Building a World Class TPM Team, Sophia Vicent
• Driving engineers to an arbitrary date is a value destroying mistake
• How Big Tech Runs Tech Projects and the Curious Absence of Scrum, Gergely Orosz
• How finishing what you start makes teams more productive and predictable
• How to plan?
  • Do fewer things.
  • Bottom up processes don’t work.
  • Planning is the wrong time to introduce anything new.
  • You must provide frameworks and constraints
  • Project planning has an inflection point.
  • Don’t wait to kill bad ideas.
  • Minimize dependencies
  • Headcount planning won’t map to your plans
• Basecamp's Shape Up: Stop Running in Circles and Ship Work that Matters
  • Backlogs are a big weight we don’t need to carry. (on this topic: when you work in six week cycles, later means another time)
  • Important ideas come back
  • Choosing the right cycle length (six weeks)
  • Assign projects, not tasks
  • Making bets with a capped downside (the circuit breaker) and honoring them with uninterrupted time
  • Downhill versus uphill work and communicating about unknowns
• Project Management for Software Engineers: a 5-step process to running a project.
• Rescuing a project in progress, Jason Fried
  • Stop, status, selection, focus, finish, next.
• How I've run major projects

The ultimate inspiration is the deadline. — Nolan Bushnell

You must create hilariously aggressive deadlines for yourself, otherwise, you’ll get swept away in unnecessary details that aren’t actually mission-critical. If you’re thinking about color schemes and button widths, your timeline is too long. – Tara Viswanathan

Estimating work (project management)

• Yes, You Should Estimate Software Projects, Gergely Orosz
• Cut Out Time Estimates on Roadmaps: Get Into a Product Delivery Rhythm
• Hacks for engineering estimates
  • Estimate: prediction of how long a project will take
  • Target: statement of a desirable business objective
  • Commitment: promise to deliver defined functionality by a certain date
  • Plan: steps to achieve a particular result
  • Identify the extremes (latest/soonest)
  • Note the precision (weeks? days? hours?)
  • Ask for confidence level over time
• Ask HN: How do you deal with managers/customers questioning your estimates?
  • Call it a forecast, not an estimate.
  • Supply confidence intervals
  • Show compassion
  • Offer solutions
  • Try this tool: https://estigator.mozz.app/app/
• SomeEstimates

Quality

See also my professional-programming repo

• The code quality pyramid
• Time for a Code-Yellow?: A Blunt Instrument That Works
• We stopped roadmap work for a week and fixed 189 bugs (about fixit weeks)
• Andon (manufacturing): "The alert can be activated manually by a worker using a pullcord or button or may be activated automatically by the production equipment itself. The system may include a means to pause production so the issue can be corrected."

Release management

• The Tick-Tock of Apple

Remote teams

• How to Work Faster in a Remote Team
• Notion, Remote work wiki
• Gitlab, Remote work emergency plan: What to do (and where to start)
• A guide to distributed teams, Increment: Teams.
• The ultimate guide to remote work, Zapier. Includes topics such as:
  • How to brainstorm remotely
  • Remote team activities: how to have fun when you work from home
  • The best online whiteboards

RFCs (request for comments)

• Scaling Engineering Teams via Writing Things Down and Sharing - aka RFCs, Gergely Orosz
  • Do planning before building something new.
  • If everyone agrees how the project should be done then writing the approach down should be a piece of cake.
  • The type of information pushed to people in an organization shapes the culture considerably.
• Lightweight RFC Process, Apache Software Foundation
• 6 Lessons I learned while implementing technical RFCs as a decision making tool
• A thorough team guide to RFCs.
• Design Docs at Google

Scaling an organization

• Scaling Without Imploding
• Stripe Atlas: Guide to scaling engineering organizations

Second level manager (2LM)

• Managing Your Time as a Middle Manager

Security

• The SaaS CTO Security Checklist Redux
• Does Your Organization Have a Security.txt File?, Krebs on Security
• SOC2: The Screenshots Will Continue Until Security Improves

Soft skills, Emotional Quotient (EQ)

• Those 20 Key Habits that Hold You Back
• How to Deal with Difficult People on Software Projects
• Leadership Soft Skills: Master Your Own Mind to Lead Your Team to Success
  • The importance of soft skills in engineering leadership
  • Process to improving leadership soft skills
  • Practices to fine-tune leadership soft skills
  • Helping direct reports improve leadership soft skills
  • Emphasizing leadership soft skills in your culture

Storytelling

See Presentation

Strategy

See also: Strategy section on charlax/entrepreneurship-resources

Shameless plug here, two presentations I contributed to:

• 🎤 Amazon: the hidden empire
• 🎤 Apple: 8 easy steps to beat Microsoft
• Michael Porter's generic strategies (Wikipedia)
• Steve Jobs explaining why you should start from the customers, and go backward (video 🎞). He makes the point that stopping the OpenDoc project was the right thing to do because it was a technology without any customer.
• Can Do Vs Must Do , AVC. "Doing a startup is like playing a video game. Each level requires you to master one thing and once you do that, you level up and then there is a new thing to master."
• "Waterline principle" from Bill Gore: "Think of being on a ship, and imagine that any decision gone bad will blow a hole in the side of the ship. If you blow a hole above the waterline (where the ship won’t take on water and possibly sink), you can patch the hole, learn from the experience, and sail on. But if you blow a hole below the waterline, you can find yourself facing gushers of water pouring in, pulling you toward the ocean floor. And if it’s a big enough hole, you might go down really fast, just like some of the financial firm catastrophes of 2008. To be clear, great enterprises do make big bets, but they avoid big bets that could blow holes below the waterline.", How We Might Fall.
• Write five, then synthesize: good engineering strategy is boring, Will Larson.
• Is engineering strategy useful?, Will Larson
• Do not start by changing the culture to drive the improvements, follow it first
• Build vs Buy

Survey

• Using cultural survey data., Will Larson

Talent management

• Your company needs Junior devs
  • Junior Talent forces your team to teach, coach, collaborate
  • Knowledge discovery IS innovation
  • The “Protege effect” is a well studied phenomenon where the teacher’s knowledge deepens when required to teach.
  • Generalists innovate better than specialists
  • Juniors mean psychological safety means more innovation
  • Your org suffers from not hiring juniors

Team vision

"Starting with the why" is one of The 7 Habits of Highly Effective People's best chapters.

• Seth Godin, A manifesto for small teams doing important work: really inspiring list of short cultural values for a team. Craft your own!
• Seth Godin, Big questions before little ones
• 🎞 Focusing is about saying no (Steve Jobs)
• 🎞 Vision is about perseverance (Steve Jobs)
• 🎞 Bryan Cantrill (Joyent VP of Eng) about the importance of why.
  • The primary motivator is mission and purpose. Software development is about delivering utility to humanity.
  • The soul is what motivates. You need to be able to explain the "why".
• 🎞 Steve Jobs on the same topic.
  • Focus on the gems.
• 🎞 Start with why, TED talk by Simon Sinek.
• 🎤 Insist on Focus, Keith Rabois
  • The reason why this [forcing people to focus and work on only one important problem] was such a successful strategy is that most people tend to substitute from A+ problems that are very difficult to solve to B+ problems for which they already know a solution to.
• Six critical questions every organization must answer (from Patrick Lencioni's The Advantage)

Technical strategy

• Joel Spolsky, Things You Should Never Do, Part I: Joel explains why (according to him) you should never rewrite a codebase.
• 🎤 Choose Boring Technology, Dan McKinley.
• Stevey's Google Platforms Rant: how Amazon became a platform.
• Letter to Shareholders, Jeff Bezos: “Day 2 is stasis. Followed by irrelevance. Followed by excruciating, painful decline. Followed by death. And that is why it is always Day 1.” So much is packed in this letter. Day 1 is about true customer obsession, resisting proxies, embracing external trends, high-velocity decision making.
• 5 Red Flags Signaling Your Rebuild Will Fail
• Polyglot programming in startup environments
  • Never introduce a new programming language in an existing code-base because of personal preference. Building software is a team effort. Globalize your code languages. Team cohesion is what matters the most.
  • You must have production experience in the programming language you want to replace or complement with another one
  • A decision to introduce a new programming language must be based on non-functional requirements, measurements or other relevant arguments, and not personal opinions.
  • Always think about the team and company, and especially about hiring and expanding the team.
  • A programming language is just a tool to deliver software. Don’t be in a tight relationship with your screwdriver.
• Tech Migrations, the Spotify Way
  • Ruthlessly prioritize
  • Product-ify migrations: accountability, test first, train, lead with value, KYC, gamify
  • Automate, automate, and move up the stack!
• hwayne/awesome-cold-showers: for when people get too hyped up about things
• IT Software Engineering Principles
• Leading With Confidence: How Engineering Managers Can Avoid Technical Decay
  • Ask for More Details From Individual Contributors About Their Challenges
  • Establish Sessions for Knowledge Sharing and Solicit the Sharing of Recent Experiences
  • Implement the Practice of Doing Side Projects
  • Follow the Engineer/Manager Pendulum Career Path

Team culture

• Lessons from 7 highly successful software engineering cultures
• Engineering a culture of psychological safety
• Culture Eats Strategy For Breakfast
• Habits of High-Functioning Teams
  • High Psychological Safety
  • Good hygiene practices
  • Active redistribution of “experience points”
  • Communicating generously
• Principles trump processes
• Brilliant Jerks in Engineering
  • The selfless brilliant jerk
  • The selfish brilliant jerk
  • Problems causes by brilliant jerks
  • Dealing with brilliant jerks
  • Includes lots of resources and practical questions!

Those are considered classics:

• Valve Employee Handbook
• 🎤 Netflix Culture Deck
• Gitlab's employee handbook (includes cultural values)
• The HubSpot Culture Code: Creating a Company We Love
• Don’t pave the path used by the unhappy cows
• Amazon's leadership principles

culturecodes is a repository of culture deck from companies (including the ones above).

Engineering values:

• Engineering Values. A letter to the Medium Engineering…
  • Professional & personal growth is more important than team stability
  • Everyone is a mentor; human connection is the path to bringing out the best in people
  • Excellent teams require diversity & inclusiveness
  • Good leaders are active and supportive
  • Good engineers are rigorous and resolute
  • Pursuit of greatness is a virtue
• Engineering Values at Lullabot
  • People matter more
  • Cultivate inclusivity
  • Learn and share
  • Excellence balances perfect and done
  • Code for the future
  • Work joy into work
• Figma's engineering values
  • Communicate early and often
  • Lift your team
  • Craftsmanship
  • Prioritize impact
• HubSpot’s Engineering Values
  • Customers Come First
  • Complacency Equals Failure
  • Think Like an Owner
  • Move Quickly & Iterate
  • Small Teams Win
  • Keep It Simple
  • Embrace Organizational Change
  • Scale Each Other
• Our engineering values at Wise
  • Ship often. Learn. Iterate. Have impact.
  • Be replaceable — single ownership is no ownership.
  • Move fast, but build for tomorrow.
  • Strong opinions, weakly held, openly shared.
  • Raise the bar — for yourself and your team.

Team dynamics

• Shields Down, Rands in Repose
  • Boredom in its many forms is a major contributor to resignations, but the truth is the list of contributing factors to shield weakening is immense.
  • Every moment as a leader is an opportunity to either strengthen or weaken shields.

Training

• Great developers are raised, not hired
  • Take some money, energy, time that you spend on recruiting and invest it in teaching your best developers mentoring skills.
  • Adjust your interview process and give a chance to candidates that are not good enough yet, but are eager to learn and have a growth mindset.
  • Relax “hard requirements” in your job ads to avoid filtering out impostors.
• “Sharing Interesting Stuff”: A simple yet powerful management tool
  • Your direct report sends you something they consider worth sharing with you (can be a blog post, book chapter, video, podcast…) and a few related questions they have in mind a few days before you meet together.
  • On the D day, you share your opinion about it and try to answer the questions that go with it.
  • You switch roles for the next session.
• Introduce Team G Morning Learning Sessions to Coach the Growth Mindset
  • Meet every morning for 30 minutes. Spend 20 minutes studying and 10 minutes sharing what you have learned.
• Your Startup’s Management Training Probably Sucks — Here’s How to Make it Better, First Round Review
  • People often think they don’t like management training. But what they’re really saying is “I don’t like shitty management training.”
  • Mistake: only training new managers
  • Snacks are good for the kitchen. They’re less useful for leadership lessons.
  • 4 topics every manager training should include:
    • Goal setting
    • Talent management
    • Org planning
    • Leadership & culture development

Trust

The best new ideas always have unanticipated benefits. So it's stupid to require people who want to do new things to enumerate the benefits beforehand. The best you can do is choose smart people and then trust their intuitions about what's worth exploring.

— Paul Graham https://twitter.com/paulg/status/1619753568264921089

Work ethics & work/life balance

• The Virtues of Laziness and Impatience: "there are two areas I encourage you to practice showing, right now: figuring out what’s important, and going home."
• Lazy Leadership: "entrepreneurship is really just a fancy word for delegation".
• Your non-linear problem of 90% utilization, Jason Cohen: why constantly running at 90% utilization is actually counter-productive.
• Evidence-based advice on how to be successful in any jobs: most self-help advices are not research-based. The ones listed in this article are.

Workshop facilitation

• List of workshop facilitation methods
  • Ritual dissent
  • Triopticon
  • Future backwards

Writing

➡️ See also my professional-programming list

See also the RFCs section.

• The 7 Emails You Need to Know How to Write
• The Inverted Pyramid or BLUF (bottom line up front) (Wikipedia): a method to prioritize and structure information in a text.
• How to say you’re sorry, Jason Fried (Founder & CEO Basecamp)
• How to write with style, Kurt Vonnegut.
• A blogging style guide
• How Jeff Bezos turned narrative into Amazon's Competitive Advantage
• Writing is Thinking: Learning to Write with Confidence
• Paul Graham, How to Write Usefully
  • Useful writing tells people something true and important that they didn't already know, and tells them as unequivocally as possible.
  • Translated into essay writing, what this means is that if you write a bad sentence, you don't publish it. You delete it and try again. Often you abandon whole branches of four or five paragraphs. Sometimes a whole essay.
  • Importance + novelty + correctness + strength, is the recipe for a good essay
• Encouraging a Culture of Written Communication
  • Easy to Search. Single Source of Truth.
  • Balancing Async and Synchronous Communication
  • Thinking Out Loud
• Design Docs at Google
• How to Write Something Compelling
  • If you want to design something attractive, you have to add an axis to your creative process. You have to make the ideas simple and universal at the same time.
• What I think about when I edit
  • Decide what you’re actually saying
  • Repeat yourself (within reason)
  • Eliminate passive voice
  • Don't use adverbs
  • Make use of whitespace

Other sources

Other lists

• 🧰 92bondstreet/cto: a curated list of CTO resources
• 🧰 mateusz-brainhub/awesome-cto-resources: a community-curated list of awesome resources to help you grow as a CTO
• kuchin/awesome-cto
• ryanburgess/engineer-manager

Movies

• 🎞 Moneyball. What's the problem?
• 🎞 Office Space
• 🎞 The Pursuit of Happyness contains some great lessons about hustle. Watch the interview scene.

TV Shows

Netflix's Chef's table profiles a couple world-renown chef. The kitchen world bears a lot of similarities with management. In the season two, I especially recommend episode 1 and 3:

• Alex Atala's story shows that you need to constantly reinvent and disrupt yourself.
• Dominique Crenn explains how she was given ownership over her work in her first kitchen experience (where she was basically given just a dish name, a list of ingredients, and was expected to invent the recipe with no kitchen training). She replicated that in her own kitchen.

The Office is a great satire of a dysfunctioning office.

Keeping up-to-date: blogs and newsletters

Here are some blogs and newsletter I follow.

Newsletter

• Software Lead Weekly (Oren Ellenbogen): a short curation of great management articles. Also include some videos, and some less serious, funny material. A lot of the links founds in this repo appeared in Oren's weekly email.
• HBR's Management Tip of the Day
• Tech People Leadership (Joe Dunn): Links, notes and opinions for leaders in the tech industry.
• CTO Insights (Tosho Trajanov): Weekly readings on software engineering & technical leadership.

Blogs

• Hacker News: mandatory if you want to stay abreast of what's going in tech. There are some good management articles from time to time as well. Since it can be a pretty huge time sink, I subscribe to a curation of the top articles instead (RSS feed here).

Podcast

• FRICTION with Bob Sutton. This podcast does not have any new episode since 2017, but it has some really great content. Great conversations. Lots of stories.
  • Part organizational design. Part therapy. Organizational psychologist and Stanford Professor Bob Sutton is back to tackle friction, the phenomenon that frustrates employees, fatigues teams and causes organizations to flounder and fail.
• CTO Insights with Katerina Trajchevska. A great podcast on all things CTO—featuring thoughtful conversations with tech leaders like DHH (Basecamp), Kent Beck (Agile Manifesto), and more.
• The Pragmatic Engineer Podcast with Gergely Orosz This podcast features candid conversations with senior engineering leaders from top tech companies. Topics include scaling teams, navigating hypergrowth, building resilient systems, and leading with impact—grounded in real-world experience.

My other lists

• engineering-management
• entrepreneurship-resources
• professional-programming
• python-education