bookCover

In the company I work for we have this book club, a.k.a an excuse for a bunch of us devs to gather around and share past anecdotes while going over some book.

The latest book picked in there was the one mentioned in the title and, while at first I was hesitant to dive deep into the subject (since I’m not a manager nor see myself being one in the near future), I must say I was pleasantly surprised with all the perspective I found in it.

Since the beginning the author states very clearly this a reference book so you shouldn’t read it cover to cover if you don’t have the time nor the need to do so. You may very well pick the chapter that suits your particular current case and tackle it to find some answers.

Going into the first chapter we found ourselves with a simple but complicated question: do we (as developers) know what it takes/makes a decent manager? It seems a rather easy one to answer but looking into our collective experience, it turns out most of us have had to deal with a fair amount of bad management during our careers. So as starting point the author lays out what it means to be good manager.

It also goes explains what to expect from 1:1 with your managers, asking feedback frequently to improve yourself and own your career instead of delegating it to the current company you’re working for.

Of course you can’t have one without the other so it also goes into length detailing the basic professional behavior you, as a professional software developer, should strive to (later on I’ll post about some other books I’ve read related to this almost hidden topic of software ethics). Holding to your world, being responsible with the software and documentation you deliver and keeping always kind communication norms with those around you in your workplace sound like silly statements to state but it’s amazing how often one or more of them are neglected by our community.

A keen example of this is talking jargon to a non-technical person (that’s just rude and childish). Imagine whenever you were to a doctor appointment he or she would use every technicality in medical literature, how dumb do you think you’d feel asking her endless time to go over a simple headache diagnosis because you didn’t get it the first 2353214 times? Exactly. Don’t be a jerk please.

Moving forward, there are several ways you could be a manager without necessarily holding a roles as such, one of this in the form of mentorship. This part I really enjoyed because the most valuable lessons I’ve learned so far in my developer career have come directly from developers with higher seniority than me who took the time to explain certain topics -from silly ones such as “Keep asking until you have no further doubt when a requirement is handed to you” until moral ones like “Always make your best effort, no matter you hate the project you’re in. The quality of your job must be agnostic to your context”-. She takes the time to show a few ways you can mentor someone and the many benefits that experience gives you as a professional.

There’s a complete chapter dedicated to the technical lead role which I found fascinating due to it explained so clearly the key responsibility of it which is being the link between the engineering and the product branch of any product. Of course this title might be labeled differently across companies (engineering manager for instance). The gist of this position is having the technical knowledge to defend and estimate deliverables while at the same time discussing with managers from different areas regarding pain points the project as a whole have and need tackling, as well as prioritization and scalability. It’s a mouthful!

But since the title of the book is the manager’s path, it stands to reason that the majority of it covers the different management’s styles, hierarchies, do’s and don’ts. It does so in managing sections:

  1. People
  2. A team
  3. Multiple teams
  4. Multiple managers

Like I said at the top of the post, I’m not a manager myself so if you suspect I skip most of these sections then you suspected correctly… Almost. I decided to take a glance the first two since they have been primarily where my professional career has developed. It was interesting seeing so well articulated some terminology for behavior deep down I knew had to be wrong with some of the managers I had in the past (such as micromanagement) and also refreshing to learn that it’s no hippy bullshit whenever you hear an agile couch talking about trust in the work environment. Without it, no team can be truly productive at its peak -it’d be only individuals making separate contributions without any synergy at all.

Final chapters are specifically targeted to high profile managers (CTO/technical founders) for they cover how they should handle culture development within a company/start-up, goal prioritization, hierarchical ladder building, decision making, outage postmortems, code review and many other necessary practices to strive for.

As a closing words I can safely claim it’s a light and insightful read for anyone looking to solve 90% of the problems you’d expect to find in any software organization (after all, the book is tailored for IT management). It’s not a read for just in case as opposed to just in time information as Tim Ferriss says, so be mindful about this if you’re not interested in the topics I mentioned above.