Understanding Role Specifications

Over the years there has been lots of discussions to clear up the confusion around various roles in IT and Software environment. A typical discussion revolved around the question: "Are you looking for an Architect or are you looking for a developer?"

In one such discussion we spent over an hour exchanging various viewpoints and I promised to consolidate some few points in a blog.

1.       Roles are not synonymous to persons. While a person can execute multiple roles, it should be clear what is being specified. An individual may execute the roles of software/IT programmer, engineer, developer, full-stack developer, designer and architect. In the industry you may hear or read of "Generalising Specialists" or "Specialising Generalists".

2.       There are some fine boundaries between roles. The finesse of the boundaries may not be clear to a novice, but with a developed expertise, these boundaries become clearer. For example, writing a computer programme (i.e. Expressing some instructions in a programming language, which is essential to the role of a programmer) has a fine boundary to engineering the sequence in which a set of instructions should be executed by a software (i.e. the essentials of software engineering). In a similar fine thinking, engineering a software has a fine boundary to describing the multiple facets of the software before or after implementation (i.e. the essentials of architecting a software).

3.       Specified roles are good indicators revealing some insights to the collaborative environment. For example, when the specified role gets engineering and architecting mixed up, then you should watch out for an environment where "Generalising Specialists" or "Specialising Generalists" are being solicited.