You're hiring... you make a list of mandatory skills and some preferred ones. You interview someone... they don't get ticks in all the mandatory fields... so easy decision. They are mandatory! You have to say no.
Now... some time passes... you are interviewing people, but no-one seems to be passing the bar. Time is running out. You have to staff your project or it won't be viable. What do you do?
What would you do?
My thought for the day..
Staffing a project with the wrong people WILL LEAD TO FAILURE! Usually a slow, expensive failure. Having the project canceled because it wasn't viable is a much better business decision, and in the long run may save the company (and your job).
3 comments:
The trouble is, based on that philosophy, I wouldn't have been hired for any job I've ever gone for, and since I'm a genius who single-handedly saves every project he works on :), my employers would have been worse of for it.
While dropping the bar is bad, maybe the bar shouldn't be defined as a set of checkboxes?
Craig says "I wouldn't have been hired for any job".
That being the case means that the 'mandatory' items were wrong to start with. If those doing the employing are unable to identify the essence of great developers well then you might as well use a lottery approach.
Rob Smyth
Oh so true Nigel.
I would add to this the next layer that once somebody is employed:
- Nobody is every 'released' if they fail to perform during their intial 'probation' period.
- No performance review/management, or incompetent performance reviews.
I guess it is hard to say 'no'. A manager saying 'we cannot do this job as planned as we cannot recruit the staff', while what ought to happen, is perceived as a managers failure. I think it would be good management allowing a rethink of salaries or project viability.
Our industry seems to suffer from implied failure by software developers when they are teamed with those unable to do the work. I often notice management seeing staffing as 'resourcing'. That is, 'I did my job as I resourced X developers on to that team'.
I'm noticing (over the years) the smells:
- Endless training without measuring results.
- Refering to developers as 'resources'.
- 'Linear madness'. That is, a project is going slow so lets put more 'resources' onto it.
Actually, thinking about it, isnt the drop the bar 'resource management madness'? That is, forget the skills we need more resources.
If training was the answer then why employ people with qualifications when you could get a taxi driver for less $ (sorry Taxi drivers).
Or perhaps 'managers' see themselves as part of the mangement team and not part of the development team(s). For collaboration a manager is a member of both (team of teams) and has responsibility to both.
The smells for this I notice are:
- Team leaders / managers refering to a team as 'my team' and rarely as 'the team'.
- Teams not involved in decision making (or 'no resistors' decision making) .... Aaagh!
See ya
Rob Smyth
Post a Comment