Posted by Comments
This is the contents of a document I wrote for my manager so that he knows what to expect from me with respect to my style of management. This was written two years ago, on August 17, 2017. I've made minor adaptations to its contents so that the format is better suited to a blog article.
This document presents a vision of the future management of the software engineering team in this company. It is written in the English language because the sources and references are written in English; it appeared better to have a uniform language throughout these few pages rather than a mix of languages.
This management model can be broken down into a few ideal points:
It is directly inspired from my personal motto:
The manager’s function is not to make people work, but to make it possible for people to work.
It is also inspired from this quote of Masaru Ibuka, founder of Sony:
To establish a place of work where engineers can feel the joy of technological innovation, be aware of their mission to society, and work to their heart’s content.
Some authors found that “Two people [(software engineers)] from the same organization tend to perform alike.” From then, they go on to postulate that “productivity differential [in software engineering] is explained by the environment of the workplace and the corporate culture”.
It means that the productivity of software engineers and the quality of their work depend more upon the work environment and the culture within a company than it does upon individual talent.
The typical developer in this team is not unlike all other developers in the world and will respond to the same arguments. He or she will not be unlike any other employee in the company. Put simply, developers are just like other people.
Developing software means engineering a complex machine. It involves creating, thinking and rethinking, analyzing tasks and situations, and devising solutions to the problem at hand. What no one (not even seasoned senior developers) ever says, tells or writes, is that software engineering equates to solving an endless train of problems one after the other.
Developers love to create things.
Developers love to explain their ideas. It could be said that developers are teachers waiting to bloom.
Developers love to be acknowledged for their work.
Developers love to debate. And they are not sore losers when another solution beats theirs on the grounds of technical merit.
Unfortunately for the professional world, developers also tend to be 1- keen to use new technologies and 2- eager to embrace them, which clashes with the need of the enterprise world for stability. In order to reconcile these two facts, developers must be able to read about new technology and tools, and experiment with these: some time devoted to technology watch and self-guided study is necessary.
Fortunately, developers are lazy people and the software field encourages “positive” laziness (“do not reinvent the wheel”). But unfortunately, developers are lazy people and their laziness does an insidious harm: they tend to avoid anything remotely related to documentation, while at the same time lamenting the lack of it. They tend to show little curiosity for accounts of other people’s experiences, and as such, they stay away from books. But how do you get better when you’ve stopped learning?
On the specific subject of books, DeMarco and Lister wrote:
The statistics about reading are particularly discouraging: the average software developer, for example, doesn’t own a single book on the subject of his or her work, and hasn’t ever read one. The fact is horrifying for anyone concerned about the quality of work in the field; for folks like us who write books, it is positively tragic.
A change of culture is needed.
In spite of the hypothesis that “developers are people just like the other people”, it would be a bold assertion to think that any manager can manage developers (software engineers, testers, graphic designers, etc.). The reason is that developers have to be shielded from what plays badly with them, which most managers are not aware of… unless they have themselves experienced the job.
The objective in the coming months (till the end of 2017) is to implement some changes that will bring the environment closer to the ideal environment as described above.
In addition to what is labeled “Planned” in orange above, improving the productivity of our team can be done with these measures:
For now (late August 2017), here are the subjects of planned presentation and discussion sessions:
 Peopleware – Productive Projects and Teams, p. 34.
 Peopleware – Productive Projects and Teams, p. 46.
 Peopleware – Productive Projects and Teams, p. 47.
 Peopleware – Productive Projects and Teams, p. 11.