Fog Creek Software
Discussion Board

The five-minute manager ...

I'm in a situation similar to when Joel was working at Juno in which the company culture is to pull in managers for one-hour design meetings to arbitrate disagreements on design.  The feature this time around is relatively minor and normally I wouldn't be so steamed about wasting an hour of my time, except that in this case the manager hasn't (a) as much read our project spec and (b) the last time I lost an argument in one of these "design meetings" with this manager it set our group back almost six weeks (and counting).  As much as I'd like to pick my battles I find myself rolling over when I shouldn't ...

So my question is ... how do you subconciously train your managers not to get involved bungee-cord-jumping style in the design disagreements of the implementors?  Failing that, how do I stand firm on my position without sounding like a stuck-up closed minded prima donna?  Does anyone have any techniques or advice on how to argue design so that it builds informed consensus instead of polarizing the two sides?

Monday, November 5, 2001

Do everything possible to reach an agreement or compromise before involving management. If the object of your debate is outside the spec, which means a manager must approve, involve management only after you're ready to present a proposal that all implementors can agree on.

The implementors are supposed to be the experts on implemetation issues. Sit down together and think of all reasons for and against all implementation ideas, then throw out all the bad reasons so only the good ones are left. Then talk about it for 10 minutes and make a decision. If you can't do that, one of you needs go work somewhere else.

Johannes Bjerregaard
Monday, November 5, 2001

Your solution is definitely valid but it assumes that the managers recognise that the implementors have specific knowledge and expertise in the area of design and this adds weight to the implementors suggestions and reasoning. What do you do when a manager simply sees your suggestions, no matter how concrete, as simply one of many valid points of view. When it comes to the crunch those managers are much likely to go for their own points of view because, after all, they believe that they're managers for a reason and that reason is that they have more experience to make these decisions.

Monday, November 5, 2001

I think that Johannes' point (one that I heartily agree with) is that in this situation you should ignore the managers. Keep them out of the decision process and it doesn't matter how much they do or do not value your opinion. And if you must involve them, give them only one option. (Or, to make them feel like they are being useful, present the same option in two different ways and let them pick one.)

So, once you've decided to ignore your manager you've got to convince your peers to do the same.

First, get away from the manager:
1) "Marvin the Manager is an idiot, why do we bring our problems to him?"
2) "Marvin is too far away from our code to have a point of view, why are we asking him about it?"
3) "We were hired for our brains (hopefully :), let's use them to hash this out!"

Second, talk amongst yourselves. You need to convince the people you are working with that you're in this _together_, and you need to be able to articulate the benefits and drawbacks of both designs.

1) "Here's what I think the benefits of your design are, and the drawbacks of mine. Can you tell me the same for my design?"
2) "Hey, I think you may have a good idea there that I'm just not understanding. How 'bout if we sit down with neutral peer Patty and see whether together we can get to the bottom of it."

Good luck!

Tuesday, November 6, 2001

I thought I was the only one with this problem, and it's being following me around for years ... I was starting to get paranoid.

The "bungi cord" analogy is cool, but it implies danger - and I've never seen a manager take responsibility when the coders don't finish on time, even if it was THEM that caused the delay indirectly.

It's really confusing when you're hired as a programmer, which is most definitely an above-averagely difficult job, and you're treated like a standard office worker.  Management should be there to "move the furniture around" and generally aid the programmers in there quest for a Ship-It award (;-p) and not second-guess everything - it's so demoralising.  So I sympathise.

Surely this is an ideal scenario where our friend the PM can step in and fix everything? 

Simon Stewart
Tuesday, November 6, 2001

I have a related problem. In my case, the manager is a technically oriented person, whose knowledge is slightly out-of-date. This gives him the feeling that his opinions are more valid than the designers (assembler experience vs. OO experience?).

This wouldn't be a problem, were it not for the fact that he insists on designing the class structure himself and asking developers to implement it - this approach has already put us months & months behind teams with more laissez-faire leaders. Get out of that one!

Unfortunately, I think I know what answers I'll get to this. "Call in healthy & get a new job!"

Tuesday, November 6, 2001

There is no 'one size fits all' response to this.  Often it arises as much from a lack of communication from developers as it does from the 'Munudgemunt'.

I work both ends of the piece of string in this, I develop and I manage developers, sometimes at the same time, sometimes not.

Almost all of the serious rifts in design I can remember have arisen out a misunderstanding out of what the product is supposed to do.

Once these design/implementation differences come up arguments happen and listening stops.  Regardless of which side of the divide you are on always take the view of explaining not only what you want but why and the implications of doing the opposite and of the implications of your own needs.

