Teams, Architects and Decisions

I know lots of great programmers. Some calls themselves architects. This text is not, in any way, intended to lessen what they do. Also, I want to make it clear that I don't support cowboy coding or poor design in any way. Agile, done well, holds quality and correctness in high regard. So do I.

Let's talk about Software Architects. The title itself doesn't really mean anything, it's just a label and everyone has their own definition of it. Also it seems everyone and their uncle is calling themselves architects these days. I suppose that is natural, because the title has a nice ring to it and it tends to come with benefits such as better pay and authority.

Unfortunately, many architects are just average programmers who never should have been given that particular rod of power in the first place. This has far reaching consequences, not only for poor developers having to work with the mess, but the entire organization and its customers. It's also worth mentioning that architecture, as a term, associates development with construction work and that has nothing to do with creating software.

All this dilutes whatever meaning the title once had. I kinda think that is good, because in the end we are just programmers with different amounts of experiences and skills. Some more than others. So should a highly skilled programmer be called an architect? I don't know, and it's not very important. What is important, on the other hand, is making sure your teams have enough competent programmers who understands how to structure the system in such a way that it ultimately makes your customers happy. I don't know if that is good architecture or not, nor do I care. What I do know is that we are in the business of deliver working software, not architectures.

Creating software requires all manners of technical skills: analysis, test, design etc. That's what all developers have to deal with on a day to day basis. From the top of my head, I cannot think of a single thing an architect should do that an experienced programmer should not (I leave customer/requirements out of this, those tasks are handled by the Product Owner).

What is your definition of an architect as compared to a developer? How can you single out the architecture from the system?

My definition

Not surprisingly, I think of a software architect as a great developer. A great programmer should be humble, patient, eager to explain and use her experience to coach and mentor her team mates and not wield her knowledge as some kind of power. Having a least one experienced programmer sharing her knowledge with the team is very important, so I think the definition of an architect as an experienced programmer with coaching skills is spot on.

I recommend Martin Fowlers take on this topic. In short, he says that architecture is "the shared understanding of the system" which makes the architecture a social construct. Further, the role of the architect is "to mentor the development team, to raise their level so that they can take on more complex issues.".

I agree with him. It makes the architect a servant leader and not a decision maker. Again, a great developer.

Teams and leaders

The reason for having a team in the first place is that it should be able to perform better than just the sum of its parts. That is obvious, but you cannot simply throw some people in a room and expect them to work as an effective, coherent team from day one. All teams have to go through several stages to start performing better than its parts. Unfortunately, you cannot skip any of these stages.

Getting a team to the performing stage takes effort and courage from the organization. Not surprisingly, this is where it fails. The team does something wrong and/or conflicts arises so the organization feels the need to "step in" and do something about it. Take charge. Usually this is handled by putting a powerful leader into place to make sure these things does not happen. This person is called their team leader, project manager, architect or something like that. She is put there to control the team and make sure it doesn't fail.

Putting a leader with decisive authority in the team is the classic way of dealing with problems. What happens is that the developers becomes dependent on a single person for direction and decisions, so they never really learn to trust their own skills. In the end, this effectively blocks the team from reaching the performing stage and never learns to perform effectively. They end up being mediocre at best. How ironic is that?

A better approach is having a coach on the team. A coach is a type of leader without decisive power. Her primary goal is not to control, but rather to support the team being their "servant leader", helping them grow their skills and teach them to use their abilities. A coach guides the team through the decision making process, helping them come up with new ideas and thinking in different directions.

Creating a powerful team costs a bit in the beginning, but you make up for it in the end. It's like technical debt, but for teams.

Who should decide then?

I like the Scrum definition of a team:

"There are no titles for Development Team members other than Developer. Regardless of the work being performed by the person, there are no exceptions to this rule". 

A team should consist of cross-functional developers with equal authority, able to deliver the next product increment (it's the same in XP as well).

There is always someone with more experience, but that does not mean they should make the decisions. A team working to reach a convergent decision does a much better job with that compared to a single person on his own. So there is no need for any single person (architect or team leader) with decisive powers. In the end, decisions are made and owned by the team.

Summary

1. Self-organization and collaboration is the best way to create software
2. This requires every developer on the team to be an equal when it comes to decision making
3. A person with decisive technical power is contradictory to that

A few questions with answers

How can you treat everybody 'equal' if one has just one year experience and one has 20 years experience?

The team should be able to handle this. It means they should self-organize to create their own decision making structure. The team will eventually learn to know each other and start trusting each individuals area of expertise. Naturally, the input from a senior will carry a bit more weight in the eyes of the other team members, and that is as it should be. It does not mean he can override their decisions though.

What is the problem if somebody is in charge of some specific topic and lead the team?

That is not a problem as long as the team is making the decisions, not that single person. Obviously the teams database admin will have much more to say about databases than the other guys, but he are not allowed to do as he pleases.

We are looking to hire an architect. He should have these skills: testing, design, deployment, support, business knowledge, clean code, gui, networking, databases, legacy…

That does not look like the skill set of a single individual, but rather the skill set of a cross-functional team of developers. When complexity increases you don't go look for one single person to deal with it, you start looking for teams of people collaborating better to solve the problems.