Jiri’s Notepad

  Last time I gave a broad outline of the template I use to interview architects. As the interviews are now pretty much done, I thought it may be a good idea to share the approach I used.

The list is aimed primarily at enterprise architects, but with some adjustments, the approach can be used for hiring for other roles too. In any case I would discourage anyone to use it step by step. Deciding what kind of person you need is the key for any personnel selection. I can hardly imagine a situation in which I would not want some specific skills.

My experience has been that as long as you move quickly and the candidate does not ask too many questions, you can do the interview within two hours. But in the future I will probably include a bit more time as a contingency, or split the interview into two parts.

With those caveats, here is the step by step interview template.

1. Intro - business context and the role

Firstly, I give the interviewee some context to allow them to make sense of the broader context of the job, including information about the customer business, project or programme objectives and IT landscape. I explain why we are looking for someone to fill in the role.

Did they google your company and the customer? Do they understand what kind of business you and your customer are in, what products and services you are selling?

Next, I explain the content of the role: What it is about, level of seniority, key responsibilities. I give an overview of the hot topics of the day that will need sorting out and broader objectives of the assignment.

Check verbal and non-verbal signals for their level of comfort with the role. What questions are they asking: do they show the understanding of the role? Are they asking about the problems you currently facing and you did not mention in the interview?

This is the step when the carefully prepared schedule can go off the track. Because the decent candidates for the top-end architecture jobs are rather rare, the interview is as much an opportunity for you to sell the job as ask the questions.

2. Experience

At this point I normally ask the candidate to talk me through their CV starting from the most recent job, going back in time and explaining the key jobs they did. In places, I interrupt and ask about specifics of their role– what was the level of responsibility, what exactly they did, what challenges they had, what was the result?

I can probe further to get a better feel for how much experience they really have. To do that, I ask about known tricky aspects of the job. ‘Define the SOA’ question comes in here, but I can equally ask about the how they ran a requirements workshop, approach they used to mapping of the business process or what are the limitations of implementing disaster tolerance in a dual data centre setup.

Check how well they answer, whether they try to dodge by answering a different question. This is probably more important working with nearshore / offshore architects as the level of socially acceptable BS varies between countries.

In addition to this, try to get a feel for what is their natural focus: Are they more of a global or detailed level person? How flexible they are in moving between global / business and technical / detail? Do they think mostly in terms of models and abstractions, people, process or technology? (These are all meta-programmes that key for successful architects and which I check out later if I have the time).
By this point I also have a feel for how effective they are at communicating and presenting in English (if it is not their native language). If necessary, I also check how comfortable they are with writing formal documents in English.

3. Other relevant skills
Next, I ask about key areas we have not discussed so far that are critical for the role. I am looking for straight answers showing experience or at least understanding of the subject. The questions depend on the unique context of the role and can include for instance the following:

• People management: “What is important when building and managing teams?”
• Technology governance: “What is the key for getting things done in a situation where you are accountable for the outcomes but do not have a direct responsibility for managing delivery teams or suppliers?”
• Customer facing skills: “What is the difference between communicating with a customer, one’s boss and peers?”
  Sales: “What is the most important in selling technical solutions to business?”
• Relevant delivery models: “What is the difference between consulting/strategy & delivery assignments? Or, what are the merits and delivery implications of outsourcing and offshoring?”
• Formal methods: “What formal architecture (e.g. TOGAF, Zachman) or design methods (RUP, Agile) do you know / used. What are the limitations of these methods?”

If you are doing the whole interview in person, you have now been going on about an hour so it is a good time to have a coffee break.

4. Case Study
As the next step, I’d go on to a case study. Unless I am using a standard process defined by HR, I’d give them a brief, real world but anonymised, two page request for proposal. They have 10 minutes to read it, 5 minutes to ask questions and then 15 minutes to respond and the discussion.

I check the following: What questions do they ask? Where do they start? How clear is the architecture? What principles are they applying? Why aren’t they doing certain things? How do they react when a better way is suggested? How do they react when a worse way is suggested? (courtesy of SJ)

5. Passion / interests
To allow candidates relax after the cross-experience cross-examination I can ask few lighter questions. Although the questions are more or less conversational, they can help you get a feeling for whether the person works just to ‘pay the bills’ and what are his natural professional interests. (Questions again courtesy of SJ)

• “How do you keep up to date about technology?” Selection of their reading tells you a lot about how ‘switched on’ the are.
• “Do you read IT books? Which book did you found most influential?” I didn’t found that many people (even those whom I would say are more experienced than myself) who read the classics, such as the Mythical Man Month, Peopleware, Death March, so I rather ask a general question about the books.
• “Make a prediction on what technologies that are currently hyped will be big in next ten years and why”
• “Who do you think are the most influential technology companies?”

6. Cognitive, motivation and working traits