If its possible and there are two clear cut ways of doing something, do them both then decide.  Or at least do enough work so that you can pull it out of the hat when the wrong decision becomes apparent.

What you can't do is assume that you know better than everyone (either individually or as a group) else and your knowledge is more important and so you won't even take your design decisions outside your group.

That's fine for when it works but when things go wrong and major slippage occurs, guess who carries the can.  The manager you decided wasn't worth keeping informed.

When the arguments are insoluble ask for a third party either internally or externally let them arbitrate or facilitate an agreement.  Email me if you like :-).

As for the manager that feels that they need to be active in the design process (perhaps because that's what s/he's paid for, or perhaps because he can't trust the team to meet the promises he's made), engage them fully in the process.  If they want to do class design, let them, thank them for the design, implement it.  If in implementing it you need to change that design, change it, go back for approval, go back lots of times with lots of good ideas. 

Convince them that they need to delegate more (or alternately let them convince you that they really do know what they are about and that them designing classes was in order to get you to design better ones).

But the only way forward is to engage people in the process, being precious about who does what is counterproductive.  Sometimes managers are managers for good reason.

Simon Lucy
Tuesday, November 6, 2001

Malcolm: Thanks for clarifying. That's exactly what I meant :)

Johannes Bjerregaard
Tuesday, November 6, 2001

Simon Lucy writes: "When the arguments are insoluble ask for a third party either internally or externally let them arbitrate or facilitate an agreement. Email me if you like :-)."

Simon, that might just be the first good idea you've had all day.  :-)  Let me build on that, and see what everyone thinks.  What if the third party is us?  We're all developers here, I suspect.  What if, whenever we have a conflict in design, we post it here for review?

The upsides:  you get a third party of peers, fellow developers.  We're (hopefully) pretty talented as developers go, so you'd get an expert opinion.  We also have an interest in the human side of development, or else we wouldn't hang around here.  There's a lot of us, enough that you shouldn't get biases toward one platform or another.

The downsides:  we'd clog this forum.  (Maybe a separate mailing list would be appropriate, maybe with an "ad" here.)  If only one side of a dispute is a participant here, there's a chance of biased representation.  And finally, (whine) we don't have tiiiiime to get into all these arguments.  :-)

Personally, I'm actually a bit timid about doing this - it could get pretty consuming, and even ugly in a few cases.  Even so, who knows, maybe others here might think it's worth doing...

Paul Brinkley
Tuesday, November 6, 2001

If telling the truth seems inappropriate then lie through your teeth.  Tell them what they want to hear.  Stroke their egos.

So long as you do it ethically for the good of the team and company you have nothing to feel bad about.

Tuesday, November 6, 2001

One concern with this is that the manager is often the connection to reality.  Two technically-minded people can often get to arguing over a feature that the customers couldn't care less about.  It ties into the problem of doing things that are technically "cool", but are befuddling to the user.  "Yes, but with my idea, the customer will be able to type in the hex address of their entry in the database, and view it directly!  It's a great feature, I use it every day!"

Tuesday, November 6, 2001

I do front-end design. We arbitrate design decisions based on how well they meet user goals and needs within constraints of the project.

Sometimes that decision is based on the user research we've done up front in the project, sometimes it's based on usability testing. Regardless of how we know what's best for supporting user's needs, it has become a measuring stick that management agrees with and supports.

For back-end design, I'm not sure there's as simple a solution.

best of luck

Tuesday, November 6, 2001

Followup on the original situation.

Fortunately I was able to resolve the design problem just as Johannes (and Joel) suggested -- by having a sit-down with the coder and hashing it out.  Midway through she made a very good point and it finally dawned on me what she was trying to accomplish.  I think the difficulty was that neither one of us had a clear view of the problem we were trying to solve, and once she finally put it into words the answer was immanently clear to both of us.

It seems like a good design argument should proceed along these lines:

1. Understand what the problem is they're trying to solve. 
2. If the solution seems inelegant to you, list out and explain all your reservations with their design.  Write them down on a whiteboard if that helps keep track of them.
3. Once all your issues are out on the table, listen to their feedback and see if there is middle ground which you can use to create a common best-of-both worlds design.
4. Decide if this is a problem that needs to be addressed immediately or in a future version.

Tuesday, November 6, 2001

One of Joel's best essays IMHO was <a href="$8">Why Juno management was so much worse than Microsoft's </a>. Simon summed it up when he said "Management should be there to "move the furniture around" and generally aid the programmers ". If only it were actually like that....(now, in a perfect world......) all the time!

Tuesday, November 6, 2001

One of the biggest problems I have faced is when your manager actually _owns_ the company.

