Just In Time People
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.
Tweets that mention Just In Time People « Critical Results -- Topsy.com
June 14, 2010 @ 10:45 am
[…] This post was mentioned on Twitter by Mark W. Schumann, Paolo Valdemarin. Paolo Valdemarin said: RT @MarkWSchumann: In which I struggle with hiring people "just in time." Summary: you really can't. Blogged at http://bit.ly/a1EoUM […]
"user experience expert who’s only part time"
June 14, 2010 @ 10:55 am
Great analysis Mark.
Adding resources to a project that doesn’t need resources is a waste of other resources.
I’ve heard many people advise me to hire the smartest people in X industry right away, because with those people your chance of success is improved.
That’s not bullshit, but it’s not really true either. Adding people you don’t need is a waste of talent and a waste of management.
In this instance, hiring isn’t really our problem. We’re asked what resources we need (or don’t need) and we tell them. What they do with that feedback is up to them.
Mark W. Schumann
June 14, 2010 @ 11:18 am
Yes, Josh is the UX guy. Hey Josh.
Actually, what’s so wrong with hiring the second smartest people? They’re still really smart, right?
Josh Walsh
June 14, 2010 @ 11:24 am
Hell, hire the dumbest guy who can get the job done correctly and on time. Why not?
:-p
Mark W. Schumann
June 15, 2010 @ 12:28 pm
Here’s an interesting take on specializing, and on overspecializing. Just in time, too!
http://www.noop.nl/2010/06/t-shaped-people.html
Dr. Steve G. Belovich
June 16, 2010 @ 11:29 am
Using the same “toolsets” in the same way by the same type of people will yield pretty much the same results. To get a better result, either the personnel have to change their thinking and/or the toolsets have to change.
Practical experience has demonstrated (far beyond any rational contestation) that great tools wielded by “code monkeys” still result in poor systems. Smart (e.g., adaptable & willing to learn) folks can get it done, stupid ones cannot. If results matter, then focus on identifying and hiring the smart(er) folks.
Mark W. Schumann
June 16, 2010 @ 11:32 am
You want:
Dr. Steve G. Belovich
June 16, 2010 @ 2:12 pm
Hi Mark – My response: Agreed!
What’s interesting is that smart people – even with the wrong tools – will still get the job done because they are smart enough to NOT use the wrong tools. They may even invent their own tools. Their focus is always on getting it right and satisfying the customer. Those people win every time.
Mark W. Schumann
June 19, 2010 @ 5:24 pm
By the way, folks, Dr. Steve Belovich is so into the “tools” angle on this that he’s developed… well, it’s hard to describe briefly but it’s basically a rules-based engine that promises to cut a lot of the repetitive, error-prone, and insecure work out of software development–and does it on any number of deployment platforms at once.
Check it out at http://iqware.us/
Yes, this is a plug, but other than buying me lunch once in a while Steve isn’t paying me (or even asking me) to say it.
jfbauer
June 29, 2010 @ 7:25 am
In pseudo defense of corporate resource “bloat” when it comes to staffing a project … with so many moving parts in your average mid to large size IT department, the ability to align resources with perfect affinity to a ‘just in time need” is next to impossible. When you are focusing on a new “product” that has no legacy dependencies, you have a much better opportunity to map out a linear resource forecast. In a corporate IT setting, you need to have a flexible resource model to bend/flex with the priority of the moment. All you need is a project sponsor swap-out that changes the focus from build to buy and your resource model completely shifts out from under you.