[HN Gopher] Ask HN: Books to read when you transform from SWE in...
___________________________________________________________________
Ask HN: Books to read when you transform from SWE into SWE
Management?
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!
Author : DDerTyp
Score : 271 points
Date : 2022-02-28 08:37 UTC (14 hours ago)
| silent1mezzo wrote:
| The First 90 Days by Michael Watkins is an amazing book for
| anyone getting into management and then again whenever you move
| roles/companies.
| christopherbalz wrote:
| + And worth re-reading as well. Totally generic to field but
| definitely applicable here.
| robin_reala wrote:
| You should definitely subscribe to Charity Major's blog. Every
| post gets a "oh, of course" from me. https://charity.wtf/
| bsenftner wrote:
| 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.
| gregdoesit wrote:
| 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.
| bsenftner wrote:
| 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.
| elmarschraml wrote:
| 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...
| cloverich wrote:
| 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.
| jstanier wrote:
| 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?"
| a_c wrote:
| 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.
| wiz21c wrote:
| The Prince by Machiavel.
| euph0ria wrote:
| Haha
| pid-1 wrote:
| 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.
| Jach wrote:
| 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.
| nonrandomstring wrote:
| 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
| SkyPuncher wrote:
| > 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.
| twox2 wrote:
| "The Phoenix Project"
| Jtsummers wrote:
| 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.
| twox2 wrote:
| 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.
| fallmonkey wrote:
| 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.
| unculture wrote:
| The Manager's Path by Camille Fournier
| kaycebasques wrote:
| 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.
| mro_name wrote:
| "Getting to Yes: Negotiating Agreement Without Giving In" by
| Roger Fisher and William Ury
|
| https://en.wikipedia.org/wiki/Getting_to_Yes:_Negotiating_Ag...
| taffronaut wrote:
| Books or writing on negotiation generally and appreciating that
| when it comes to management, negotiation is everywhere.
| salawat wrote:
| 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.
| c0brac0bra wrote:
| $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?
| salawat wrote:
| 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.
| Aeolun wrote:
| 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.
| splittingTimes wrote:
| This.
|
| DeMarco's Peopleware is a bit more hands on compared to the man
| month.
| brodo wrote:
| 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.
| dotBen wrote:
| 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.
| flakyfilibuster wrote:
| 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.
| colemanron wrote:
| 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
| strife25 wrote:
| 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.
| p33p wrote:
| 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.
| cutenewt wrote:
| I second this. The Manager's Path is a terrible book.
| throwanem wrote:
| 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.
| casralad wrote:
| Software Engineering at Google [https://abseil.io/resources/swe-
| book]
| adastra22 wrote:
| The usual suspects: The Mythical Man-Month by Fred Brooks.
| Management by Peter Drucker.
| brobinson wrote:
| Leadership Strategy and Tactics: Field Manual
| NikolaNovak wrote:
| The very first article from this book was the most "lightbulb"
| moment for me in my transition from technical SME to management:
|
| https://store.hbr.org/product/hbr-s-10-must-reads-for-new-ma...
|
| 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.
| DanielBMarkham wrote:
| 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.
| sugaroverflow wrote:
| _- 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).
| rg111 wrote:
| - Peopleware
|
| - The Mythical Man Month
|
| - High Output Management
| [deleted]
| Scarblac wrote:
| 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
| mr90210 wrote:
| Start here: https://holub.com/reading/
| endymi0n wrote:
| 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:
|
| https://www.defmacro.org/2014/10/03/engman.html
|
| 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:
|
| https://news.ycombinator.com/item?id=30240428
|
| EDIT: replaced second link with HN one as it contains an Emoji
| and broke due to policy
| p0larboy wrote:
| 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.
| brianmcc wrote:
| I recommend "Managing Humans" by Michael Lopp aka "Rands".
|
| https://randsinrepose.com/
|
| It's a bit tongue in cheek rather than "management theory" but no
| less worthwhile for it.
| zweiasakura wrote:
| 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...
| svmanager wrote:
| We write https://staysaasy.com which includes various insights we
| think the existing literature doesn't cover.
|
| Some examples:
| https://staysaasy.com/communication/2021/10/30/look.html
| https://staysaasy.com/management/2021/07/17/Less-Divisive.ht...
| https://staysaasy.com/management/2021/06/26/check-on-your-te...
| mooreds wrote:
| 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.
| cnj wrote:
| 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.
| max23_ wrote:
| Just read this recently from SO blog, hopefully it is helpful:
|
| https://stackoverflow.blog/2022/02/23/what-you-give-up-when-...
| philk10 wrote:
| Becoming a Technical Leader - an Organic Problem-Solving Approach
| by Jerry Weinberg
| (https://geraldmweinberg.com/Site/Technical_Leader.html)
| tsm wrote:
| _An Elegant Puzzle_ by Will Larson: https://press.stripe.com/an-
| elegant-puzzle
| blowski wrote:
| 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.
| intellectronica wrote:
| Excellent book. Also many great posts on his blog
| https://lethain.com/
| [deleted]
| goodgoblin wrote:
| 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.
| ep103 wrote:
| 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
| ChrisMarshallNY wrote:
| 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...
| jll29 wrote:
| * 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)
| pc86 wrote:
| If there's anything I would beg new EMs _not_ to do, it would
| be going out to get a PMP.
| pan69 wrote:
| Peopleware: Productive Projects and Teams
|
| https://en.wikipedia.org/wiki/Peopleware:_Productive_Project...
| intellectronica wrote:
| - 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.
| mprovost wrote:
| 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.
| austincheney wrote:
| 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?
| mprovost wrote:
| 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
| ath0 wrote:
| 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...
| qiskit wrote:
| 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.
| onion2k wrote:
| 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.
| jrs235 wrote:
| Debugging Teams: Better Productivity through Collaboration
| http://amzn.to/2FQb9xx (affiliate link)
| kqr wrote:
| 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.
| jlintz wrote:
| What books of his would you recommend?
| Jtsummers wrote:
| _Out of the Crisis_ is the one I 've read and would
| recommend. Written in the 1980s, but most of it still applies
| today.
| kqr wrote:
| Both Out of the Crisis and The New Economics are very good.
| gashmol wrote:
| 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.)
| cjcenizal wrote:
| 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.
| rjzzleep wrote:
| High Output Management always gets recommended. How did his
| management work out for Intel?
| cushychicken wrote:
| 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.
| mandeepj wrote:
| > A 10x return over a decade is pretty damn good
|
| I think it was 100x
| santoshalper wrote:
| Assuming your facts are correct, your math isn't. $0.10 ->
| $9.50 is a 95x return.
| senko wrote:
| 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?
| Zaheer wrote:
| The Manager's Handbook is a great free online resource (by the
| founder of Clearbit): https://themanagershandbook.com/
___________________________________________________________________
(page generated 2022-02-28 23:02 UTC)