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
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.
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
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
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.