The Old Joel on Software Forum: Part 3 (of 5) - What to do whan I don't have a clue?

What to do whan I don't have a clue?

I'm a manager in charge of a software development project.

A few years ago, I was a programmer and was good at it.

I tend to have very friendly relations with my subordinates - I treat them well, etc.

The problem is - what can I do when they ask me about a problem I don't know anything about?

There are parts of the spec that need clarification, etc - and I have not clue how to proceed - I need to think maybe for 3 days, in which time the development is stopped.

The problem is, how can I handle these kinds of situations?

Thank you!

Manager
Tuesday, December 9, 2003

Let them do it as they know best. Read Joel.

Alex
Tuesday, December 9, 2003

I have tried that several times.

They are excellent programmers, but don't have a clue about how to design a good user interface, what the user wants, etc.

:-(

So - if they are working from a good spec, this is ok, but there are times when I don't know what to write on the spec.

Manager
Tuesday, December 9, 2003

Maybe it's your company or it's you, but you're suffering from delusions as to what a manager should be. A manager simply gets people to do good work. This includes hiring the right people and then motivating them. That's about it. The answer to your problem is this light is simple: hire someone or consult with someone who can solve your problem.

Like most "high-tech" companies, you seem to imply that as a manager, you should be the technical expert. This is, or at least shouldn't be, the case. If managers are supposed to have the answer to every question, then my feeling is that they should be engineering instead.

StickyWicket
Tuesday, December 9, 2003

"They are excellent programmers, but don't have a clue about how to design a good user interface, what the user wants, etc."

Then hire programmers who ARE good UI designers, and make sure there is communication between development (the do'ers) and the customer representatives, typically product management in marketing (the specify'ers).

Brad Wilson (dotnetguy.techieswithcats.com)
Tuesday, December 9, 2003

Brad, your reply is very interesting.

But - how do I find which applicants have good GUI design skills?

For programming jobs - I know how to select them - I just give them a very tough programming test, similar to hard real-world work, and the ones that make it (about 1 in 20 applicants which are already preselected by their experience) are good programmers.

But - how do I find a programming with good GUI design skills?

Also, about hiring an expert only to design the interface - most of the time I can't do this, because we don't have a lot of resources - we are a small company.

So, the spec writting job is mine.

Manager
Tuesday, December 9, 2003

You could delegate parts of the spec writing to one or more of your team members, and then review the work afterwards.

It sounds to me like you don't trust your team to do certain tasks that they may be able to do with a little mentoring. The first time one of your subordinates takes control of writing the spec, what they deliver might not be as good as what you could have done. That's okay, if they've never tried gathering requirements and formulating a spec before, as long as they learn from experience. You might be pleasantly surprised at what your subordinates can do, and they might be better motivated for it.

If you're concerned about their ability to design GUIs, put them on a GUI design course if you have the budget. If you haven't, at least get some good UI books (eg: Alan Cooper's "About Face") and make sure people read and understand them if GUI design is that important to your company.

Or, when hiring people, give them some screen dumps of an app and ask them to comment on its usability. Or, better still, get them to design the user interface for something simple.

Better Than Being Unemployed...
Tuesday, December 9, 2003

Another link that might be useful. "Hire developers, not programmers."

This is especially important in a small company when the technical staff have to be more than just code cutters.

http://software.ericsink.com/No_Programmers.html

Better Than Being Unemployed...
Tuesday, December 9, 2003

Quit!

Utopia is a place where no moron exists
Tuesday, December 9, 2003

Talk to the users and get some answers. Make some prototypes of the alternatives if that will help them choose. And then figure out where your process is broken so that you don't get into a situation where a missing spec has to stop your development effort cold again.

Rameses
Tuesday, December 9, 2003

Call it a special "3 days to improve our process" and have them overhaul the build process, the SCM, the unit testing, the installer, the office layout, learn new technologies ...

Just me (Sir to you)
Tuesday, December 9, 2003

Draw up a couple of designs on paper and then do a few hallway UI tests. Talk to the people who will use the app. Your customers are the best resource for evaluating what will work.

PangoX
Tuesday, December 9, 2003

Manager.

Use the Socratic method. When I worked for BIG management consultancy firm, I always used this with great success when I felt I was out of my depth.

The answer is there. You both just need to tease it out of each other. That said, you have to ask the right questions.

As long as you know enough to ask the first couple of open ended questions, and can apply deductive logic, you are safe.

Tapiwa
Tuesday, December 9, 2003

If you have 3 days to think about it in the middle of development, you have 3 days to think about it before development starts. Also, if everyone is twiddling their thumbs during that time, you have more minds than just your own to work on the problem - use them.

I hope you're not designing the UI for a modern insane asylum.

www.MarkTAW.com
Tuesday, December 9, 2003

Manager >
Have a meating with the entire team, with just two points on the agenda:
*What is the problem.
*How do we solve it.

Group discussion is often very helpfull in clarifying problems. You can spare one hour for this.

Eric DeBois
Tuesday, December 9, 2003

Post to JOS.

Recursion Rules
Tuesday, December 9, 2003

Manager, at least you're *asking*. No, don't quit.

Most of the dumb@sses I've worked for don't ask. They don't know, they don't care, and they don't think that it matters that they don't know. Admitting that you don't know is the first step toward wisdom.

I also vote for the Socratic method. Ask your people to educate you on technical issues and tradeoffs. You make the final decision, but let them be your "trail guides".

Everyone can't know everything, or something.

Bored Bystander
Tuesday, December 9, 2003

"how do I find a programming with good GUI design skills?"

/me clears throat

Wednesday, December 10, 2003

As a manager I would like to comment.
A manager is not a manager because he knows the answers to everything, he is a manager because he can solve problems and create solutions. You don't need to do this yourself, and you don't need to be embarrassed that you don't have the answer.
Talk to the programmers you work with, you have a good relationship with them, so this will make it easy. They will appreciate the fact that you value your opinion, and make you seem more like a human and less like the pointy haired boss.
Talk to the customer and see what they want. In my experience, it is rare to have an all encompassing spec, and most customers will be grateful that you want to solve problems now rather than when you are in final UAT and the delivery deadline is looming.
Bottom line, communication. The old saying "its better to keep your mouth shut and be thought a fool, then to open it and have it confirmed" DOES NOT APPLY. It is because of this, that most people keep quiet because they think everyone else knows what is going on and they are the only one clueless, that much of IT is in the state it is today. IT is a science and science is about sharing new ideas and perfecting existing ones.
Do not sit and do nothing, this shows indecisiveness, call a review meeting, visit the customer, get others involved.
Also don’t try to do the work yourself – the bottom line is that as a manager one of your jobs is NOT to do actual work. Make a decision on who should do it, review the work, decide the format yes, but do not sit down and do it yourself.

Jules
Wednesday, December 10, 2003