Tuesday, May 30, 2006

 

Management Is Art I

Some nice viewpoints from an experienced manager/IT worker: Stevey's Blog Rants: (Not) Managing Software Developers

I still have a lot more experience to gain; I know my firmly held beliefs will change. That being said, I still think that some formality, some measurement is very valuable. I think it's because I am frustrated by not knowing where I stand right now: What is expected of me? Am I meeting up? That's why I'm so big on one-on-ones. You can give and get that kind of valuable feedback, even if there isn't a formal plan with concrete metrics.


Thursday, May 25, 2006

 

Metrics == BAD?

"...Metrics and ROI are closely related and subject to many of the same fallacies.

I think that this "management by spreadsheet"... is in many cases a defense against unwanted ideas. If managers don't want something to happen they can ask for ROI calculations and dispute them ’till the cows come home.

If they do want something to happen (like corporate jets), they can simply do it without demanding ROI analysis. Thus metrics become a tool for defending the status quo and any preconceived notions management may have."

From the comments of The Problem with metrics on Positive Sharing

I don't think metrics have to be bad. There's just so much bad management going around and metrics are misused for "management by spreadsheet". I think  good management is like good news;  you never hear about it.

Tags: ,


Tuesday, May 23, 2006

 

Being Great...

I just had to link to this:

"That’s why managers matter, and why management is vitally important."
The 10 Beliefs of Great Managers

Tags:


 

Performance Measurement perceptions

I "interviewed" a friend about performance measurement at his organization.
Do you think the performance measurement is effective?
Effective in doing or changing what is really the question. Some companies do it cause it is "best practice" and don't even measure the effectiveness or care. If the aim to be effective in creating better code - then I don't think it is effective in that. I don't think something that is done once every 6 months (or even 12) and done on a piece of paper is going to change "micro" things like creating better code - Better developers sitting with weaker developers numerous times throughout a day is more likely to create better code. What I do think performance measurement could be good for (but most companies don't see it like that) is measuring the "macro" or longer term performance of someone (especially measuring them against what they are MEANT to be doing as opposed to what they ARE doing). A lot of smaller companies I think are very used to "put your head down and work" they never look at the bigger picture and never even get to setting longer term goals let alone measuring them. What is a longer term goal is questionable but things like building up coding knowledge base, or migrating all historic systems to a new code base maybe?

 Do you get an accurate appraisal of your contribution and effort?
As above I think generally the problem is that the appraisal is trying to use a "macro" type of forum to address "micro" type issues. What good is saying to someone your code is "generally" of "good" quality. I do not think that quantitative measurements are particularly helpful either - after all what does being a 7/10 for clean code really mean? However when tying into a bonus system sometimes you need these. Also a 7/10 is completely relevant to what company you are in as well as what is expected of you. A senior developer is expected to produce better code than a junior developer, however that doesn't mean you give the junior guy 2/10 for everything. Far more useful is knowing how to improve. So short answer - No, not in my experience is it very useful.

Do you think that other measurements might be better?
Specifically I would like to see IT companies spending more time measuring the employee (and the company) in a far broader view. The company (or representative) and the employee need to continually discuss how they are being mutually beneficial to each other - with specific reference to the longer term. Many companies (and especially IT companies) seem to think people work for them so that they can get paid. While this is true - people have a lot more reasons for working at a company - their career being one. I wait for the day when my boss has an open (and non-threatening chat) to me about what other options I have in terms of job/company as well as career. I think bosses prefer to be ignorant and presume that as long as they pay their staff (and enough) they don't have to think about anything else. I think bosses would prefer "not to know" why their staff might want to work elsewhere. Anyway - the reason I think this is so important is that once companies and employees can start to align their longer term goals - and continually ensure that they are still aligned - the shorted term goals are far more likely to fit in place.

Do you think the measurements used contribute to your productivity?
Productivity for measuring performance is misleading. Attainment of Goals is far more useful. I can be productive because I write thousands of lines of code. But it could be very bad code. Or maybe it is really good code but the client didn't really want that function in the first place and I was just getting distracted because it interested me. Productivity measures quantity (within a certain quality allowance). Measuring someone's performance is FAR more complex than measuring quantity (or quality). To only measure productivity assumes that productivity is even a goal in the first place. Short answer again - No I generally don't think the appraisals or the measurements generally contribute to productivity.


