As I’m sure at some point they will not be available on the Utah Code Camp downloads page, I’ve gone ahead and posted my slide decks from my sessions on SlideShare. They are not entirely comprehensible, especially the Rhino Mocks one since the majority of the time was spent in code. I’ll get that posted soon as well.
Recently the Utah Development Center at Microsoft (where I work) had a “morale event” (I still think it’s funny that they explicitly call them that) where we visited a local laser tag place. We played three times and each time I ended up in the middle of the pack (yeah, I’m not that good). But I did see some interesting lessons that could be taken from the experience. Here is one of those lessons.
After the first round, an interesting thing happened. We each got a printed “score card” to tell us how we had done. It had how many kills, how many timed you were killed, breakdown by opposition player (friendly fire was off), number of shots fired, accuracy percentage and some overall team stats. The one additional number on the sheet was “rank”. Being good little programmers/engineers, most of us started to try to reverse engineer the ranking algorithm. It appeared to be surprisingly simple. We were ranked by number of kills. (I don’t think this was confirmed, but we suspected that number of timed you were killed was used as a tie breaker.)
It was like the game totally changed. Because it did.
Suddenly the feedback loop from the metrics used gave us this: Don’t worry about accuracy percentage, don’t worry about the number of times you get killed. Kill the most people and you win. The only thing that matters to your rank is number of kills. The next game the overall kill count went up significantly (about 20% increase).
Metrics have the tendency to focus us like this, which is super powerful. But remember, with that great power comes great responsibility. While many still played for “team pride”, for some people the individual ranking became the most important personal metric of success. If you no longer care about the success of your team, the number of kills that you sustain no longer matters. It is not a metric that you care about. All that matters is getting the most individual kills.
Choose the metrics that you use with care.
A recent real life example that I heard went something like this: The manager of a development group doing SINO (Scrum in name only) set a goal for the group that “this year, we’re going to get everything done that we commit to for a sprint done in that sprint.” This is a well intentioned goal. Basically do what you say you’re going to do. BUT, if that is the metric used, what happens to the amount of work committed to in a given sprint? In order to do well against the metric, the amount of work committed to drops (or estimates are WAY high). Suddenly half way through a sprint (or less) the developers have completed the work that had been committed to. All that matters is getting the work committed to done.
Some managers reaction would be to think, “Well, that didn’t work, lets add some more metrics to get what I want. Let’s continue to try to control the system.”
That may or may not be the best approach. Eventually you may end up with a system that is so bogged down with itself that no work actually gets done.
I’m not saying that metrics are bad. They can be very, very good and are very, very powerful. Just be sure that you’re using the right tool for the right job. Don’t use a nail gun where the gentle tap of a hammer is the right thing.
I recently led a practice of the Prime Factors Kata in C# at the Utah Software Craftsmanship Group. I couldn’t find a C# version, so I adapted the Java version that Uncle Bob posted back in 2005. I’ve done a recording of me practicing the kata so that others can practice it. I recorded it at a fairly high resolution (approximately 1920x1080) which means you’ll need to watch it on a screen around that size in order to make out the text in most cases… sorry, this is my first attempt at screen capture of a coding exercise… I’m sure I’ll get better with practice!
Enjoy!
Prime Factors Kata in C# from Mike Clement on Vimeo.
What’s wrong with that phrase? A better question would be is there anything right with it…
“But we can get ‘em cheap” is the ultimate lie, especially in hiring. Now, that’s not to say that you can’t get quality team members for “cheap”. BUT, when you preface that with “but” it means that you don’t really want to hire that candidate. It means that you are attempting to justify a bad hire with a claim of “cost savings”.
But the lie is that you’re not really saving money.
Let’s say that this “get ‘em cheap” candidate (A) would somehow accept an offer of $45K. But you have doubts. You wonder why somebody would take such a low salary with the experience that they claim on their resume, but you go ahead, extend the offer. Surprisingly they except your low offer and so you get ready for your new employee.
In a parallel universe, you passed on candidate A because they weren’t good enough, even if you could “get ‘em cheap”. So you keep looking, and maybe looking some more. So you’re going to incur additional costs in the recruiting/hiring process. But you’re confident that you’ll find a quality candidate if you keep looking.
So you keep looking.
And looking.
And looking.
And then you find candidate B.
But you’re pretty sure that they’re going to want at least $80K if not more. And sure enough, after some negotiation, you settle on $90K. Plus you definitely spent more time and money looking than you wanted to. You’re pretty sure it’ll be worth it though.
Back in candidate A land, you start doing training. You’re explaining a concept and you can tell your new hire isn’t quite getting it. They are nodding away, but you’re pretty sure they just aren’t asking questions because they don’t want to appear incompetent. You get the feeling that they are following the old motto “better to keep your mouth closed and be thought a fool than to open it and remove all doubt” might be your new hire’s strategy, but you can’t tell so you write it off as you just not being able to read them. But you get the same feeling as you go through your other training sessions. He also comes and asks some questions that are a little weird… and repetitive.
But he was cheap right? Well you’re now not only paying A’s salary but now wasting one of your productive developer’s time. A’s not really getting much done, but you figure it’ll just take a little longer for him to ramp up. But he keeps bugging your devs… and soon you realize that the new hire has been rotating around who he asks questions in order to make it less noticeable that he doesn’t know what he’s doing… so instead of repeating a question twice, it’s really that he’s asked it five times… and in code review it comes out that he still doesn’t get it.
So two months later you’ve tried and tried and things aren’t working out. You have encouraged, warned and helped as much as you feel you can, but it’s just not working out. Not only has A been minimally productive himself, he’s constantly needed help from others which means that your team hasn’t been as productive. So you end up firing A and start looking again, until you find someone that you can “get cheap”…
Meanwhile in the parallel universe, candidate B is asking all the right questions… once. You see the light turn on in his head as you explain your system architecture. And the questions that he asks help you understand that maybe there are some improvements that could be made to your framework code to help ease development. B is productive within two weeks and at the end of their second four week sprint has gotten as much done as most “ramped up” devs.
So which is the better deal? Which really is cheaper?
“But we can get ‘em cheap” to me is the ultimate red flag. It means that more than likely you’re getting a low quality candidate for a low salary but at a cost that is really higher than anybody should be willing to pay.
Are there ways to get good devs less expensively? Sure! Interns and new college hires can be a great way to get bright devs that can be trained easily relatively inexpensively. But even that is not an endless pool as you still need more senior devs to mentor and train them.
There is another hidden cost/benefit that comes with a new hire, and this is probably one of the most costly: What do your other devs think when that new hire walks in the door for the first day? Do they think “what a great addition to the team!” or “oh boy, I can’t believe I work here where they hire these people”. Building a great team means that every hire counts. There is no room for “meh” team members on a great team. Should they all be great in the same way? No! But they all should be great at something the team needs.
Even if your A turned out “okay” (half as productive as B, but decently productive) and you could hire two of them for the same salary as (or even less than) B, B would still be a better deal because 1) fixed per employee costs (like hardware, software, health insurance, benefits) and 2) your communication graph is smaller. Your team will be tighter and more productive with a single solid performer that is able to raise the performance of the whole team than two blah performers. Smart people want to work with smart people!
Just remember, if you hear “but we got ‘em cheap” when frustrated with a new hire, you’ll probably be hearing the same thing in 6 months when you’re training his replacement.
Are you familiar with the Peter Principle? In a sentence, it states that employees are promoted to their level of incompetence. Think about that for a second.
Sure it’s kinda cute and makes you chuckle, but what does that really mean for your organization? It means you have a certain percentage of your employees/co-workers that are incompetent at their current positions. The scary thing is that most of these people are in management positions… they are running your company.
The sad thing is that these same people were most likely competent if not exceptional in another non-management position in your company. How else did they get promoted to that management position if not by demonstrating competence in another role? But that also means that there are people in your organization that are getting paid to fail instead of being put in a position to succeed.
So the question is why? Why waste all this talent and ability? Why not put them in a position to succeed? Because to put them in their old positions would often result in a “demotion” and this is culturally difficult to do.
The trick is not to tie promotions to role. Otherwise you artificially limit promotions/salaries for those in individual contributor positions because they aren’t “moving up” the org chart. You contribute to a culture that the only way to progress your career is to “get into management”. This is a mistake.
The flawed fundamental assumption is that if you are good at something, you’ll be good at managing people that are doing that something. Managing people requires a unique skill that is often not found in your top individual performers. People management needs to be its own role within your company. Those that recognize their limitations and feel that they are best in an individual contributor position may feel less valued in the organization, causing them to leave.
On wikipedia it is says that a result of the Peter Principle is that “work is accomplished by those employees who have not yet reached their level of incompetence”. Make sure that your organization keeps people below their level of incompetence or else who’s going to do the work?
My name is Mike Clement. I'm a husband, father of four, a Latter-day Saint and currently a Distinguished Software Engineer at Hunter Industries.
Opinions expressed here are my own and do not necessarily reflect those of my company :)
Software on the Side is my blog about software development (coding, design and architecture), software development management, technology and leadership. Why "Software on the Side"? I guess there are a few meanings.
Sessions that I've presented (and can again!)