If I still have time at this point, I check the meta-programmes that are relevant to the specific role. This gives you a good feel for whether the persons working and thinking style is compatible with the job. I believe that good architects have certain meta-programmes, but beware many of them are context and role sensitive so you need to know what you are after. I ask a quick series of questions, not going into too much of a detail. I may cross-check against the thing I learnt during the CV walkthrough and case study but I don’t probe or challenge.

Most questions below are taken from these two articles, where you can also get proper names for the types of meta programmes and also explanations for ‘what does it mean’.

• “What motivates you in an assignment or project?” Is the person’s motivational energy centred on goals/achievements or on problems to be dealt with or issues to be avoided?
• “How do you know you did a good job?” Does the person assess their performance through their own internal standards/beliefs or through information/feedback from external sources?

• “Which type of work would you like more? a) Processes are set and you would be running within pretty well defined parameters or b) You need to define your job description, KPIs and scope of your work” Does the person look for alternatives or like to keep their options open or prefer to follow established procedures?
• “Your boss and head of sales/relationship manager are on the holiday and the customer calls with an urgent big problem – e.g. they need to make a significant extensions to the customer management system to accommodate the seasonal peak. What do you do?” Does the person tend to initiate or prefer to wait for others to lead?
• “When you starting a job, do you like to understand the problem at high level or go into detail? Does the person prefer to work with details or the big picture? Cross-check the response against the observations you made during the ‘tell me about your experience’ part.
• “Is the person focused on their own internal experience or on the non-verbal behaviour of others?” Observe how much attention they are paying to what you say. When you asked them earlier to talk you through their experience, did they start from the most recent job going back in time as asked?
• “Do you rather like working on your own or as part of the team? Would you be happy if you did not manage a team?” Does the person prefer working alone, with people close by or as part of a team? Is he flexible to switch between the roles?
• “What do you like in a job to find it motivating?”Is it people, systems and models, information, money, action, process or technology?

Using these questions, you can get a really good insight not only into the other’s person experience and technical skills, but also everything around that that so often determines how effective the person will be in the specific context – both within a specific assignment and beyond. Sure, you still need to use your judgment. And most certainly, there is still a risk you hire someone who turns out to be not as good as expected. But at least you will understand enough about the other person to take this as a calculated risk rather than letting yourself to be at a mercy of a pure chance.

Image courtesy of  Zach Klein.

I will soon be saying ‘I just came to tell you that I’m going’ (maybe I’ll even  try to do that in French) to my current enterprise architecture role and the great city where I’ve now spent almost two years. But before that happens, I need to hire myself a replacement.

Choosing a good person for the job is important from many angles, so it is worth getting it right. That’s why I like to read on this subject and always look for opportunities to refine my interviewing technique.

The difference between hiring employees and contractors
The main difference this time around is that I am looking for someone to work as a permanent employee, which gives the whole selection process a slightly different perspective:

• When hiring contractors, I am looking for relevant knowledge, skills and experience directly related to the job at hand. Life is too short and project cost per hour too high to be getting someone up to speed on SAP CRM functions, intricacies of ADO.NET, or developing their project management skills. My main objective is to get the work done as quickly as possible.
• On the other hand, when recruiting permanent staff, you are starting with an assumption that the person will stay around few years. During this period, there is going to be at least one generational change in the technology area of choice and the person will participate in a number diverse projects. This means that the candidate needs to have roughly matching skills, but more importantly, he or she needs to be able to learn and adapt to change.

Knowing what you are looking for
After the first round of interviews I’ve done at the end of September, I had a phone call with a lady from a recruitment agency supplying our candidates quizzing me on our criteria for short listing one person over another. After a while, I came up with something as follows:

Firstly, I rank the candidates allocating a number of points to various skills and experience categories. Obviously, the type of things you are looking for are job related and will differ between Java developer, technical manager or network architect and it is not my point to cover them here. For instance for my replacement, I allocated the points as follows:

• Up to 30 points - technical & architectureal knowledge (ten per category: application technology, infrastructure and security/continuity, focus on real world experience, extra points for knowledge of formal methods)
• 20 points - getting things done (personal effectiveness in the given context)
• 10 points - delivery experience (worked through all delivery stages from project inception to deployment and operations)
• 10 points - sales experience + consulting skills

In addition to that, I checked for few (dis)qualifiers:

• capability to adapt to change;
• systematic approach to problem solving;
• communication skills;
• personality and working traits compatible with a role.

The real trick for doing an interview is how to find all of these in below two hours. This require to know pretty well what you are looking for and use a mix of different interviewing techniques to check for only the things you are after. I now aim the interview to cover three areas: skills and experience, job compatibility, and few other general things like problem solving, flexibility and professional interests.

Skills and experience
Unless you are in show biz, it’s not a good idea to hire someone just for their personality. When hiring architects, technical and other subject matter skills do matter and that’s why they are the first thing I check. I do this normally through the ‘talk me through your CV’ approach, digging deeper into relevant responsibilities or technical skills using STAR Interview Method.

