Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Books to read when you transform from SWE into SWE Management?
314 points by DDerTyp on Feb 28, 2022 | hide | past | favorite | 93 comments
Hello HackerNews!

I started my SWE career in 2016. I'm in a team which develops an enterprise SaaS-Application. Now I got the opportunity to transform into a leader role which focuses on DevOps, Tests, QA, Documentation and related topics.

So far, we set goals and start to introduce the team (around 5 people) into that topic.

My question is - are there any good books, articles, podcasts, ... which can help me in this "challenge"? I already got some basic (practical) knowledge in leading people and managing a product.

Stay safe!

Everyone recommends The Manager's Path, but I don't think it's a good book to explain HOW to become a manager. The book's goal is to explain the career path of a manager from tech lead to CTO.

My #1 recommendation these days is "Become an Effective Software Engineering Manager" by Jamies Stanier. This book explains how to approach the work a manager is involved in and what you can expect from the day to day. Planning, hard conversations, performance reviews etc.

Also, look for general management books. Leadership is something all humans do – software management is about managing creative people. Some other books I recommend are:

• Creativity, Inc by Ed Matmull • Crucial Conversation • Team of Teams

For email newsletters, I recommend Software Lead Weekly (https://softwareleadweekly.com/) and Better Allies (https://betterallies.com/more-content/).

Lastly, I also write a blog called Build the Stage (https://www.buildthestage.com) about managing SWEs. I've got posts about performance reviews, team meetings, how to give feedback, etc. It'll help you out.

Stanier's book should be required reading for anyone becoming a people manager for the first time. I cannot recommend it enough and regularly give it to new or aspiring managers.

Yep, I really like sports related books too, such as Eleven Rings: The Soul of Success, and Leading: Learning from Life and My Years at Manchester United

I second this. The Manager's Path is a terrible book.

What's wrong with it? I'm just gathering recommendations myself, and it'd help to know especially if there are more general red flags to watch out for.

The book is completely fine and worth the read! Just know that it's a book to explain the career path of an Engineering Manager in the tech industry.

My criticism is around how often the book is recommended. Many people want to learn HOW to become a manager. Manager's Path doesn't provide that.

Conversely, a lot of people recommend An Elegant Puzzle. Great book, but I would not recommend it to first time managers – it's too advanced.

Elegant Puzzle is for experienced managers, specifically people that are managing Managers. Check it out if you're 2+ years into their management career.

Here's the single one resource I'm giving any of our new leaders, it's really short and the highest signal-to-noise ratio I've ever seen:


I'm personally revisiting it every time I send it around, because it's just so good.

Here's another I've seen recently that goes into a bit of detail while not being quite as succinct:


EDIT: replaced second link with HN one as it contains an Emoji and broke due to policy

The "defmarco" blog post is gold. I appreciate that he put it a quick bullet format, rather than a long fleshed-out ebook.

Most of the rules actually applies across all types of roles and not just a engineering one.

Gonna print this one out and nailed it on my desk.

Things I've saved from previous discussions:

HN Question "Advice for a new & inexperienced tech lead?": https://news.ycombinator.com/item?id=22255301

HN Question "Best book / resources on leadership, especially for tech teams?" https://news.ycombinator.com/item?id=21712194

HN Question "I want my tech lead's job" https://news.ycombinator.com/item?id=21369535

Useful comments on a leadership blog post link https://news.ycombinator.com/item?id=21376838

Second the recommendations for "an elegant puzzle" and "the manager's path".

Cant believe this one has not been mentioned yet: "Becoming an effective software engineering manager" by James Stanier (https://pragprog.com/titles/jsengman/become-an-effective-sof...) - a good book, and very specific for exactly your situation.

Would also like to mention my own podcast "Ask an engineering manager" - more focused on SWEs, but also has some episodes about how to be an Eng Mgr, e.g. https://askanengineeringmanager.libsyn.com/017-typical-mista...

Thanks for mentioning my book. Indeed, it's written exactly with that moment of time in mind: the "OK, so I want to do this. But how?"

I enjoyed an Elegant Puzzle but often felt it was targeted at a step above first time management, with topics on having interview pipelines, org design, etc. But it was still a good read.

His follow up book on Staff Engineering I think is a good read for first time managers. It lays out the other leadership path, which is helpful both for understanding where you fit in and the other leadership path you can guide your reports towards, based on their trajectory and interests.

I recommend "Managing Humans" by Michael Lopp aka "Rands".


It's a bit tongue in cheek rather than "management theory" but no less worthwhile for it.

I agree on Rands In Repose. The articles helped me pivot my priorities from shipping code to helping my team ship code. Here's a gist of the articles i found the most helpful: https://gist.github.com/samarkamat/f19a4c4596550429eae1b95cb...

There’s really only one thing you have to take away from ‘The Mythical Man Month’ and ‘Peopleware’ in my opinion (more people != more work), but they’re still valuable reads.


DeMarco's Peopleware is a bit more hands on compared to the man month.

Man month is also pretty dated by now. There is some valid advice in the book still, but oftentimes it has to be 'translated' to the modern computing environment. Other things in it are just completely outdated.

I wouldn't recommend it as a starting point, but I learned a lot from The Mythical Man Month. It seems like every agile/scrum/kanban/lean book starts by arguing that the old ways of managing projects had problems. It was useful for me to read Brooks' deep dive into what, exactly, those old ways were. Some of the methods stand the test of time and others have not (e.g. not using too many comments in your code because of how much disk space they consume).

Another vote for Peopleware. It felt like it was written for a prior era, and that's when I read it in the early 2000s!

But then you realize that the fundamentals of being a good engineering manager are the same regardless of the technologies you're using and building.

Join the Rands Leadership Slack. Highly highly recommended: https://randsinrepose.com/welcome-to-rands-leadership-slack/

You can learn an awful lot by just browsing around, but they also have channels for questions, both with your name and anonymous.

Becoming a Technical Leader - an Organic Problem-Solving Approach by Jerry Weinberg (https://geraldmweinberg.com/Site/Technical_Leader.html)

I'd say almost anything by Joel Spolsky[0]. Smart and Gets Things Done[1] was one that I enjoyed.

[0] https://www.joelonsoftware.com

[1] https://www.joelonsoftware.com/2007/06/05/smart-and-gets-thi...

I’ve just made this transition myself! Congratulations! I have a very short list of reading recommendations here: https://www.cenizal.com/reading/

In addition to the blog links on that page, I found these books to be the most useful:

High Output Management, by Andy Grove. My number one recommendation for anyone interested in managing people, particularly engineers. This book presents methods and processes for helping individuals maximize their impact, while remaining grounded in reality and humanity.

Thanks for the Feedback, by Douglas Stone and Sheila Heen. This book gave me great insight into how I handle feedback and what I can do to make the most of it. It also helped me understand how others might take my feedback, and develop methods for sharing my feedback effectively.

The Manager's Path, by Camille Fournier. A pragmatic guide to the stages of technical leadership, from tech lead to CTO. A great read even for engineers with no interest in people management, because it provides a clear line-of-sight into what those folks care about and how they make decisions.

High Output Management always gets recommended. How did his management work out for Intel?

To quote Wikipedia:

> He was the third employee and eventual third CEO of Intel, transforming the company into the world's largest semiconductor company.

Looks like it worked pretty well.

Also from Wikipedia:

> He relinquished his CEO title in May 1998, [...] and remained chairman of the board until November 2004.

Care to guess when the decisions causing today's woes for Intel started happening?

I stand corrected.

He became CEO in 1987, when Intel's stock price was in the range of $0.10-0.20.

When he left the post of CEO in May 1998, Intel's stock price was ~$9.50.

A 10x return over a decade is pretty damn good.

Assuming your facts are correct, your math isn't. $0.10 -> $9.50 is a 95x return.

> A 10x return over a decade is pretty damn good

I think it was 100x

"Getting to Yes: Negotiating Agreement Without Giving In" by Roger Fisher and William Ury


Books or writing on negotiation generally and appreciating that when it comes to management, negotiation is everywhere.

I'll take a shot, assuming that you are asking how to manage a technology team, not how to understand technology at a wider scale. You need both tech leadership and end-to-end/shallow-deep abilities. But the tech side is a different question entirely. Looks like some other folks have provided answers so I won't go there. (The tech side is a lot to go into in a thread, and would include some kind of conversation figuring out where you are technically. "I'm a SWE" doesn't begin to cover it.)

Without any thought at all:

- One Minute Manager

- Debugging the development process

- The Culture Code

- The Five Dysfunctions of a Team

- Difficult Conversations

Take some negotiation and interviewing hands-on courses.

- The Five Dysfunctions of a Team

Was a really helpful and great book to help put in words some of the challenges I faced on a previous team (while I had an absent manager).

Lots of good recommendations in the thread.

I found this one to be pretty valuable: https://www.amazon.de/Difficult-Conversations-Discuss-What-M... (sorry, amazon link)

Because, obviously you're going to get into situation as a manager where you have to have difficult conversations.

If you are replacing a previous manager, you could ask him. He'd probably give you the best recommendation tailored specifically for your office/business domain/environment. In my experience, manager's/tech lead would recommend books. But a good habit in general is to proactively look at your manager's/tech lead's library if they have one in their office.

- Power: Why Some People Have It and Others Don't by Jeffrey Pfeffer

- What Got You Here Won't Get You There: How Successful People Become Even More Successful by Marshall Goldsmith

These two books are not specifically on the topic of becoming an engineering manager but cover the important aspects of how to work effectively as a leader in organizations. Turns out that's very important too.

The very first article from this book was the most "lightbulb" moment for me in my transition from technical SME to management:


It's NOT IT related. But the key lessons on how our role changes, how our goals and methods should change, and which of our expectations/assumptions of leadership are catastrophically incorrect, I think is universal.

For example, if I may be so bold, you said "to transform into a leader role which focuses on DevOps, Tests, QA, Documentation and related topics". NOWHERE in there you mention people ... and that's the #1 problem those of us coming from technical to leadership make :). We think "now we'll have the power to fix all those stupid technical deficiencies", rather than "Now I'm responsible for making sure team is motivated, inspired, working well, and they are in line with company's (and client's) goals and requirements".

It's the one 12-pager I recommend to all people who are becoming or relatively new managers (I read it after about 12 months in management; on one hand I wish I read it day 1; on the other hand, I'm not sure if I would've believed / embraced it as much until I lived it. Your mileage may vary).

Edit: For what it's worth; I did NOT believe or embrace this the first couple of years, but there is no upper limit to training, practice, and enhancing our emotional intelligence skills. It's harder than technical skills, not the least because as techies we may not see its value immediately, and it's a lot less clear cut of a topic. But learning how to understand, get along with, and inspire/motivate/coach/lead your fellow human beings, is a life long study.

Going from SE toward SEM I'd suggest you get into s/w metrics. Nothing is better for decision making and advancing good arguments at meetings than being able to give numbers.

- Fenton: Software Metrics

Obviously there's a ton of pop management stuff. A few of my favourites:

- Horowtz: The Hard Thing About Hard Things

- Pink: Drive

- Evans: The Trousers of Reality

- Gall: General Systemantics

> Nothing is better for decision making and advancing good arguments at meetings than being able to give numbers.

I strongly disagree with this.

While there is a fact/data side to being a manager, the key skill is understanding the human/soft side of it.

Strong disagree. Metrics-based management leads to so much dysfunction. Read Robert Austin’s Measuring and Managing Performance in Organizations for the details, but the short version is that metrics distract people from things that are important but non-measurable.

I haven't found s/w metrics to be useful.

* read (all or at least the top 3):

- Death March

- Peopleware: Productive Projects and Teams

- The Mythical Man Month

- Growing Software: Proven Strategies for Managing Software Engineers

- Managing Humans: Biting and Humorous Tales of a Software Engineering Manager

* consider getting PMI certified (PMP): https://www.theknowledgeacademy.com/de/offers/pmi-certificat...

- technical tools for planning

- stakeholder communication

* follow your gut (if you are a developer you will know how they want to be treated)

If there's anything I would beg new EMs not to do, it would be going out to get a PMP.

One quick observation: you say that your new role focuses on Devops etc... That sounds like a tech lead to me. A manager focuses on their people, not a tech stack. One of the hardest parts of transitioning from an IC to a manager is letting go of control of technical decisions, and learning to trust your team. Of course you need to be able to set the general direction, but it's more about building a culture than it is about the exact implementation. If the team doesn't want to do devops, or testing, or write documentation, etc then it doesn't really matter which tech you choose. Getting people to work together and build consensus is the hard part.

As a military officer I agree that trust is a huge amount of effective leadership. It’s something that is immediately visible when visiting a different team.

So what do you do, as a software manager, if you don’t trust your team? Do you set higher technical standards? Do you invest in training? Do you hold responsible for failure to deliver a certain level of quality?

It's not really about the manager trusting the team, it's the other way around, gaining the trust of your reports. If you don't trust your team to achieve their goals, then yes you do have a problem and you can address that in all kinds of ways. But by default you should trust the team. On the other hand, you don't deserve your team's trust until you've earned it.

From the military side you might be familiar with Auftragstaktik [0]. Basically, you set the goal and a timeframe and let the team figure out how to achieve it. You have to connect their work to some kind of success metric. Otherwise you're just saying something like "we have to implement Devops", as a goal in itself, not connected to anything else.

[0] https://en.wikipedia.org/wiki/Mission-type_tactics

Depends on the diagnosis!

Two blog posts: [1] from Rands on skill vs will.

And [2], from Roy Rapoport on a five-step process for dealing with problems.

In both cases, it’s not enough to say you “don’t trust” your team. You have to do the work to diagnose WHY things aren’t working the way you want - do they see there’s a problem? Do they want to fix it? Do they have the skills?

Trying to fix a problem you can’t diagnose is going to be very hard.

[1] https://randsinrepose.com/archives/avoiding-the-fez/

[2] https://medium.com/@royrapoport/the-five-conditions-for-impr...

Before answering, can you share what do you want to get out from your career? Some starter questions: Why do you want to get into software management? Do you want to get into software management in general, or for the particular company you working for? Is it a stepping stone to your goal, e.g. building your own product?

The books shared in other comments are all good, I personally vouch for the Mythical Man Month. I consider High Output Management a must read for management in general. The Elegant Puzzle is quite useful for team of certain scale, but I would say less useful for startup of a few engineers. Still useful, just less.

The Manager's Handbook is a great free online resource (by the founder of Clearbit): https://themanagershandbook.com/

You should definitely subscribe to Charity Major’s blog. Every post gets a “oh, of course” from me. https://charity.wtf/

I'd recommend Julie Zhuo's The Making of a Manager. She's got a twitter https://twitter.com/joulee where you could check out her sharing of managerial wisdom to have your own gauge.

This book focuses on the practical side like sharing useful feedback, smart recruiting strategy and meeting optimization, all towards the goal of greater outcome and amplifying team success, instead of just more activities entailed by conventional manager model.

Regarding documentation, check out Docs for Developers by Bhatti et al. The subtitle describes the book as "an engineer's field guide to technical writing" and that's exactly what the book is. It provides you a detailed step-by-step overview of what high-quality documentation process and output looks like. I've been a technical writer for 9+ years and can vouch that anyone following the blueprints laid out in that book will probably end up with significantly better docs.

An Elegant Puzzle by Will Larson: https://press.stripe.com/an-elegant-puzzle

I found this to be immensely useful for my specific situation (mid-sized startup), but people in much bigger (enterprise-level) or smaller (<20 staff) seemed to get much less from it.

Excellent book. Also many great posts on his blog https://lethain.com/

The Manager’s Path by Camille Fournier

There are kind of two main axes you can impact

1. The Devs

2. The Org

For The Devs

With regard to the developers you need to make sure they have what they need to succeed, and to help them grow.

For this "Peopleware" is great - it helps understand the "servant leader" mindshift

For The Org

With regard to the organization, your main job will be making sure the organization doesn't make classic mistakes.

Mythical Man Month is great for this. Another great resource is the "Classic Mistakes" section from McConnell's book Rapid Development.

If you google that you can find a PDF for it.

I recommend you start an MBA program at night. There is no single book, there is no single topic, you need a broad range of new perspectives to be a truly effective manager.

Which MBA program covers engineering management specifically? I have a close friend who completed an MBA at Harvard and that program did not cover anything related to the type of people management engineering managers do. When my friend became a manager, had to learn all this on the go and from peers / managers and some of the resources linked in this thread.

Your friend must have been asleep, Harvard MBA 100% covers engineering management. If you mean how to manage in the specifics of a Scrum or Agile or TDD environment, yes, covered, but lightly. What is taught during an MBA tends to be more universal; there was a topic of "why is 'Six Sigma' not taught?" in my MBA program from the early 00's. Because Six Sigma is a product and constitutes a passing fad. And it's fad has passed, nobody cares about Six Sigma anymore. What is taught are the universal skills of good communication, material cultural sensitivity, group dynamics, and organizational behavior management, aka incentive design. What is not taught is the passing fads business culture consumes.

High Output Management - for general management issues.

Software Project Survival Guide - for software specific issues. (Don't be discourged by all the documents it discusses.)

One book I haven't seen mentioned so far is Elastic Leadership - https://www.elasticleadership.com/

I like that it's quite hands-on, and that it also explicitly focuses on HOW to get teams out of a bad state.

If your team is doing perfectly fine right now, it may not be the best book to pick up, but when things spiral downwards, I can highly recommend it.

Handbook of Total Quality Management.

Demings, Jaran, Ishikawa, Crosby, Taguchi

Divest yourself of the impression that Quality is just about Testing. It's a long uphill fight.

Godspeed friend, and stay sane.

$230 on Amazon. Several books have been recommended that are no longer in print and are incredibly expensive for used copies. I'd be interested to know the reason behind this. If they're so useful, why aren't they in print?

That particular one you have to catch lucky. I stumbled across it in the University library, and it's basically an aggregator of the work of the biggest names in the Quality Management/Quality Assurance field. I.e. if you haven't run into those gentleman before and regularly hold the title of QA, you are missing out on the theory behind what you are doing.

Most text/theory in Quality Management lit focuses on industrial/manufacturing incarnations and there are some (the most tiring people on the planet) who insist somehow Software engineering is fundamentally different than manufacturing; it isn't. That's a myth disproven time and time again. The book will walk you through how the work of Quality Management permeates all layers of any number of different business verticals.

I scored mine in paperback used for a steal. It was awesome.

Long story short, it isn't. It's just easier because material expenditure tends to be lower, but this is compensated for in higher communication overhead when interfacing between teams.

The reasin they aren't in print, is since, as the name suggests, it is a reference book, they generally do not fly off the shelves like hot cakes, and are the kinds of texts you reach out for when you've basically exhausted everything you have and still have no idea what it is you are missing, and damnit, someone had to run into something like this before.

Remember, publishers are profit driven, and the practitioners in a field, (nevermind the subset that actually take into account the historical theory in their field) is not a numerous bunch.

Even for 230, I'd have bought it just to have the theory in my hands in a form I find more conducive to reference than otherwise.

I'd also caution against scoffing at out of print literature. We lose reams of expertise and old nuggets if wisdom that when cross referenced with newer material actually help build up a profound understanding of a field. I've not gotten one book I regret buying in terms of professional brush up, and it does more than you think to proof you against the great hype BS cycle that tech is so rife with. I can't count the number of times I've caught domething in tge bud as abother manifestation of a path already tread.

But you do you. Your style and mind probably works different than mine.

At my previous company I was the lead on a team that was tasked with taking projects that had gone off the rails a bit (or a lot...) and try to get them back on track. If you land a role managing a team with a project that's not going well (a common reason for management change) then the book I'd recommend most is "Catastrophe Disentanglement" by E. M. Bennatan. It's very insightful.

The First 90 Days by Michael Watkins is an amazing book for anyone getting into management and then again whenever you move roles/companies.

+ And worth re-reading as well. Totally generic to field but definitely applicable here.

I'd recommend you check out the Level-up Engineering podcast. They cover engineering management topics with a large library of content out already, and it keeps going strong. https://codingsans.com/engineering-management-podcast

The Prince by Machiavel.

I don't remember the exact wording, but "if you're going to do many evil things, do all of them at once" really has shaped how I organize myself when I need to screw people.

Non ironically I think that's a great book for anyone working in a company.

If you go this route, read Anti-Machiavel at the same time, by Frederick the Great, a chapter by chapter rebuttal written just prior to him becoming King of Prussia.


Just read this recently from SO blog, hopefully it is helpful:


- Peopleware

- The Mythical Man Month

- High Output Management

Debugging Teams: Better Productivity through Collaboration http://amzn.to/2FQb9xx (affiliate link)

Software Engineering at Google [https://abseil.io/resources/swe-book]

The Culture Code was the most impactful book I read when I first made this transition, particularly since I was coming from smaller, more unstable companies at the time

Leadership Strategy and Tactics: Field Manual

The usual suspects: The Mythical Man-Month by Fred Brooks. Management by Peter Drucker.

"The Phoenix Project"

IMHO, this book is better read after at least reading Goldratt's The Goal. It's a sort of spiritual sequel. His Critical Chain is also worth reading before or after The Phoenix Project as it has a more direct connection.

The Goal, as written, is about manufacturing processes and a lot of people have trouble seeing past that domain when reading it. That is, they fail to generalize, or understand how to generalize, the ideas of Theory of Constraints. Critical Chain takes, essentially, the same Theory of Constraints and applies it to project management, versus production management. The Phoenix Project continues that sort of explicit extension by moving from general project management to IT systems management.

Interesting, I'll check it out thanks. I do think the Phoenix Project is too verbose for the story they have to tell, but the "aha" moment is really just the parallel that engineering can be treated like assembly line manufacturing. It was good introduction to Kanban.

Gerald M. Weinberg books. Just get them all. QSM 1-4 for start.

If you read nothing else, read Edwards Deming. He clearly outlines what the management philosophy of modern creative jobs must be like:

- Focus on what matters.

- An organisation needs an aim, a meaningful goal, that's not just "do what we have always done except better".

- Don't invest in shiny things because they are shiny – investments basically cost you the interest rate on a loan, rain or shine, even on Sundays.

- You can't inspect quality into a product or process.

- When your inspectors fix minor quality problems themselves instead of rejecting the product, the upstream process learns that minor quality problems are acceptable.

- Quality starts at the upstream process – this applies also to the upstream process.

- Making and then fixing quality problems can be a huge part of an organisations expenses, but of course there's no line item on the books for "mistakes", so that huge cost gets absorbed as the cost of doing business.

- The organisation hierarchy doesn't matter – how the work flows between people is what matters.

- Management by numeric goals results in cheating, information hiding, and bad decisions to meet the quota at any cost.

- Management by results ends up wasting a lot of effort trying to correct for statistical noise.

- To improve outcomes, you must improve the process.

- Don't compare yourself to arbitrary goals – estimate what the current process costs you and what you could earn with an improved process, then find out if that's worth the investment.

- To get a sense of the process, use statistical process control charts.

- Unless there's something truly extraordinary going on, don't judge individuals for their performance.

- Individual performance is almost always random noise compared to team performance.

- Judge team performance, and reward fairly based on that.

- In the rare case where individual performance is consistently beating team performance and you have statistical evidence of this, see it as a learning opportunity: if the rest of the team did what this person did, its performance would be insanely improved – find out what that is.

- Team performance is the outcome of manager performance.

- The point is not to be right, but to be learning.

- Humans have a right to take joy and pride in their work, free from fear of grading or ranking.

- When optimising an organisation, parts of the organisation might have to operate at a loss – trying to operate every part of an organisation at profit easily deoptimises the organisation.

- Avoid unnecessary paperwork or approval procedures, rely instead on statistics and sampling to ensure the system is stable.

- Well, technically, if inspection is really, really cheap (which it rarely is – consider also delay costs!) or mistakes really, really expensive (which they sometimes are, like for code that hits production), 100 % inspection makes sense.

- Putting out fires or fixing problems with clear, assignable causes is not process improvement – it's simply putting the process back where it should have been to begin with.

- Help people understand the greater context: how is the product used, who uses it, what do they think, how is the company making money, and so on, and so on.

- Leaders should be skilled in the jobs of the people they lead.

- How do you know whether you're doing your job well? How does other people in your organisation know?

- Everyone thinks it's obvious what success or failure would look like, but when probed for details, it turns out no two persons have the same definition. Ensure everyone agrees on how a test for success is performed.

- If you find signal in the data, first verify the validity of the data. Look first for errors in measurement.

- Plan, Do, Check, Act. Use the Shewhart cycle to learn!

- Once a process is in statistical control, a sample drawn from that process gives you no information whatsoever that you didn't already have. A sample from a process in statistical control is by definition a random number to you.

As you can see, there's a very wide variety of important things one can learn from Deming. Everyone should do it.

What books of his would you recommend?

In addition to Dr. Deming's books you can check out The Deming Institute (www.deminginstitute.org). They have a "learn" section with blog posts, podcasts, and articles about the Deming philosophy and how it's being used today. Plus they have sections on some of Deming's main teachings (e.g. the Red Bead Experiment).

Out of the Crisis is the one I've read and would recommend. Written in the 1980s, but most of it still applies today.

Both Out of the Crisis and The New Economics are very good.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact