Managers Dont Code

Yes, but they should!

No, they shouldn't.

There are those who emotionally consider code the same way some plantation owners consider dirt. They sit on a porch sipping lemonade wearing a clean white suit and direct things, while everyone else touches the dirt. Don't do that. The dirt is where the plantation's product grows.

Chances are, the plantation owner has never touched dirt in his life; being born into a wealthy family which has always had servants (or slaves if we're talking about the period before 1865) to do the work. Most engineering managers I've met were engineers before getting promoted; so even if they don't touch dirt now they know what it feels like.

Some such managers were excellent coders but poor managers - they'd be better off holding the shovel rather than the whip. Others were poor engineers but good managers. Leading people is a skill unto itself; and while a manager should be familiar with the work they are managing; they need not necessarily be an expert at it.

I believe that every manager in a software company or an IT shop should spend some time every year doing real, live programming. And not just toying around on the side, either. Let's say that for 6 weeks out of every 52 a manager should be assigned to a real development project outside his/her normal managing domain. This would accomplish several benefits:

Keep managers connected to the technology
Remind them what real coding is like
Ensure that they are thinking about SuccessionPlanning
Provide exposure to an entirely different part of the business
For many managers, increase their level of job satisfaction

Level 1 of adopting this practice means that you have put the option in place for managers who are interested.

Level 2 means that this is a mandated activity, and their coding performance is used as part of their annual evaluation and bonus allocation. -- BillBarnett

Perhaps managers could combine writing software with their duties as ObjectOrientedManagement.

Should we also require every programmer in an IT shop to spend some time every year doing real, live management? If so, what would we expect that to achieve? If not, why the asymmetry?

Because managers are responsible for what the programmers get done, but not vice versa.

Only theoretically. In practice, programmers do suffer from mistakes of his manager.

Suffer is not the same as responsible.

How can be responsible for mean anything other than will suffer the consequences?

You've reversed it. If I'm responsible for the team, then I will suffer the consequences of any inadequate performance. However, if I suffer the consequences of someone else's inadequate performance, then I am not necessarily responsible for them. If I'm a programmer, and the CFO screws up and the company goes bust, in what way am I responsible for the CFO's actions?

Does it make sense for Bob to be responsible for what Alice did, but Bob will not suffer any consequences of Alice's actions?

No. But I didn't say that The manager is responsible for what the programmers did, and as such may get fired if the programmers did a poor job. The programmers may also get fired if the manager did a poor job, does it matter practically if he is responsible for it or not?

''Yes. The programmer can't do the job of all the people who he might be impacted by. On this argument, the programmer should spend time as CFO!'

The striking difference here seems to be power instead of responsibility, the manager can fire the programmer, but not vice versa. The manager can step in can write code, but the programmer cannot step in to manage. So we have this page but not ProgrammersDontManage?.

I think power is interesting, but it's not the main difference here. I still maintain that it _is_ responsibility.

Perhaps "control" is more appropriate. ManagersDontCode is a problem because the manager can control how the programmers code, and sometimes the managers has to approve how the programmers code (e.g., for buying the tools and the libraries used, etc), and thus make technical decisions which they are not equipped for. OTOH, programmers cannot control how managers manage, nor do managers need the programmers approval on how to do his job.

Because managers are responsible for what the programmers get done, but not vice versa.

How is that relevant? We might want to reap similar benefits:

Keep programmers connected to the organizational issues
Remind them what management is about
Ensure that they are thinking about succession planning
Provide exposure to an entirely different part of the business
For many programmers, increase their level of job satisfaction (well, erm... strike that)

How is "Bob is responsible for what Alice gets done" connected to the notion that "Bob should spend some of his time doing Alice's work"? I'm playing devil's advocate here, but we find "obvious" the notion that there is some benefit from management knowing more intimately what the work of the people being managed consists of; aren't there benefits from the reverse situation which we'd find "obvious" if it was common practice?

Because a manager's job is (partly) to keep the programmers happy, motivated and productive, and it's difficult to do that without having some appreciation of what a programmer does. It's not so important that programmers know and appreciate what managers do (although the quantity of nonsense talked about managers on this wiki might suggest otherwise). It might be good for them to do so, but it's not going to have the same impact on the eventual results.

And anyway, I wasn't arguing that programmers should not do managerial work (although it seems to assume there's nothing to learn in order to do that). Just that there is an asymmetry in roles, and so an asymmetry in requirement to do the other's job is not necessarily unexpected. -- AnonymousManager? :-)

