Should Managers Be Expected To Program?

Question

There are opposing views about whether managers (especially front-line managers) should be expected to actively program or not. Once a manager has 4 or more reports, some say it is negligent for them to code. There is too much other work to be done. Others say that if a manager doesn't code, he or she will lose their understanding of the product and the process. What experience and advice do you have on the subject?

Edit: Let me clarify. This is not about whether a manager should know how to code. This is about whether he/she should be actively spending time coding while in the manager role.

Answer 1

The latest StackOverflow podcast discusses this question with Michael Lopp.

Answer 2

I would say no your job is to supervised and offered assistant if needed . But if your are coding how can you manage effectively.

Answer 3

If a manager is coding, he's not managing. Managing well is a full-time job.

Answer 4

oh yes ... my current manager is a hardcore c++ programmer and I've realized that I do take him much more seriously than my last manager. He commands respect (as opposed to demands)

Answer 5

I believe that a manager should not be actively involved in the programming aspect of building an application. He is after all, a manager, and is expected to be guiding the direction that the project will take. The whole purpose behind having a Manager in charge of a Project is to have someone manage the workflow.

If a Manager gets into the nitty gritty of the code, he will not be able to effectively delegate tasks to his team. And I disagree that you need to code to gain an understanding of the process. At the management level, a high level understanding is quite sufficient. A manager knows the functionality that is required and he can tell if that is being achieved.

Answer 6

The programming manager always has to choose if he's going to be programming or managing. When the project approaches deadlines and the going gets a little tough, the demand is high for both of these services at the same time. At some point he will not be doing any of the tasks well, putting the entire project at risk. On a personel level it can also put an unhuman strain on a single person.

Programmer and manager at the same time, yes, but not on the same project and keep deliveries in different time-frames.

Answer 7

Only in small shops. You don't seem to distinguish what the business needs from what the person needs.

If you're employed as a manager, you should be managing. That's hard enough to do without wasting company time on coding (believe me, I was a manager for a couple of years before coming to my senses).

If a manager wants to keep current with tech, they should do it on their own time, unless specifically demanded by the business. It's too easy for one of the roles to suffer if they try to do both.

That's my opinion, but I'm just one guy :-)

Answer 8

In my previous project the PM was also an architect/developer. Soon he did not have the time to handle either task decently, so the project was suffering on both fronts.

Answer 9

Can you describe in your case what are the responsibilities of a "manager"? The answer completely depends on what the responsibilities of a "manager" are in your team.

I am a manager for 6 people and I still spend a lot of time actively coding. It doesn't take 100% of my time to delegate tasks to other people. It doesn't even take 5% of my time to delegate enough tasks so everyone has something to work on. I do a lot more "manager" work besides task delegation and it still doesn't add up to 100%, so unless I was coding I'd be sitting around doing nothing.

Without knowing more, I would say there is no way that a manager needs 25% of their time per person to manage people unless they are an obsessed micro-manager constantly stopping by each dev to ask if they're done yet, or the organization is such a bureaucratic nightmare they are spending all their time in useless meetings.

Answer 10

I'd say it depends on the managers skill set. If a manger has no skill or little skill as a programmer then he or she should stick to managing. If this is a programmer that got promoted or a manger with significant technical skill then there is an expectation that the manager will spend at least a small amount of time coding.

Answer 11

In my opinion, if manager has some previous experience as coder, he has more respect in team (if he has been good programmer :) ). He has more understanding for the process, and he is more assertive to client/consultant/marketer demands.

He can give advice and tips to team members. He could be some kind of mentor for younger coders.

I would prefer to have as a manager good programmer with natural abilities in leadership and soft skills than a guy who has PMI certificate.

Answer 12

Consider this: as a manager, you're responsible for the performance of a team. If they do poorly, you're the person accountable.

So, your time should be spent on things that improve the performance of the team. For instance, on them becoming better coders. Being a coder yourself is certainly an asset there, but you have to use it wisely.

For instance, anytime you code something because someone on your team tried and failed (or worse, gave up on it as too hard), you're doing them a disservice. If you code something because the team would be late otherwise, you're fooling yourself. The worst kind of manager is one who makes themselves a bottleneck.

Answer 13

The manager should not necessarily code on the project, but it is a great help if he knows how to code well. This will help on many fronts:

• Estimates are much more realistic
• Manager can argue his case with management using his know-how
• He can spot design and implementation issues during code reviews

Answer 14

I don't think you can expect a manager to program. But my current manager does and he is extremely good and he has an enormous amount of domain knowledge. So I'm very glad he does.

Answer 15

I have known someone really struggle with being a manager once they moved out of also having their hands in the code.

