Different Roles in a Full Stack Team

I don't think life is a box of chocolate. But it keeps surprising me never the less. In my case that means that I keep finding value in different activities. Such that I have not done myself or that my teams have not done very much. Maybe it could be best described as evolution.

I started as a coder. Although people didn't say it out loud (often), making modifications to 'the core' was more spectacular than making modifications to the graphical user interface. Mostly the illusion came from the siloed organizational structure. People who do something like to think they are somehow better than those 'other people' who do other things. Which is silly, of course, but still very human. :)

But anyway, I was a core developer. I worked with a big legacy core and could do magical things with it. I could create new features and implement new parts according to the details people gave me. Testing was something that was often mentioned as a valuable thing, but generally praise was given more to people who coded.

At some point I started to realize that testing is, in fact, important. My code wasn't perfect. My mind, the mind of a coder, was thinking how the system should be used. I didn't give a lot of thought to how the system wasn't supposed to be used. But many times users come up with very creative ways of doing things if the tool allows. When someone tested my code, it became better. It had less bugs. So testers were, and still are, useful.

When you work as a group or as a team it makes sense to have someone who makes sure that things happen. I don't think it needs to be a coach or Scrum Master (but it's ok too). More senior team member with right personality and skill-set can be even better.

Then lately, since Apple introduced iPhone, usability has become increasingly important. If the team has a dedicated designer, that's truly awesome. But even having usability built into the working practices is good. It's easy to get carried away with improving the algorithms and trying to write really clean code, but forget the fact that in the end someone should be able to use the system. And hopefully be able to do it without consulting a thick manual. So design and usability are important too.

Finally comes the role of architecture. It's possible to live without named architects, but I don't think it's possible to develop software with multiple teams if the architecture is neglected. Architecture might emerge, but it might not be the architecture you want to see. I dislike the idea of lifting architects to a podium or letting be live in an ivory tower. In my view architect could be a role. For the sake of clarity it would be just good that someone (even if team members take turns) will check occasionally the big picture and make sure all development efforts serve the grand plan. So I consider architects to be important too.

As a conclusion my view of different (necessary) roles in a team has changed over the years. Originally I thought only coders were needed, but now I know it takes a bigger family to grow flourishing software. And in this post I've intentionally scoped out many important business roles. Without proper Product Management and sales there probably won't be anything to develop. But let's leave something also for the future. :)