The MAD model

The main purpose behind the Manager, Architect, Developers (MAD) proposal is not to create a new software development methodology or replace methodologies that already exist and are used for decades. The goal is to suggest a very strict core-baseline around hierarchies, communication, responsibilities, team structuring and evaluation. All these fundamental ingredients tend to be neglected, over-complicated or simply disappear when companies develop software under pressure. It is strongly believed that the lack of a clear policy that defines the minimal procedures around any chosen methodology, constitutes the Achilles’ heel of these environments.

Inspired from systems such as the one of professional sports clubs, the article brings some different ideas under consideration. It presents a certainly more aggressive model with respect to the desired team structure and it tries to leave out all the unnecessary time consuming luxuries. However, at the same time it argues how that aggressiveness could benefit the overall development process by minimizing the overheads, simplifying the decision making and granting authority and control to the roles required.

The Hierarchy

Each team is formed by only one Manager and only one Architect. They have the same level of authority and they are the only ones that can make the final calls in the part that they own. Both of them are reporting to the same Director, who acts as the product owner and overall supervisor for the entire progress. In particular, the Manager owns the non-technical, business oriented side of the product, together with the career development for all the involved Developers. The Architect owns the solution and the developed features and he has full control of the entire development team. At the core of the team is a mix of Senior and Junior Developers that their combined skills are able to ensure on-time deliverables (see Figure below).

1. The Director

He interacts directly with the Manager and the Architect of the team and he is responsible for their career paths. He has the ability to overwrite decisions that were taken at lower levels, but at his own risk. In practice, he is continuously aware of the overall development status and has visibility only to very important obstacles that arise. Everything else remains quite transparent at his level. He can be seen as the equivalent of the sports team owner.

2. The Manager

He is accountable for ensuring revenue growth, establishing valuable customer and third-party collaborations, driving developers career path, marketing, branding and competitors analysis. In practice, the manager is the person that leads the business aspects of the product. He interacts directly with the Architect for synchronizing the commitments of the team, release dates and other mandates and he reports back to the Director.

Nevertheless, he never interferes directly with the development process, any technical decisions or even the chosen software development methodology. These decisions belong to the Architect and the Developers. In that way, all the responsibility for the technical side of the product is delegated into the overall development team, which now has all the freedom for increasing productivity, efficiency and quality, any way it believes that works best, with no restrictions!

3. The Architect

He is the equivalent of the coach in a sports team. He is the owner of all technical decisions related to the product and has the authority to refuse any changes that could downgrade the quality of the product or change the initial planned schedule for deliverables. Indisputably, the Architect constitutes the mastermind of the product, the key figure for decision making and he is challenged to prove that he can achieve all the desirable objectives. He has an extremely technical background with many years of software development in his career and he is closely related to the product area that he works.

The MAD model considers that the one to one mapping with the role of a coach is incredible. Therefore, the Architect is granted full-control over his team. He has the ability to choose, replace or move around Developers under his own terms. In return, he is fully accountable for the performance of the team and the product features delivered. The Architect communicates directly with Director and the Manager for all the higher level decisions. At the same time, he interacts daily with all the Developers of the team, while he takes seriously and discusses all the technical advices that are coming from his Developers.

4. The Developers

Highly skilled and talented individuals, that can communicate well and tackle together all kind of technical challenges that arise during software development. The majority of the team must be formed by senior engineers with a very small pool of junior engineers. All of them are willing to work hard, perform and learn from each other. It is very crucial that each member of the team is motivated to be part of the targeted project and enjoys working with all the used technologies. Otherwise, the team creates weak links, which are hard to balance.

Developers represent the equivalent of the players in a sports team. They are in control as they build the software and each of them has expertises around a specific area. Their knowledge is mandatory to match as close as possible the tasks that they are assigned. In the MAD model, Senior Developers are required to mentor continuously at least one junior member of the team. They become responsible for his performance and his deliverables, as part of their senior duties. Developers follow a hierarchy based on seniority and only via that hierarchy they are able to propagate requests to the Architect, Manager or Director, when and if needed.