When programmers have the aptitude and interest, there is tremendous value in rotating people through temporary team lead and management responsibilities. Firstly, this helps them explore other career paths, helps them develop important skills. Secondly, it gives them greater insight into the problems that a manager faces, and helps them internalize practices or values that are valuable to the team but not necessarily palatable to the individual developer. Finally, it helps the team by broadening the base of people who can take on leadership roles - which helps the long term viability of the team as an organic unit (a factor far too often overlooked).

In the ideal world, all the programmers on a team would be interested in taking a hand at the tiller, and so could rotate into these team lead/management roles. In the real world, I am less concerned about programmers understanding the needs of managers than vice versa. Because one of the most important parts of a manager's job is carving out a space in which programmers can not only be successful, but also enjoy themselves.

And you're right, it might not directly increase the programmer's job satisfaction. But maybe in a "there but for the grace of God go I" sort of fashion it might make them enjoy their normal role more. <grin> -- bb

A devil's advocate might crudely object to the above ideas as follows:

This is a nice idealistic vision, but totally infeasible in the real world.

Most managers, even if they protest otherwise, don't REALLY want to code, they want to control big empires of other people doing their bidding
Time spent coding would be an outrageously poor use of a manager's highly skilled (and expensive) time and effort
A senior manager would just browbeat a normal project manager into giving him/her a good assessment for coding effort
How could mission critical managers afford to take 6 weeks a year off from their real jobs to play around with technology? Important projects and deadlines would necessarily suffer -- bb

While I believe every software development manager should have been a proficient software developer first, I don't see the importance of maintaining that skill. Also, what tasks would you assign to a manager for this 6 week period? I would assume the tasks would have to be limited to trivial maintenance fixes and would probably not provide the benefit the original author envisioned. The manager needs the programming experience to understand, trust, and lead programmers, but I don't believe it is possible to maintain a high level of programming skill while also managing. -- AnonymousDonor

Managers who think they know how to code, but are not really very good at it, are worse than those who don't code at all. -- KrisJohnson

PairProgramming would help the project leader get the manager involved in meatier tasks than trivial maintenance, I suppose. It would also help address the problem of bad coding practices by the manager. But this would require all participants, the project lead, the temporarily-coding-manager, and the normally-coding-partner, to have the right mindset. TitlePhobia? could be a real problem in many organizations... -- bb

I worked on a project where the manager coded with disastrous results. He would never test any of his changes but would check them into SourceSafe. The resulting breakage would take the rest of the team hours to sort out. Every day he spent coding cost us time totaling several days of repairs.

Managers shouldn't be exempt from the rules just because they're managers. If they are, then nothing can help you.

Be thankful that he checked them into the source base.

Oh please. Particularly Bill, in his "Devil's Advocate" post above. I am a manager and a good one. And this discussion, IMNSHO, shows a lack of understanding of what effective managers do.

First level technical managers rarely care about controlling big empires. We leave that game to the big boys and girls.
Engineers do respect managers with technical skills. And there are lots of ways to keep those up to date without doing programming assignments. Personally, I write open source software in my free time. And read articles here. And, etc. etc. etc. But the people I manage also don't want me second guessing their technical decisions. They're just as happy that I don't write code on their projects.
A managers job is to manage the development system - which includes people, group dynamics, process, culture, and a thousand other things. Designing an effective development system is a much different problem than designing a software solution.
The boss is always the boss. Putting the boss onto a development project serves only to distort the project in all sorts of unhealthy ways. Who's going to be comfortable reviewing my code or criticizing my design?

I've gone back and forth between management and being a senior technologist. I'd suggest that anyone wanting to improve the way management is done should try the job for a couple of years first. Then go back to being a technologist - and watch and reflect on what effective managers do.

Getting off the soapbox now.... -- HowardFear

I would have to agree with most of the above wholeheartedly, but have one comment about "the boss is always the boss". Some of the most effective management I have seen was in a sort of unusual situation: corporate R&D group where compared to the immediate manager everyone in the group was better educated (each member had at least one Ph.D), most were more experienced, and all were better compensated. The group was directly responsible to the CTO, who had made it clear to all involved that the middle manager was the most expendable member. However, this resulted in an interesting dynamic. The middle-manager fit well into the role of facilitator rather than supervisor, and this really worked well because while he respected the technical competence of the group, they respected his duties and recognized their worth. It struck me that this model was perhaps the most appropriate for several high tech situations, where core work is done by people brighter and more educated than most if not all of management - with all the personal problems that can entail. It only works through mutual respect, which can be hard on both sides it seems.

