My boss and I are trying to make the case to our company leadership that the development team should be run by developers (at least a good chunk of them by me). The thing is, although the company is also a software company, it is primarily a service company. It's an ASP, really, so it's integrated software and service in one, but we have a large enough service base that the operations wing dominates the software development wing by an overpowering margin (at least in numbers of people and in budget and so on). Thus, the higher management of the company is mostly rooted in an operations management mindset.

It's important to understand that in operations management, the conventional wisdom (which is probably largely correct) is that the best manager is someone who is really good at managing. You need someone to manage X? Get a good manager. You need someone to manage Y? Get a good manager. It doesn't really matter so much what X and Y are. Certainly, you'll need good team leads and so on who are familiar with X and Y, but your managers should know how to manage, first and foremost.

The problem is that we believe this is not true for software development. Actually, I think that it's this kind of mindset that leads one down the road to a lot of bad development methodologies. To date, we've managed to defend having the Chief Software Architect (my boss) be basically in charge of the whole software development group, but we're getting increasing pressure to grow the team significantly (which we want to do) and to bring in a VP of engineering to manage this increasingly large team (which we're not so sure we want).

Anyway, this brings me to the question: we're looking to gather some references about why it makes good business sense to have developers be managed by developers. One really good one is this article by Paul Graham (at least parts of it discuss this point), but one article by one guy is probably not good enough. I'd also be willing to hear countervailing viewpoints, too (I'm not really the "I've made up my mind, and now I want some data to back me up" type that this post may make me sound).

I do believe that if we make a good case explaining why this is the right thing to do, then we will be able to convince the senior leadership. For example, the sales organization has managed to let themselves be run like a sales organization (that is: by quotas and commissions and such), rather than like a line organization, but they did this because the senior leadership understood why this was important. We need to pull off the same thing, now, for the development organization.

Thanks in advance for all the good reading.

------------ :Wq Not an editor command: Wq

Replies are listed 'Best First'.
Re: Making the Business Case for Developer-Run Development
by Zaxo (Archbishop) on Aug 10, 2004 at 03:03 UTC

    Brooks has a fine discussion of the topic in The Mythical Man-Month. He makes a good case for having a traditional manager as assistant to the lead developer, with responsibility for budget tending, office politics, gossip, lies, damn lies, and other business activities that no developer wants to indulge in. The assistant's main job is to keep the developer happy.

    Update, chromatic++ caught a thinko on Brooks's book title. Fixed.

    After Compline,

      Brooks has a fine discussion of the topic in The Mythical Man-Month. He makes a good case for having a traditional manager as assistant to the lead developer, with responsibility for budget tending, office politics, gossip, lies, damn lies, and other business activities that no developer wants to indulge in. The assistant's main job is to keep the developer happy.

      Management isn't just there to keep the developers happy, although IMNSHO that's one of a manager's primary responsibilities. Management is also there to make sure that the developers are solving the right problems, and that they're using their time properly. It's not terribly useful for a development team to solve a really cool problem in general when only a specific instance is relevant to the company. Developers can get into a "forest for the trees" situation -- too close to the problem to really be able to tell what the company needs.

      F o x t r o t U n i f o r m
      Found a typo in this node? /msg me
      % man 3 strfry

Re: Making the Business Case for Developer-Run Development
by chromatic (Archbishop) on Aug 10, 2004 at 04:05 UTC

    Big Disclaimer: I wrote a book about software development strategies. I like to think I'm correct, but I don't know your team, your company, or your business, so all I can do is ask leading questions.

    The problem is that we believe this is not true for software development.

    Why is that?

    A manager of developers has to answer several questions:

    • What should we build?
    • How long will it take to build?
    • What level of quality does it need?
    • How much will it cost?
    • How can the team work effectively?

    How do you propose to answer those questions? What parts of the traditional management structure in your company make it difficult to answer those questions correctly?

Re: Making the Business Case for Developer-Run Development
by Elgon (Curate) on Aug 10, 2004 at 09:57 UTC

    An interesting line of thought; I've read some of Paul Graham's essays and handed them to people with whom I work, with varying results. My thoughts are below...

    A large part of this debate seems to come from a gradual drift in what it means to be a manager; IMEAO opinion, a manager is someone who exists to enable people to do their job as well as they can. This can be taken in several ways, but largely this can be divided into technical and nontechnical management...

    Non-Technical Management; The manager has a non-technical background or has little understanding of the technical issues faced by developers. Please make a careful mental note here - Just because these people do not have the technical skills which developers have, does not mean any of the following things...

    a) That they are stupid
    b) That they cannot pick up some technical skills on the way
    c) That they cannot effectively help you to achieve your goals

    What these people can bring to a technical team is their ability to communicate to upper management in a language that they will understand, while being close enough to the people at the coalface to see a vaguely accurate picture of the situation. A manager or leader who represents you well can be worth their weight in gold if they understand when to butt out and leave the technical work to those with the appropriate skills.

    Technical Management; The manager is technical, that is to say, they have a good understanding of the general nature of the problems being faced by the people who work "under" them. This understanding or appreciation for technical issues means that they are capable to act as a mentor, arbitator and someone who can direct the actual work of a technical department. This should not be taken to mean any of the following things...

    a) That they cannot appreciate business issues
    b) That they have poor management skills
    c) That they have poor communication skills

    People such as these are very important, for they not only direct the technical flow of a department, but they also help train up the newer folks in the department and, for this reason, their experience and skill in helping others can far outweigh the possibility that their skillset may not be up to date. The possibility that they have been around for a while can also make senior management listen to them a little more. But, just as the nontechnical manager has to butt out occasionally, so too, the technical manager has to realise that business reality can override "good practice"; It can be very easy to end up rearranging the deck chairs on the Titanic if you don't keep half an eye on the bigger picture.

    Bottom Line: If the technical and nontechnical halves of a department try and work together, seeing each others views of a given situation or issue, you will be able to achieve a hell of a lot more than if the techical folks start whining about "clueless management" and nontecnical leadership try to impose their view of the world on technical staff.

    Let the flamefest begin!


    "Stercus! Dixit Pooh. Eeyore, missilis lux navigii heffalumporum iaculas. Piglet, mecum ad cellae migratae secundae concurras."

Re: Making the Business Case for Developer-Run Development
by tilly (Archbishop) on Aug 10, 2004 at 16:19 UTC
    I've read a lot of books on managing developers, but I'm not sure that I can give a good answer on whether it is better for software developers to be managed by programmers or managers.

    Let me speak from personal experience first.

    The single manager that I felt was most effective in dealing with me did not have a programming background. He was way out of his depth - and knew it. Which motivated him to be really conscientious. Furthermore he knew the audience that I was developing for far better than I possibly could. He had to depend on me to lay out technical alternatives. But he also gave very valuable feedback on exactly what I was weakest in.

    The single manager who did the worst with me also did not have a programming background. But his problems were unrelated to that fact. Since I don't want to rant, I'll skip him.

    The second-worst manager that I had was previously a programmer. He constantly got into trouble by trying to micromanage and compartmentalize people. He wanted all lines of communication to go through him so that he was always in the loop. Unfortunately this caused constant miscommunication and conflict between people.

    So developers are not necessarily better than non-developers at managing developers.

    That said, there is no shortage of management traps that are specific to developers. For instance people who are used to dealing with operations are used to having straightforward metrics to measure progress by. How many phone calls were made? How many tonnes of steel were produced? This is easy to track, and there is a fairly straightforward correlation between effort and output. By contrast measuring progress in programming is very hard, and unless management is very careful they will never have a clue about what is really happening. Furthermore there is no simple correlation between effort and output, in fact most programming teams wind up going past the point of diminishing returns.

    For a simple concrete example, take the nature of "mental flow". A good portion of what programmers do can only be done when you have reached a state of sustained concentration called "flow". This state takes 15-20 minutes to achieve, and once achieved can be shattered by one off-topic interruption. At the average organization, interruptions come every 10 minutes or so. This keeps people from ever getting to a point where they are productive unless they work when nobody else is around. Which is one reason why programmers like to keep odd hours.

    This need is absolutely necessary to successfully program. It is also very difficult for someone to appreciate it if they have never had a job with this need. Two examples of such jobs are management and service. Which, not coincidentally, are the jobs of whoever will wind up in charge, and the background that that person will likely bring to the table.

    Facts like these are widely understood by programmers. If I had to start with one reference, it would be Peopleware. * Observers attribute some of Microsoft's success to the fact that their management was very concious of everything that Peopleware said.) You could also recommend something by Steve McConnell like Software Project Survival Guide or Rapid Development. Or grab any of the many other fine books that have been written on managing software projects.

    But the story doesn't end there. It is easy for books written by and for programmers to talk about all of the important things which programmers find easy to get right. It is much harder to talk about all of the important things which programmers tend to get wrong. Even reading about that poses a challenge for us. As I brought up in What you refuse to see, is your worst trap, that kind of criticism becomes a challenge to our egos. And those challenges are always hard for us to hear.

    Few books that are popular among programmers address that. I'm in the process of reading one that does right now, The Inmates are Running the Asylum by Alan Cooper. (Note: Scanning through the reviews at Amazon, some of the criticism is justified, but most of it seems to me to be the result of developers reacting to perceived criticism...) He talks a lot about the ways in which developers manage to drive the design process towards directions in which developers have an easier life. We naturally gravitate towards interfaces that mirror the hierarchies of the implementation with little thought about whether that will make any sense to the user or address the user's needs. The simple act of overestimating the technical difficulty of taking any other approach makes it hard for anyone else to challenge our control.

    Take a look back at my description of the non-technical manager who I worked with best. Look at what I said that he brought to the table. I can see how easily a developer could choose to dismiss what he had to say, and the resulting conflict would have made him ineffective. Luckily I didn't make that choice and things worked out very well. Conversely it is always going to be very hard for a manager who was a developer to bring that perspective to the table. the process of writing this post I seem to have come to an opinion on the topic. I think that both technical and non-technical managers can be effective managers for developers. The two groups both face general challenges that have to do with management, and slightly different sets of challenges from the unique demands of software. The specific problems that arise for managers who were developers are going to be less visible to developers because developers share the same blind spots. Conversely managers who weren't developers have challenges that are very visible to the developers that they manage. One of the worst of those challenges is the ease with which the managed developers can choose to subtly (or not so subtly) guarantee the failure of any manager that they don't respect. Often without conciously intending to do so.

    With that in mind, I'd say that you can choose to make the business case that you'll guarantee the failure of non-technical managers until you get your way. Or you can instead make the business case that there are a lot of issues which are specific to development, and it is critical that any managers understand some of them.

    * I like presenting Peopleware with the factoid that in the early 90's standard practice at Microsoft was that anyone who was promoted to manager was handed a copy of Peopleware, and then was quizzed about it in the halls until they were guaranteed to have read it. Observers attribute some of Microsoft's success to the fact that their management was very concious of everything that Peopleware said.

Re: Making the Business Case for Developer-Run Development
by bgreenlee (Friar) on Aug 10, 2004 at 07:58 UTC

    As Zaxo/Brooks mentioned, a significant part of the role of manager is dealing with crap like office politics, budgets, etc.--something that most developers don't want to deal with. I know if I were your current boss, I'd rather focus on architecture and development.

    It is important, though, that whoever takes on this managerial role is sufficiently technical to grasp the issues the developers are dealing with. At my last company we had someone like this, and it worked great. She knew her stuff, but didn't want to be a developer. Developers could talk to her straight about why such-and-such was taking longer than expected, and she got it (often suggesting better alternatives). She was great at deflecting all the office crap and letting her team focus on writing software. The developers respected her, so when she had to bring down the hammer and say that something had to be done this way for whatever business reason, they had an easier time accepting that.

    If your company is going to bring someone in, I would suggest that as part of the interview process, you and some of your team get to interview him/her, to make sure they've got the technical chops.


Re: Making the Business Case for Developer-Run Development
by JanneVee (Friar) on Aug 10, 2004 at 11:47 UTC

    In my personal experience it is not as much about developer managing other developers, it is about a manager that understands developers managing developers. A person can manage developers as long as he understands them, and trust developers to give him/her the right information. The "managing" person can achieve good results without having written a single line of code in his/her life.

      ++JanneVee. This is absolutely true and you can just replace developer with x. And just from my personal experience not all xes make good managers (in fact most of us don't).
Re: Making the Business Case for Developer-Run Development
by adrianh (Chancellor) on Aug 10, 2004 at 10:42 UTC
    My boss and I are trying to make the case to our company leadership that the development team should be run by developers (at least a good chunk of them by me).

    What do mean by "run by" ? Lead developer? CTO? Project Manager? Whats the role and what are its responsibilities?

    The problem is that we believe this is not true for software development.

    Why? You seem to feel quite strongly on the subject :-)

    Looking back at the people I've had above me in the org chart over the years I'd say, on average, the technical ones tend to be slightly worse. Good techies that lack all political and social skills get promoted into management and do a terrible job of it.

    One really good one is this article by Paul Graham

    I'm not really sure how Graham's article applies. He's mostly talking about about hiring Great Hackers to code, and says nice things about Steve Jobs' management - who isn't a software developer by any stretch of the imagination.

      I'm not really sure how Graham's article applies.
      Well, he does talk about it in a few different places, but I don't think it could be more clear how he feels on the matter when he says:
      I've seen occasional articles about how to manage programmers. Really there should be two articles: one about what to do if you are yourself a programmer, and one about what to do if you're not. And the second could probably be condensed into two words: give up.
      He then goes on to justify this statement with a few paragraphs, too.
      ------------ :Wq Not an editor command: Wq
        He then goes on to justify this statement with a few paragraphs, too.

        Unfortunately I don't find the justification that compelling :-) The only management problem specific to non-developers he talks about is "if you're not a hacker, you can't tell who the good hackers are".

        First, there is an element of recursion there (how to you hire the great hacker that knows who good hackers are since you can't tell who a good hacker is?)

        Second there is nothing special about software development. The same is also true of all skilled professions (how do you know who the good designer is if you have no aesthetic skills, etc.)

        If hiring people is the only problem there are many simple solutions that good managers already know about (e.g. specialised head hunters, consulting in-house experts, auditions, etc.)

        Graham's article is a good read - but to my eyes it's about hiring great hackers to code, not hiring great hackers to manage. He even discusses mechanisms for isolating them from end-users to get them productive. Hardly a feature for a manager!

        The other time he talks about management:

        This is an area where managers can make a difference. Like a parent saying to a child, I bet you can't clean up your whole room in ten minutes, a good manager can sometimes redefine a problem as a more interesting one. Steve Jobs seems to be particularly good at this, in part simply by having high standards.

        he's talking about Steve Jobs - a non-developer.

        So I come back to the question - what exactly is your manager role's responsibilities, and why do you think that a non-developer won't be able to do them?

        (I'm not trying to say that a developer would necessarily be bad for the role. Good managers with a techie background do exist. I'm just saying that, for a management role, I'd be more interested in good management skills rather than good software development skills. Better a good manager with no developer experience than an average manager with developer experience. Good managers can learn what the need to know.)

Re: Making the Business Case for Developer-Run Development
by coreolyn (Parson) on Aug 10, 2004 at 12:53 UTC

    Excellent node.

    I started in small shops where management wanted nothing to do with the coding except to ask when it would be done. Now I find myself in a larger corporation where management imposes a slew of processes ( and endless meetings ) that impede development. Therefore my heart totally agree's with the premise of developers managing developers, but my mind accepts the need and rational for managers in management.

    At the pure development level the developer-manager makes complete sense and a good management-manager would keep arms distance from that process, spending there time fending off the distractions from above and insuring that the product gets through the barriers in the the rest of the life cycle.

    From everything I've observed a developer-manager would be a waste of a good developer. That being said the cash value of each of these positions and departments needs to be better understood by executive management.

    . . .the operations wing dominates the software development wing by an overpowering margin (at least in numbers of people and in budget and so on)

    This would seem to me to be more the crux of the issue than who is managing a given project. I too am in a similar enviornment. I cannot for the life of me understand how a truly forward looking company can spend more on the the proceses of producing and maintaining that which already exists than it does on new infrastructure and development.

    IMHO Good developers shun management and I think Paul Graham's article reflects that.

Re: Making the Business Case for Developer-Run Development
by dragonchild (Archbishop) on Aug 10, 2004 at 12:39 UTC
    I think a distinction needs to be made between the director and the manager. The director is in charge of things like the budget and justifying that budget to the CEO. The director receives that justification from the manager. The manager is in charge of making sure projects are planned, requirements are gathered, and projects proceed apace. The manager receives the funding for that from the director. Beneath the manager should be the project manager (time coordination), development leads, etc ... and they report to the manager.

    The director doesn't need any technical knowledge. It's good if the manager has knowledge of at least the development process.

    If you're lucky, you can get someone who can be both director and manager. My experience has usually been that some poor schlob ends up having to be both, but is really only qualified for one. My best experiences, though, have been where the two hats were on different heads.

    We are the carpenters and bricklayers of the Information Age.

    Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

    I shouldn't have to say this, but any code, unless otherwise stated, is untested

Re: Making the Business Case for Developer-Run Development
by mstone (Deacon) on Aug 11, 2004 at 20:49 UTC

    What we've got here is a case of premature optimization. You've stated the problem in terms of what you think should be the solution, and if you keep heading in that direction, it will bite your ass.

    The real question here isn't "which one can we do without -- the generic manager's skillset or the experienced developer's skillset?" The correct answer to that question is: "neither one." You need both generic management skills and specific domain skills to make any technology project run. The real question you need to answer is, "how do we balance those two skillsets to get the project done?"

    Strictly speaking, any generic manager worth a damn should know that, and should already have a solid grasp of the generic management skill called, "listening to the people who actually know what they're talking about." Unfortunately, a lot of generic managers suck at that particular skill, which leads to situations like the one you're in right now.

    With regard to the actual business case, the arguments run as follows:

    First of all, you're never going to convince a team of high-level professional managers that their skills aren't necessary. You've lost that fight before you even started it, so don't waste your time and antagonize the people making the decisions by pursuing that agenda. You're gonna get a generic manager no matter what you do, so just accept that fact and move on.

    Once you accept the fact that you will have a generic manager, you can focus on creating a department structure that uses that manager's skills in the way that's best for the company.

    For the sake of a quick lesson in managing your managers, I'm going to stop here and dissect what I've just done. I've re-cast the issue from being a question of whether generic management skills are even necessary (which you're guaranteed to lose) to being a matter of negotiating an allocation of responsibilty that's best for everyone. That simple change guarantees your first win, because managers are negotiation geeks. Their whole mindset makes them unable to resist an idea presented in those terms.

    Getting your managers to negotiate at all is your first win. The next job is to win the negotation itself. You do that by showing that making a generic manager responsible for certain issues will be bad for the company, while making a developer responsible for those issues will be good for the company. I'll give you both the strategic and tactical breakdown for how to do that.

    Strategically, you need to focus on one key issue: estimation. You want absolute control of the estimation process to be in the hands of a developer, and for that power to include veto power over the two child issues of the estimation process, scheduling and resource allocation.

    Your first objective is to establish the fact that bad estimates are bad for the company. There are a couple of simple points to make there.. that bad estimates mean overcommitment of resources, slipped schedules, and the risk of failing to deliver a product at all. Slipped schedules and broken promisees piss off your customers, so nobody wants that. Overcommited resources translate to missed opportunities, becase eventually chasing an opportunity means slipping a schedule or breaking a promise to a customer.

    The more advanced argument, which will be harder to sell, is that bad estimates, bad schedules, and bad resource allocation can increase the cost of development by a factor of one hundred. Yes, that's a hundred. A well-managed project can do in four man-days and $1k what a badly managed project will do in one man-year and $100k.

    Your managers will choke on that number the first time you present it, but you can back off and establish that bad organization can at least make things take longer and cost more.. maybe not by two orders of magnitude, but by some amount. Then you present the argument that every phase of development:

    1. Requirements gathering
    2. Design
    3. Specification
    4. Unit coding & testing
    5. Integration & integration testing
    6. Post-release debugging

    costs roughly twice as much as the phase before it. A problem you fight with for two hours during spec time could be eliminated by an hour of negotiating requirements. The worst and most expensive time to find a problem is at the post-release debug phase, because the problem that could have been handled with an hour of requirements negotiation now takes two programmers four days to fix.. and then you have the cumulative cost of any work that went into the release product which had to be thrown away. The result adds up to a 100:1 difference pretty quickly.

    Requirements, design, and specification are the three most cost-effective areas of development. They all tend to require small teams, and they save you from big losses down the line. That frees up your labor to work on other projects, and to catch those opportunities you would have missed if everyone was doing a death march.

    Requirements, design, and specification are also the three areas where a generic manager is least qualified to make a definitive judgement. That's why you want the power to make those decisions in the hands of a developer who does know how to get those jobs done.

    Now.. tactically, you should handle your negotiation using a technique Barry Boehm (Google the name) developed while working for the DoD, called "win-case negotiation." The idea is to go around your circle of negotiators having everyone state what the condition they need in order to feel that they've won. In most cases, you'll find that a lot of the win conditions are orthogonal to each other.. the developers want control over estimation, while the managers want to be sure there's a good hand on the wheel once the schedule has actually been set. The goal is to establish a solution that allows everyone to feel that they've won what they feel is most important.

    Getting down to specifics, you might want to float the idea of a department where the big-picture work -- deciding what's possible, what resources are necessary for any given project, and what schedules are reasonable -- belongs to a developer, or a small team of high-level developers. But the department will also have a small team of generic managers who work for the managing developers, taking care of the strictly management end of running the teams -- budgeting, paperwork, creating teams that gel, motivating and managing egos, managing communication with the rest of the company. The managers would end up 'running' the teams the way your sysads 'run' the computers. They'd maintain things and keep them operating, while not having complete say over what should be done.

    One last piece of advice: If you really want to win this, blow a hundred bucks or so and buy copies of:

    • Why Does Software Cost So Much?: And Other Puzzles of the Information Age (ISBN: 093263334X), and
    • The Deadline: A Novel About Project Management (ISBN: 0932633390)

    both written by Tom DeMarco, for every high-level manager you want to convince. Read them, and you'll understand why.

      That simple change guarantees your first win, because managers are negotiation geeks. Their whole mindset makes them unable to resist an idea presented in those terms.

      That's a really smart observation. I hadn't thought about it in those terms before. ++

Re: Making the Business Case for Developer-Run Development
by qq (Hermit) on Aug 10, 2004 at 22:15 UTC

    Why does the senior management want to install a manager? Is it just because the department is growing, so they think its a natual step, or are there specific concerns they have? Ask yourself these questions as part of your preparation. Then ask them.

    Explain that you have a good working practice (I assume you do) and that you are concerned it will be disrupted.

    In my experience the most difficult thing for developers, and the piece that gets most contentious, is estimating time and budgets. A large part of the Xtreme programming philosophy (client on site, allways having working software, small steps) seems to be about finding another approach to this, since its so difficult to plan and estimate correctly up front.

    If that is a concern, explain that its notoriously difficult in the software industry, and its a known concern with lot of competing methodologies that attempt to solve it. Its not just that developers are always bad at estimating, and its not something that a hard nosed manager will just be able to fix.

    Generally though, it seems like you don't want a non-technical manager making decisions that are directly or indirectly technical. This includes both "use Java for this" and "have this ready in 2 weeks (which makes a whole lot of technical decisions for you right aways)". So tell the senior management that, and make sure the job description does not allow it. Decisions of that nature should be taken jointly by the lead developer and the manager. Not the manager consulting the developer, but a joint decision. That needs to be in the contract.

    Make sure you get in on the recruitment process. This includes the job spec, and the interviews.

    Managers are not bad, but don't let them change the way you work. And don't don't don't accept anyone with PRINCE2 training!


      And don't don't don't accept anyone with PRINCE2 training!

      Why? sounds like you have real Project Horror storie in there somewhere.

        Well, generalizing from a sample of one ...

        I'd say that PRINCE2 is very heavy on design up front and full specifications, and creates endless documents (not developer documentation, but customer/client docs).

        The documents had a rigid structure that included lines like "The scope of this document is defined by its inclusions. However exclusions are included to further define the scope of this document". After a page of boiler plate text that defined the scope of the document came several pages that defined the scope of the project. And everything had to be signed by three people, in four different places.

        PRINCE2 is also presented as a miracle cure that if properly understood and implemented will suddenly disolve all the real world difficulties of development and customer satisfaction in one go. I spent months on defining and redefining "processes" while watching our real work get neglected. It only stopped when the company went under.

        This manager was a nice guy, friendly, listened well, stood up for developers when needed. But he was blinded by his management training, and couldn't really hear alternatives. If you gave criticism, he'd reply "if there is something you are not happy about, please bring it up" - which you just had. Then, later, he'd give you an two hour personal meeting to explain why you had missed the point and he'd patiently explain his boneheaded opinion again. Whereas you'd be too tired to oppose, and meekly submit.

        He also micromanaged technical work, but thats another story


Re: Making the Business Case for Developer-Run Development
by johndageek (Hermit) on Aug 10, 2004 at 18:58 UTC
    There have been several good replies to this post!

    In my experience, the stronger a person is in a given field, the worse they will be as a manager. Super salespeople, great programmers, gifted mechanics all make lousy managers. Superb managers generally do well manageing any group. The trick is to find a manager that understands how to manage well.

    Good luck!

Re: Making the Business Case for Developer-Run Development
by poqui (Deacon) on Aug 10, 2004 at 21:34 UTC
    I have had many managers, and even tried being a manager a time or 2.

    In my opinion, the best managers are managers first, then maybe technical.
    The reason I say this is that my view of a manager's duty is to deal with the politics and the budget and the personnel issues, and leave the technical stuff to the techies. When techies have to deal with these things they generally become broken.
    Even splitting roles down to Project Managers and People Managers and Budget Managers is a good idea, because I haven't often found that the same person is good at all 3.
Re: Making the Business Case for Developer-Run Development
by KeighleHawk (Scribe) on Aug 11, 2004 at 21:15 UTC
    Okay, first of all, **BAD** link to put in your post if you happen to want quick feedback :-) I spent two fricken hours wandering Paul's site before deciding I should either get back to work, or at least respond to your query. I had not seen his site before (shame on me)...

    Anyway, you clearly can not show this article to your management. That would be like slapping them in the face and then referring to each of them as "Mr. Poopy-Pants." This would be more an "internal document" to your group to help plan your approach, but do NOT show it to anyone else.

    I won't relate stories of my past management or theories on good vs bad or developer vs management background since that seems to be well covered above. What I will say is the truth of the matter is it is not skill, training or experience that matter most. Those all help, but what matters most is desire.

    That and a little PR with a dash of semantics...

    What I mean by this is don't get caught up in a single detail (we want a developer to manage us). Just like in software, make sure you are solving the right problem. In this case, you don't really want a "developer" to manage you; you want someone who understands and **likes** developers to manage you.

    So I would make the following recommendations:

    1. Change the job title from VP of Development to CTO (assuming you do not already have one of those). This might "scare" away some of the PHB's and limit the playing field.

    2. Keep in mind this person does have to manage, not do. Like all the others on this list said, someone not willing to be socially acceptable, politically correct, and at least a little bit subtle won't help you out. Cut them from the process immediatly.

    3. Insist on the bulk of the interviews and strongest weight in the decision process come from your group. Most places consider this (at least interviews by the team) to be pretty standard so a little subtlety should get you this.

    4. Ask a variety of questions but the biggest one to sneak up on is "Why do you want to manage technical people." Best answer I ever go to this was "because programmers fascinate me and I want to figure out how to manage them..."

    5. Ask general, but not specific technology questions. By that, I do not mean ask "which is better, Java or DOS batch files?" I mean, ask things like "when is the best time to switch underlying technologies?" "what's the balance between **great code** and code that just runs?" "what's more important, meeting the customer requirements or meeting the customer needs? What's the distinction and how do you manage the difference?" No one will ever agree on the answer to these questions in a general sense, so you and your group need to decide for yourselves the quality of the responses.

    6. Ask about their hobbies and what they do for fun. Remember, you have to work with this person. That includes hanging with them at the company party, making small talk before a meeting starts, saying something cheery when you cross in the hall. Plus, this will give you better information on thier "soft skills" as well as give you an indication of what it will be like to work with this person.

    7. Avoid questions that put them in an adversarial role right off the bat. eg. "What would you do if the other suits wanted us to do something and we said that was a bad idea? Determine for yourself from other conversation (like the one above) whether you think you can trust them. If you feel you can trust them then you have your answer without having to be abrupt about it.

    Regardless of the skills involved, if you can't stand to be around the person, you're not going to work well with them.

    I'll probably take a shot or two for this one, but I've become convinced asking technical questions on an interview is virtually worthless. Trying to do so leads you into one of the following time-wasting traps:

    • contrived, idiotic scenarios involving primitive natives and a log bridge
    • what I call, "stupid party tricks" questions. ie. how would you do this in SQL? I've found people don't like when I answer "I wouldn't, I'd use PERL..." but that's off topic...
    • Our company has been struggling on this problem for six months, can you solve it for free in the next five minutes?

    In your case, you would have the added problem (as others have pointed out) of excluding very good possible candidates by hitting them with a technical interview.

    I think people are more and more beginning to believe the best programmers cannot be measured by what they know, but rather by what they can figure out. This can only be determined by actual work experience with the person (which you cannot get or simulate) or by peripheral converstaion and "gut" feeling.

    Anyone who manages such a group needs to be able to manage this and undestand intrinsically that no one in thier group can be pigeon holed and that managing them is a full time job. More like fostering, mentoring or parenting than traditional management. But you can't test for that either so your best indication is going to come from "chatting" rather than skills testing.

    So, my new theory (always got to have a theory) is to not interview for a position, but to interview for a friend. You have one caveate to that. If the person is going to work for you, they need to be a person you think you can mentor. If they are going to work with you, they should be someone you'd be willing to waste a few minutes with in the break room. If they are going to manage you, they need to be someone who's leadership you are willing to submit too after you've given all your best arguemnets.

    Strictly speaking, as "professionals" we get the job done with whomever our lot is cast with. But if you have a choice, why not hire a freind, even if that person is a "new" freind found through the interview process?

    End of the day, if you don't like talking to the person and you don't think they will represent you well without you standing there to make sure, try to pass them over, regardless of thier technical wizardry. Likewise, someone you enjoy talking to who seems genuinly interested in your group, can learn what they need to know.