A team management model

10 Aug 2019

Posted by Amenel No comments yet

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:

  • Provide the best environment possible.
  • Provide the best tools possible.
  • Trust people to do the best work that they can.
  • Help people work by removing obstacles.
  • Help people grow by teaching skills or knowledge.
  • Deal with each event that may induce or has induced some frustration or dissatisfaction as it shows up.

It is directly inspired from my personal motto:[1]

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:[2]

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.”[3] 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”[4].

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[5] and will respond to the same arguments[6]. 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.

Getting to know a developer’s job

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[7] 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.

What does the company need from the team?

  • Productivity.
  • Quality work.

What do our developers need?

  • Teamwork.
  • Trust.
  • Some part of business analysis.
  • Documentation, written to account for the future: the documentation needs to be future-proof. Put differently, documentation has to be written with the question “how am I going to use this documentation in two years from now?” in mind.
  • Unit tests. Over the course of its lifespan, a software program will be the responsibility of several waves of engineers. People join and leave teams, for a variety of reasons. A significant portion of the overall cost of a software program will be made of maintenance rather than raw creation.
  • A vision. Although there’s admittedly less ego in a software developer than in another professional, say a surgeon, we all unconsciously aspire to some kind of longevity. Short-term goals are not as motivating as long-term ones. Would somebody free from any constraints or specific goals want to build something that will not last?

What plays badly with developers?

  • Pressure.
  • Shifting priorities.
  • Abandoned tasks, i.e. work started but put aside to never be finished.
  • Requests to write comprehensive documentation: usually, documentation does not need to be complete for the simple reason that part of a developer’s job is to make use of reusable elements of software. Therefore, any developer knows that some reading and experimenting is mandatory and part of the job. The type of documentation asked for should be one that helps quickly find one’s way and understand the subject at hand, one that lets spend time where it will be useful to spend it. Therefore, asking developers to write extensive, thorough or long documentation is a sure way to alienate them from documentation.
  • More “work”. Developers don’t need more “work”, that is things that they perceive as somewhat irrelevant to their main task which is writing code in order to create, fix or maintain applications. That’s when the “layer of abstraction” comes into play[8]. That’s what the manager is for: dealing with any task that the developers are not supposed to do, in addition to more generally providing the best possible environment for the team.

The ideal environment

  • Top-of-the-line equipment. (Planned)
  • Efficient tools. (Planned)
  • Freedom within the team. (In-place)
  • Individual autonomy. (In progress)
  • Quiet. (Will not change)
  • No distractions, not even a window above or behind the computer screens. (Will not change)
  • 1-person or 2-person offices. (Will not change)
  • Ample space on the desks. (Will not change)
  • Walls behind the desk and in front of the developer, especially for cheatsheets. (Will not change)
  • Social gatherings, and celebrations of milestones. (In progress)
  • No personal phones ringing or vibrating. (In progress)
  • A notebook and some writing material. (In progress)
  • Apart from planned meetings, developers are not interrupted without prior agreement on their part. (Planned)
  • If not for discussing user stories or specs of another kind, nobody from outside the team talks to the developers: they shall talk to the manager. (Planned)
  • Developers have a means (a sign such as a “Do not disturb” sign, or a token of any kind) of signalling that they are not open to interruption. (Planned)

What can we do in the short term?

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.

  • Items labeled in green will be maintained and if pertinent, reinforced.
  • Items labeled in red will not be worked on.
  • Items labeled in orange constitute most of the points to set up and/or to improve.

In addition to what is labeled “Planned” in orange above, improving the productivity of our team can be done with these measures:

  1. Upper management: Implementing remote work through a 2-day-per-week home office plan. Less will provide anecdotal benefit and with more days a week, we run the risk of diluting team spirit and loosening social links.
  2. Team manager: Implementing a change of state of mind so that “working for the future” becomes an integral part of the culture of the team. This is usually done through presentations, discussions and debates.
  3. Team manager: Trying to instill in the team members some curiosity about best software engineering practices.

For now (late August 2017), here are the subjects of planned presentation and discussion sessions:

  • Software development processes and teams elsewhere (Spotify, Trello, Microsoft, etc.).
  • How to write a good future-proof documentation.
  • What are unit tests for and how to write them.
  • How to create reusable AngularJS components in order to accelerate frontend development.

[1] Peopleware – Productive Projects and Teams, p. 34.

[3] Peopleware – Productive Projects and Teams, p. 46.

[4] Peopleware – Productive Projects and Teams, p. 47.

[7] Peopleware – Productive Projects and Teams, p. 11.



Post your comment

You cannot post comments until you have logged in. Login Here.


No one has commented on this page yet.

RSS feed for comments on this page | RSS feed for all comments