It’s been an exciting job building a Microsoft Technology Center from the scratch – all right almost from scratch. The most important job of creating and selling the business value prop behind setting up a MTC is done by my boss – Sheila Gulati. From that point, I was tasked with setting up the MTC in Bangalore and this includes logistics, hiring, marketing (internal as well as external), partner management, lab set up and budget management – basically the whole nine yards of setting up and running a business. Given that I have been a techie all along, it’s been a wonderful experience for me to learn about business side of things and needless to say, I am learning a lot these days.

 

Let’s talk about hiring for a moment. I have to hire a set of technology architects and a bunch of contractors for managing logistics part of MTC. Needless to say, hiring right technology architects is essential to survival. Basically, the technology architects in MTC Bangalore should own a particular practice – a practice could be Connected Systems, BI, SQL, Collaborative solutions, Infrastructure Optimization, High performance computing etc. Owning a practice means the following things

 

-         Ability to map customer business problems and pain points to technical solutions. TA is not expected to be a domain expert and it is expected that Account Manager and field folks who are associated with that particular opportunity has to help our TA to understand business context. But, TA should be able to take the business problem and map it to MS technology/solution platform.

 

-         Ability to design a solution (widely called as solution architecture) using Microsoft Platform. Oh, by the way, when I say Solution Architecture, I don’t just mean the routine ceremonial, hand-waving high level visio/UML type architecture, but the low level design that includes how exactly the solution be built with MS with focus on performance, security and extensibility.

 

-         TA is considered the GOD of the practice. She is expected to be omniscient about the technology area that belongs to her practice that she owns. For example, if you are a TA for HPC, you are expected to know anything and everything about Beowulf cluster, MPI programming, HPC management, RIS etc. Customers expect you to know everything; we expect you to know everything about the area that you own.

 

-         Needless to say, TA should have great communication skills and more importantly, great listening skills.

 

So, you can say it is all about technology depth, great design skills, great communication skills and customer empathy – and oh yes, little bit of experience is required (minimum 10 years).

 

With this idea, I set about to hire technology architects for MTC. The experience has been illuminating.

 

 

Architect…Who

We did receive whole bunch of resumes. The resumes roughly fall under following categories.

 

A)    Project manager. Typically has been handling a mid-large sized team (25-100). The resume is all about how he/she built a practice, enabled his/her reports to do whatever they are set out to do..blah blah. They don’t have any hands-on experience of late (that means 2-5 years). Majority of the resumes belong to this category. These ends up being paper rejects because of wrong fit.

 

B)     Developers with a difference – and the difference being that they have been developing similar apps for 10 years. They typically build in-house apps for IT dept for large customers for quite sometime. Typically (not always), they wouldn’t have designed large scale apps and hence doesn’t know some of the fundamentals related to scalability, transactions (yes sir, it is true), basic algorithms etc. Their title is architect, simply because of their experience. Most of them are paper rejects because of lack of designing large scale apps, some of them get rejected in the first round after stumbling upon cursive questions on transactions and scalability.

 

C)    Individual contributors – These people have been designing and developing large scale apps for quite sometime. They like being individual contributors (good fit) and they want to remain technical (good fit). In this case, people with good communication and consulting skills (apart from technical skills) proceed to next round. We’ve had some success here. But, unfortunately, we don’t get a lot of these.

 

Here is an interesting statistics about the source of resumes. Usually, type A and type B come from System Integrators and Customer IS departments. Type C typically comes from ISVs and some SIs. So, you may wonder why we are getting type A (project management folks) when it is very clear what we want is some one with deep technical, hands-on and consulting skills. The problem is because of the nebulous definition of the word ‘Architect’ in the context of IT industry.  

 

Let’s look at the definition of an Architect from the following sites

http://www.bredemeyer.com/pdf_files/role.pdf

http://www.agilearchitect.org/agile/role.htm

http://www.artima.com/intv/architect.html

http://www.certmag.com/articles/templates/CM_gen_Article_template.asp?articleid=1406&zoneid=225

 

If you look at the definition of ‘Solution Architect’ in many of these sites, they go beyond the role of solution architect (i.e., to build a solution architecture) and cross over into many of the project management functions (like political handling (for god’s sake how is this part of architect’s job. Actually every role has some politics associated with it. What’s new here), little bit of project management like managing budget, ROI calculation etc). The agile folks seem to have a much more pragmatic view of Solution architects as opposed to others. I think the problem seems to be more like the confusion of different roles such as architects, project management, portfolio management etc. It is entirely possible a single person may be doing all the roles, but it is important to cleave them apart.

 

And I am not sure why we take these definitions as god’s gospel. Where are the proof points that this model has worked? Given that overwhelming of the software projects are failure (http://www.agilefactor.com/stats.aspx), what you have, in fact, is the counter-proofs that these models never worked. I personally feel closer to agile approach.

 

There is an interesting aside. In India, most of the IT population works for system integrators. In the Indian Sis, it is (at least it used to be) very difficult for a techie to have a career as software engineer. This is not because the SIs don’t want to promote individual contributor role with technical focus, but because of the ‘time and material’ business model they all follow. In this model, ROI of a ‘resource’ is directly proportional to how much they can be billed in a specific time. If you remain as an engineer for quite sometime, the ROI (of you) will be diminished over time as your pay increases over time, while your billable amount remain constant (or near constant). I guess this is changing now as the customers also recognize the word ‘architect’ and willing to pay a little bit more. Also, there are few companies in Pune that truly value Software engineers and have built career plan for them as individual contributor role.

 

In the next blog entry, I will talk about architects in Microsoft and how different they are from the architects as understood by outside world.

 

PS: These are all my personal opinions based on my observations and it doesn't reflect my employer's view point.