Software development can be complex. It needs a lot of thinking about code should be written and how complex systems should communicate amongst themselves. It doesn’t become more easy if you ad the various titles that are involved with this development process. You need software developers, but also software architects, art directors, UX designers, Interaction designers and so on. When you venture into the agile way of working it often gets blurry. Who does what, who works within the team and who is advising the team and so on.
I have to admit that I hate titles. I really do. I encounter people who do not exactly do what they are supposed do so they get involved with everything but do not take any responsibility with the end result. I’m not saying that this happens everywhere but the majority of project where I was involved with I encountered this behavior. For example I have worked with an Interaction Designer who locked himself up for two weeks. Didn’t talk to anyone and came up with a plan. After he left, the team found out that the plan was complete bogus. Strange that this happened and unfortunately it did cost a lot of money. People accepted it because he was the designer and designs have to be done before you can start the development. I also worked with Software architects who where involved with every decision including how the software was written and deployed. Some of them even use to write code themselves because they believed others couldn’t do it they way they planned it. And these are just two examples that show how it should not be done.
So what is the right approach? I always like to look at the exact name of the titles and compare them with how people outside of ICT fulfill their role. Lets take the Architect. What does he or she do? The architect designs the architecture. What does that mean. He or she only designs the outlines of the project. In the case of a building or bridge, only how the entire object should find it’s way to completion. Not how it looks, that is something for a designer and not how every bold and joint it applied. You don’t see an architect apply paint or build a wall. So why do they do that in software development. The same goes for an art director or designer. They should come up with how things look, not what kind of paint is applied and in what manner. So why do we accept this behavior in software development.
As I said I don’t like titles. It gives people an excuse not to get too much involved when they choose to. I often get the question which roles should be in the scrum team and which roles should work as advisor. As soon as this question emerges I know something is wrong. At that point I know that people only look at the process and their part in it and not to the objective, namely the product that has to be delivered. The development team should be in the centre of attention. Same with building a bridge where you don’t want everyone to grab hold of the hammer but you want al involved to talk an agree on the end result. A while ago I came across an article by Joe Reynolds on www.inc.com. He came up with an idea that people could make up their own titles. I really like that. So you can get names like “Java Rooky”, “Fixer of Designs” or “The guy with the outcome” and so on. It stimulates company flatness and people no longer can hide behind their role and responsibilities. It gets rid of ego and assumption. And if you don’t want to do this then simply use the titles as they are. A designer design, a developer develops and an architect is only responsible for the architecture. And to go on, the scrum masters just masters the scrum. The product owner owns the product and the coach coaches. It can be so simple.
“Drop your company’s stale ego-massaging titles, and stop taking yourself so seriously.”