Fog Creek Software
Discussion Board




Problems with Software Management

Several recent posts on here have pointed to "management" as possibly the biggest deterrent to success on many software projects.  Any theories why it's such a problem?  I've seen a lot of symptoms advertised here, as well as a few pat answers like "Managers are stoopid," but nothing that points the way to a solution.  What needs to change?

management candidate
Thursday, February 13, 2003

Management should learn about Software development or better yet, management should be made of people with software experience. Of course this is not fool proof.

Prakash S
Thursday, February 13, 2003

Expanding on prakash's point

It is hard to aquire the skills needed to be a good project managers. You need project managers that can discuss/plan a project intelligently with programmers/QA, and understand when something is legitimate and when they are being buffaloed, and understand the business, and have enough spine to stand up to/effectively deal with sales/vps, and still be flexible/energetic enough to change plans, co-ordinate/problem solve for/with different groups (i.e. I know we told you to implement featureX first, but teamA is late with feature Y, so hold off on featureX and do featureZ type stuff).


It is a hard job and ALL these traits are rare in one person and I have only worked with one guy who can do all this, Tim, if you are reading this, I miss you.

Daniel Shchyokin
Friday, February 14, 2003

Another option for a good manager - someone who understands they don't know software and knows to keep out of the way of the developers.

Instead, they act as a referee - general guidance, deconfliction, keeping upper management off their backs, etc...

Philo

Philip Janus
Friday, February 14, 2003

It's easy to observe the managers making mistakes and I don't know if I would be any better. I've seen some really bad management where I work, but I guess it could be worse. One problem might be that the managers all come from technical backgrounds. The interpersonal skills needed for managers are hardly related to their technical education and experience.
On the other hand you don't want a manager with great interpersonal skills who doesn't understand technology. And how many people are good at both?
I imagine a great manager would be similar to a great parent -- they know how to let people develop their natural talents. It must be wonderful to work for someone like that. A great manager must have faith in human nature, tolerance of individual differences, and also has to expect a lot from people. Don't tolerate laziness, but don't think people will work harder if they're afraid of you. People will work harder if their efforts are appreciated, if they're made to feel special and important. How many managers understand that?
I guess the essential ingredient is wisdom, and you can't expect the average manager to have much of that.

PC
Friday, February 14, 2003

1. "Instead, they act as a referee - general guidance, deconfliction"

This does not work:

