Handling Technical Interviews Part 2

In the last post  Handling Technical Interviews Part 1, we addressed recruiting challenges for technical folks, the recruiting principles, the candidate roles etc. In this post we will look at the finer and subtle aspects such as inter-personal skills, candidate enrollment, flexibility,vision, expectations of the candidates that need to be considered before making the final call.

Inter-Personal skills

While the work landscape at large is increasingly evolving into dynamic short-lived associations ( teams) that are formed and broken in internet time it is very essential that the candidate display a high sense of team work affinity. Those days of individual prowess and achievement are long over and are replaced by focused and objective teams that execute tasks and projects and dissolve soon after. Also are the other variations where there are telecommuting and remote virtual teams contributing online in diverse time zones.

These scenarios call for sharper inter-personal skills, be that of verbal, written (formal and informal mails, mobile text-ing, telephone, conferencing (audio and video-conferencing), blogs, podcasts and any other format/medium (for one to one or mass communication) and overall flexibility in taking on various roles as need be. Also, taking on challenges and overcoming them and making decisions with abstract, uncertain or lesser information  is what may be ideally desired.

So what are these interpersonal skills anyway?

At the basic level it may comprise of verbal skills, written skills, team interaction skills, leadership skills, presentation skills, team coordination skills, mentoring skills and assertion and negotiation skills , flexibility etc. Now it is fallacy to expect every candidates to be good at all the skills at the same time. Usually the lower rungs of people may have the basic written and verbal skills in place but may require more time and experience acquiring the other relatively sophisticated skill sets. So the focus of the interview will depend upon the roles for which the candidate is to be hired. However, again the scenarios of good technical skills but average to poor verbal and written communication skills (in lower rungs of roles) may be common among the local vernacular population.

The key is to understand the interaction scenarios on job and hire accordingly. For e.g. a programmer may not be in customer-facing roles in the beginning years of his career and hence may fit well in that position even though his written and verbal and customer-facing skills may not be that sharp. But the same exception is absolutely not acceptable for a business development or engagement manager or a sales role where these qualities have to be exceedingly importance than his technology skills.

Candidate, Vision and Enrollment and Compensation

This is another area that is often overlooked or ignored when the recruitments happen.

The candidate appearing for interview has a certain perception of the job as to his position, his role and responsibilities and his expected compensation. If the picture that emerges out of the interview is not what was assumed then there is a risk of credibility loss on the part of the organization that talked to him at the first place and that may be carried forward even if he or she comes on board and that is bad situation to be avoided at all costs. This is what the candidate enrollment is all about.

How do we make sure that the candidate is happy and looking-forward to the role offered along with the constraints that he feels driven against. Well, complete transparency and negotiation may be the only way out of this, because there has to be a win-win and no place for a win-loose or loose-win scenario. Often, how a candidate feels about his job (job satisfaction) has a great impact on his productivity on the job and his team interaction pattern and his general effectiveness. So ideally there should be no place for compromise on this matter. Though compensation is an HR area and architects should not venture into it as a general rule, it is still the most sensitive issue where parity is necessary among the peers so that people respect each other and feel respected.

People gotten aboard at substantially lower packages taking advantage of recessionary job climate will seldom hang around and will be the first ones to dump these organizations at a small chance! So the theories of talent-management, career management and long list of xxxxx- managements developed by the in house HR gurus may fall flat if this ethic is violated knowingly or unknowingly.

Finally having said that all, still many a time you may feel stumped when a promising candidate hired much eagerly with lot of expectations may turn out to be a dead beat!

So good luck with your hiring!

P.S. I have changed the title of this topic posts from ” The Architect as a Technical Recruiter” to “Handling Technical Interviews” because  I realized that the word ‘recruiter’ was a little ‘out of spirit’ for the Architect and his daily job profile.

 

Handling Technical Interviews Part 1

Well that title may sound a little out of place at first read but Architects are all time interviewing and selecting people for their organizations and projects. Now what is the difference between a HR recruiter and an Architect selecting people? Well there is a hell of a difference! While the HR guy might focus on soft skills, attitude and general likeability and cost-to-company factors of the person being interviewed, the architect has a different stick for measuring the worth of the candidate. This is the context of this blog and will be expanded further.

Recruiting Challenges

The job market is more volatile and in flux than ever and there is a serious shortage of skilled IT resources world over. Really good people with matching skill sets that required for projects are difficult to find and the whole process is time consuming and error prone. Hundreds of recruiters or head hunters are on constant lookout for anybody that even remotely matches the skill set requirements. Even though a die-hard recruiter may get some people on board, there is no guarantee that the person will hang around long enough. There is always another employer showing him the better carrot! It is simple driven by the demand-supply equations in the marketplace. This often results in compromises on the candidate quality and ultimately the quality of the projects being delivered on the IT scenarios.

Architect as a Technical Recruiter.

Most often in many organizations the technical interview rounds are conducted by Architects or technical project managers and by technical leads in reverse order. The idea is to filter out the most unlikely candidate before he reaches the technical leaders and saves their valuable time.

The Interview Principles

A well prepared candidate shows focus, confidence and smooth interaction with the absence of doodling and verbal mitigation. Similarly a well prepared and organized architect shows equal poise, finesse and composure conducting the interview without appearing jerky, rude or condescending to the candidate. Both the candidate and the architect should finish the process with good afterthoughts.

Technical Roles, Positions, Designations and Responsibilities

Every architect should be clear about the role or position for which he is recruiting. This is absolutely important since it is very easy to get carried away and ask the wrong questions to the candidate who might be stumped with nervousness and may give the wrong picture at the end. Below   are some of the roles that may needed to be performed.

• Developer/Sr Developer
• Technical Lead
• Project Lead
• Business Domain Analyst/Expert
• Application Architect
• Technical Architect
• Enterprise Architect

The lower rungs of the roles/positions  (Developer through Enterprise Architect) calls for a more focused technology specific knowledge and expertise ranging from individual focused skill set to team mentoring, leadership and evangelistic skills that are applicable across domains of technologies, platforms and industries.

The Phone Filter

One of the valuable approaches in initiating the interview is the simple phone call. Call up the candidate to know the overall picture at a summarized level. With the phone call you get to know the candidate’s verbal and interaction skills, his thought process, general outlook  and the overall suitability. That way you save lot of time and effort and money by filtering the unsuitable candidates right away.

Described below is a general approach in selecting candidates that is built upon my experience hiring candidates for all the positions mentioned above.

Candidate Functional Analysis

Let us focus on the candidate’s general skill types. Overall a candidate may match a purely technical , purely managerial or a techno managerial function. Further he or she may be a research and development oriented, academic, operational (project delivery oriented who simply thrives on deadlines and pressures).

Candidate Credibility Analysis

While it is nearly impossible to judge a candidate in the usually short time of the interview process, still an attempt can be made to ascertain the credibility factors.

Foremost in this effort would be the competence. The candidate has to prove his competence through the answers for the questions posed to him or her. The quality of the answers, often give the clue to the content (knowledge or expertise) whether it is hallow or solid. Sometimes the correctness of the answer may not be that significant compared to the approach.  For e.g. Knowing by easy recall some obscure method of an equally obscure class deep in the API of a programming language may not signify an expertise but a particular approach to solve a problem might reflect competence, maturity and experience. The main aspect here is the competence and the ability to get things done in the presence of usual organizational hurdles. This angle  is greatly elaborated in the equally great book “Smart and Gets Things Done” by Joel Spolsky. Joel also goes on to say that particularly for programmers the difference in productivity for great to very good programmers is usually 10 times! And that’s a pretty huge difference! Now in this regard the advice here is that if you even get a slightest doubt about a candidate’s competence you are much safer rejecting him outright for your and his own good! There are no “Ok” candidates!. Either they have to be Grrrrreat  or they are bad!!!!! That has been my experience.

Secondly it is the character aspect. Character signifies honesty and in-your-face simplicity and attitude that is real and that comes forth naturally to him or her when you talk to a candidate. There is no dual sense. no beating around the bush and no playing games.

Thirdly it is composure aspect. How the candidate is mentally, emotionally composed in handling abrupt and unpredictable influences and events that affect to his overall psyche and personae. Candidates that display high composure are usually easy going, cool tempered and rational and are likely to handle themselves well in any eventuality instead of creating a scene or a mess.

Next on the list is the High-energy. Candidates who repeatedly are achievers, high-performers are seldom 9 to 5 employees who mind only office or home one at a time at a give time. They are often people with chaos around except that the constant chaos results in a positive outcome each time every time. They often display leadership and a certain self max-ing that energizes the team around them to perform and achieve.

The last but not the least is likeability. How an employee is liked and accepted by his peers, subordinates, superiors is often the significant factor in that employee’s appraisal and growth.

In the next post we will look at the inter-personal aspects, candidate enrollment, vision, expectations and other aspects that are significant in the process of technical recruitment.

The Architect as a Solutionist Part 2

Further now let us look at the following aspects

Effort Estimates and Financials
Effort estimation with acceptable accuracy used to be a fine art till recently. However recent advances in tools and SOA methodologies have significantly lowered the overall efforts in general and have raised the bar for accuracy in estimation. There are various approaches and estimation methodologies such as those based on work-breakdown-structure, function-point and use cases. Often estimates are done based on two or more approaches and with different estimators and the figures compared for divergence and confidence. This is an area on which most of the clients/customers focus minutely to understand  the basis of estimation and this often influences the customer a lot in awarding the projects to vendors. Your finance depart may already have a set of standard rates and billing/invoicing processes in place that you need to understand and collaborate with them effectively if that role is executed by you. If some else is doing that in your team you need to collaborate and ascertain the figures for efforts, expected scope creep, other contingencies and weight ages added to the final set of effort and cost figures.

Project Management and Execution time lines plan
This is another crucial area which represents your organization’s proposal and capability and operational ability to execute the project in question. It also reflects your organization’s experience in executing the project. It should at least contain the overall SDLC plan and the time lines, the resources loading plan, the skill sets/roles, the development methodology, the testing approach, the integration testing plan (if relevant), the risk management approach, the Issue tracking and Resolution model and the tools to be utilized, the attrition management plan including buffer resources (if specifically asked for) disaster recovery model etc. Sometimes due to the deadline pressures entire sections of Project Management Methodology content are copied and pasted into another one which is an embarrassing situation to get into if it finds the way into the final document! Each project may have some unique aspects that need to addressed. This information should be used to customize your Project Management Methodology and plan for the project.

Conference Calls
Often there may be some gray areas in the requirements provided by customers that need further elaboration or confirmation or direction. Conference calls are usually arranged with customers to understand the basis of the inputs, perspective, and enhanced clarity of the requirements.

Organized conference call often need to have the following roles.

1.  Facilitator
There needs to be a facilitator for the call whose job is to ensure that the right set of questions are asked by the right set of folks and the acceptable answers are obtained.

2. Key Participants

For the conference calls the key participants need to identified and invited in advance so that the purpose of the call is not diluted. If the call is about technical aspects of the project, the architect(s), the technical leads may need to be present.

3. Silent Listeners and Loggers

These folks may not interact in the call but  may be needed depending upon the context to document the agenda, discussion points, action items and view points. There job is also to document the same and send it to attendees on the mail so that everyone is on the same page. Also from the solution perspective the open questions/issues if any are tracked and logs maintained from day one since this can provide valuable information going forward or tracing back anytime in future in the event of disputes and facilitate non-repudiation.

The quality of the conference calls needs to be better than the quantity. Scenarios of the entire project teams of offshore folks on a daily calls late into the night offshore-time with questionable exchange of information with customers/peers on site useful to the project are quite common and recurring. You as an architect can lead/supervise the activity and enforce quality interaction with fewer scheduled calls! Instead of insisting a call daily till the deadline, you can have a documents such as issues tracker, questions-answer sheets and other that may be needed that shuttle between on site and offshore daily. That way it is transparent and daily logged for progress tracking. Dealing with customer directly may require prudence  and practical intelligence so that it is a win-win strategy for both the parties.

Proposal Document
The proposal document itself is the significant reflection of what your organization endeavors to develop/build at what costs and what time lines. As discussed earlier that content often has to be produced in collaboration with many folks in the organization including pre-sales ( the guys who can communicate the customer’s pulse on this project), the development organization directors, senior managers, project managers, technical architects, tech leads, the finance folks, the technical writers, document formatters , visual artists that work on the diagrams/images on tools like Photoshop/Coreldraw, the document printing and binding and dispatching folks etc.

As an architect get to know what are the roles that are being taken upon and what are the roles that you have to take up additionally. This will ensure and prevent last minute surprises and expectation mismatches. The tools used to produce the document also play a significant part in provide elegance and professional touch to the end document. Tools also allow to richly format the document, embed other documents , easy navigation and printing and viewing options. So make sure you have good tools that  can give your work the edge.

Follow-up and Post-Proposal Learning

The final proposal document once it is sent out is usually the property of the customer and cannot be changed. So post the activity of dispatching the proposal there is usually some time before the results come in. There is a need to learn and document from every proposal even though you may have won it and more so if you have lost the opportunity to the competition. However this activity is seldom given its due importance by the proposal teams. There is need to identify as to what went wrong or what could have been enhanced or what was missing. Scenarios of proposal teams hectically working on the proposal for like two months, only to know that they didn’t qualify the basic selection criteria, are quite common and happen all the time.

“If you commit a mistake, learn from it! If you commit the same mistake again you have failed to learn or else you are a fool!”

This principle is handy here to be remembered and followed.

So the information clarity, flow , sharing are of paramount importance here. Often this process is adhoc in many organizations and streamlining the same will help you avoid many mistakes and win business for your organization.

The Architect as a Solutionist Part 1

Many a architect one time  or another have solutioned an architecture  for customers for their unique requirements. It all starts with an RFP formal or informal, from their customer stating a plan that may be completely new foray into some line of business or an enhancement to an existing IT application(s). In a typical customer-vendor model the request percolates from the top relationship management folks at the vendor camp to the executive brains often the project managers and the IT architect(s). Often an architect is assigned and takes over the technical ownership of the solutioning process. In this post we will see as an architect what it takes for a typical seasoned architect to achieve success solutioning the typical proposal.

Solution Stakeholders
As a solution architect this is the first area you need to align yourself. You need to find out the relationship folks, sales folks, the top managers on the organizational side and on the customer side who are involved in the project You also need to understand the stakeholder mindsets, expectations the context and the ground realities under which the proposal is being invited. You may rely on an information seeking mail or tele-calls targeted to the stakeholders one-on-one or otherwise. This info will help you understand and appreciate the scope of your engagement and contribution and also set expectations correctly.

Proposal  Format and Content Scope
As mentioned before most of the proposals start with an RFQ or an RFP being floated with one or more vendors inviting a solution. Sometimes the information sought is enforced via a standard template or simply through a set of questions that need to be answered. Sometimes the customers even go to the length of limiting the words in the answers/responses! In the absence of such a template vendors use their own templates that seek to cover all the most important aspects of their solutions. As an architect your first step would be to get to know what is the format and overall content that may go in the proposal. Sometimes if the proposal is targeted at a new relationship it might contain a large treatise of the standard organizational sales pitch.

Knowledge areas and Ownership.
Typically a proposal/solution calls for knowledge and representation for various areas like technology, finance, experience in project execution and SDLC management, estimation, communication and interaction skills etc. And typically there will be a team of people on the proposal with different skill sets. As an architect get to know what exactly are you to contribute and what are the time lines for the same.

Solution Approach and Clarity

The most important technical part of the solution is the technical solution. This will be typically evaluated by the customer technical folks to ascertain the correctness, feasibility, viability and requirements traceability. As an architect you have to draw upon your best and put the most appealing solution. Many times there may be more than one solutions to the problem. Sometimes the customer may insist on you putting one and one only solution! Anyway, decide on your unique context and base your response on that. If you are proposing more than one solution be sure to elaborate on the alternative solutions with their pros and cons. Also make sure it also reflects in your project execution estimates, risks, time lines  and financials. From a customer evaluation perspective some of the most important things may be clarity of the solution, re-use or leverage of existing assets to drive down the costs and complexity and efforts, risks identification and mitigation strategies, financials and execution  methodologies and the comfort level with a particular vendor. Some customers may come from a Six Sigma background and may insist on process clarity end-to-end. These facts need to be addressed in the solution.

Also be sure to emphasize on the innovative aspects of your proposal if any. Innovation can be technology, process based or business domain based that will impact the project significantly and customer can sway in your direction. Often the most important aspect of your solutions may be the ‘Requirements Traceability’ that customers often look at when evaluating the correctness and virtue of a solution along with other factors. Make sure you walk-through the solutions with requirements in your hands and construct direct traceability matrix with whatever template suiting your organization or that of the customers.

In the next part we will see the other facets such as Project Management and Execution,Customer Conference Calls
Proposal Document Development etc

The Innovative Architect – Part 1

Last year I heard a story of a small time vendor who sold snacks at a roadside eating joint. He was illiterate so he couldn’t read newspapers.He had a hard time hearing so could follow the media. However, he was innovative in his business. He packaged his product specially for his customers in attractive plates and gave away the add-ons like chutney and sauces free for multiple helpings.He had a thriving volume business helped by daily office-goers who liked what he sold at that price only till his MBA son who came back from abroad saw what his dad was doing. His first reaction was ‘Why waste money on these frills?’ You know the recession has hit the world! Stop this waste and let us be prudent! His dad followed his tips only to loose customers in the long run went bankrupt! Moral of the story is “Get a scarcity mindset instead of an abundance mindset, stop innovating, be a follower and you will be dead soon!”

Innovation has different meaning to different people based on their experience and mindset. For some it is process improvement that saves millions. For some it is novel architectural strategy or a quick re-engineering of a business process or a product that significantly raises the market penetration or margins. Yet for some it is often associated with thought-leadership and the direct product resultant of that activity. However for most of us: the practicing Architects, innovation can be a sense of novelty expressed in an idea, a product, a process or a technique that is somehow better than the existing, in terms of value proposition. Most of the architects would want to be innovative and thought-leaders in their work life. This blog attempts to help establish a mindset, a perspective on the opportunities the architect might be presented to be innovative and a thought leader and help his or her career and value-proposition. So the question is where to make a beginning if you have not already made one.

The jungle for this game is quite diverse and treacherous. Treading a careful calculated path might save you and you may have limited number of lives when you want to play. Following text attempts to give you hints, clues on your path.

OK, the first action may be your “Environment Analysis”.

Ask yourself these questions and try to get answers as much as possible. Obviously your answers may be unique to your circumstances and subject to your contextual interpretation.

(Please note that you may have less or more relevant questions based on your unique context)

1. What is the organization context I am working with? ( Business Vision and Mission, Business Domain, LOB, Enterprise, IT Architecture Platform, short-term and long-term organizational goals etc)
2. What are my competencies that are being most effectively harnessed on my job by my employer? ( Product/Platform Knowledge & experience, technical consulting experience , proposal solutioning experience, mentoring junior architects, SDLC process experience, Enterprise strategy and evangelic experience and skills sets, team building and operational management skills etc)
3. What are the technical or techno-business IT issues facing the organization? Are they majorly because of IT or one or more business processes that still has scope for optimization? ( Re-engineering, right-sizing, downsizing, phasing-out/sun setting,merger, Business Partner/Third-party integration etc)
4. Is a scorecard approach ( Architecture, business ) appropriate and useful in this context?
5. How much of Automation is used for processes with the current context? ( software tools for modeling, dashboard SLA reporting, operational analytics, business intelligence, data mining, open-source or home-grown frameworks for problem analysis, development, testing, deployment monitoring etc)
6. What is the level of rigor for Quality and Process and how are they measured and what is their imp[act on the ultimate deliverables for me and my team?

Armed with answers to the above you may be in a better position to know and appreciate your environment.

In the next post we will look at using the uncovered answers to strike an innovation strategy that is unique as your signature that will contribute towards your effort in becoming an innovative architect.

What IT Architects Really do on their Job?

When I was a college grad, I had read a all time great book titled “The Fountain Head” by the influential American philosopher -Ayn Rand. It depicted a guy who wanted to be an building architect I mean a civil architect. It described him as an unconventional experimental and maverick who swims against the currents all the time, got beaten ( not in the physical sense) by a bunch of thug architects who did nothing more than copying ( cutting-pasting in modern sense) and re-furbishing the conventional creations and living a high-flying glamorous yet hollow existence. I thought the original architects to be highly creative , independent, assertive and having the X-factor who had a passion to create newer marvels, landmarks and their thoughts in 3D overcoming all the constraints !

I thought the same of IT architects too. But over the practical years that impression has been toned down! Many a times I see an IT architecture a compromise of the enterprise assets, financial constraints and a committee vision which may not be necessarily be best for the organization in the long of the short term whatever your perspective. I remember someone has said

“Taj Mahal would not have been built if the emperor had asked for quotations and gone for the lowest!”

Having said that it still takes a lot of jugglery for the chief architect (or the architect team) to really balance the fighting hordes of opposing camps of agendas and to arrive at a picture that is liked by all (especially the CXOs!) Add to that a continuous change of technologies and possibilities and the economy lately! You can see that the job is not really easy!

In the next post I will address the various facets and caps the architect might have to wear to make a meaningful unit of work before calling the day-off on the job!

Architecture as I am seeing it!

Hello everyone!

Welcome to my debut post on IT Architecture!

This is the first post of the my technical blog on IT Architecture based on my perspective and exposure!

Wishing you all an informative, unbiased, thought-provoking and interesting reading!

I can be reached at manisharch2008@rediffmail.com for any questions suggestions that you may have!

Thanks again!