I decided to read this book in an attempt to improve my understanding of how my managers think. I must say that this is the first book in engineering management that I read, and I am still in the very beginning of a journey that I don’t know where it exactly will lead me. For this reason my opinion stated in this post could change after further reading about the topic. I still don’t know if I would like to become a manager in the future, but I am very interested in learning more about the topic.
The main goal of the book is to empower their readers, mostly engineering managers, with rule of thumbs for certain daily basis situations in an engineering product, tools and processes for hiring engineers, mentoring, motivation and career management advices. A lot of very valuable insights can be taken from the book, and I could get a better understanding of how broad the topic of management can be.
Now, about the book, I must admit it was interesting to read. I could clearly see from the beginning, that it really is focused on management folks, e.g. because of the easy going language on the tech terms. The authors have lots of years of experience in IT Management and they’ve been part of some big companies in this industry. Therefore I pretty much respect their opinion, as they have way more experience than me. But this fact doesn’t stop me from criticising their tips/ideas :)
Here I will list a few tips they gave in the book, and put my thoughts on top of it.
Remote teams are not as productive as onsite teams
The authors argue that issues in communication can happen with remote teams, leading to lack of understanding on the feature requirements. They also put into account that these teams would be less productive than a onsite one.
I must admit that it could be true in companies that suffer from poor communication skills and are not remote friendly. If decisions are made at the office, without communication with the remote folks, how can they catch up with that information?
If the company has a mindset of inclusion and remote friendly, encouraging async communication in e-mails, Slack or any other tool, it is very likely that the people working remotely could be even more productive than the ones working onsite. Another reason to believe that remote folks could even perform better, is the distraction free environment (if done properly at their homes) and flexibility.
Contractors as mercenaries
The authors state that contractors are like mercenaries, and they just do that job for the money. They even argue that these folks should be treated differently from your normal full-time employees.
As it could be true for some contractors that they are there just for the money, I quite disagree with the tip of treating them differently from the “regular” employees at your company. If you want them to achieve good results and deliver good projects, they should feel part of the team, they should be able to communicate properly with the rest of the team, and their feedback also should be taken into account.
The authors also mention that these folks don’t need a performance feedback (review) system, because their best feedback is being paid. I disagree, and I believe that giving proper feedback about their performance could improve their work on the company’s project they are trying to help.
The boss with the inflated ego
Another point that caught my attention, was when the authors talked about dealing with a boss with inflated ego. Basically their advice is to take what’s there and do what you are told to do.
Sure it can be a survival tip for some companies where you have no better choice, but I believe this kind of behaviour can lead you to creating a dysfunctional culture, where people focus on personal success and status before the team’s success.
Relying on a single person’s ego can lead to unreflected decisions that may not be the best for the company and the product. Furthermore you produce a culture of avoiding conflicts, as in seeking artificial harmony over constructive conversations/discussions, and the practice of destructive communication.
It’s frustrating for employees to be passed over in decisions they don´t support. This could finally bring the whole company into a dangerous path if the boss is not able to take feedback and only act based on his/her biases.
Participate in stand-ups to get a notion of progress
They argue that a good opportunity to access progress of your team, is to attend to daily standups.
I agree that it is a good way of checking in and showing interest on what’s the status of the team and if they need help with some topic. But I also think some teams can perceive this attitude as micromanagement. So I would recommend to pay special attention on how your team behaves when you attend the standup. Are they comfortable talking about their tasks? Are they afraid or intimidated? Are they talking to you as in giving reports to their supervisors? If the answer to one of these questions is yes, there might be some work needed in building a link with the team, demonstrating that the reason you are there is to help the project to move forward.
Wrapping up
These are some of the topics that I found myself wondering if they are really good tips or not. But as much as I don’t agree with a lot of other things, this book could be a good resource for managers in a more traditional company. Practioners of the famous command-control style of management could get a lot of input for further improvements and self criticism.
It is also true that I could get a better sense of what it looks like to be an engineering management and all its related skills. It is a lot about knowing how to deal with different kind of people, building relationships with different departments, investing in the team growth, celebrating success, acting and learning on failures, budgeting and many more. Most of these topics I don’t feel able to give feedback or to criticise, based on my lack of experience, but on the ones about the engineering team, I felt pretty comfortable doing thought experiments and imagining certain situations. I would recommend this book for other developers too, so we can create a bit more empathy and think on the “big picture”, with all the other disciplines around our engineering world.
Special thanks to Chilja Speransky for reviewing the post.