- 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
41–50 of 97 posts
- 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
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.
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.
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.
- 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.
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.
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.
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.
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
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.