Job compatibility
When I was interviewing developers last time about two years ago, I was impressed by my co-interviewer pulling out a list of several personality-oriented questions. For a while I enjoyed using them to grill the candidates, but since then I learnt to do this sparingly as it is way too easy to make someone feeling really bad by pushing without finding too much. Sure you will probably learn how they cope under a pressure, but unless this capability is essential for the role, the chances are you are losing time in an interviewing that you can spend on more worthwhile subjects.

So rather than pressing the people with tough questions, I now prefer to quickly go with them through a list of more general questions looking at how they think, motivate themselves and at their working habits. These questions will help you confirm the candidate will be able to do the job, but also that he / she will be happy to do it, which in turn influences their staying power.

Problem solving, capability to change and professional interests
When I started preparing for my recent interviews, I reviewed and used a subset of Steve Jones’ excellent Questions I like to ask at interviews. Steve has some very good pointers that will help you find out about the candidate’s professional side that you are unlikely to understand through other ways of questioning.

Be prepared and quick

As I mentioned there are quite a few things to find out, so the key is to be really prepared and if you move through the process swiftly. I have found out that if I stay focused, such interview can be done in just about two hours.

I don’t have any statistics, but I do believe that if you listen and observe carefully, you get  a better all-round view of the candidate and can make up your mind on both his short term and longer term suitability for the job.

As a parting thought, I think it is worth approaching interviewees as if they were your friends or colleagues. Job hunting is not the one of the most pleasant life experience and the chances are it will be you sitting in the interviewee chair next time around.

One of the books I managed to read over the summer holiday was Lean Thinking. I will cover more in my future posts, but for the starter I wanted to write about the Lean Thinking approach to business change. Although this change approach was developed with the purpose of introducing ‘lean’ into manufacturing organisations, I believe its steps are generic enough for it to apply to introducing change in other contexts. Like enterprise architecture, for instance.

I have spent most of the last year introducing basic enterprise architecture disciplines for a large multi-national company. The big architecture approach with its truckloads of documentation is toast, and something that my hard-nosed and cost-conscious customers would never go for and so we had to find an alternative approach. After reading the Lean book, I was surprised how closely the steps we had taken resembled the change blueprint described by Womack & Jones.

The situation I have been in is probably not too unusual, and so it may be useful to understand what the Lean approach to change is about. Below are my notes on the steps of the lean change approach and their application to EA:

1. Find a change agent. Change agent is not the person pushing the change (I assume this will be done by yourself), but someone who will sponsor the change. Someone in a position of authority. Best people for this are CIO, CTO, IT Delivery Director for technical EA aspects; or Chief Strategy Officer/COO, if you are more into business architecture. This person needs to be fully behind what you plan to do - not only in words but also in action. If he is not willing to extend the time he has in exec board meetings and his credibility to your cause, change your scope, get ready for partial success or leave straight away.
2. Get the knowledge. Unlike Womack & Jones, I would do this as a first step. Without a knowledge of the subject matter area, you will not be able sell the concept to your sponsor in the first place and if so, he is likely to get buyer’s remorse and pull out at a later stage.
3. Seize the crisis, or create one. Find an issue that will allow to rally the support from the appropriate stakeholders or help create a customer demand that will force the change.
4. Forget grand strategy for the moment. Leave your Zachman books in the drawer and focus on resolution of the issue in a way that lays the structure for the future and that delivers apparent practical value. Prepare an outline of what you want to cover beyond this first step.
5. Map value stream. Understand your current process and its pain-points. They could be whatever – inconsistent process, major capability missing, bad or un-enforced contracts, lack of specific skills. Alternatively, you can look at portfolio of existing systems for inconsistent product standards, systems with duplicate functionality or underserved business niche for opportunities for solution-lead projects.
6. Begin ASAP with an important and visible activity. When evaluating the gaps, target areas that are simple but very visible to both people on the ground and senior folks and is relatively easy and quick to fix . Make sure the change becomes part of business as usual rather than a one-off. If you have time, do a bit of strategic planning, preparing a vision of where you ultimately want to get to and the list of possible next steps.
7. Demand immediate results. This presumes a correct choice of subject and pain-points to be fixed and ongoing support of your sponsor. Blaze through to implementation and get results quickly. The last thing you want to do is to be handling several years of implementation issues plus the opposition of people with a stake in maintaining status quo.
8. Extend scope as soon as you get momentum. Use the vision/outline strategy, refine to communicate the need for a more thorough approach to your stakeholders. If you you go for a big-bang change, hire people to help you. If you are taking contibuous improvement, look what is the next pain-point, increasing the stakes from the last time. You changes can now go as deep and as far as the goodwill you created in the previous step takes you.

So what is Lean approach to EA about? The approach is great fit for environments that are focused on cost-control and getting a hard, demonstrable value. It uses guided tactical steps that are building up a momentum towards a more strategic approach.