So, whilst I think that in many circumstances, the amount of strategic and liason work required force a manager to become a non-programmer, it's a dangerous transition. In particular, a feel for project robustness, progress and overall code quality is something they may only have by being involved in programming. A non-programming manager needs more transparency in the development process.

I am very nervous about having managers with no technical experience directly responsible for development - I have seen this be a disaster where people bluff them and play games with priorities that don't reflect actual engineering needs.

Answer 16

If you expect to manage programmers you should be able to create at least some software. I had a lot of respect for our CEO who was a VP at Microsoft since he created some of the early prototypes and had even written some nifty apps such as one to tell you when the next bus was coming on your root. He does not write software on a day to day basis but when we are discussing how many hash functions to use in a bloom filter he is very involved. He also participated in code reviews and always asked good questions. So I think that managers should be able to write code even if they don't every day.

Answer 17

Maybe and Sometimes

If you are managing a small team, say 2 programmers, then the work of managing doesn't take all your time. It's fine to be an active programmer on the project in that case.

Managers' schedules are highly chaotic. You can come to work with an open schedule and then spend 7 hours in meetings. When you're a programmer, you need to be able to accept a piece of programming work, commit to delivering it, and do so. The chaotic schedule of a manager means that you don't know that you'll be able to do that.

As a manager I have at times been able to create new features that wouldn't otherwise fit the schedule, but only very small ones. Then when we discover bugs in my code, or learn that it should be done differently, we have to scramble to figure out who is going to do that work, because I'm usually busy again at that point. For this reason, it's a good idea for the work to be very small.

(C# Promote Local to Parameter refactoring was born this way. In hindsight, I suspect we would have made a better product if we had skipped it, and cut the Reorder and Remove Parameter refactorings, too.)

Answer 18

There really are no absolute answers here, just a question - is that manager effective?

To answer no just because a manager isn't supposed to do the nitty gritty stuff is a fallacy. I have never met a good manager who just delegates tasks and does performance reviews. Successful managing requires commanding a level of respect from your team. There is a higher chance of cohesiveness if your team believes that you know what you are talking about. A "project" manager can delegate tasks (I'm not putting down project managers by the way), but a manager leads, guides, teaches and provides a place to go for questions and issues. When managing a technical team, inevitably technical questions come up and we look to higher authorities and the manager is in that position. You also have to consider the style and skills of that manager, if they can be effective at guiding a programmer by doing some coding, then there is nothing wrong with that if it's effective.

Scale is important too. A manager of a team of 20 programmers who is actively working on a mission critical piece of code is likely not very effective, but take the same manager in a small company of 2 programmers and his/her contribution could mean the difference between success and outright failure.

What about complexity? If you are a programmer at NASA and you are working on the code that manages the telemetry of the space shuttle, I for one would want a strong technical manager who really understands the project beyond a mission statement. At the very least, a good manager should know enough to know where to get the right answers and bring the right people together and that takes knowledge, experience and an understanding of the problem scope.

