Overall 6/10 – Maybe a more junior/beginning developer would find this useful but for an inexperienced dev it’s mostly common sense.

I bought this book for the wrong reason. I saw it, looked at the index and thought that the content was exactly what I would have wanted as a beginning software developer. Problem being I’m no longer a beginning software developer so too much of the content is no longer useful.

Some Takeaways I did like:

• Think of yourself, as a business
  • Consider what company long-term suits our goals
  • Market yourself
• Climbing the Corporate Ladder (Big Company)
  • Take Responsibility – If you take responsibility for something, credit will follow.
  • Become Visible
• Quota System – Forcing yourself to regularly contribute small pieces towards a big goal

Quirky ideas I wouldn’t have considered but can’t discredit or find interesting include:

• Hire a professional resume writer. HIs argument is that you only write one and that you are not an expert. I think that could be a sound argument. I once worked for a consulting firm, where they “creatively wrote” the CVs for staff. They could remove parts that were factually true and replace it with what seemed like buzz-word bingo to a techy like me but it worked!
• Hard work is hard and boring. Sometimes there’s no silver bullet and you just need to put in the work. Sounds obvious but I agree with the author, often people delay or try to find a magical soltuion when what is really needed is hard work. Reminds me of: “..those silver bullets that you and Mike are looking for are fine and good, but our web server is five times slower. There is no silver bullet that’s going to fix that. No, we are going to have to use a lot of lead bullets.” – Bill Turnpin
• Any action is better than no action

Overall 7/10 – May have been more revolutionary when first released but large parts of the book would now be common knowledge

The book has 6 parts:

1. Managing the Human Resource
2. The Office Environment
3. The Right People
4. Growing Productive Teams
5. It’s supposed to be Fun to Work Here
6. Son of Peopleware

On first read-through I struggled with this book, perhaps it’s not ideally suited for a straight read from start to finish. There is no single narrative or clear progression from chapter to chapter. It’s more of a , here’s rough hidings and these two software guys are going to rant and deliver wisdom in this general area. On first read the points they made seem a very mixed bag of common sense, useful, interesting and some parts..impractical. It’s like two hardcore software guys got in a room and said, oh man if we could do this perfect what, how would we run things.

It was only when I reflected back that a more coherent picture came together, that I couldn’t fault most of what they said and I had an increased if begrudged respect for the book. Maybe the world just isn’t ready to embrace as high a quality of software as they suggest nor the lovely self-chosen offices. I feel like I’d love to apply their ideas to places I’ve worked but that the distance between ideal and current standard company policies are too great. I do think I would re-read this book every few years and see if I can nudge places I work towards some of those ideals that I hope are true.

My Reading Notes:

Managing the Human Resource

We are not making burgers, mistakes will happen, in fact there should be an error quota and projects/attempts get canned. A project in steady state is dead but not all things requested should be done, think about them and if they should even be started.

ch4 Quality if Time Permits

Quality far beyond that required by the end user is a means to higher productivity. “. “Quality is free, but only to those willing to pay heavily for it.” How many projects have we seen get bogged down with technical debt, have low morale and slowly die due to porr quality. Question is knowing what level of quality where. The book proposes always letting the builders decide.

“We all tend to tie our self-esteem strongly to the quality of the product we produce–not the quantity of the product, but the quality.” Even if the project would benefit from a huge amount of mediocre work, morale will suffer. They accept that the market does not need or want quality as much as the builders but that “Quality, far beyond that required by the end user, is a means to higher productivity.”

Parkinsons Lay – “Work expands to fill the time alloted”. Book claims this law is entirely wrong. That given knowledge work and high calibre employees that people want to complete stuff. Also makes a good point that bad estimates can demoralise. e.g. Didn’t make the last three sprint goals well 23 never make it so who cares. Small dataset shows builders most efficient setting goals themselves.

The Office

To me, half this chapter is obvious but useless within very large companies where avoiding cube farms is all but impossible. Some points it makes are:

• Most offices are designed by furniture police that want neat layouts, optimising most people per room
• Raises a fun meme you do hear a lot “Never get work done between 9-5″. I’ve worked with some offshore people that loved when everyone else went home.
• An employee costs X, office costs fraction of X. Attempting to save $1 of office costs risks productivity of employee.
• Data from their wargames showed quiet area with sapce essential. Space important as noice increases exponentially to volume.

ch10 – Brain vs Body Time

Consider how useless/sloppy time recording systems are. They don’t even account for what matters, FLOW. Interesting formula presented:

Efficiency-Factor = (uninterrupted hours) / (body present hours)

Books suggests some obvious but difficult things: dont answer phones, bring back small offices with doors, allow workers to organise office space.
ch13 Taking Umbrella Steps – basically says offices should be grown organiccaly and end up looking like university campuses, with many small focussed areas and lots of small offices with windows looking out at open areas. This is a far cry from most banking offices!

