Hi, friends!
I read the first book from my reading list now (or to be precise: I read the introduction and the skimmed the rest of it).
This book is not on how to manage a team effectively. This book is on a specific software tool called Visual Studio Team Services (VSTS) and Team Foundation Server (TFS) by Microsoft.
VSTS/TFS seems to be a heavy-weight software that offers to support processes over all the life cycle of a software project; you can create team structures, backlogs, remote estimation sessions, road maps, test status reports, but tickets and much more.
The book explains how to use all the features of that software. So if you’re trying to learn something about team management practices, it’s not worth reading!
Maybe if you have all these processes in place anyway and you are using a mess of different tools for them, it can be interesting to check if this software would provide a better experience. But coming from a small agile team with the mindset to not produce organisational overhead (the only tool we use is a lean backlog), I fear that using VSTS/TFS would rather slow you down by requiring additional org work to have everything in that software.
There is one statement from the introduction that I want to mention though:
They say, the project management role in modern projects/products is moving towards servant leadership, the role is more of a delivery enabler than a manger.
First of all, the statement is funny because I feel, when you start using VSTS/TFS like described in the book the project manager becomes more of a servant of the tool, that requires effort to maintain all the different views and also requires to train your team on the tool, instead of enabling the delivery.
But apart from that irony, I like the statement. The good project manager (or team lead in a product team, since I don’t like projects) has the main task to enable the team to deliver working software.
From my point of view, this includes getting all the ressources the team needs, keeping distraction away, knowing the strengths and weeknesses of the team members in order to assign tasks properly, keeping up motivation (and regularly check if and why motivation is dropping) and teaching and mentoring the younger devs in the team, given that the team lead is actually an experienced software developer and not somebody who stopped coding because it’s too hard.
I’m still looking for other books on the topic of engineering management, I will keep you updated!