The key hiring question

If I could ask one question in a hiring interview, it would be to prompt a real-world example of decision-making under pressure.

Esther Schindler asked recently, and this is a paraphrase because Twitter won’t show it to me today, what question you’d ask a candidate interviewing for a network administration job.

My idea was something like this: “Tell me about a time something broke, how you felt about it, how you tried to fix it, and what the result was.” You may recognize this as “behavioral interviewing,” which I learned a little bit about in my very first job after college.

Continue reading “The key hiring question”

From the Saturday afternoon memo department

Agile very disciplined even though it’s informal on the surface–the exact opposite of doing what you feel like.

To: [name elided]
From: MWS
Date: Saturday, 6:04 p.m.

Wow, I do weekend things on a weekend, come back to the computer, and there’s all this action.

What’s this about needing something done by end of month? I’m pretty sure [name elided] already handled the demo, which is why those cards are in archive. If there’s something I’m supposed to do by month’s end, there should be a card for it in the backlog. And the progress of cards is how you know things are getting done. If I’m doing things that aren’t on the cards, the funders are going to ask what the hell I’ve been doing. And I won’t have a good answer for that.

A decision is made to do something when a card gets added to the backlog. If it’s not in the backlog, the decision to do it hasn’t really been made. Among many other reasons, this is necessary because it keeps the project owner from making half-assed decisions. You either have to do it, and add points to the project, or admit that it’s not really on the agenda. You can’t pester the team to do stuff that’s not in the backlog and then hold them responsible for the backlog not getting done.

Bottom line: Agile is the exact opposite of doing whatever the hell you feel like. It’s very disciplined even though it looks informal. It will absolutely not work if you keep trying to circumvent it or make it be something else.

Why Your Project Is Late

Why is your project behind schedule? Have you considered that maybe it’s because you want it to be?

I talked to this guy about six months ago whose independent software company had five or six really well conceptualized vertical market applications.

None of them were actually done yet. Some were at that classic 80% completion mark. And he’d been at this thing for five whole years!

Continue reading “Why Your Project Is Late”

Just In Time People

It’s possible that an early hire results in “Wow, that person is exactly who we needed.” But much more likely is some highly capable developer waiting around for something to do. Expensively.

Hey, I’m starting kind of a big new project as of last week. I’ll fill the background in later, but for purposes of this blog post I’m telling you:

  • It’s potentially a big deal in social media;
  • The technology is a mix of the banal and the cutting edge; and
  • The visionary guy is kind of a kook.

At the moment the technical staff on this thing is a user experience expert who’s only part time, a project manager who is also not supposed to be on this full time, and yours truly. That’s actually fine. We’re still in the visioning and demonstration phase. We haven’t even selected a platform and toolset. What we have is a mission and a timeline for implementing that mission.

Depending on the toolset, this can be really easy or really hard to implement in the next six months. I’m taking a good look at this platform called eVectors, which may come in very handy for the base website and perhaps the Persistent Conversation tool we’re developing.

On one hand

If I can implement all the desired functionality within the eVectors framework, with perhaps a little custom PHP code, six months will feel like plenty of time. In that case, it would be crazy to add “resources” in terms of people to this project. Same goes if we land on a similar high-level tool.

On the other hand

If the framework ends up not taking 80% of the coding off my hands, sure, we’ll probably want more “bodies.” (As an aside, which is worse: “resources” or “bodies” in this context? Geez.) Based on a modern interpretation of Brooks’s Law, we need to do this sooner rather than later. And the Visionary Guy points out that it can take a while to cultivate and recruit a high-end senior developer.

Just In Time

This is where the “Just In Time” concept can be hard to follow. Ideally we’d snap all kinds of resources into this project exactly when they’re needed and cast them off when they’re not needed. By “resources” in this context I mean servers, externally developed software, money, tools, subscriptions, advice… really anything that goes into making this thing work. And most resources are like that. At least in theory you can snap your fingers and get a server in a few days. It’s possible to time this stuff.

Actual people? Not so much. And that’s what Visionary Guy is afraid of. He thinks that if we don’t grab this particular person right now, the opportunity may be lost and we’ll be stuck without him or her.

And it’s true that people aren’t all that fungible. Even though Sarah, Seth, and Sal have pretty similar resumes, they have all kinds of differing strengths and weaknesses. They interact with teams in different ways. They may even have good or bad personal histories with the rest of the crew–not so uncommon in Cleveland’s relatively small-townish I.T. community. So you can’t easily replace one with another. I get it.

I’m telling Visionary Guy dude, slow down. We’re all about keeping this lightweight, agile (as well as Agile), and entrepreneurial. Loading up the team with people you’re not sure you’re gonna need? That’s heavy, clumsy, and corporate. Which reminds me of another Agile concept:

You Ain’t Gonna Need It

Or in this case, “You Ain’t Gonna Need Him/Her.”

As one Agile coach remarked in the context of writing “crystal ball code,”

It is assumed that the “wow, that’s exactly what we needed” outcome is sufficiently unlikely that the costs of the other outcomes dominate.

Likewise, it’s possible that an early hire results in “Wow, that person is exactly who we needed.” But it’s kind of unlikely this early in the process. Much more likely is some highly capable developer waiting around for something to do. Expensively.

What’s Next

The plan goes something like this:

  • Evaluate the best available toolsets.
  • Align them with our project mission and timeline.
  • Do just enough pilot development to calibrate our velocity measurements.
  • Then evaluate the need for additional people.

Is it possible that we’ll miss out on the ideal candidate by waiting for a few weeks? Sure. But you don’t win by landing ideal candidates, you win by working with highly qualified people who are right for your project.

So stay tuned. Let’s see how it goes.