Been there, done that. One of the roles of a manager should be facilitator in nearly all companies, I would have thought. Certainly, most of my team know a lot technically than I do - and some of them are definitely brighter. There's a fair bit written about this and the dynamics that follow (one thing that happens is the team members find themselves having to train the manager in the technology in order for him or her to make the right decisions (at least for those (common) decisions that are not completely technical) - this gets called "training up". I think we're into WhatIsaManager again here.

Management and coding are two completely different tasks, requiring different skills and different focuses, and trying to do both reduces effectiveness in both areas. ManagersDontCode is not an AntiPattern. Managers should be technically aware, but it's best to keep them away from the code and to keep the programmers out of the business decision-making. It can be good for individuals to move between management and coding, but no one should have both roles on any particular project.

The AntiPattern is when a manager-who-doesn't-code dictates the use of particular development tools, programming languages, coding standards, and so on, or when the manager-who-doesn't-code makes technical decisions.

-- KrisJohnson

Not necessarily. The choice of development tools (and perhaps programming languages) isn't entirely a technical decision

True, but when managers makes such decisions without consulting the developers, and make the decisions based upon magazine articles or things the development-tool salespeople tell them, then it's a problem. This is a common symptom of the PointyHairedBoss. See also OldRulesWithForgottenReasons.

There is also an AntiPattern when the manager-who-shouldn't code doesn't listen to the advice of his experienced team and continues to do so with disastrous consequences. As others have already mentioned, in the end managers are people too and we have to learn to deal with the good and the bad. -- BernardFarrell

Howard's comments above especially resonate with me, and go to the heart of this issue.

My thought in posting this originally was that it shouldn't apply only to first level technical managers, but to everyone all the way up the chain. Whether this is feasible in a real organization, I guess I was motivated by how great it would be to work in a department that could actually operate this way.

Whatever the level of involvement, it is important to put managers outside their normal business domain, partly to counter the "boss is always the boss" problem that Howard rightly mentions, partly to broaden the manager's experience, and partly to help instill a sense of newness, of BeginnersMind, to the tasks at hand.

I have certainly run across a significant number of managers who say they really WISH they could take some time off and do some coding; perhaps it would be more productive to think about how such "sabbaticals" could be enabled in a corporation, rather than get all Inquisitorial and try and enforce that they MUST be taken.

I also think that Kris has made a very interesting distinction - the DarkPattern here is not precisely that ManagersDontCode. It has more to do with inappropriate decision making, role confusion, and career paths that take people too far from the hands-on roles they especially enjoy. -- bb

Somewhere in there we started grappling with the question, WhatIsaManager.

Maybe we can look at different types of managers who don't code:

Managers who have never done any programming.
Managers who used to be programmers, but have been coerced into management roles due to circumstance.
Managers who occasionally act as programmers (but aren't doing so right now).
Managers who used to be programmers, but now exclusively do managing and want to keep it that way.

I think the first type should not be forced to do any programming. It is unlikely that they can get enough training and experience to really understand what professional programmers do. A more likely outcome is that they will write a few HelloWorld programs and decide that programming is easy. It's better if these managers understand and accept their ignorance.

Similarly, the last type is "hopeless" - they will never put enough work into it to really get any insight into what it is like to develop software with current technologies/tools. They may play around with things once in a while because they find it interesting, but I don't think it makes sense for the company to mandate it. Usually, these managers are willing to let the programmers make the technical decisions, so that they can concentrate on the management tasks. (But occasionally you will find one who thinks his experience writing COBOL programs back in the Seventies gives him the moral authority to make technical decisions today, and this can be a problem.)

For the middle two types - the people who want to code and will do so again - periodic reimmersions into programming would be beneficial. This is especially true if those managers still consider themselves to be programmers, and will be making technical decisions as if they were programmers (rather than delegating those decisions to the real developers), or if they serve as mentors/teachers of the developers they are managing.

-- KrisJohnson

Would it also be helpful to distinguish managers according to what kinds of responsibilities they hold, besides "managing people"? (E.g. technical lead, project manager, chief architect, or whatever.)

I find I spend a lot of time dealing with the damage the first type of manager does to things. They've never developed. They never intend to develop; their interaction with computers is reading email and writing long word documents to email to people. And yet, for some reason in many organizations, they turn up to technical meetings and make technical decisions.

They do this based on a variety of things: what Computing's last headline on the subject said, what their nephew (who's doing graphic design at some place that's been a university for a year) mentioned about the subject, what the salesman told them, what the guy in the next building muttered about while on a smoking break...

Putting them somewhere near the workfloor for a while might be a good idea. "Here, we'd normally spend 10 minutes writing a Perl script to do this, but since it was banned because open source software isn't secure, we'll spend three days writing something in Fortran... and hence the project will be at least three days late..."

{Personal experience: company trying to pick between CVS or ClearCase as their standard revision control system. I offer to give the committee a quick talk on both, having used both. It transpires that no-one on the committee, or anyone they'd talked to had logins on any of the systems the rcs was for... we concluded they were making the decision based on the colour of the box the software would come in...}

Sadly, they seem to feel that the people who actually /do/ things are beneath them. That kind of aggrieves me. Management is great when it works. They go run interference and stop the customer bugging the developers, they do the paperwork, fill in the forms, arrange for machines to arrive at just the right time... but they're peers in the process. We need them, they need us. The managers that don't code seem (a lot of the time) to look down on developers, like we're the new BlueCollarWorkers? or something.

Discussing this with people, we arrive at a theory that this is a conflict between an old-fashioned view of management and a new management class. In most of economic history, managers were the experienced people. The wise ones. The ones that had done the job for 20 years and understood it. You put them in charge of the young'uns so they didn't stray too far.

We now have a class of "professional managers". They manage things. They seem to feel it doesn't matter what they manage, and they don't need to understand what they manage. This wouldn't be bad, were there not a hang-over idea from before that management is technically superior to the workers under them and gets to make decisions and inflict them upon the workers.

I don't know how true this is, but it certainly seems a reasonable explanation as to why the managers tend to be 1) younger than me, 2) don't do IT and 3) get to make technical decisions... -- KatieLucas

I have certainly run across a significant number of managers who say they really WISH they could take some time off and do some coding.

You don't just do coding. Coding is one part in a long process the begins before the coding and doesn't really ever end. The fact that they wish they could "do" coding means they don't understand what they are talking about. Development is a profession. People don't talk about doing some brain surgery. -- AnonymousDonor

The managers who express this wish are generally former programmers. They already have the skills; they just don't have time to exercise and improve them. Managers without programming experience are generally uninterested in trying to do it, as programming is considered to be a step down in the management world. -- KrisJohnson

The key is former. They won't be participating in the design. They won't be fixing bugs.

Why not? That's what I used to do a fair amount of when managing software projects. Assuming you have a development background, it's a good thing to work on - the task is fairly self-contained, often quite short, and takes an unwanted task away from the developers

They won't be training others. They just want to step in and code completely independent of the life cycle of a real product.

Big, big assumption here

Development is not for dilettantes and hurts everyone else who is spending full time on a product to think it can be so. -- AnonymousDonor

Agree about dilettantes, but those managers who want to be full-time developers for a while (with no management role) should be allowed to do so. Otherwise, you end up with nothing but clueless/out-of-date managers. -- KrisJohnson

Why would they be clueless and out-of-date? They shouldn't be making the technical judgements anyway. The rest can be done via reading and training and anything they want to do at home on their own time. -- AnonymousDonor

We may just have to agree to disagree on this. But I think having technically knowledgeable managers is valuable enough that companies should make the necessary investments to keep and nurture them. And one can't keep technical knowledge up to date just by reading books or playing around at home - real-world experience is necessary. -- KrisJohnson

I guess we will. Their experience won't be real-world though. It will be a hodge-podge of snatches of time. That's not real. In the trenches is real. They won't be getting very dirty. -- AnonymousDonor

Well, I'm thinking in terms of eight-month-or-more periods of time. I think that is sufficient to have useful experience. -- KrisJohnson

I'd agree with that. Does that happen? -- AnonymousDonor

The problem I have run into is where the Manager and Developer roles are used at the same time. I've seen a coworker try to use some valid things (like SourceSafe) and his manager refused because he didn't understand and would not trust the developer's technical expertise. The manager says that when he is "coding" that he is just a peer, but in the end, if he wants to or does not want to do something, he pulls rank.

There's definitely something valuable in having the higher-ups spend time periodically "in the trenches". After the Columbia disaster, Space Shuttle astronauts pitched in to help search for debris. From a story via Yahoo News:

: All three astronauts wore the same thick yellow shirts and yellow hard hats as the other searchers. The only way to distinguish them was by the NASA stickers and stickers of their mission patch pasted on their helmets.
: "We wanted to come down and get an idea what they are doing, as well as to thank these guys and hop in there with them and let them know we're completely behind them on this," U.S. astronaut James Kelly said. "The bottom line is they're part of the team. If they don't do their job, then we're not going to get to do our job later."
: Shawn Martin, a U.S. Forest Service worker from Washington who was among the searchers, said he was grateful for the astronauts' assistance.

: "They wanted to pound brush with us. They fell in line and stuck up with us and bled with us," Martin said.

Perhaps Programmers should spend the same amount of time being a user or tester.

And marketeer, sales person, business development, accountant, ... thereby leaving them no time to program

There's a division of roles in a company for a reason. While it's a good idea to be familiar with what others do, for better understanding and appreciation, it's impossible to do a meaningful stint at everyone else's job. It's possible for a manager to contribute to the tasks of the layer "below" him or her, often, but not as an equivalent to a team member, and not much more widely.

All the areas have their own skills and expertise. All those commenting on this page and others about the uselessness of management should try being a manager for a while. Then, maybe, you'd realize.

Actually, the suggestion at the top of this section is a very good one. Also, although the poster probably didn't realize it, the facetious suggestions in the second line are also quite good. To effectively program, one must understand the use of the system and how to verify the correctness of the software. Programmers need to understand how their software compares to competing products and how customers view their product. We need to get programmers out of their cubicles and into the environment where the software is used. Only then will programmers begin to understand what they need to do.

Yes, but I still stand by "it's impossible to do a meaningful stint at everyone else's job". Programmers are no different from many other people in this respect. I don't expect the industrial chemists working on the next kitchen cleaning fluid to take a stint as a contract cleaner. It *is* a problem in many companies that programmers aren't given enough information about what the end-user does, but that doesn't mean they need to go get it by doing the job themselves.

If the chemists had never cleaned anything, I seriously doubt they could make any advances in cleaning products. To solve a problem, one must be involved in the target environment, not divorced from it.

I think this is nonsense. So if you've never flown a rocket, you can't design one? "Involved" doesn't mean "has done the job".

No, but if (for example you're designing the cockpit controls that astronauts will use, you will do a better job if you've either had some pilot experience, or at least put in some time in a simulator.''

I've done it (manage and program) and it sucks. You can't do it. Management is a full-time job. Programming is a full-time code. Try to do both, and you do neither properly. Theoretically the idea of a manager doing a stint as a programmer sounds reasonable, but I can't honestly see how that would work. What does the manager do? Stop managing for a couple of months while he works on a programming project? And who does the management during that time? (One of the programmers?!) Not feasible, I'd say.

On the other hand, managers really should be ex-programmers, because nobody else has a real grasp of the problems and issues of programming, of what (in the office environment) makes programming easier and what makes it harder. -- ChrisSandow

Depending on how your organization works, it is possible that a person could be a manager on project A and then be a programmer on project B. If project A and project B go on concurrently, then there would be obvious conflicts about priorities, but if project B starts after project A finishes (or enters some non-critical state), then this could work.

I have been harboring this pet theory: Consider a tower or a ladder or a pyramid or whatnot of people in a more or less hierarchical order. A single-dimensional order - way too narrow and not regarding their actual knowledgeability and making no difference between proficiency in different fields. People often think that there's the brilliant architects or rulers or generals and then there are the hordes of lower lifeforms doing grunt work. Or that is the stereotypical view even if no-one believes in it. It seems to me that in reality, there would be the "lowest" worker who has to know everything and has immense freedom in deciding how to do things. If there are things that he/she can automate constrain into best practices or such, they can be delegated _up_ the ladder. Topmost are the people who only need to see the figures and provide feedback.

Reality is probably much more mixed.

(Sorry about the rambling. If this is felt to be irrelevant, feel free to delete or move it.)