Not very encouraging. What is the job description of Manager?

 

Performance Measurement

I'm intrigued by the concept of Performance Measurement. I think that an organization must set concrete goals for its staff, transparently measures progress towards those goals and provide regular feedback on that progress. That, to me, is the essence of management. As a manager I ask myself:

I'm not implying I'm good at this! But a step in the right direction can make a big difference. Some people think this is the management of the future. I think it's common sense. And I'll tell you why.


Monday, May 22, 2006

 

Listen to your people

Give your people credit for knowing what needs to be done. Don't take their word for granted. But at least be open to really hear what they have to say. Encourage them to be open and say what's on their mind.
News From The Trenches

Managers, are you listening more than you are talking? One-on-ones!


 

Three simple rules

Is it possible that three simple rules can make you a great manager? Yes. Hire the right guys, set them free, and give them all the glory. It works.
from Computerworld Security

Wednesday, May 17, 2006

 

So what did I learn from Hiring Fun?

Well, firstly, that the system worked. That was my biggest relief.

Secondly, I need to do a few things in future:
- Question more closely the candidate's experience. Ounces of experience are not quite like ounces of gold it seems.
- Do the design portion of the test in the first interview. If the candidate cannot plan a simple system then no amount of syntax knowledge can replace.

Thirdly, I was reminded very clearly that the best candidate is not always the best candidate. I did immediately change the job advertisement we had. I reduced the focus on PHP and tried to look for a broader range of experience. Someone who has dabbled in different languages is more likely to be a real programmer. Ultimately, though, you just have to keep asking the right questions.

And, as Joel says, provide the right incentives.


Tuesday, May 16, 2006

 

Hiring Fun

We were interviewing for a mid-weight web developer position. I had advertised for someone with two to three years of PHP programming experience and the other stuff which I think is important (Passion! Detail! Your Own Ideas!) but which everyone just seems to skims over. The team leaders and I had liked one individual out of this group; he was confident and attentive. He seemed like the kind of person who would fit into the group.

So I called him in for a second interview. I use the second interview to do a technical test and ask the more serious questions that I think are a little premature for the first interview. The technical test is straightforward:

Create a user login/access rights system. Users need to have access rights to certain pages. A user must log in and be able to access all the pages they have rights to access. A user must not be able to see the content of a page if they are not logged in or if they do not have rights to see that page. You must provide:

  • A rough process-flow diagram.
  • A diagram showing your database design.
  • A login page and php code to implement the above spec.

With this I provided an empty database, a few dummy pages with dummy content (products.php, contact.php, download.php), a machine with an internet connection, php and sql server documentation and a standard set of tools. The interviewee has one hour.

After an hour I stopped the interviewee to have a look at what he had accomplished. He had the basics of a login system (code for login successful/unsuccessful) in php. I asked him if he had a database design diagram and he drew a block with users and another block with rights and hesitantly drew a few lines between them.

"But how do you store what rights a user has?" I asked.

"Well here..." he says, tapping the rights table.

"But what if we need access rights for thousands of pages?"

"Um..." says the interviewee.

I moved on to the in-depth questions.

After he left, one of the team leaders and I took a look at his code. The HTML was odd; The parameters had mixed case, which stood out to me as not being hand-written. Not a requirement, I admit. But a small system like this doesn't need complex HTML. The PHP hadn't taken any kinds of rights management into account and didn't actually connect to the database. He had left the browser window open. And that is when dissapointment turned to shock and incredulity:

I emailed him later that day to thank him for his time but to say that we would not be considering him for the position.


 

The start of new things

I make a lot of noise in my own quiet way. However, I find myself, all too often, ranting to the deaf, too frequently railing to the disinterested. I have learned to be satisfied with small victories, amused by small incidents, comforted by small friendships. I must now ask myself: is that enough?
www.bigpicturesmalloffice.com

This page is powered by Blogger. Isn't yours?