The only solution I found was to drop off.

(Spelling and grammar corrections welcome :-))

Leonardo Herrera
Tuesday, November 6, 2001

On arbitrating design disputes in this forum:

I think a forum for doing this might be useful, I doubt here is the right place though.  There's a few hillocks in the way, commitment is one as Paul identifies, another is that organisations might not like either their dirty linen or USPs being discussed in a public forum.

FUD is still marketing tool number 1 it seems.

On the other hand if you could anonymise the queries and have some kind of peer review that might be useful.

Simon Lucy
Wednesday, November 7, 2001

Leonardo Herrera wrote:

> One of the biggest problems I have faced is when your manager actually _owns_ the company. The only solution I found was to drop off.

Two things in that situation:

a) Remember the proverb "there's no sense in keeping a guard dog if you don't listen to him bark"; ie if he's paying me to do coding/design/architecture then it's *my* (not his) reponsibility to do it right: let him know that you'll listen to him re. requirements etc., that you respect all the invaluable work he must do as owner, but that a design decision must make sense to you and your peers (ie the people who he hired to do the job) if you will be the ones implementing it.

b) Sort out your differences/make decisions with the people who are competent to assist in this kind of decision making (eg your peers); if you need information from the manager, get information ... but the technical, design-level decisions based on that information are yours to make.

> I wouldn't be so steamed about wasting an hour of my time

Avoid discussing or defending design with such managers. Talk with them about other things (features, schedules, etc.). Answer their questions, briefly and at the appropriate level of detail. In case of difficulty, make sure he knows that you have in fact already considered almost everything in making your decisions (although you're always happy to get more information) and that you would be quite happy to explain it all, if they needed to know, and if they had a day or year or so in which to get fully up to speed. Don't forget to thank him for his help, and assure him that he can be confident in you.

Christopher Wells
Wednesday, November 7, 2001

Another approach is to not ask a manager, but a senior techie who does not have any stake in the discussion.

Present both designs to the senior techie and let him make comments on both, and let him choose one or the other.

Usually the techie doesn't have to make a choice, because a healthy design discussion builds after the two designs have been presented.

Christian Mogensen
Thursday, November 8, 2001

<Another approach is to not ask a manager, but a senior techie who does not have any stake in the discussion.

Present both designs to the senior techie and let him make comments on both, and let him choose one or the other.

Usually the techie doesn't have to make a choice, because a healthy design discussion builds after the two designs have been presented.>

I'd avoid any expectation that the "senior techie" should be expected to make a decision, but yes someone like that would be an ideal mediator.

The reason I'd avoid any expectation of them making the decision (while welcoming all the input and assistance they wanted to give you with making the decision yourself) is because "junior techies" need to learn how, when, and why to take decisions themselves if they wish to become "senior techies".

Robert Moir
Thursday, November 8, 2001

What would people suggest for the following type of

A group of chip and software driver engineers are
required to develop a networking product.  But
they don't know the difference between bridging
and routing and are convinced that the VxWorks
IP stack is broken because it doesn't facilititate
bridging between two ports that are attached with
different IP network addresses.

Meetings to discuss design are futile because of
the large number of attendees and low clue

What I'm trying to do is convince the manager
that the group needs to compose more detailed
specs before proceeding.  If people are forced
to write things down in more detail they will
have examine the concepts more closely.

Any other ideas?

Eric G
Saturday, November 17, 2001

Make them learn the difference between bridging
and routing. Shoot the ones that dont, or dont invite them to the meetings, whichever is easiest.

Tony McConnell
Saturday, November 24, 2001

A few observations and opinions:
- Once you decide your manager is worthless, it shows.  He/she will sense this in your interactions.  As a result his/her defenses go up and productive group problem solving is less likely to happen.  You need to give him/her some sense that you want to work together.

- You might start the discussion by reviewing the goals.  What problem are you trying to solve?  How does it affect the application and the customer?  When the problem is solved what will the outcome look/feel like.  If you both can agree on that, you have something to measure the different proposals against.

- Listen.  Make sure you fully understand the other suggestions.  Put them into your own words and play it back to the suggester.  People want to be understood.  After you fully understand and the manager knows it, than bring up any issues or concerns.

- Be wary of arrogance.  It is a relationship killer.  There are usually many good solutions to a problem, so yours is probably not be the only one.

- Maybe you should scratch all ideas on the table and start brainstorming again.  You can always come back to the original proposals if you don't come up with something new, and this will help the group gain a deeper understanding.

Joe Lombardo
Friday, December 7, 2001

*  Recent Topics

*  Fog Creek Home