Football is played in teams. Software engineering is more like, well, engineering.
There needs to be designers, architects, analysts, administrators, and so on. The project manager is not the designer, architect etc, but surely it is very clear, that there needs to be some architecting and so on in the project, too. The architectures and designs tell what needs to be done and what will be done or you will be fired unless you have some better ideas that we can surely discuss about.
I think what it comes down to is what motivates the members of your team.
I find that different management styles work for different types of people, and Iâll openly admit I micromanage a few of my developers, but if I didnât their work would be a disaster.
Other developers I can count on and trust and have no problem leaving them alone, I know they will deliver a quality product, and come to me with any problems early on.
You canât apply one rule to the whole team, it all depends on the personalities and work ethics of each member.
@Petr Macek
Of course what Iâm talking about is not micromanagement. Thatâs the point. This list of five easy ways to tell if youâre a micromanager is not especially insightful.
@keppla and sod
Nobody said that close managing equates to âdoing the teamâs jobâ. (btw I very much see the manager as part of the team)
When a manager points out to team members what they have done wrong (and not in a way that would undermine their self confidence) they can learn and the manager learns what that team member can do by themselves own and where they need more guidance.
That actually builds their confidence and and usefulness. Once they have been told they usually remember when they need to do something similar. Nobody enjoys having done a full dayâs work only to find later on that they have done it incorrectly. So by pointing them in the right direction and making sure that they do not go off on a tangent is a very good thing and is not âdoing the teamâs jobâ.
Working in one of the worldâs larger cities (London), communication can be very difficult due to different cultures that migrants have. No company can afford to discard them only because it is difficult to communicate with them as they are a large part of the workforce that is available. English can be a problem in itself. That is another argument for keeping a close eye on the progress a team makes.
From reading the comments, it seems that a lot of developers suffer from hurt pride. I can let them in on a secret. When a project fails, and I think it is safe to say we have all been there, and someone has to put their hand up and take the flak for it, it is the manager who gets it in the neck. And a good manager will do so without turning on his/her team and undermining their confidence and motivation because there are other projects to be completed and the team spirit has to be kept alive. But keep that in mind next time a manager asks you to explain why you did things in a certain way or why a major bug has not been caught in testing.
Luckily no major disasters ever happened in my days as a full-time developer, but I like to think that I had managers who I would have protected their teams like that and I know I am like that for my boys and girls.
For what it is worthâŚ
Iâm a coder/manager at my firm, and the CEO. But weâre small so that doesnât mean much.
I only answered yes to one of those and a sometimes to another but Iâm in total agreement with the article.
I think many people view Management as power but in reality, Iâve learned that you donât have power, you more expectation and responsibility.
Managers should make sure the employees are happy and productive and that they are on the right path towards meeting the organizationâs goals. That doesnât mean doing everything right it means working together to reach the goals.
Honestly, if being a manager was a reward for better work, they should give you less pay. I believe the higher up you are, the more responsibilities and effort (not necessarily work) is expected of you and youâre compensated by more money to make up for that fact.
How many managers have wished they could have a seemingly worry-free position with the same pay?
Jeff -
Most of the micromanagers Iâve met have been new, either formerly competant workers elevated to management, or outsiders with no specific technical experience. In either case (and itâs entirely understandable), they tend to focus on things they know. New former coders tend to focus on all the stupid things they were subjected to as coders: lines of code counts, interminable bug reviews, etc. Outsiders are just as bad because their only common knowledge with the coders is how to test the fire alarm system.
At some point, if your senior managers are astute, theyâll force your former micromanager into generating daily Gantt charts, preparing reports on vacation projections, etc., and theyâll too busy to manage you.
Is there anything to gain from it? At some point, for some price, your cusromer would like tor receive a workinh system.
Not to champion or debate any points already made, but something that should be considered as a different beast altogether:
Job security vs. economic woes.
Try not to make your obsolete.
I only take exception to #3. Taking this one too far, is the real problem. Not taking it far enough is also a problem. Unfortunately, too many times, developers duplicate efforts of other developers or have their heads down in code and canât see the big picture. A managerâs job is to remove obstacles, trust employees, and be a head coach for the team. However, this means that you have to watch the game and what your players are doing. Many times as a manager, I was able to find out that someone was trying to solve a problem that another developer was already working on or had already solved. Not sitting with a developer and finding out whatâs going on can be as hazardous as doing it too much.
I think it depends more on the approach, the intent, and the attitude. True, there are plenty of bad managers out there, but their job is enhance communication. Thatâs hard to do if you donât know whatâs going on.
Last (maybe).
Someone else blogged about Zombies today: http://tinyurl.com/8b7enh
Its one thing for a zombie-making manager (ZMM) to take this to heart (ZMM to-doâs: Get a heart) but what about those who are being zombified, especially in a tight market?
A positive attitude will help a lot. Yesterday and today, Joyce Meyer interviewed Dr. Leaf, a brain researcher, on her show. Dr. Leaf explained how memories are basically stored as negatives or positives. The negative thoughts actually release fear-related chemicals everytime their accessed with cause something like 85% of diseases. The positive ones actually release chemicals that bring healing to your body.
Being zombified could definately be taken as a negative. Some of the steps to take are:
Lastly, realize what you really deserve. Someday, youâll stand before God. Do you really want what your deserve or do you want mercy?
Point taken, though I believe a more relevant post would be how not to micromanage when you feel the urge to do so in the real world. Unless of course you recommend I fire everyone who doesnât meet my standards!
@KM
Ha ha those South Asian dumbasses. Thank God for Dan the great for getting some work out of them!!
I think youâre adding a racist undertone that isnât necessary. And itâs South EAST Asia. Iâm not calling anyone a dumbass, Iâm bemoaning a lack of ambition and professionalism.
Itâs like being an artist in some ways.
Do you think Picasso had someone telling him what to do? No, he may have influences from people or other artists to guide him, but not telling him how to create art.
OK, what do you do if:
- Your team regularly commits errors to make the editors of Daily WTF blush?
- Theyâve been doing it that way their entire career and arenât very interested in changing?
- Theyâre above average coders in the SE Asian nation you live in?
At least you can shoot zombies.
Well I have worked with people that codes like if they just got a frontal lobothomy, also that resembles their willing to improve their skills⌠well, basically their entire attitude in ever life matter.
Must of them are permanently crippled and no matter what you do they are not going to change.
When I have found myself in that situation here is what Iâve done:
First you isolate the troublesome member from the critical tasks (the kind of things that no matter how viciously programed, are not going to hurt the rest of the code). The less important or relevant the better. I call making some one a Potato Peeler.
Know, here comes the fun part, you give the rest of the team the task to meticulously peer review the code that the Potato Peeler (PP) builds. Next, every time the teams has to work extra hours you give the PP the chance to leave early. If he happens to mess something up, you give the task of fixing the issue to anyone else but him.
Suddenly everyone starts to noticeing that this guy is not contributing to the work that the rest of the team has to do and the magic element comes into play⌠GROUP PRESSURE.
You canât imagine how powerful group pressure is (Religions are build around it).
Suddenly you have an entire team demanding some results from the PP. That common inconformity ends bonding the team together (thatâs a psychological state called the common enemy perspective and again religions are build around that too). You can ignore an asshole manager but you canât do that with a whole team, right?
So either the PP starts changing his attitude in order to regain its place on the group or he succumbs to the pressure, alienating himself and eventually leaving the project. Both ends being beneficial to the rest of the team.
Believe me it works 8 out of 10 times.
Very good article, it remembers me Seth Godinâs âtribesâ. He separates management and leadership; youâre talking more about leaders and not managers. Anyway, I strongly agree with you.
Nobody said that close managing equates to âdoing the teamâs jobâ.
What you describe, i would not call micromanagement, because, as you say, it builds confidence and therefore is only temporary, after a while the managed people get what is expected, and you dont need that much control, because you created a working environment.
Micromanagement, in my terminology, is the tendency to try to literally control everything, without a clear exit strategy.
If it is like the firstposter said: there are no chances that the coworkers get better or even try, and they are producing WTFonly-code, there is no such exit strategy and you have to do all the work.
If they want to get better, and produce acceptable code, it is more like training them, iâd say.
But maybe i am just burned child with micro management, i used to Work in a company, where i felt, that i had to justify every tiny detail to an invisible, everchanging, secret plan inside the managers Head. Like in boot camp: for every action there is an equal and an opposite criticism.
It didnt matter if it worked.
There were no styles to adhere to (yes. indeed.).
The only thing in question seemed to be: would the manager have done it the same way?
Nice post Jeff. I am also reading Peopleware courtesy post from Joel. You two guys are doing great job of promoting developers. I started this company with my few friends and we were developers and now we are kind of project managers after 4-5 years.
As a founder we have great ambition for this company and would like to see our programmers enjoying their work. If we take that quiz yes we are micromanaging sometimes or most of the time but that is very dubious.
So far we were not doing it and we gave developers free hand to do whatever they wanted to do because we did not know what project management is. We trusted their instincts but what you do when client is not satisfied with the quality your developers are giving?
In fact you yourself is not satisfied with it when you see the output? You just go ahead and give the same to client?
The problem is its not developers do not want to do good work, its just that they do not know what is good.
Sometimes deadlines make them paralyzed and they get afraid to try new things as it may delay the project. Sometimes developers are not ambitious enough to try out new things on their own.
What do you call a code review process (inspired from fagan inspection method) which we have just started? is it called micro management where we are telling them what is wrong with their code?
I am confused here as I do not know whether I am right or wrong after reading this post and after reading Peopleware.
I dream of having an office like Fogcreek where programmers are treated like stars but are my programmers worth that? I am not sure. They may be and I hope they are.
I would really like if you can comment on this.
Iâd rather have the zombie horde than a posse of cowboys. Only CMM Level 5 writes bug free code. Thatâs why they write the code for our nuclear reactors and space shuttles.
Process and Big M methodology isnât zombie creation. Itâs development for grown-ups.
See The Zombie Horde vs. a Posse of Cowboys: http://blog.markturansky.com/archives/123
Chepech, your method did work miracles, in 1966- 1976 Chinaâs cultural revolution, during which Mao, after officially stepping down from the leadership, used the communist internal propaganda to persecute most of the new central leaders who he found unamusing. They all ended up dead in political prison. I believe both Starlin and Hitler did similar things.
In the beginning it would seem like the bad eggs are gone. But the social fallout from the process will create a tendency to resort to such public lynching every time some people experience some frustration.
I wouldnât want to be in your organization.
Damn, I miss her âŚ
@Mike Turansky
Only CMM Level 5 writes bug free code
Actually, if you read the article you quote carefully, NO-ONE writes bug free code. Even Part of CMM Level 5, which is a process, not an attribute of the coders, is extremely high levels of testing and reviewing. This is only actually suitable for very large or safety-critical organisations, where failure is disastrous, because of the terminally high overhead involved.
Also, thereâs a vital point that everyone involved apparently has a great deal of respect for each otherâs abilities.
The developers have even begun their own formal inspections of the code in carefully moderated sessions, a rigorous proof-reading they hope will confound the testers. The verifiers, in turn, argue that they deserve credit for some errors found before they even start testing.
From the verification groupâs perspective, says Pat McLellan, a senior manager, weâre aware that if there was no independent verification group, the developers would tend to be more lax. Just the presence of our group makes them more careful.
No-oneâs saying that you shouldnât have standards or procedures to work to, such as regular testing and bug tracking. But again, if you read that article, everyoneâs involved in making the process better, and making it work. Thatâs not zombification at all.
And finally:
Admittedly they have a lot of advantages over the rest of the software world. They have a single product: one program that flies one spaceship. They understand their software intimately, and they get more familiar with it all the time. The group has one customer, a smart one. And money is not the critical constraint: the groups $35 million per year budget is a trivial slice of the NASA pie, but on a dollars-per-line basis, it makes the group among the nationâs most expensive software organizations.
This is a fairly massive caveat, wouldnât you say?
And then thereâs this:
The most important things the shuttle group does â carefully planning the software in advance, writing no code until the design is complete, making no changes without supporting blueprints, keeping a completely accurate record of the code â are not expensive.
This is, if not a lie, at least an untruth. If you consider time as a resource, they can be massively expensive. And, as a commenter points out, $35 million per year to maintain a 420,000 line program which only works for a single customer is actually pretty damn expensive.
To summarize, your example wonât apply to 99% of software products, and Jeffâs point about having respect for the abilities of your employees still applies. Thank you however, for pointing me to a fascinating article.
http://www.fastcompany.com/magazine/06/writestuff.html