Heather McLean

Interviewing for a new position is frequently a stressful and frustrating activity for everyone involved. Interviewees get nervous since they know everything is on the line in this one meeting, and more than one really good candidate was passed up because they didn’t interview well. Interviewers get frustrated because it can be difficult to cover all the necessary bases in an interview, and it’s also hard to tell between a good candidate and someone who’s just good at interviewing. It’s also difficult to standardize the interview process, since everyone who comes in to the interview has a different idea of what makes a good candidate and will confuse the interviewee with a fire hose of disjointed questions.

In my mind, interviews really should be that last checkpoint, something you do when you’ve already decided this person is a good candidate, but you just want to make sure they’re a real, live person and can fit in with the team’s personalities and the company’s culture. There are so many things you can do before the person walks in the door to make sure they’re the right person on the job.

• Make the most of your phone screening process. Unless you have highly technical recruiters, don’t rely on HR to do the phone screens. Have someone from the team take 15 minutes to talk to the person and do basically a “pop quiz.” Don’t ad hoc it; have the team agree on a standard set of questions to ask. Also, take this time to find out what the candidate is looking for in a new position, and be honest about your company and team. It does no one any good to bring someone in for an interview when you can tell long beforehand that the position is not for them.
• Rely heavily on referrals, but not too heavily. One of your best pools of potential candidates comes from existing team members. A statement of support saying, “I’ve worked with this person before and would work with them again,” should tell you all you need to know. At the same time, be mindful that some folks are trying to do their friends a favor or just want the referral bonus, so don’t allow referrals to trump your whole process.
• External references are all but useless. Really. I don’t even check them anymore. Candidates are going to cherry-pick references that they know are going to speak well of them, so there’s really no reason to waste the time making phone calls.
• Demand samples. Any potential team member should be able to provide samples of work. It doesn’t have to be from a previous job (those are typically locked under NDAs anyways), but contributions to open source/community projects, pet projects, or even just mental exercises are good. Developers can provide code, QAs can provide test cases and automated test scripts, and BAs can provide fully developed use cases and acceptance criteria. Really, anyone can put together a basic portfolio.

These tips will get you a lot farther than an interview alone. Additionally, here are some tips for the interview itself.

• Use multiple, small groups. Don’t let everything rest on one interview. Doing two or three interviews in an afternoon with different groups of people can help get a better picture of the candidate. Also, there may be interviewers in the different groups that the interviewee responds to better than others. Also, keep the interviewers down to groups of about three. This will keep the interview focused and less intimidating to the candidate.
• Plan ahead of time. There should be an agreement beforehand between the interviewers on what topics will be covered and even what questions will be asked. By no means does this mean using a script, but it helps keep the interview from being too spontaneous, and it standardizes the experience for interviewees.
• Don’t get too technical. That’s what your phone screen was for. By the time the candidate gets to the interview, you should already know that they can do some coding in C# or write test scripts in QTP. Good interview questions should relate to problem solving, teamwork, and personal achievements. On the flip side, this is a good time to have them do some technical demonstrations for you that aren’t as easy over the phone, such as whiteboard coding or stepping through a complex use case.
• Take them to lunch. Or dinner, or cocktails–whatever ends up working best with the schedule. In the grand scheme of acquiring new talent, the cost is negligible, and these sort of social situations will typically alleviate some of the interviewee’s stress and anxiety.

In my new environment, we’re growing so fast that space is becoming an issue very quickly. We now have resources spread between two offices in different cities (luckily within 10 minutes of each other, though). We’re also considering our options on hiring some coding facilities in Canada or elsewhere for support work, though we have no plans for overseas yet. Due to space constraints, we have also talked about letting folks work from home part of the time.

Still, in a fully agile environment this poses some difficult challenges. The agile culture has emphasized team co-location and face-to-face interactions heavily as a best practice, but obviously in this scenario that’s not likely to be possible. This disrupts team interaction, project visibility, and a variety of other positive aspects of the agile methodology.

There is a never-ending plethora of tips for distributed agile teams, but obviously there is no one-size-fits-all solution. I’ve been brainstorming for a while, and over the next couple of weeks I’m going to try and prepare some solution proposals for the executives here. I’ll let you know what I discover.

If you have any suggestions of your own, feel free to share them.