Part of management is to lead, and if the manager is passionate about programming and code, even if he or she doesn't do it every day, that fire in the belly that motivates them to code every once in a while, even regularly, becomes contagious. Isn't that a good manager? One who creates an environment where their programmers are motivated? (Hasn't Joel said in the podcast that he tries to write code at least once a week?)

The answer to this question lies in the context of the organization, the skills of the manager as a technical leader and resource leader. The answer depends on the size of the company and the culture and most importantly it comes down to whether or not that specific manager is effective by writing code or not.

Answer 19

Yes.

• The head chef cooks.
• The editor in chief writes articles.
• The head trader trades.
• The director of cardiology operates.

There are tons of holes you can poke in this (see comments). My point is that there isn't such a hard line between "manager" and "practitioner". Once you stop actively coding and reading the code in your project, you become disconnected from reality very quickly.

If you are involved in personally interacting with and leading a group of developers on a daily basis, you should be coding.

Answer 20

It depends on the environment and the manager. "Manager" is a very broad role covering a spectrum from "team leader" to "CEO".

Technical managers should have a deep understanding of what their team is doing and how they are doing it. Engineers will look to their manager for guidance, advice, coaching and leadership - if the manager is no longer coding at all, he or she is unlikely to be able to coach the team effectively and may not have their respect and trust.

As a technical manager myself, my approach is that I still code but I no longer schedule myself into projects. This allows me to coach and lead my team effectively (because I am keeping my skills current), but scale back my coding time rapidly if the management demands increase.

Answer 21

I had a job with a great manager. Because of a large project he was actively involved with coding to help pick up the slack. The manager left and was not replaced for quite some time. We had an over-seer from the accounting department (Not knowing how to code was the least of his problems). We were to be more independent and self-managed.

Now I know what a good manager should be doing for their programmers instead of writing code:

1. Sit in those boring meetings where other managers discuss the label on a text box for half an hour.
2. Beg someone in accounting to pay for me to take the same training class that every other programmer in our department has taken.
3. Discover that one of the most important objectives to the operations manager is to have all development to occur in one application after our team spent the last two years developing custom websites without engaging in a shouting match during a weekly staff meeting. How I wished for a simple memo: All future development will occur here _.
4. Deal with a fellow staff member who spends the entire time during our weekly review lamenting about how much is on his plate, but doesn't mention that he has not actually accomplished anything in the past week.
5. Organize and prioritize the requests from all the different department managers.
6. Frequently review code for standards instead of waiting 6 months to discover to his astonishment how bad one of the developer's code really is.
7. Provide a place for programmers to work. You don't have to know what that is; just ask.
8. Treating people the same is not the same as being fair. The dress code that is appropriate for employees who work in front of customers is not the same for a programmer. Wearing a tie will not improve code. It just gives staff one more reason to return a head-hunter's call.
9. Be available when your staff needs you. You can't code at the same time.
10. Take the time to have a well-thought arguement to senior management why someone else should get paid to write documentation.

When requests for development are made, make sure the other party is willing and able to do the testing to approve the software in a timely fashion. Or better yet, make sure they make requests for applications they actually plan on using. 12. Know about the software you have to support and make sure your staff is prepared. We just paid $150,000 to upgrade our ERP software which now requires SQL Server 2112; hope the DB Admin can figure it out. 13. Know when your people are blowing smoke on how long a project will take. And don't base it on how long you think you can do it; base it on knowing how fast they can code by sitting down next to them and watch them work. Knowledge of the project itself is necessary as well.

Answer 22

There have been some great answers already, but the best one is the one we're all familiar with: It depends.

There are times, depending on the type of work and the size of the team, that a manager really needs to spend more time managing.

However, a manager of programmers will benefit greatly in delivering some of his management deliverables by also being involved in the code and the product. Who would you rather have performing a code review, a manager that didn't know anything about the difference between good code and bad, or the manager that knew from looking at the code that you really had great ideas and the ability to implement them? Which of those managers would know best how to distribute the various work assignments and how to work with the team's strengths and weaknesses?

But it really depends. On a large team and a very busy project, it's going to be tough for a manager to be actively involved in the code. And as others have noted, a lot depends too on the kind of manager. A manager responsible for many people and multiple concurrent projects will have a different type of duty than a team lead who's closer to the code and a specific team.

Answer 23

While I don't think a manager should generally be coding (as opposed to managing, which is their job); if a manager can code, and the project is late or in danger of being late, its nice to see the manager on the front lines and helping out. If nothing else, its a morale booster. No one wants to be in the office on Saturday working, while their manager is out and about periodically "checking in" through their blackberry.

Answer 24

Absolutely. Some reasons:

1. Keep current on changing technology.
2. Ability to know what is and isn't possible when committing to work.
3. Ability to jump in and help if the team falls behind, or needs a quick bug fix.
4. The team just plain respects you more because you know what your talking about, and know how to 'talk code' with the developers.

Answer 25

If you're managing some work that is difficult and respected then being able to do that work competently (and periodically demonstrating this fact to the team) is very useful and helps to earn team's respect. So for manager of high-qualified software developers spending some time on programming would pay off. On the other hand, manager of cheap coders in highly hierarhical organization may not bother.

Of course, manager should never take programming tasks that are on the critical path or close to it. The top priority in a deadline are always management tasks as noone else in the team could do that.

Answer 26

A manager needs to jump in from time to time, however they should resist the idea that "it would take less time to do it myself than explain how I want it done to someone else". That idea is common in inexperienced managers.

Lets say that a team of 12 need to work with libfoo, a library that is notoriously difficult to use. You, as the manager realize that the team will only be using 1/8 of what the library provides, so it makes sense to write a wrapper to make that part easier to work with.

You explain this to some members of the team, after two or three tries its still not what you imagined .. at that point you need to jump in and make adjustments.

Meanwhile, while you are writing this yourself, you tend to spend less time reviewing commits to other parts of the project and fall behind on your reports, budget and other managerial duties. So, you have to realize, every time your doing the job of a programmer, the project has a part time manager.

In the grand scheme of things it makes sense to identify the brightest and most experienced member of your team and make them your tool for such things. Ideally, this someone is an individual who could easily do your job but doesn't want it, they exist in nearly every team. If you can identify (and identify with) this person, you will only need to jump in when they get stuck, which should not be often at all.

Moreover, if you manage your projects well, you will spend as much time teaching as you do managing. If you do that well, you will seldom be confronted with situations that require you to reconcile misunderstandings with your own code.