How can you referee when you don't understand the issue. granted you don't have to be a great programmer, but some understanding of software development is required (and it can't be just a general understanding).

I had a project manager at my previous employer who came into my cube and started asking me about the project.

PHPM: Are you done with X

ME: No, I am getting a class cast exception when I make this function call, and I do not know why. I will be done as soon as I figure this out.

PHPM (who claimed 8 years of programming experience by the way): What is a function call?

The problem with this is that to her any project description does not sound like:

"We need to define the Schema, Map A Set Of Objects To THe Schema, Design The UI, Code, Test Debug"

To Her It sounds Like:
"Blah Blah Blah I will be done on the 28th of June", She cant referee, she cant make intelligent decisions about coordination, she cant intelligently adjust the schedule, she is useless.

2."keeping upper management off their backs",

how can this happen when she does not know what is going on- lets say I finished feature X, but not Y does she know which i more important, does she know which one should have taken longer, suppose feature X "should" take 2 weeks and feature Y "should" take one day, suppose I do feature Y, and play doom for 9 days how will she know I've been goofing off or am incompetant unless she has enough programming knowledge to know the difference.

More important when she deals with management on such issues, lets say product needs to ship tommorrow come hell or high water, will she know to tell UMgmt. feature X should be cut and not feature Y? Will she know when QA hands Her A Test Schedule If its realistic, or will she bow to Sales and say OK 2 days of testing sounds ok.


A project manager NEEDS hands on programming experience, otherwise they cannot deal with techies, and they are not capable of intelligently making the decisions that need to be made on  ALL software projects.

Joel: correct me If I am wrong, but isn't one of microsofts criteria for managers: NEVER hire a manager that is incapable of doing there subbordinates jobs.

Daniel Shchyokin
Friday, February 14, 2003

>>Another option for a good manager - someone who understands they don't know software and knows to keep out of the way of the developers.

Instead, they act as a referee - general guidance, deconfliction, keeping upper management off their backs, etc...<<

Also, economic planning, reports, etc.

That's my description:) MBA degree instead of Computer science, general management skills instead of programming ones.
I had spent about 40% of my time "keeping upper management off" my developers' and my client's backs, really hard work...still can't understand why tops always think that they know how to program Java better than Java developers do and how to do business - better then their clients ...

Slava
Friday, February 14, 2003

Daniel, it looks like you had a bad manager, that's all.
Good manager doesn`t do his subordinates work, he manages his subordinates well to let them do their work.
His work is to find an expert and let this expert solve the problem.
Another example, not from programming field: I worked in bank when I was young, and our president didn`t have a clue about security guards work, about cashiers work, about ATM supporting personnel work, etc - how did he managed to be a bank's president?
And where are you going to find a guy that can count money, work with currency detector, carry a gun to protect bank's property, fix a broken ATM, work with credits and loans, etc, etc - to fit a position of bank's president that knows how to do work of his subordinates?

Buy a book about management principles and read it, you'll understand what I`m talking about.

Slava
Friday, February 14, 2003

As I learn more about management, I've been thinking that programming is a lot like a team sport.  You may have some good players, or a good coach, but until everyone learns how to work together and figure things out, the process will always be lacking.  The most successful projects i've worked on seemed to come after a few rough starts, even when really good people are involved. 

Vincent Marquez
Friday, February 14, 2003

Daniel said it right when he said that managers need backbone to stand up to the customers' pressure. Like him I've only had one who has had it (mind you, he was just as mean to us if we were slacking, so it cuts both ways :-)

I don't think (s)he needs to be a developer himself though, he just needs to be able to smell bs from far enough away and be able to take the advice of those who do know.


Friday, February 14, 2003

<Vincent>
As I learn more about management, I've been thinking that programming is a lot like a team sport.  You may have some good players, or a good coach, but until everyone learns how to work together and figure things out, the process will always be lacking.
</Vincent>

I really couldn't agree more. 

I like this analogy because good teams have great leaders.  And all great coaches have systems that promote winning.  In order to win with the system however, you need players with talent that buy into the process.

Its the same with a technology team:
Do you have a good leader?
Does he/she have a good system?
Do you have talented professionals?
Does everyone buy into the system?

Unfortunately, I have never been on a 'team' where I could have answered 'yes' to all of these questions.

Canuck
Friday, February 14, 2003

Daniel wrote:
"A project manager NEEDS hands on programming experience, otherwise they cannot deal with techies, and they are not capable of intelligently making the decisions that need to be made on  ALL software projects."

I would have been inclined to agree with you on, save for my current manager, of the last two years.

He is non-tech, in every sense of the word.  Yet, he has delivered more products on time, on budget and within scope than anyone I have ever worked with before.  His last project had a $2.5 million budget with a staff of 10.

How does he do it?

1.  He makes it his job to allow us to do ours
2.  Testing is his first priority
3.  He trusts us
4.  Tremendous amount of common sense
5.  He plans, but with our estimates

Please, please don't ever quit!
Friday, February 14, 2003

"Joel: correct me If I am wrong, but isn't one of microsofts criteria for managers: NEVER hire a manager that is incapable of doing there subbordinates jobs."

I have heard from a few successful executives that there's a go/no-go point in the "small company growth curve." Somewhere around the 100 employee/$50M point companies reach a critical mass. Whether they continue to grow, implode, or stagnate is based on a fairly simple metric - can the founders make the shift from small company to large company mentality? And one key indicator - when middle management becomes a necessity, do they hire technicians or leaders?

Technicians: Fail
Leaders: Prosper

Middle management should not be dealing with how the programmers do their jobs - they should simply be coordinating the job getting done. If the programmers need an ombudsman to deal with management then you get the most senior developer to do that job.

Here's a hint - the entire military runs this way. Officers don't know how to service tanks or launch missiles. They are there to lead.

Finally, the best boss I've ever had (out of a cast of dozens) is also the least technical boss I've ever had. He coordinates and prioritizes, but how things happen is completely up to me.

Philo

Philip Janus
Friday, February 14, 2003

Phillip Wrote:
<<
"I have heard from a few successful executives that there's a go/no-go point in the "small company growth curve." Somewhere around the 100 employee/$50M point companies reach a critical mass. Whether they continue to grow, implode, or stagnate is based on a fairly simple metric - can the founders make the shift from small company to large company mentality? And one key indicator - when middle management becomes a necessity, do they hire technicians or leaders?"

Technicians: Fail
Leaders: Prosper
>>

I am not saying you need one or the other, I am saying you need both. And "Leaders prosper" is a less than scientifically accurate statment, i've seen plenty of "leaders with no technical skills" fail miserably, just as technicians.

And, as far as me having a bad manager, my point is I've  seen lots of bad managers which were either "Technicians/Leaders/Neither" and you need both qualities, and they are rare, and thats why most software projects fall behind

As far as Slava pointing out that the manager delivers projects on time because he "trusts" his developers, then he is lucky not good, because lets say he had to build a team from scratch, if he didn't know how to program (and I am not saying godlike programming skills, but at least some basics)how could he hire good programmers.

As Far as the Branch Manager Example: yes he doesn't know security guard jobs, janitors jobs, maintenance jobs etc... but you better believe they wouldn't hire a branch manager who didn't know: financial accounting, auditing, govt. regulations, loan under writing,how to use the tellers software etc ... Mind you he doesn't need 50 years of expereince as a teller, or be a master at any of them, but he does need to know them.

Daniel Shchyokin
Friday, February 14, 2003

Manager all suck. It's the fault of business culture.

The biggest problem I see with software management is the same problem with ALL management. It's the business culture of putting people whose job is not to "do" up on a pedestal and it's the self infatuation of so called managers who only see the power trip they're on.

In my opinion, a manager should be a referee, a prioritizer, and a facilitator. In practice, most managers think that their only proper role is to "lead" by force, and this usually degenerates into nothing but coercing people under them to do things that the manager can't understand or comprehend.

Whenever I've had a resource problem or needed something in terms of management support, managers have been the absolute last people I'd elect to ask for a decision or support.
Leadership is most properly exercized by example. Most managers confuse leadership with an authoritarian mentality and glorification of themselves.
Lastly, management generally attracts the wrong candidates. People who gravitate to management and are accepted in that culture tend to have narcissistic personalities that should *not* be entrusted with leading anyone.

Bored Bystander
Friday, February 14, 2003


If you like this thread, you'd probably get a kick outta my blog:

http://www.csis.gvsu.edu/~heusserm


heh.

Matt H.
Friday, February 14, 2003

One problem I see almost universally in the practice of management, and elsewhere as well, is people actively ignoring uncertainty and dynamism in the world.  Instead of acknowledging it and managing it, they ignore it.  What's more, I don't know of any more reliable way to send a manager into a panic than to raise the issue to awareness.  It's actually kind of comical, unless you happen to be unfortunate enough to be impacted by this behavior.

For example, on a project a while back the manager wanted our first task to be to put together a project schedule.  This of course seems reasonable.  The thing is that once the schedule was developed, any deviation was looked on as mortal sin.  It got so that the primary goal of the project seemed to be making all the plan's predictions come true, rather than producing a quality product in a reasonable amount of time at a reasonable cost. 

My theory on what happened in this instance, and in so many others, is that the manager wanted to take a snapshot of the world at project inception, build a model plan to achieve his goal, and then hold the world constant while we followed the model.  How naive is that?  Instead of working to have the plan meet the goals of the product, we wound up working to make the product meet the goals of the plan.  Needless to say that the outcome of that effort was dismal, at best. 

I don't understand what motivates this kind of behavior.  It's reasonable for the manager to want an accurate assessment of the situation as early as possible, so I understand why they tend to use early estimates as promises.  What I don't understand is why it has to be a scalar value.  Why not a range?  A range will always be more accurate than a point and it carries a great deal more information than a point.  A range can reliably be used as a promise very early in the project, but points cannot.

They do this over and over even though they know it's going to hurt them, the product, and the team.  What motivates this self destructive behavior?  What kinds of metrics are managers usually evaluated against?  Maybe that would explain it. 

And why is (manageable) uncertainty so scary?  There are good tools and techniques available for dealing with it, it's not too hard to understand, and properly managing it is a great way to push up quality while pushing down schedule and cost.  Why are they afraid to update their plans when new information becomes available, both good and bad?  Why do they treat models as if they were a high fidelity representation of reality, instead of a useful abstraction that simply allows them to focus?

I'll probably never be able to get on well with management because I really have a hard time getting inside their heads.  I understand the business pretty well, I think, and so much of what I see management seems contrary to what I believe the goals of the business are - almost irrational at times.  It's scary.

confused coder
Friday, February 14, 2003

I've seen that "deviation from the schedule" fear myself, and I think it's common and incredibly destructive.

I believe that this often comes from a human tendency to want fixed dates.  Contracts often specify that the product must be delivered by a particular date.  Customers want firm dates.

There's nothing wrong with this, as long as everyone understands that these dates are estimates.  When management is unwilling to return to the customer and say "Our server exploded in flaming chunks, which set us back three weeks," then you have trouble.

On the gripping hand, it is *hard* to go back to a customer and say that you've screwed up.  I don't envy management when they have to admit that something's going to be late.

IMHO, it's a character issue.  Management should be willing to trust its employees and be honest with its customer(s) about actual progress.

How many honest people -- not just managers, but people -- do you know?

Brent P. Newhall
Friday, February 14, 2003

> Here's a hint - the entire military runs this way. Officers don't know how to service tanks or launch missiles. They are there to lead.

This is not true, and it's worth looking at because military organisations are extremely effective and good at what they do. In professional armies, officers most certainly do know how to do the main jobs of their subordinates. They are forced to undergo the same tough basic training.

Even pilots of the most advanced fighters are required to to be able to refuel them and perform basic maintenance without help.

Getting back to software, the whole point is that people without understanding of software will not be good managers in softwre environments.

Must be a manager
Saturday, February 15, 2003

<<Here's a hint - the entire military runs this way. Officers don't know how to service tanks or launch missiles. They are there to lead.>>



The commandant of the marines corps still has to pass his marksmanship test every year or he retires.

According to Tom Clancy the commander of an aircraft carrier can ONLY be a former fighter pilot, not a surface ship commander

Daniel Shchyokin
Saturday, February 15, 2003

"Getting back to software, the whole point is that people without understanding of software will not be good managers in softwre environments. "

This is an interesting point, maybe some of you could comment further on it.  The teams I've worked with typically have two leadership positions.  There is a technical lead who is responsible for planning and executing the software development.  This person has to be very knowledgeable about all aspects of software design and implementation and typically acts as the team's "guru" of sorts.

The other position is the project manager.  His job entails managing the process by which the team produces the product.  This fellow isn't always a "software guy"- he relies heavily on the tech lead for summary information about that part of the product.  (He also relies on leaders responsible for other product components like documentation, media, and so forth).  The main inward facing responsibilities of this guy are to manage the schedule and budget, make sure that everyone is coordinated, manage project risk, and so forth.  In other words, this guy manages.

The trick here is that the interface between the manager and the tech lead has to be effective.  The manager has to keep the tech lead posted on the state of the business so that the tech lead can assess the impact of changes to the product.  So, for example, if priorities change, the tech lead can adjust his plans to accomodate them.

Similarly, the tech lead has to communicate important information to the project manager.  He needs to provide information about changing estimates, work completed, and so on - anything that might have an impact on the overall product plan - so that the project manager can respond to it accordingly.

This system seems to work pretty well for us.  I've been in the role of technical lead a few times now, and I've always been trusted enough so that my decisions are respected.  I've always (except once) had a lot of esteem for the project managers I've worked with, as well, so I've always tried my best to accomodate them in my plans.  This has worked well, so far.  I'm planning to try the project manager role soon though, so that's one reason I posed the initial question.  I want to make sure I do a good job.

So what I'd like to know is, the quote mentioned above seems to imply that a single person is performing both of the roles I've tried to describe above.  Is this common?  Are most of the complaints mentioned in this (and other) threads coming from environments where only one person is doing both of these jobs?  Should only one person be doing both things?

management candidate
Sunday, February 16, 2003

"a single person is performing both of the roles I've tried to describe above.  Is this common? "

- most times, yeah.

Prakash S
Sunday, February 16, 2003

"The main inward facing responsibilities of this guy are to manage the schedule and budget, make sure that everyone is coordinated, manage project risk, and so forth.  In other words, this guy manages."

Mgt Candidate,

this can work, but the criteria is that mgr. guy, and sw guy must trust each others motives and judgement a lot, i.e mgr guy, must trust sw guy to decide what a risk, but step back for a second if all manager guy does is keep schedule, listen in on meetings and write emails, i.e does none of the technical leadership work, assesing priorites etc.., well if it were my company that persons title would be admin assistant not a manager.

Daniel Shchyokin
Sunday, February 16, 2003

My theory is that the reason management seems to most often be so bad is for the same reason the government seems to most often be so bad - because they are. It's just that we don't see just how horrid it would be if there were none whatsoever.

A few ill-fated open source projects are a good way to look at just how programmers can behave when no one is managing their efforts.

The key to remember here is that many times managers are not actually called managers. The lead programmer is usually in fact a part-time manager. Project management and technical management are also quite different roles, as has been pointed out, but both are the roles of managers.

On the whole, I don't think bad management in project management, or even just project management in the software field, is bad for any special reason - it's bad for the reason any other role can be done badly. Bad management is bad management.

Some reasons:

1) Personality conflicts, not properly resolved.
2) Management style and worker style conflicts, not properly resolved.
3) Insufficient ability in Management skill (it IS a skill, like any other).
4) Insufficient knowledge of field of work to manage effectively (ie, someone who is incredibly computer stupid trying to manage the details of software development directly, rather than delegating the task to someone who is more knowledgable and skilled).

That seems to cover bad management in all its forms and flavors.

Brian Hall
Wednesday, February 19, 2003

*  Recent Topics

*  Fog Creek Home