A post from Adam Martin inspired today’s deep thought. In his post, he refers to a form of product management strategy (or rather, anti-strategy) known as “pure, blind, Hope.” I’ve also heard this espoused more romantically as the “if you build it, they will come” approach, though that generally applies to an earlier point in the product lifecycle. It’s a form of hubris that appears frequently at executive-level product management, though people at all levels can be guilty of it.

Generally what happens is that someone comes up with the “killer product idea,” and then pitches it with lots of pizazz and hooplah (typically accompanied by flashy PowerPoint slides) that show how awesome it is and how people are just dying to use it… without actually doing any hard research or formulating an actual plan. They convince the people holding the purse strings to fork over unthinkable sums of money to bring the project to market. Even if it doesn’t flop outright, the lack of vision will eventually sent it into a death spiral, and all the while management will continue to shovel money into the sinking ship in the hopes that a miracle will occur. It’s a bizarre form of product management that I’ve never quite understood even though I see it all the time. To a degree, it contributes to a “muck flinging” approach as well: management will continue to throw products at the wall until one of them sticks.

All of this could be avoided with an actual strategy for building and sustaining the product. Unfortunately, that does require the expenditure of brainpower and legwork to do some research. Important things to know before you ever begin are:

• What is the product’s purpose? Why are we doing this? (“Because it’s cool” can sometimes be a valid answer, but it shouldn’t be the only one.)
• Who is going to use this product? How can we excite them about it and target those potential users specifically without necessarily spending gobs of money to blanket the market with advertising?
• How do we make money off the product at launch? Or, how do we position ourselves to turn a profit later (without relying on additional infusions of capital, preferably)?
• What happens after launch? Where is the product headed in 1 year? 5 years? 10 years?

If those in charge of product development would sit down and answer these basic questions about their products instead of focusing on glitz and glamor, it would go far to stop the habit of dumping money into something that will only wilt and die. Even then, the strategy you came up with at the beginning may not be applicable later; I recommend re-answering these questions from scratch periodically so that you can adjust as needed.

I was recently re-reading Martin Fowler’s article The New Methodology when I came across a passage that stuck with me:

One of the aims of traditional methodologies is to develop a process where the people involved are replaceable parts. With such a process you can treat people as resources who are available in various types. You have an analyst, some coders, some testers, a manager. The individuals aren’t so important, only the roles are important. That way if you plan a project it doesn’t matter which analyst and which testers you get, just that you know how many you have so you know how the number of resources affects your plan.

But this raises a key question: are the people involved in software development replaceable parts? One of the key features of agile methods is that they reject this assumption.

One of my biggest pet peeves is when managers and planners refer to people as “resources.” I get this visual of a bunch of managers sitting around a table and trading little chits that represent people until everyone is happy with what they have, but all the chits are the same… just commodities to be pushed around from project to project.

When you treat people as interchangeable cogs in a machine, you miss several important factors about your team members:

• People are not equivalent pieces. I refer you of course to the ever-popular book The Mythical Man-Month by Frederick Brooks. If I have estimated¹ that two people can do the work in six months, increasing that to four people does not mean that we will get it done in three months. Team members all have differing levels of expertise and productivity, differing skills and motivations; you must know how to leverage these individual talents rather than lumping them together as a whole.
• People bring the greatest benefits and the biggest hindrances to the project. When you reduce them to a column on a spreadsheet, you are naïvely discounting their individual personalities and quirks. People can have breakthroughs that cut development time in half. They can also have a family emergency and lose you a week of production.²
• People are perceptive. They know when they’re being treated as faceless automatons rather than real human beings, and they will resent you for it. Don’t ever believe that your team members aren’t keenly aware of how you talk about them behind closed doors.
• People have preferences and motivations. Assigning people to tasks that they may be good at but hate is counter-intuitive. Yes, Bob may be a database whiz, but if he hates the reporting engine, assigning him to fixing the reports isn’t going to be the best utilization. Assign people to tasks that they enjoy, even if it’s not their strong suit; they’ll be more productive and learn a broader range of skills. Conversely, don’t let people pigeon hole themselves—ask them to branch out every once in a while and leave their comfort zones.
• People have lives beyond work. Don’t plan for people to have 100% attendance. Don’t even plan for them to work 40 hours per week. As I mentioned above, people are perceptive, and if they feel you are treating their personal lives as secondary to work, they will resent you for it, and morale and productivity will plummet.

