Posts

The myth of estimation

Estimation of software development is never scientific, though software is one of the most scientific miracles that stupid sapiens have achieved. It is so tricky, and you often don't even believe what you estimated. Your peers, your product managers and your supervisors expect you and your team to estimate everything, and often take your estimation as a "commitment" when you try very hard to explain the the inaccuracy is the nature of estimation because we are Terran not Protoss. Nevertheless, it is life of engineering leaders and we have to embrace it. Estimation is not just for your sprint plan, but more importantly, it is for the communication with other sapiens. Because Mankind's communication has different levels, Mankind's estimation should do the same. Sizing Sizing is the top level of estimation. I also call it 30,000 feet high estimation. The goal is to size the raw items for your quarterly or even yearly roadmap. The item to estimate could be a ...

Pilot: What makes a good manager in a software company?

Not many management books tell the truth about how to evaluate a manager. Here is the deal, and it is super simple, just two criteria: 1. A good manager leads the team to ship the product, a.k.a, to change the world. 2. A good manager makes the team better when he left the team. I really like the book The Effective Executive by  Peter Drucker . A core idea in the book is: Effectiveness is decided by the results. So, no matter a person has or has not shining leadership and charisma, or he is good or bad at public speaking and business writing, he is a bad manager if he made the team worse. Likewise, a person is a good manager if he improved the team with good results regardless of how he did it and what kind of person he is. Often, you could tell if the team improved apparently, however it is tricky some time. I think the next question is: how to fairly evaluate a team's improvement. So, stay tuned...