Need of a T-Shape Developer and an Architect


We as individuals have one thing common. And that thing is "aspiration". We all aspire to grow, be successful, command respect, be knowledgeable and so on. The same is true for an individual who is one of the cogs in the success story of many Software companies. 

The individual in the subject is an engineer. He/she could be a junior or senior or very senior engineer. And as he/she grows in the experience, expectations exponentially grows. 

An engineer who has probably worked as a Microsoft or Java or Database or UI expert is not expected to know it all. Similarly, an architect (a very senior engineer) is expected to know not only around application solutions but also should be able to converse and practice in the space of infrastructure & domains. 

Such individuals are also termed as full stack developers or architects. In this article, we refer them as T-Shape developer/architect. 

As per Wiki, the concept of T-shaped skills, or T-shaped persons is a metaphor used in job recruitment to describe the abilities of persons in the workforce. The vertical bar on the T represents the depth of related skills and expertise in a single field, whereas the horizontal bar is the ability to collaborate across disciplines with experts in other areas and to apply knowledge in areas of expertise other than one's own.

Using the same analogy, a T-shaped developer is the one who has a deep and robust understanding for a programming stack and has broad breadth exposure and knowledge of other ancillary programming stacks. 


E.g. a T-shape developer could be an individual who is an expert in Microsoft.Net (C#) and has a good grip on Angular and Database. 
Such credentials make the developer an end to end engineer who can work on all layers of the software development lifecycle. In this, e.g., the engineer has in-depth C# knowledge (represents the vertical bar of T) and has a fair or good understanding and expertise about Angular and DB. 

For an architect, however, he/she must possess not only in-depth knowledge but also to have broad technical expertise across several platforms. 

At the same time, the architect’s growth directly proportional to the number of platforms in which he/she has academic and mainly practical expertise, and also, with the number of subject areas in which he/she know oats.

While we talk about T-shape developer, the progression starts from the standard vertical bar and goes on to become T-shape to Pie-shape and eventually to an M-shape architect. 

The adjacent diagram represents a time to role graph. As time progresses, the expectations from the role also increase. 

Starting as a developer (represented by an I), the expectations from the individual increases. Apart from the depth of core programming understanding, it is now expected that the individual understands 1+ platforms and domain. And the expectations increase as the role progress. 

Following table can be used as a role to expectation mapping reference:


ShapeRoleExpectations (knows)
IDeveloper1 platform 
tLead Developer1+ platform + 1 domain
TArchitect1++ platforms, 1++ domains, Architecture Principles & Practices
nSr. Architect2+ platforms, 2+ domains, Enterprise Architecture
mPrincipal Architect3+ platforms, 3+ domains, Wide Enterprise Architecture







Share:

0 comments:

Post a Comment