People

Managers unlikely to change employees personality in any major way. For short work duration, people unlikely to change. How they are at start is very similar to how they are when they leave. I personally have seen a few people change but yes it’s been the minority, this suggests hiring people is crucial step.

ch15 – Hiring a juggler .. then ask to see him juggle. Don’t just ask the theory. Favour auditions/small pieces of work with the team to see if he fits in. Rjecting people can also be a team bonding experience as it lets a good team realize how elite they are. Can you afford not to hire the best? What message would that send to your current team? This isn’t so terrifying as you’d think, you want the best for the team not necessarily smartest self centred person.

ch16 – happy to be here

What’s your annual employee turnover rate? How much does a replacement cost?

Your goal should be to instil that this is the best place to work and you would be crazy to leave. Turnover = more turnover as creates a “passing-through” mentality. If people are treated disposably, then they act like they are. You must trust people to get to know one area well and that way many will actually stay.
Self-Healing System

Methodolgies seek to enforce conformance through statute. Better to achieve convergence using:

Training – teach certain methods = they use it as they know it best
Tools – automated aids encourage use
Peer Review – Spreads training and tools people may have missed and encourages using same methods

Growing Productive Teams
ch18 Sum of the whole is greater than the parts

A jelled team works towards a SHARED COMMON GOAL. That goal may be arbitrary or boring (100% test coverage) but its essential to have. Notice that goal may not correspond to firms overall goal e.g. increased profits Q4. A jelled team will have: strong ssense of Identity and Eliteness.
Teamicide – things that Destroy Teams

Buracracy
Physical Separation
Fragmentation of Peoples Time
Defensive Management – trust your team
Quality Reduction of Product
Phoney Deadlines
Clique Control

ch23 – Chemistry for Team Formation

Cult of Quality
Provide Lots of satisfying Closure
Build a sense of Eliteness
Encourage Heterogenity
Preserve and Protect Teams
Provide Strategic not Tactical Direction

It’s supposed to be Fun to Work Here

ch24 – Chaos and Order – People crave some disorder and unexpected fun. Suggestions include: hackathons, wargames, pilot projects.
ch30 Making Change Possible

How change happens:

change

People are emotional, hate change and react in number of ways:

Blindly Loyal and follow
Believers but Questioners – Sceptics, passive, opposed due to fear
Militantly Opposed (and will undermine)

Only the “believers but Questioners” are worth trying to affect and intellectual arguments will not win out. You must celebrate “old way” as helping change happen. Point out that “You never improve, if you can’t change at all”.

Later chapters had some interesting points:
– Middlemanagement is only place where learning can happen AND change be implemented.
– Learning is limited by Orgs ability to keep its people

Overall 9/10 – Highly engaging easily-read book for software developers.

Interesting book that uses a story about an IT manager getting promoted and being responsible for a team as a way to explain lean/agile concepts. Working in IT a relatively long period now I guess most the scenes are basically from somewhere I’ve worked which is nice that it’s realistic but perhaps shows the book would be more useful for those newer to software development.

Small Topics

The book covers a wide range of topics in varying levels of detail. While quite succcessfully tying them together into one story.

• Incompetent management – Few bad employees making trouble. Useful to hear of scenarios but characters were shallow though served their purpose.
• Issue prioritization – kanban and prioritize issues that fix the bottleneck only. Bill re-discovers kanban from manual post-it note creation. How to decide whether a project is worthwhile, the company projects should return >10% rate of return in time period.
• Releases – Bad change release procedures, continuous deployment
• Change Management – Allow all minor/low risk automatically, only monitor medium and require manual intervention of high risk items. Else you’ll never survive.
• SDLC/Kanban – Things are only done when deployed, anything else is WIP that should be avoided. Smaller iterations = lower risk
• One Genius – How to reduce reliance on 1/2 great developers and spread work over a team
• Types of Work – Business projects, Internal Projects, Changes and Unplanned Work! Last one is very dangerous as it throws off planning.
• Dev vs Ops – Shouldn’t be separate but working together.
• Teams – Need trust and mutual respect.
• Minimizing WIP is essential – Nice analogy of a factory with parts and Work In Progress building up showing how that can actually slow progress.

Key Takeaways for Me

The Three Ways

1. left to right flow of work – small batch sizes, never pass defects downstream and constantly optimize for global goals. Limit work in progress.
2. right-to-left – have constant fast feedback to ensure to prevent problems. Stop the production line if going wrong.
3. Foster a good culture – Encourage constant experimentation and risk taking. But understand that practice and repetition pre-requisite to mastery. High trust is essential.

Percent Busy and Waiting Times

We’ve all relied on a chain of people/teams or systems and wondered why simple changes take so long. This graph goes some way to explaining it: