How does a non-technical manager add value to a team of self-motivated software developers?

Can someone with no relevant experience contribute to a team?

I am seeing a lot of programmers turning away from management and administration roles. They want to build stuff. And as a result, a lot of these positions are filled by non-technical people. I fail to see how they add value. Is scheduling meetings, booking offsites, and other administrative work enough to justify their role?

The greasers of wheels

I fail to see how they add value. Is scheduling meetings, booking offsites, and other administrative work enough to justify their role?

Don't underestimate the amount of interaction your manager does with other departments. They handle budgets, training plans, HR paperwork. They protect the developers from getting sucked into meetings with other departments and provide a unified front for your group.

In short, their job is to protect self-motivated developers from all of the other demotivating things that exist in business.

Who's at the helm

As it applies specifically to software development, there are two sorts of value-adding roles for managers: project management and team leading.

A project manager interfaces with clients and middle management, which is a time saver for the developers. Often there are clarifications or scope changes that come up in projects, and it is helpful to clients and middle managers to have a single point of contact. Trying to field questions from every member of a development team leads to unrecorded project decisions and undocumented commitments, the bane of scope management.

On the other side, a team leader is involved with career/skills development, making sure the workload is appropriately distributed among team members, and providing resources and rewards commensurate with the individual contributions and needs.

Neither of these roles requires a heads-down programmer, in fact somewhat the opposite. A programmer will often jump to a code-writing task as the first response to a question or crisis, and it's helpful to have someone whose job is to ask whether that task really needs to be done.

Lead the way with coffee

The best managers are magicians. They make the rest of the company disappear for their developers. I can't remember the exact quote from Joel but it was something to the effect that it's management's job to make sure there's a fat Internet Pipe, a beast of a machine, and lots of caffeine so all the developers have to worry about is what they do best.

A good manager is the voice of your group to the rest of the company.

Find more answers or leave your own at the original post. See more Q&A like this at Programmers, a question and answer site for professional programmers interested in conceptual questions about software development. If you've got your own programming problem that requires a solution, login to Programmers and ask a question (it's free).

a) People Work. Normally they (should be) more experienced people who know the lay of the land and can help engineers to get further in a company. Also people need to switch teams and you need someone who keeps a working team together etc. pp. Apart from that at least in big companies a lot of bureaucracy regarding ratings, raises etc. pp.

b) Communications with other teams, protecting/enhancing the team scope. Presenting work to higher ups etc. pp. Sometimes they also are a bit of project manager. Depending on the size of the team you can be all of that.

In the end the main reason you need a boss is because most employees are it guys with the social skills of rabid squirrels. (ok I am exaggerating but programmers tend to have a god complex. I think 95% of programmers consider themselves above average. ) A daddy instance to reach out to in case a decision is needed is just healthy for a lot of situations.

The best manager I've ever had in IT was technical enough to understand what each of his people's jobs were and to talk about them and offer advice when needed. He was an incredibly smart guy, but there wasn't any question about who on the team knew more about the nuts-and-bolts of our tasks—and that was a very good thing. He kept the group operating and did manager-stuff, allowing us to produce and hit milestones, while he handled the politicking and reporting up and all the other manager-y tasks necessary in a big corporation.

I'll echo Elij17's comment: dude was magic.

I'd far, far rather have a semi-technical professional manager than a manger who mustang'd his way up the ranks from engineer to management; the more they know, the more they tend to fear delegation and prefer micromanagement.

During the year-end evaluations, the most senior team member said that he was happy to have me there, so that he could focus on coding and not having to spend time in non-coding tasks.

I'm not a purely management type- I code some small projects and I am one of the two main maintainers of our main LOB project (which is basically stable and only gets minor enhancements and bugfixes). I handle project management, task assignment, tracking, etc., and I am also the main interface with the rest of the company (although there's lots of direct communication). Technically I tend to have the last say on stuff, though I mostly act as peer review and rarely have to veto technical decisions. I also do mentoring on the junior devs and act as the last point of escalation.

Yes, I do feel diluted, and I have lots of task switching overhead- and I'm not very productive by myself (I do some support/bug fixing and I've completed many side-projects, but most of the heavy lifting gets done by the rest of the team), but everyone seems to be happy about the arrangement. I like to think that I get a big enough productivity boost of the rest of the team to justify my position.

I do have to say that I don't enjoy much the non-technical aspects of the work- I'd rather take on a more technical lead role, but it's pretty hard to find such positions.

At my previous gig I led 3-5 developers and 2-3 graphic designers. That hardly left me any time to do any technical work (save for being the IT person), so I'd say that for a bigger team, there's enough work for a non-coder to be valuable.

The best manager I've ever had in IT was technical enough to understand what each of his people's jobs were and to talk about them and offer advice when needed. He was an incredibly smart guy, but there wasn't any question about who on the team knew more about the nuts-and-bolts of our tasks—and that was a very good thing. He kept the group operating and did manager-stuff, allowing us to produce and hit milestones, while he handled the politicking and reporting up and all the other manager-y tasks necessary in a big corporation.

I'll echo Elij17's comment: dude was magic.

I'd far, far rather have a semi-technical professional manager than a manger who mustang'd his way up the ranks from engineer to management; the more they know, the more they tend to fear delegation and prefer micromanagement.

Exactly. The reason this question was asked is probably a testinate to the fact the original poster had the great figure to always have good managers. If you feel like you are always doing productive things and you don't know what your manager is doing, they are very, very good at their job. I 100% agree with the statement that the best managers make the rest of the company dissapear from the developer.

Blocking and tackling is an important managerial function for an otherwise self-motivated and self-guiding team. Keep the crap out, filter relevant communications, respond on the team's behalf for requests that don't need responses from the team members.

I view management as being not being about leadership, but about human networking a particular group in a company with the other groups in a company, both up and down as well as laterally. A good manager facilitates a group's endeavors while letting that group know what is required of them as well as what the group requires of others and negotiates the balance. This frees up people to do what they are good at and what they want to productively do, rather than get bogged down in distractions and non-productivity stuff.

Is scheduling meetings, booking offsites, and other administrative work enough to justify their role?

Really, people ask this? Yes. Managers are important. The ability to manage effectively is a more specialized skill than being able to code.

There is a dishonest implication in the question though. No business is ever going to hire a manager for a technical department that is completely "non-technical". Just because a manager doesn't individually perform every job on a team doesn't mean they don't understand what each member of the team needs to do. By virtue of the fact that they are leading a technical team to success makes them a technical manager.

{ Housekeeping question: is it possible to do a separate series LIKE this ... but, you know, focused on real nuts-and-bolts technology/coding implementation questions? This *idea* is awesome, but the bulk of these articles end up focusing on helping new coders come to grip with the ego-deflating reality of working in a managed environment. That's not really a technical question.}

In my experience the issue has been more about whether such a role (a manager who has no technical ability) is worth a manager's salary for a team whose members average $100k+ due to their technical ability. As a manager you'd expect them to make more than any of their direct reports, but without any training or skill other than project management and perhaps a tenacious personality, it makes for an awkward placement. The one time I had such a manager, people jokingly called him the "team secretary". Some of the best managers I've come across were making $50k managing teams whose individuals were making $30k, in production enviromnents.

I work for a company where the managers add little value, are mostly non technical and just generally come up with stupid initiatives for how developers can get the manager to the next level up the ladder. It's a big problem when you have managers and only managers who contribute very little promoted on the backs of the hard work by developers. It's especially a problem when there's no 360 peer review of managers in the organization. Where a manager decides to ding you in your performance review without justification just to show their superiors how tough they can be and how there is no right of appeal based on the conclusions your manager has made. Kiss up kick down managers are the worst.

As long as the non-technical person knows they are non-technical and does not use their position to enforce or manipulate technical decisions then they can contribute. I am currently employed at EA and there are several non-technical people in positions of power making stupid technical decisions because they think they know better then the code monkeys. There is a reason why so many EA game launches fail so horribly.

The best manager I had as a system admin was a completely non technical faculty who was chair of the department. He was actually a chemistry PhD, so very smart but not technical. He realized that and trusted the people like me he had in place below him. Made for a very nice work environment. Its not that I never had to explain why I made a recommendation; I did, often. But it made it much easier to present a logical argument for or against something without ego getting in the way.

Interesting that such a question gets asked. Maybe that shows just how much of a disconnect there is between management and those they lead? Wonder if tomorrow's question will be from a manager about developers?

What I wonder is - how does size of a company affect productivity and efficiency.Because from my admittedly limited experience - the bigger it is, the worse it is.

I tend do agree but fail to see why it is that way. I agree that big company wide initiatives are doomed to fail but if you keep the teams isolated and focused on their limited goals (i.e. Launch this one game) they can be very productive and efficient. Invariably in big companies someone at the top gets a bright idea and tries to get everyone to use it. Lets force everyone to use this shinny new account management system that can't actually scale to everyone's load is only supported on 2 of the 20 platforms that games are built on.

At the risk of jumping to conclusions, I'd guess that many managers would say that they deal with the god damn customers so the engineers don't have to. They have people skills. They are good at dealing with people. Can't you understand that? What the hell is wrong with you people?

More seriously, my question for all those people saying that the best managers they've had did the admin and cleared the way for more technically-adept staff to make the decisions, is this: where are those managers now? The ones I have known were marginalized by more power-hungry people and/or became as frustrated as the developers they helped. They either got laid off or quit to do something else. Much like Mr. Smykowski and his famous mat. Still, at least having some non-technical aptitudes means they can do that.

My manager is not a developer, but he knows the business of the company. For in-house software development, that is key. He is the one that knows what the executives want, what the users want, and how things are supposed to work. We, the developers, decide how it gets done in software, but he, the manager, decides what it is that gets done. A good manager is basically a proxy for the stakeholders and users, and is available for input every day. It makes a huge contribution to the success of our projects.

I feel like I see companies make managerial mistakes more and more these days. They either think that the manager needs to be able to do the job of the person they are managing (ie.code) or think that they can be replaced by a team member. Both are terrible mistakes. It does help if the manager understands the basics of what his team does, he does not need to be able to do what they do. His job is to MANAGE his team. This means taking care of daily operations, being a liaison between teams and other management and keeping the team motivated. A great manager doesn't run his team, he facilitates his team working better.

This problem tangentially reminds me of companies that want to hire salespeople who are engineers or tech people. A good salesperson can sell anything, to them its just a product and the important part is their interaction with other people. Engineers and tech people make terrible sales people, they want to focus on the product and interacting with people comes second.

Not only do I believe a manager adds a lot of value, there should be at least two different types of "managers" for any single developer in my opinion, or rather - the traditional manager should not be about my daily work:

Personal - responsible for youOne is your HR-like manager who's supposed to keep your motivation up, setting your salary, helping you develop your skills, helping you with evaluating yourself, assuring you have the proper equipment to do your job as good as possible, handling people issues in the office, the go-to-person to talk to about your daily life, problems at home, request vacations from and so on.

This one is all about who you are as a person and this manager is indeed often required to be a magician to be good, hiding the tedious chores of a company from you if you want, especially for developers who generally loathes involvement in those things.

Product - responsible for the productThe other one is your product manager/product owner with no real authority over you or your team on a personal level but is the single point of contact for deciding what to work on every day, dealing with and trying to decide on priorities and responsibility for what you deliver.

This one is all about what work you do and the funnel to and from the actual business and/or clients, a good product owner takes care of requests from business and streamlines them for you and makes sure all your requests on vague specs and so forth gets answered as quickly as possible in the best possible way, facilitating meetings with clients if so needed. As this person shouldn't have authority over you from an HR perspective, you can debate and contest stupid technical ideas without any fear of repercussions and let the delivery and end-product do the talking for you and your team.

None of these need to be especially technical as long as they're smart, capable of learning quickly and have good basic people skills. The dreadfulness of just keeping tabs on required meetings and rejecting non-required meetings is enough to easily sustain a separate non-technical coworker in my opinion

Yeah, just look at Steve Jobs. As a nontechnical guy managing a high tech operation, boy was he quite the failure, eh?

I think your downvotes comes from people who didn't understand your comment. He had reportedly no clue on programming or similar deep technical stuff; but that does not mean that guy was a genius in recognizing talent and good ideas.

I can't speak for the folks over on the development side of the house, but I've been a sysadmin, and I have been a manager of sysadmins. I've also been manager in less technical situations.

The thing that has struck me over and over again about frontline management positions is, people often get those jobs without any training. And in the first few weeks of one's new managership, one is told about the reports that are expected by higher level managers, and the general expectations upper management has of the team. As time goes by, the new manager sort of learns all the rest of the job ... by osmosis. It's never really formally laid out.

Things like: what relationship are you expected to build with the people you're managing? Should you be snapping off orders to subordinates, or playing a passive-aggressive game, or ... well, there are a lot of ways to handle this. And it's usually left to the manager to find them out and try them and see what works. So with no training and no clear expectation it is not surprising at all that a lot of managers get this wrong. There lots of ways to get it wrong ... and lots of ways to get it right. And it's different for every team and for every larger org, too.

Things like: what relationship does the team have with other parts of the org? Who does the team need stuff from? Who needs stuff from the team? What bargains is the manager authorized to make? When there's conflict, who (if anyone!) can break deadlocks?

Things like: upper management didn't say anything about it before today, but evaluations are due in two days. And no one ever even hinted that you, Mr. Manager, should have been keeping notes for the last 11 months. So here are the forms, judge these 8 people fairly and comprehensively according to criteria you weren't aware of yesterday, for the whole year. It will affect their morale, their pay, and their ongoing careers. Get it on your boss's desk in 48 hours.

Things like: 10 hours have passed today, and I was busy all day. But what did I get done? When I was an individual contributor I could show you a number of tickets completed or servers racked or scripts written. But now, as a manager, it seems like I take care of all these little details and go to endless meetings and pass messages around all day, with nothing tangible to show for it! (The answer here is, you handled a bunch if niggling little things so your team could concentrate on doing an awesome job with the tangible work, and that's a good thing! But it can take a long time actually realize this is your new lot in life as a manager.)

It's hard for a good team manager to even communicate the value he/she delivered to the team. The best ones, even if they could communicate that value, won't say much about it because why bother anyone with all that trivia? And a bad manager might literally have never learned what things he/she wasn't delivering to the team.

Everyone appears to be in agreement that the benefits of having a team lead who knows his/her stuff that can guide and assist his team are undeniable. When this team lead fails to fulfill their position, they use their position in the team to gain prestige through the team''s efforts, or blur what might be extraordinary effort on the part of a team member are when things get nasty. This negative is only magnified by the disparity in what they earn vs what their team members earn. There is nothing worse for moral than a team leader or manager that earns a multiplier above the people in their team while providing little help or impeding them from furthering their own career. Remember everyone is there to improve their own situation. When things at the workplace down align with that goal, there will be a problem and it will be reflected in the results of the team/workplace.

As Lee's comment about 'Mustang'd' alludes to, many of the things expected of managers are similar to what is expected of officers in the military. They certainly aren't supposed to be experts (no lieutenant is going to have the depth of technical expertise as their experienced NCO), but they are expected to lead and organise.

Which brings me to your comment about managers being pitched into the job willy-nilly in many instances. All militaries regard the training of officers as important enough to justify a special school for just such a task. What's the commercial equivalent of OCS?

I can't speak for the folks over on the development side of the house, but I've been a sysadmin, and I have been a manager of sysadmins. I've also been manager in less technical situations.

The thing that has struck me over and over again about frontline management positions is, people often get those jobs without any training. And in the first few weeks of one's new managership, one is told about the reports that are expected by higher level managers, and the general expectations upper management has of the team. As time goes by, the new manager sort of learns all the rest of the job ... by osmosis. It's never really formally laid out.

Things like: what relationship are you expected to build with the people you're managing? Should you be snapping off orders to subordinates, or playing a passive-aggressive game, or ... well, there are a lot of ways to handle this. And it's usually left to the manager to find them out and try them and see what works. So with no training and no clear expectation it is not surprising at all that a lot of managers get this wrong. There lots of ways to get it wrong ... and lots of ways to get it right. And it's different for every team and for every larger org, too.

Things like: what relationship does the team have with other parts of the org? Who does the team need stuff from? Who needs stuff from the team? What bargains is the manager authorized to make? When there's conflict, who (if anyone!) can break deadlocks?

Things like: upper management didn't say anything about it before today, but evaluations are due in two days. And no one ever even hinted that you, Mr. Manager, should have been keeping notes for the last 11 months. So here are the forms, judge these 8 people fairly and comprehensively according to criteria you weren't aware of yesterday, for the whole year. It will affect their morale, their pay, and their ongoing careers. Get it on your boss's desk in 48 hours.

Things like: 10 hours have passed today, and I was busy all day. But what did I get done? When I was an individual contributor I could show you a number of tickets completed or servers racked or scripts written. But now, as a manager, it seems like I take care of all these little details and go to endless meetings and pass messages around all day, with nothing tangible to show for it! (The answer here is, you handled a bunch if niggling little things so your team could concentrate on doing an awesome job with the tangible work, and that's a good thing! But it can take a long time actually realize this is your new lot in life as a manager.)

It's hard for a good team manager to even communicate the value he/she delivered to the team. The best ones, even if they could communicate that value, won't say much about it because why bother anyone with all that trivia? And a bad manager might literally have never learned what things he/she wasn't delivering to the team.

This is one area where the military excels. Every time you are promoted, you go through advancing levels of leadership training, and things like evaluations, training, discipline, etc are laid out for you to be aware that you'll need to know.

It's one of the reasons why military experience is a big plus in the civilian workforce. Not the technical things you are trained on, it's the middle management that is useful.

As Lee's comment about 'Mustang'd' alludes to, many of the things expected of managers are similar to what is expected of officers in the military. They certainly aren't supposed to be experts (no lieutenant is going to have the depth of technical expertise as their experienced NCO), but they are expected to lead and organise.

Which brings me to your comment about managers being pitched into the job willy-nilly in many instances. All militaries regard the training of officers as important enough to justify a special school for just such a task. What's the commercial equivalent of OCS?

The best manager I've ever had in IT was technical enough to understand what each of his people's jobs were and to talk about them and offer advice when needed. He was an incredibly smart guy, but there wasn't any question about who on the team knew more about the nuts-and-bolts of our tasks—and that was a very good thing. He kept the group operating and did manager-stuff, allowing us to produce and hit milestones, while he handled the politicking and reporting up and all the other manager-y tasks necessary in a big corporation.

I'll echo Elij17's comment: dude was magic.

I'd far, far rather have a semi-technical professional manager than a manger who mustang'd his way up the ranks from engineer to management; the more they know, the more they tend to fear delegation and prefer micromanagement.

Exactly. In my experience a lot of more technical managers hoard knowledge and view information sharing and knowledgeable subordinates as undermining their authority. One of the best managers I've had wasn't very technical at all, but he did a great job of fostering an open team and seemed to have a magical ability to divert training funds to our department before others even knew they'd become available.