I’d like to take a moment to talk about a style of management I call the “just deal with it” approach. It’s an all-too-common situation that happens in highly structured organizations, and the really sad part is that it is self-defeating for the people who are perpetrating it. The scenario plays out something like this:

1. Executive Management sets goals for the month, quarter, year, whichever and communicates them to Vice Executive Management.
2. Vice Executive Management wraps those goals up with additional goals of their own and communicates them to Management.
3. Management now has goals that it had no say in developing but must somehow meet with the resources/time at hand. Those goals are communicated to Implementation.
4. Implementation (developers, business analysts, quality assurance, etc.) receive a set of goals that seemingly come out of nowhere and have no relationship to the reality of what they will have to implement.

Do you see the fatal pattern here? Communication and goal-setting goes one way… from the top down. It’s a “trickle-down” form of setting commitments. This results in a multitude of consequences:

• Management and Implementation are frustrated by the lack of involvement in setting their own commitments and deadlines.
• Execute and Vice Executive Management are frustrated by deadlines that constantly slip or bring less-than-promised deliveries.
• The only motivation for Management and Implementation to meet goals is to avoid pressure from the higher levels.
• Implementation has two choices: miss deadlines/under-deliver or burn out trying to “crunch.”
• No one feels like communicating with each other because everyone sees everyone else as “the problem.” This is often the part where the sentiment of “just deal with it” crops up, as everyone from the top down is expected to deal with what rolled downhill rather than fix the problem.

It’s a cyclical beast; as soon as one set of goals are missed, a new set is sent down the pipes. The upper levels take a fire-and-forget approach, and then they are left wondering why that approach didn’t work. If you tell a subordinate to do something, they should just do it, right? I don’t mean to be overly critical of upper management, but keep in mind that this is a post about management techniques; I’m going to pick on those who earned it. To be fair, however, this doesn’t happen because the goal-setters are inhuman monsters who want to drive their subordinates to madness (well, I would hope, at least). It happens because there is a fundamental misunderstanding of how to properly set company- and department-wide goals, especially with regards to product development.

The most important thing to remember is that the goals you are setting are not just your goals. Mr. CIO is not the only one who will work on them, so he should not be the only one who determines what they are and when they will be delivered. I’m not advocating that you include junior developers in board meetings, but it is important that the lower levels of management and the implementers are involved at some point in the process. Go to your subordinates and say, “Hey, this is what I want to accomplish. How do we do that and how long do you think it’ll take?” This will build goodwill and will also open your eyes to a whole new level of complexities that you may not have seen before.

Most upper management takes the first step, presenting the goals for evaluation to their direct reports. This is good, but at some point you have to reach the lowest levels. The people at the bottom are the ones who will be building your products, so they are the most likely to know all the intricacies of making your goals happen. You may not realize at surface analysis that adding a single button to an extant dialog is actually 3 weeks of work instead of 3 days because of mitigating circumstances and quirks of the platform. To be fair, it’s not your job to know those things; thus, you need your product teams to help you out.

Also, if your implementers are involved, a miraculous thing happens… they begin to care. It’s very easy to blow off deadlines and such that are deemed “unreasonable” and handed down from the top. But if a developer tells you that something is going to take 5 days to complete, suddenly the onus is on him to meet his commitment, and he’s more likely to put in extra effort if that deadline slips.

There is a win-win scenario to this situation, and it nets you two very important results: more accurate/realistic deadlines, and a workforce that will actually put forth genuine effort to keep those commitments. It just requires you to literally turn your thinking upside down.

Our previous set of status meetings failed to be productive. They lasted at least an hour every day, often more than that. They were unfocused, and often crossed so many topics that no one really remembered what happened after they left the room. Eventually, they just kind of petered out… no one really wanted to attend them anymore, as they were obviously unproductive. The period that followed was almost as bad–no daily status, but at least people had more time to do actual work. Tasks were slipping through the cracks and overall communication declined.

So I was happy to step in with an alternative solution: a Scrum-like daily status meeting. I don’t make people stand-up, and we’re time-boxed to 30 minutes instead of 15, but otherwise the principles are the same. At each meeting the attendees are required to come prepared to answer the usual triumvirate of questions:

