Debugging Teams with ...... Humility, Respect and Trust
No man is an island entire of itself; every man is a piece of the continent, a part of the main; if a clod be washed away by the sea, Europe is the less, as well as if a promontory were, as well as any manner of thy friends or of thine own were; any man’s death diminishes me, because I am involved in mankind. And therefore never send to know for whom the bell tolls; it tolls for thee. - John Donne
In the previous post, I started this book club talking about reading is a way to learn, and stated the idea that software development requires a lot of reading, and different ways to help struggling team members with communication and careful writing. This post I will be discussing further about team work.
- Amusing Ourselves to Death with Documentation
- Debugging Teams with Humility, Respect and Trust
- Mythical Man-Month
- The Manager’s Path
Software Development is a Creative Process
Developing a piece software is a creative process. It takes a creative mind to come up solutions to solve a problem. Many software are invented because the inventor encountered a bad experience and decided there is a better way. No 2 days are exactly the same for a software developer.
When writing a program, there are also creativity involved to just make the software run a bit faster as well. Such as the use of software algorithms, specific usage of language features and frameworks.
Furthermore, there are different techniques to come up with a solution, such as pair programming. Alternatively, sometimes I just leaving it in back of my mind. The brain will surprise me with a solution the next day1.
On top of all that, the developer has to write the software for easy to read and understand as well. Once a particular part of a software is written, the developer will spent most of her time reading and understanding the source code, and only small portion of the time modifying it2.
Software development is so much of a creative activities, that in my opinion, it should be well regarded as any other craftsmanship. The developer should be pride in crafting a piece of software.
Software Development is a Team Sport
Writing software is a team sport, and we posit that the human factors involved have as much influence on the outcome as the technical factors.
There are many ways to express ones craftsmanship. For example in the automotive world, on one end of the spectrum, one could hand beating every single panel to create a timeless classic, like the Eagle speedster, or having a team of talents using the latest technologies to deliver the “last analog supercar”, Gordon Murray Automotive T.50.
For computer program, it is possible for a single developer to come up with an idea and write the software all by herself. However, there is only so much a single person can do. There are many roles in a team that, do different jobs than writing code yet equally important. Such as tech lead, product owner, testers, engineering manager and marketing.
Everyone in the team do different tasks so that developers can focus on writing great code3.
Bus Factor (noun)
the number of people that need to get hit by a bus before your project is completely doomed.
When the team get bigger and especially more developers come onboard. One common way to divide work is having developer each working on specific areas of the product. For example, for a 2 developers scenario working in a client-server based application, one would focus on the client side and the other on the server side.
In this case, it is obvious to everyone that, it will be a major problem when there is only 1 developer holding a specific knowledge about the product. The bus factor in this case would be 1, not to mention the problem of silo mentality. The developer might not literally hit by a bus, but she could be taking personal time off, sick days, or simply decided to retire. It is very evident as well the solution to alleviate this situation by training one or more developers up to share the responsibility.
It is very easy to put too much of the emphasis on the individual software developer, who is the apparent low bus factor, and overlooked the rest of the team. A project could also failed because the marketing guy, who has in-depth knowledge about the customer, got “hit by the bus”.
Build a Superstar Team, Not Team of Superstars
Only by giving up some ego will you ever change directions and get exposed to new things. Again, it’s about increasing humility and being willing to learn as much as teach.
There are many ways to increase the bus factor, one would hires a lot of superstars developer, who mastered the craft of writing software, and can crank out new features 10x faster than most regular developer. It might work for a start because those “genius” developer able to dive into any code base and start solving problems.
May be because I am not one of those “10x developer”, but I think those developers are very rare and hard to find. It is even harder to find those that can work in a team. It is far too common to mistaken arrogance and difficult to work with as someone prides in ones craftsmanship.
I would much prefer a superstar team instead, where everyone has the will the learn and mastered the craft of Humility, Respect, and Trust. An individual task might take a bit longer to solve. However the team is stronger as a whole, and deliver better results over a long period of time.
Managers wind up acting like parents, and consequently employees react like children.
After carefully constructed a team so everyone complement each other. It would be very dangerous for the manager leader alone to take ownership of the team’s culture. The team might work very well while the manager is around, but once the manager get promoted to elsewhere as a result, the team quickly started to fall apart. Therefore, it is crucial to involve everyone in maintaining the culture and environment.
Nothing more satisfying seeing a team maintaining a healthy culture even all original team members has left.
Conclusion
The moral is this: do not underestimate the power of playing the social game. It’s not about tricking or manipulating people; it’s about creating relationships to get things done, and relationships always outlast projects.
This book is so full of advice that I could spend so much more time writing everything about it. It is very suitable for developers in different stages of their carrier. When I first become a team lead and read this book for the very first time, I thought the major take-home message was manager is a four-letter word and be a servant leader.
Recently when I got the opportunity to lead another team and read it again, I realized the true values of HRT and how my visible attitude about absolutely everything - no matter how trivial is unconsciously noticed and spreads infectiously to your team.
I will definitely reading this book again for the third time in few years time, and review my progress.
You’ll end up spending less energy dealing with people-related problems and more time writing great code.