Skip to content
/ engineering-management Public
forked from charlax/engineering-management

A collection of inspiring resources related to engineering management and tech leadership

License

MIT license
0 stars 619 forks Branches Tags Activity
Star
Notifications You must be signed in to change notification settings

PatrickBernard/engineering-management

BranchesTags
 
 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

273 Commits
.git_hooks
.git_hooks
 
 
articles
articles
 
 
pictures
pictures
 
 
.pre-commit-config.yaml
.pre-commit-config.yaml
 
 
LICENSE
LICENSE
 
 
README.md
README.md
 
 
glossary.md
glossary.md
 
 

Repository files navigation

Table of Contents

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.

There are some other more specific books quoted below.

Other books I haven't read:

Book reading lists

What is engineering management?

Here are some generic resources:

General management resources

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

Tools

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

Antipatterns

Biases

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

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.

Curated examples of job ladder/career development matrix:

List of lists:

Concepts:

Change management

Code reviews

See my professional-programming section about code reviews

Communication

Conflict resolution

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.

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

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 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

Developer productivity and devexp (developer experience)

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

Diversity and inclusion

Hiring:

Employee 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

Executives

FinOps (cost)

First-time manager

Feedback

See the Performance section too.

  • 📖 Radical Candor — The Surprising Secret to Being a Good Boss
  • 📖 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.

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.

Hiring: interviews

Specifics about hiring engineering managers:

Hiring: interview questions

Hiring: job postings

Hiring: process

Hiring: résumé review

Hiring: sourcing

Hiring: take home exercises

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

Learning, retro, postmortem

See my professional-programming section about incident-response

Quotes:

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

Management style

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

Mentoring

Mindset and attitude

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.

Motivation

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

Organizational structure

See also Data organization

  • 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

Performance management

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

@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:

About GTD:

About calendars:

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?

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

Presentations, design and public speaking

Some great examples of presentations:

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

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

Product management

See also my entrepreneurship-resource repo.

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.

Project management

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)

Release management

Remote teams

Quality

See also my professional-programming repo

RFCs (request for comments)

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.

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

Those are considered classics:

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.

Scaling an organization

Security

Soft skills, Emotional Quotient (EQ)

Storytelling

See Presentation

Strategy

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.

Survey

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

Workshop facilitation

Writing

➡️ See also my professional-programming list

See also the RFCs section.

Other sources

Other lists

Movies

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.

My other lists

About

A collection of inspiring resources related to engineering management and tech leadership

Resources

Readme

License

MIT license
Activity

Stars

0 stars

Watchers

0 watching

Forks

0 forks
Report repository

Releases

No releases published

Packages

No packages published

Languages

  • Shell 100.0%