• What did you accomplish yesterday?
• What are your goals for today?
• What issues are affecting your ability to meet those goals?

I’m pleased to say that even after only one week, the system has proven effective. People don’t mind attending since it’s short and focused. We stick to the agenda above; we’re not quite used to the format yet, so some side discussions occur in the middle of the meeting, but we’re getting better. Now everyone knows what everyone else is doing, and communication is improving. We’re catching issues much faster since the team is aware of what is going on before it happens.

I won’t claim daily status is a panacea, but it’s working for us with remarkable results.

Trying to catch up with some more of my “backlog”…

This one is from early December. Joel Spolsky wrote an article for Inc.com titled How Hard Could It Be?: My Style of Servant Leadership. It’s short and to the point, and I think every manager or manager-to-be should read it and heed his words.

In particular, I identified with a couple of passages:

In our company, management’s job is to get things out of the way so that all the great people we’ve hired can get work done. … Our company was built on the idea of hiring smart and productive people and then clearing the decks.

This is something I’m really striving for in my leadership capacities. Especially coming from an expert background, sometimes it’s difficult to let go and allow your team to thrive. Sometimes I feel an impulse to jump in and do the work myself, but I have to remind myself that my team is made up of experts for a reason. I should trust in those experts and let them do their jobs… and I will stand back and remove all the white noise that gets in their ways.

I still contend with the problem from my own superiors that sometimes I am not trusted for my expertise. This is very frustrating for an intelligent and productive software engineer (or any other expert)… why would you hire a supposed expert in his field if you’re just going to tell him how to do his job? Experts want the ability to thrive in the work environment and build good products without interference. They will quickly grow bored with implementing someone else’s ideas.

Not long ago, we had a management trainee who sat around waiting for us to give him a formal title and promotion so he could “get stuff done.” Problem was, he had never managed to win enough respect or influence from the development team to actually do things.

At the same time, you must be willing to wade into the thick of things and build a rapport with your team. Someone who demands respect simply because of his or her position is only going to get it grudgingly.

This is where I strive to help my team grow. I’m not opposed to pair programming with my team members when they get stuck, or offering up ideas to improve the overall architecture, or even just dealing with annoying stuff for them.

Commanding subordinates and leading a team are two very different things. Leading by example is even a step ahead of that.

Jurgen Appelo has a new post up about the trials of performance appraisals. I think we can all agree that performance appraisals are a time of the year (or multiple times of the year) that is full of feelings both good and ill for managers and employees alike.

I found this near to my heart since this is the first year I’m doing performance appraisals for other people. I’m having the same experience as Mr. Appelo: “I had too little information to produce reliable performance appraisals.” The three people I had to appraise were on a team that I had only joined in July, so first off I was only able to appraise them for half the year. Second, even as team lead I was not in a position where I knew everything that everyone was doing or had done. This was especially difficult for evaluating individual goals, since I frequently didn’t have a complete picture of what they had to done to achieve those goals.

Still, I got through it as best I could. I still couldn’t help the trepidation of feeling like I might be judging some people too harshly and others not harshly enough. It doesn’t help that our performance appraisal system is based on a bunch of arbitrary 1 to 5 ratings. I was pretty stingy with higher numbers, but I know some others (especially the appraisees themselves) rate much more loosely.

The idea of 360 degree feedback sounds good on paper, though. I would love to be able to consult with multiple people on an appraisal so that I could get a more complete picture. Unfortunately that’s the sort of change that will be difficult to sell from the bottom up, and as Mr. Appelo points out, it won’t be received well if it’s not consistent across the organization.

While following the links from Mr. Appelo’s post, I stumbled across another article that I found interesting: What Great Managers Do Differently. It’s actually a short review of Marcus Buckingham and Curt Coffman’s book, First, Break All The Rules: What the World’s Greatest Managers Do Differently (which I will now need to add to the ever-growing pile of books I want to read). In particular, this passage caught my attention:

The traditional performance improvement process identifies specific, average or below performance areas. Suggestions for improvement, either verbal or in a formal appraisal process, focus on developing these weaknesses.

