My personal favorite is “What would happen if this were not done at all?”
Notes from the Golden Orange
EppsNet Archive: Management
From an actual job description for a Software Development Manager:
- Worth with management and directs to put together a solid SW Development career development plan in alignment with Organization Solutions all-up to grow hi-potential employees and minimize retention.
If you’re writing job descriptions and learning English at the same time, there’s no shame in having a native speaker review your work.
The job description goes on like that for 10 or 12 more bullet points. I singled that one out because I like the phrase “minimize retention.” I can recommend a couple of people for that.
I assume it’s a language problem in this case — that the author meant to say “maximize retention” or “minimize turnover” — but it might be a kick to have a job where your actual charter is to minimize retention.
You would not be an easy person to work for. You would take all the credit. Your subordinates would get all of the blame.
Picture having the names of all staff members written on a whiteboard in your office and removing them one by one with a triumphant swipe of your eraser at the end of their (hopefully brief) tenure.
Maybe your boss would stop by every now and again to tap on a name and ask, “Why is that guy still here?”
Of course, if some clinging vine is screwing up your retention rate by refusing to quit (maybe he really needs the job?), you can just call him in and fire him. Or her.
Good times! If only all job objectives were this easy to meet.
Thus spoke The Programmer.
I’ve noticed a new trend in spam is to put the word “Manager” in front of the sender’s name, e.g., Manager Joe Schmuck instead of just plain Joe Schmuck.
Are people really this stupid? Does anyone think to themselves, “I don’t know any Joe Schmuck, but if he’s come up through the ranks to the level of Manager, then I think I owe it to myself to see what he has to say”?
People ask me what is my “specialty” in software development. My specialty, if I have one, is in not having a specialty. I feel like I can contribute on any task.
That answer throws people off. They repeat the question, explaining that everyone is best at something. Managers especially like the idea of specialists because it simplifies the assignment of work: UI tasks go to the UI guys (or gals), SQL tasks go to the SQL guys, middle-tier tasks go to the middle-tier guys, and so on.
Before launching my illustrious career in software development, I worked on a union construction site. Everyone’s job was defined in excruciating detail — what each union member could and couldn’t do.
For example, if we needed to move a pallet from here to there, we had to find a teamster to drive the forklift. There were a few exceptions to that rule, depending on what was sitting on the pallet. In the exceptional cases, we had to find an operator to drive the forklift.
If we couldn’t find a teamster or an operator, the pallet had to sit where it was. We couldn’t move it. It didn’t matter how many other guys were standing around who knew how to drive a forklift.
Since then, I haven’t been a fan of specialization on work teams. It leads to some people having more work than they can possibly do while other people are standing around idle.
I’d make an exception if work demand could be guaranteed to match the available allocation of specialists (i.e., never), but if not, then give me a team of generalists every time.
Thus spoke The Programmer.
Because of the huge productivity differences between good programmers and bad programmers — 10x? 28x? More? — my biggest leverage point as a development manager is my ability to hire people.
At my last job, we had an HR Director named Lucy. In every one of our annual Employee Satisfaction Surveys, Lucy’s group had the lowest scores in the entire organization. Nobody liked or respected her.
She was, however, close with the CEO, which made that irrelevant.
Lucy’s friend Kathy Slauson runs the Slauson and Slauson recruiting agency, so that’s where we got our programming candidates, who were mostly terrible.
The Slauson agency doesn’t specialize in IT candidates, although they do have a “technical recruiter,” who unfortunately knows nothing about technology.
They don’t bring candidates in for in-person interviews. They take whatever candidates give them in the form of a résumé and they pass the résumés along to clients like me in hopes of being paid a fee.
- Candidates send résumés to Slauson.
- Slauson sends them to me.
What value does this add over candidates sending résumés directly to me? None.
Slauson doesn’t qualify candidates. They don’t map abilities and skills against the requirements of a position. They add no value to the process, and I had to screen all the résumés myself, the same as if I’d just bought them from a job board.
When I saw that Slauson was just going to throw résumés at me, I asked them to please add a short write-up, indicating why they thought each candidate was a good fit for the job.
What I got was write-ups like “Candidate is good with Technology X,” where Technology X is something I indicated as a job requirement.
When I asked “How did you assess that the candidate is good with Technology X?” they would tell me “We asked him.” Or “It’s on his résumé.”
In other words, “Candidate is good with Technology X” meant “Candidate states that he’s good with Technology X. Unverified.”
(If you’re wondering at this point why an HR department would funnel good money to a recruiting agency for doing nothing, go back and reread the part where I mention that Kathy Slauson is a personal friend of Lucy the HR Director.)
I said earlier that Slauson has a “technical recruiter.” She was in the office one afternoon and handed me a résumé.
“He doesn’t look like an ASP.NET programmer,” I said after looking it over, “which is what we’re looking for. For example, I don’t see any C# experience.”
“It’s right here,” she said, pointing at the résumé where it said this: C++.
If you’re not a programmer, you might say, well, easy mistake to make. C# (pronounced C-sharp, like a musical note) and C++ (pronounced C-plus-plus) are both programming languages containing the letter C followed by one or more symbols.
But whereas C# is the primary programming language for web development on the Microsoft platform, C++ is a lower-level language used for system development. Nobody does web development in C++.
Not surprisingly, a high percentage of Slauson’s candidates bit the dust in the initial phone screen with me, because the phone screen was their first encounter with someone whose programming knowledge was non-zero and could possibly tell a good programmer from a bad programmer.
According to Kathy Slauson, that was totally unacceptable. She thought that because she had an in with the HR department, we should be hiring every candidate she sent over, qualified or not, and paying her for the privilege, which is the way it worked before I arrived on the scene and screwed up the process.
She was always very polite to me in person, assuring me that she was doing her best to improve the quality of candidates, but behind the scenes, she was telling Lucy the HR Director that I shouldn’t be allowed to interview candidates anymore.
(That information was never supposed to reach me but it did.)
Think about that: we had a recruiter telling our HR Director that a manager shouldn’t be allowed to interview their candidates. (The fact that I no longer work there tells you which side of the issue Lucy came down on.)
Kathy also told Lucy that the candidates I was rejecting were perfectly good candidates because after I turned them down, they were being hired at other companies.
Of course they were being hired at other companies. They were being hired by companies with lower hiring standards for programmers. The best thing that could happen with some of those candidates is for them to be hired by competing organizations.
Do you think Amazon or Google worry that candidates they turn down get hired somewhere else?
(No, I wasn’t trying to match hiring standards with Amazon or Google. I’m just saying that it wasn’t my goal to be the employer of last resort, or to be able to say, “If we don’t hire ‘em, nobody’s gonna hire ‘em!”)
Everyone I hired was an order of magnitude improvement over the people they replaced.
I like to work with talented people. I’m not trying to get rich and I don’t have a career path. I’m trying to learn and get better and contribute to my profession.
If you give me a job where I’m responsible for hiring people, I’m going to hire the best people available, and decline to be force-fed unqualified candidates by a friend of the HR Director.
To be continued . . .
I recently concluded a 3-month job search. As part of my networking, I met a number of unemployed people in other fields who were having trouble not only getting jobs, but even getting interviews.
I talked to a lot of people and averaged about an interview a day, including phone interviews, mostly for development manager jobs. For every development manager job, there are multiple development jobs, so if you’re a developer, your situation is even better than mine was.
I live in Southern California, but the demand is not just local. I had multiple contacts from companies outside the SoCal area that can’t find qualified candidates.
I’ve been working again for over two months, I no longer have an active résumé on job boards, and I still get emails and calls every day from recruiters all over the country.
Agile and Scrum are in demand
The situation with Agile and Scrum right now seems to be that a lot of people are putting it on their résumé but most of them are bluffing.
One hiring manager told me that he’d talked to three dozen candidates who claimed to know Scrum and only one (me) who actually knew it.
Another hiring manager asked me to describe the Scrum process, beginning with a product owner with an idea through the end of the first sprint. It’s a basic question, and when I finished, he thanked me for my answer. “You’d be surprised how many people I ask that question and the answer is a yard sale.”
Actually, you’d be surprised how little I’d be surprised by that.
One recruiter contacted me about a 3-month Scrum Master contract in Toledo, Ohio. A glance at my résumé will tell you that I’ve never worked outside Southern California, so on a list of people likely to take a 3-month contract in Toledo, Ohio, my name would be far, far from the top, but the difficulty of finding a qualified candidate to fill that job is such that the recruiter contacted me anyway.
If you really know Agile and/or Scrum right now, it’s a seller’s market.
Stephen Covey, the author of the best-selling book “The Seven Habits of Highly Effective People,” died early Monday morning at 79 years old, according to The Associated Press.
Here are the seven habits:
- Be Proactive
- Begin with the End in Mind
- Put First Things First
- Think Win/Win
- Seek First to Understand, Then to Be Understood
- Sharpen the Saw
One way to assess the value of advice is to ask, “Would anyone advise the opposite?” If the answer is no, then all you have are platitudes and truisms.
Let’s try it:
- Let Life Wash Over You Like a Big Wave
- Go Off Half-Cocked
- Proceed in a Frivolous, Undirected Manner
You get the idea.
By selling more than 25 million copies of this book, and becoming known as one of the leading business thinkers of his time, Covey revealed the vacuousness of the modern mind, although I don’t think that was his intention.
R.I.P. Stephen Covey
I see the history of management as an effort to perfect the instructions that you hope someone will follow this time — even though they have never followed directions in their whole life.
Steve Denning: The Best-Kept Management Secret On The Planet: Agile
“Well, if you’re going to control buffalo, you got to know two things, and only two things: First is,
“You can make buffalo go anywhere, just so long as they want to go there.
“You can keep buffalo out of anywhere, just so long as they don’t want to go there.
Even when it’s “really” a technical problem, it can always be traced back to management action or inaction. Even so, the experienced consultant will resist pointing out that it was management who hired all the technical people and is responsible for their development. At the same time, the consultant will look for the people who should have prevented this problem, or dealt with it when it arose.
Sometimes the best management is no management at all — first do no harm!
Jaime Flinchbaugh: 4 myths about the principle of “Respect for People”
From a Sr. IT Consultant:
I recently asked a colleague [CIO] whether he would prefer to deliver a project somewhat late and over-budget but rich with business benefits or one that is on time and under budget but of scant value to the business. He thought it was a tough call, and then went for the on-time scenario. Delivering on time and within budget is part of his IT department’s performance metrics. Chasing after the elusive business value, over which he thought he had little control anyway, is not.
- What is your target condition here?
- What is the actual condition now?
- What obstacles are now preventing you from reaching the target condition? Which one are you addressing now?
- What is your next step? (start of the next PDCA cycle)
- When can we go and see what we have learned from taking that step?
“Flexibility,” “Adaptability,” “Gets along well with others.” I don’t believe they’re what’s needed today if we’re going to force our institutions to adapt to us–which is our central problem.
The Ottoman Turks for over three centuries produced an unbroken succession of able leaders. Their performance appraisal sheet would have looked like this:
It is essential not to profess to know, or seem to know, or accept that someone else knows, that which is unknown. Almost without exception, the things that end up coming back to haunt you are things you pretended to understand but didn’t early on. At virtually every stage of even the most successful software projects, there are large numbers of very important things that are unknown. It is acceptable, even mandatory, to clearly articulate your ignorance, so that no one misunderstands the corporate state of unknowingness. If you do not disseminate this “lucid ignorance,” disaster will surely befall you.
Human nature is such that we dislike not knowing things that are important to our well being. Since there is so much we don’t know in a software project, the nearly universal tendency among developers and their managers is to gloss over or even deny altogether the extent of their ignorance. You should reward and treasure those who consistently make themselves aware of the list of relevant things that are currently unknown. It requires mental and psychological strength to resist the normal human cravings for certainty and order. It especially difficult to believe in uncertainty when things have a veneer of orderliness, which is often the case. Pseudo-order is a maladapted defense against uncertainty.
The organization surrounding you will undoubtedly abhor uncertainty, would infinitely prefer pseudo-order and will make countless attempts to magically convert your ignorance to knowledge. Your job is to make uncertainty an unshakable fact, and to coerce the reshaping of the surrounding organization to cope with the uncertain situation. The organization must learn to thrive in an uncertain environment for its own well being.
You should expend a great deal of effort making sure that all the people on the project are aware of their ignorance rather than naively converting it to falsehoods. Bear down on them until they realize they haven’t comprehensively assessed the unknowns. In the successful project, this is much easier in the early stages, or during times of change. This is no time for niceties. People ultimately prefer success even if disillusionment is a prerequisite.
In most failing projects, there are a few people at the top of the organization who think they are in trouble, lots of people at the bottom who know they are in trouble, and a bunch of worried middle managers trying to keep those at the top from talking to those at the bottom.