What great managers do instead, is assess each individual’s talents and skills. They then provide training, coaching, and development opportunities that will help the person increase these skills. They compensate for or manage around weaknesses.

This struck me as something both equally intuitive and obvious, yet something I had not considered before (“Why didn’t I think of that?!” moment). In every performance appraisal I’ve ever been a part of, it tends to generate a lot of negative feelings since the appraisee feels picked on—the appraiser points out their biggest flaws and then tells them that they must change.

The idea that the manager should instead pick up on the employee’s strengths and foster those whilst all but ignoring deficiencies is brilliant. The employee doesn’t feel worthless and can focus on those things they do well, and the manager can improve performance by directing subordinates to roles where they will excel.

A coworker recently turned me on to the Google Tech Talks Channel on YouTube. There is a wealth of good information on many different topics. In particular, I found this presentation about leadership from Mary Poppendieck especially insightful this morning:

I’m a little behind the times in responding to this (the “blogosphere” moves so fast), but I wanted to address an article that James Shore wrote back in November about the decline and fall of agile.

He talks about how agile is failing us, but I think the real underlying problem is that teams are failing to understand agile. Perhaps that is a failing of agile, but I think it speaks more to how teams and companies choose to implement it. In particular, Mr. Shore makes a good point:

[Scrum] also has a few mechanical things about a monthly Sprint and daily Scrum. Trivial stuff compared to the rest. But guess which part people adopt? That’s right–Sprints and Scrums. Rapid cycles, but none of the good stuff that makes rapid cycles sustainable.

I see this every day in my own organization. Project management gets so hung up on sprints and burndown charts that the team focuses too much on trying to deliver rapidly, avoiding quality practices like pair programming, TDD, and others.

It is not a lost cause, though. For Scrum to succeed, you need to think about your projects from the bottom up rather than the top down. Top-down thinking is a result of project management trying to hold onto waterfall practices while paying lip service to agile practices. The sad part of this is that typically in these kinds of environments, the team consistently points out these problems in their sprint retrospectives, and yet has no or little power to do anything about it.

Project management has to buy into Scrum and embrace the hands-off part of the practice. Determine the product backlog and the release cycle, but leave everything else up to the team. In return, the team should focus on delivering quality over quantity, i.e. following best practices rather than “get ‘er done.” If quantity is becoming an issue (missed commitments, etc.), then the team needs to stop committing to too much and focus on ramping up, or the product owner needs to stop forcing the team to commit to the pace the product owner wants rather than what the team can deliver.

As a closer, I wanted to share a response to the article that one of my colleagues sent me:

An interesting article. Here is an odd thought that won’t seem related, but I think it is.

Over the course of the past week, whenever I had a little “down time” (i.e., while people were sleeping), I re-read Malcolm Gladwell’s book Blink: The Act of Thinking Without Thinking. In one of the chapters, Gladwell talks about Agile, he just doesn’t call it that. He speaks of the commonality between highly successful combat commanders, on-floor commodities traders, ER personnel, firefighters, Improv comedians, and basketball players. Every one of these domains has this thing in common: they are agile. Here are the two primary keys that Gladwell asserts contributes to their success. First, in each domain, there is agreement with the circumstances. As in systems/software development, when we are using Agile, we take things as they are – we don’t try to tell the customer what they want, we try to find out what they want. Second, in each domain, once the action starts, the players do not maintain rigid adherence to a scripted outcome (how “waterfall” is that?); instead, they respond in each moment, according to a very disciplined set of fundamentals. Players in each domain spend their “off-court” time practicing those fundamentals, honing their skills, sharpening their tools, so that when the moment to perform arrives, they are prepared to perform at their very best.

We could learn a lot from people in these different domains As Gladwell asserts, they are our soul-mates. Agile will never decline or fall. It is an adaptive way of life for any domain where rigidity leads to inevitable failure.

And my response:

An excellent observation… it is similar to one of my favorite metaphors for agile (from Ken Schwaber): driving a car. It’s something we do every day without realizing it, but it embodies agile: adapting to change. As you drive, you continually assess the state of the road around you, making adjustments as necessary… most of the time minor, but if you hit a major “block,” you might change your route completely.

When you realize how much “agile” there is in the world around us and in your everyday life, you really start to see the counter-intuitiveness of waterfall.