9 ms·

On Managing Developers

111 points by isalmon 11y ago

yeukhon 11y ago
It is a good point that being a manager one would have more influence, but that's only true if you are technically and socially respected by your fellows/peers/workers. Sometimes this means you have to really do your homework and work maybe twice as hard as your developers so you don't just ask questions and assume they are right. You have to be a hard ass, keep asking, demand clarity, and always be a hard ass to get things done properly.
lifeisstillgood 11y ago
Stop with the management already. If you look at a company of say 100,000 employees, and a generous span of 1 manager to 10 subordinates, there are 33,333 managers - and as they usually are paid better than their subordinates, the cost is typically over 50% of salaries. And it's a rare industry that is not mostly salary as cost. And we now have an amazing set of technologies and examples of new organisational forms (Linux?) that say "hey, you can eliminate a huge cost base and be more productive. Wanna bet how the next decade is going to go for those called "managers"?
- quincunx 11y ago
  Not sure I understand, suppose 100,000 non-managing employees, span of 1 to 10, adds 10,000 managers, span 1 to 10, adds 1,000 more managers, span 1 to 10, adds 100 more managers, and so on. Therefore, for a company of 111,111 employees, there are 11,111 managers. Let's say double the salary on average gives 20-25% overhead? Why would, for a company of 100,000 employees, it bump up to 33,333 managers? Linux, organizationally, does not fulfill the same functions as are needed in a company (recruitment, firing, finance, HR to name a few.) How would you model a company after it?
- thewarrior 11y ago
  I downvoted you because arguing that managers are unnecessary is so naive and uninformed as to make me suspect that you're trolling. That's like saying that a film doesn't need a director. Well maybe in theory you could make a film without one but that's not the best way to go about it.
  - jnbiche 11y ago
    A number of successful companies disagree: 1. Zappos: http://www.businessinsider.com/tony-hsieh-self-management-memo-to-zappos-employees-2015-4 http://www.businessinsider.com/tony-hsieh-self-management-me... 2. Medium: http://firstround.com/review/How-Medium-is-building-a-new-kind-of-company-with-no-managers/ http://firstround.com/review/How-Medium-is-building-a-new-ki... 3. Valve: https://managing-essentials.com/valve-software-successful-self-organized-and-bossless-company https://managing-essentials.com/valve-software-successful-se...
    - bjelkeman-again 11y ago
      They are the far outliers. Very hard to achieve in my experience.
      - fapjacks 11y ago
        Since the enormous vast majority of people only have experience working in companies that would never (and definitely have never) tried a flat organizational structure, I think this is kind of a disingenuous statement. From the outside those companies do look like far outliers. But I have a suspicion that hierarchy is only extremely relevant without technology. What I mean here is that technology is a great organizational "flattener" and I think since technology like this is still in its infancy, we can't really make a blanket statement like "this is very hard to achieve". Obviously, you're right to some degree, but I think that is only an artifact of technology not yet having revolutionized "the organization".
        rhc2104 11y ago
        Stripe is an example of a company that prided itself on a manager-less structure, but then converted to having management.
        fapjacks 11y ago
        Sure, but the same can be said for organizations that were once hierarchical, but then went flat.
- carrotleads 11y ago
  I have never understood why managers need to be paid higher than the people they manage.. That is the single reason for many orgs screwing up their system as this forces excellant developers/workers to abandon their core skills and move into management..
  - neverartful 11y ago
    It does not force techies into management unless it's an 'up-or-out' kind of organization. It provides a financial incentive (and often a status symbol).
    - marcus_holmes 11y ago
      the manager's salary becomes a ceiling for the staff they manage, if managers are always paid more than the staff they manage (and I've heard some managers seriously suggest that they would not be able to manage people who got paid more than them). It becomes a problem when tech salaries are on the rise, because at some point the company either has to start paying coders more than managers, or has to implement pay rises throughout the management hierarchy in order to retain good technical staff. At this point its really tempting to promote good coders into management to keep them.
      - curun1r 11y ago
        > I've heard some managers seriously suggest that they would not be able to manage people who got paid more than them This is just greed/pride. As a manager, the only person who knows that an engineer makes more than you is you. And it's pretty common these days for companies to have an engineering track that has a VP-equivalent top position, so it's pretty common that the most senior engineers will make more than most of the managers at the company.
  - tomjen3 11y ago
    Because once they were the most skilled people and now the market is paying higher wages so either you do too or you don't get to hire managers who can work anywhere else.
makeitsuckless 11y ago
Managing developers is easy. Managing the rest of the company so the developers can do their job is the hard part.
- borski 11y ago
  Then you've never managed developers. Speaking as one, developers are not always right, and as human beings they are subject to emotion. Emotions make people hard to manage. Period.
  - MaulingMonkey 11y ago
    Seeing the difference between effective and ineffective management, and the frequency of the latter, I'm not convinced it's easy either. Some developers aren't great at gathering requirements, estimating costs, triaging requests, saying no, or any number of other things... if only because they'd rather be coding. And that's not even getting into what they can mess up when it comes to the actual development portion. A good technical manager can help cover for their shortcomings, and let them focus on their interests - what they're good at. They're not just an ablative meat shield.
    - dlitz 11y ago
      > Some developers aren't great at gathering requirements, estimating costs, triaging requests, saying no, or any number of other things... To be fair, nobody is great at those first two.
  - makeitsuckless 11y ago
    I've managed developers for years, thank you very much. You're right about that being one of the challenges, but it's still an easy challenge compared to everything else. (BTW, the biggest issue within the emotions category is that developers tend to deny, even to themselves, that an issue is an emotional rather than a rational one.)
calibraxis 11y ago
Good article. > Few developers like to write documentation. That means it’s your job. OMFG. Most traditionally-trained devs I've met in person are next to illiterate. Bizarrely incompetent at docs. Unsurprisingly their code quality stinks too. They'd probably ridicule you for mentioning "programs must be written for people to read, and only incidentally for machines to execute". (Unless you say you're quoting "the Wizard Book", because they defer to argument from authority.) Read my sourcecode, they say, as if that doesn't mean "Go fuck yourself". And they simply never want to proactively improve. That would require introspection and self-critique. Pulling teeth.
- vinceguidry 11y ago
  You have to work within people's limitations, that is, if you can't pick the people you work with. A team is only as good as it's most competent member's willingness to pull everything together and inspire the less-motivated to perform at a higher level. That's leadership, and there's precious little of it anywhere, even (especially!) in the products we use every day. If there's no real leadership, then you're stuck in the backwaters of being managed. My advice is if you find yourself in this situation, either use it as an opportunity to work on your leadership skills or check out and throw your passion into side projects.
  - calibraxis 11y ago
    Excellent points! Maybe anyone who decides to "check out" should consider getting physically away from the team, if possible. Find those who proactively help others and apply healthy self-critical thinking. Kathy Sierra in "Badass: Making Users Awesome" said: "An important, unconscious way to develop expertise is being around high-quality, high-quantity examples of expertise." The flipside is apparently true: exposure to mediocre examples begets mediocrity.
- dlitz 11y ago
  No kidding. I don't know how many time I've tweaked my code after starting to write some docs (docstrings/JavaDoc/etc.) and realizing that my abstraction boundaries were wrong. If writing those docs were somebody else's problem, my code would have been crap. This is after 10+ years in industry. On the other hand, end-user documentation can be a lot of really tedious screenshotting in some markets, and it can't always be automated.
ExpiredLink 11y ago
> Managers translate the project’s Big Picture into individual tasks for developers ... As any professional translator will tell you, this means you need to understand the work more intimately than the author. Such manager doesn't exist in the current development biotope.
- hkarthik 11y ago
  Nor should it. As a manager, I try to let the team and the PM work out the individual tasks, and ensure there is consensus and follow through by individuals. Handling external pressures, clearing roadblocks, and resolving team conflicts are where I feel that my time is best utilized.
  - Moru 11y ago
    Yes exactly. Developer and Manager is two completely different jobs. Developer to manager promoting is a brain drain. A good developer does not have to be a good manager. A good manager does not have to be a good developer.
deleted 11y ago
[deleted]
elwell 11y ago
> Not a coder yourself? Learn enough to at least write tests. No, please.
- robotkilla 11y ago
  Not a doctor yourself? Learn enough to at least diagnose.
  - alexqgb 11y ago
    For a hospital manager, that's actually not bad advice.
    - deleted 11y ago
      [deleted]
    - taeric 11y ago
      Is it? I'd be interested in any numbers surrounding the idea.
      - alexqgb 11y ago
        You shouldn't need numbers to evaluate a proposition with a premise that is self-evident. I mean, correct diagnosis is one of the first and most fundamental things a hospital does when admitting patients. Failure at this stage cascades through every step that follows, possibly with fatal consequence. If you're "managing" a place that handles this work without a working understanding of the process involved, there's a very good chance that failures can be traced - in large part - back to your desk.
        taeric 11y ago
        I have grown to not believe in anything as self evident, anymore. Directly to this premise. Correct diagnosis is a difficult and often error prone things that a hospital can do. To think you can train someone to be a manager and be good at diagnosis is putting a lot of trust on someone. Should they be able to help? Certainly. But, at some level, I would expect the manager to be better at knowing which doctor to get you in touch with moreso than how to do the diagnosis themselves.
mbernstein 11y ago
> Testing is really important, but few developers like to write tests. That means it’s your job. As a leader of an engineering team (and an engineer), I think the is this is entirely the wrong approach. It's a leader's job to get the team to understand why writing tests is important and have them write them. Sometimes an individual isn't a great fit on the team and you need to figure out how to handle it (i.e., they refuse to write tests but the rest of the team is). There are few points in this article that resonate - but there are many that are complete off base such as > Managers translate the project’s Big Picture into individual tasks for developers, with their details and interactions specified in minute detail I agree that leaders/managers translate the big picture to developers (provide vision) - but the team should figure out the minute detail - otherwise you're removing autonomy, the ability to fail, and are yourself falling into the pit of micromanagement.
- sheepmullet 11y ago
  "It's a leader's job to get the team to understand why writing tests is important and have them write them." And sometimes you shouldn't write tests, or perhaps no unit tests, or perhaps write the tests but throw most of them away, etc etc. It is all highly context specific. The real issue for managers is even if they start out technical, within a year or two they lose touch.
  - chao- 11y ago
    Good discussion of this sort of thing in a series of recorded Hangouts between Martin Fowler, Kent Beck and DHH: http://martinfowler.com/articles/is-tdd-dead/ http://martinfowler.com/articles/is-tdd-dead/ The takeaway is that the usefulness of tests is the feedback it gives you about your code (and confidence, a subtype or result of feedback). All of the BDD vs. TDD vs. Test First vs. Test Whenever can get wrapped up in too much zealotry, and is ultimately secondary to the goal of getting feedback.
  - mbernstein 11y ago
    Sure. I don't disagree about not writing tests at times, etc. That's different than the point I'm trying to make. Leaders aren't necessarily tasked with doing any job a developer thinks is shit. The leaders job is to help the developer understand the why behind doing it. Also, do you have anything quantitative to back your statement about being out of touch? That hasn't been my experience generally and I work quite hard to ensure I don't lose touch. That's obviously only data on my experiences - but I didn't make the assertion (I genuinely interested though).
tomelders 11y ago
I agree with a lot of this. One thing I would add - it's your job to integrate development into the rest of the organisation. UX, design, marketing, sales. Failure to do so leads to animosity between development and the rest of the organisation. Animosity undermines the goals of the organisation. In my experience, the biggest issue to deal with when managing developers is that they feel like they're tasked with implementing stupid ideas created by idiots. its never that simple, and developers are generally rational people who, given all the facts, know when to digg I. And resist something, and when to swallow a bitter pill for the greater good.
sheepmullet 11y ago
The problem with this kind of article is the author rarely considers/explains the context. E.g. Managing a team of 10 developers at a company with 30% turnover is very different to managing a team of 3 developers at a company with 5% turnover. Approaches and techniques vary drastically based on context.
gizi 11y ago
I came to the project only a few months ago. The project was "90% finished" but full of bugs too. We recently went live anyway. In the meanwhile, I have asked the manager/client for finding help with QA, because it is quite hard to maintain overall consistency in the system. The smallest changes create big bugs elsewhere. It is not enough that he or me do the testing. We never test enough anyway, and we still regularly hit the live servers with bad bugs that cost money. The system is meant to process money, actually. That is its core task. The problem is that my request for having QA people helping out, would cost resources, and that the recruitment process for QA profiles does not seem particularly easy either. Then, there's also the situation with the graphical designer who seems to hate programmers, and never shows up when he said he would. I think that a good manager will find a way to put the right people in the right place at the right time.
uptownfunk 11y ago
Is the dev-manager dynamic something like: In school, most people don't get the project done unless there's a deadline imposed upon them by someone else. And in the professional world that someone else here is the manager..?
- taeric 11y ago
  School is unique in that most of the questions/projects you will be faced with have a pretty solid answer. Often times a definitive one. Work... not so much.
dschiptsov 11y ago
Let's try to use the classic analogy with painters.) Suppose "your team" have to paint a cathedral for a king and you are the "manager". Of course you cannot paint yourself and hence holding an opinion that the paints and brushes are the most important things in this business. Nevertheless, you have noticed, that some guys, like Leonardo, are much better at painting of the ceilings and in order not to disappoint the king you have to hire him and all the second best guys. Of course, you are sure that these guys are just lucky and overrated. What you ougth to do, in order to not be beheaded by the king, is to be sure that Leonardo and the other painters has everything they need, of best possible quality and there is not a single obstacle on the horizon. Now imagine that instead you have decided to hold daily meetings to discuss how to mix the paints properly, about responsibility to the whole team, and importance of writing daily reports about elements finished so far, together with detailed statistics of materials spent on each element. To be sure that everything is going well, you have to climb to the ceiling few times a day and ask smart, psychological questions in orfer to avoid any possible lapse in productivity by exercising employee's morale and dedication to the project. For that reason you have short meetings in the morning. Because you have no idea why the masterpieces of these guys are so highly acclaimed, you are constantly trying to improve their decisions by introducing new elements and changing colors, which are, you have been told, are industry standard best practices, and forcing them to use not the paints they used to, but guaranteed, safe, battle-tested priducts they used to paint the walls of the king's palace and stables.

111 points by isalmon 11y ago

It is a good point that being a manager one would have more influence, but that's only true if you are technically and socially respected by your fellows/peers/workers. Sometimes this means you have to really do your homework and work maybe twice as hard as your developers so you don't just ask questions and assume they are right. You have to be a hard ass, keep asking, demand clarity, and always be a hard ass to get things done properly.

lifeisstillgood 11y ago

Stop with the management already. If you look at a company of say 100,000 employees, and a generous span of 1 manager to 10 subordinates, there are 33,333 managers - and as they usually are paid better than their subordinates, the cost is typically over 50% of salaries. And it's a rare industry that is not mostly salary as cost. And we now have an amazing set of technologies and examples of new organisational forms (Linux?) that say "hey, you can eliminate a huge cost base and be more productive. Wanna bet how the next decade is going to go for those called "managers"?

quincunx 11y ago
Not sure I understand, suppose 100,000 non-managing employees, span of 1 to 10, adds 10,000 managers, span 1 to 10, adds 1,000 more managers, span 1 to 10, adds 100 more managers, and so on. Therefore, for a company of 111,111 employees, there are 11,111 managers. Let's say double the salary on average gives 20-25% overhead? Why would, for a company of 100,000 employees, it bump up to 33,333 managers? Linux, organizationally, does not fulfill the same functions as are needed in a company (recruitment, firing, finance, HR to name a few.) How would you model a company after it?
thewarrior 11y ago
I downvoted you because arguing that managers are unnecessary is so naive and uninformed as to make me suspect that you're trolling. That's like saying that a film doesn't need a director. Well maybe in theory you could make a film without one but that's not the best way to go about it.
- jnbiche 11y ago
  A number of successful companies disagree: 1. Zappos: http://www.businessinsider.com/tony-hsieh-self-management-memo-to-zappos-employees-2015-4 http://www.businessinsider.com/tony-hsieh-self-management-me... 2. Medium: http://firstround.com/review/How-Medium-is-building-a-new-kind-of-company-with-no-managers/ http://firstround.com/review/How-Medium-is-building-a-new-ki... 3. Valve: https://managing-essentials.com/valve-software-successful-self-organized-and-bossless-company https://managing-essentials.com/valve-software-successful-se...
  - bjelkeman-again 11y ago
    They are the far outliers. Very hard to achieve in my experience.
    - fapjacks 11y ago
      Since the enormous vast majority of people only have experience working in companies that would never (and definitely have never) tried a flat organizational structure, I think this is kind of a disingenuous statement. From the outside those companies do look like far outliers. But I have a suspicion that hierarchy is only extremely relevant without technology. What I mean here is that technology is a great organizational "flattener" and I think since technology like this is still in its infancy, we can't really make a blanket statement like "this is very hard to achieve". Obviously, you're right to some degree, but I think that is only an artifact of technology not yet having revolutionized "the organization".
      - rhc2104 11y ago
        Stripe is an example of a company that prided itself on a manager-less structure, but then converted to having management.
        fapjacks 11y ago
        Sure, but the same can be said for organizations that were once hierarchical, but then went flat.
carrotleads 11y ago
I have never understood why managers need to be paid higher than the people they manage.. That is the single reason for many orgs screwing up their system as this forces excellant developers/workers to abandon their core skills and move into management..
- neverartful 11y ago
  It does not force techies into management unless it's an 'up-or-out' kind of organization. It provides a financial incentive (and often a status symbol).
  - marcus_holmes 11y ago
    the manager's salary becomes a ceiling for the staff they manage, if managers are always paid more than the staff they manage (and I've heard some managers seriously suggest that they would not be able to manage people who got paid more than them). It becomes a problem when tech salaries are on the rise, because at some point the company either has to start paying coders more than managers, or has to implement pay rises throughout the management hierarchy in order to retain good technical staff. At this point its really tempting to promote good coders into management to keep them.
    - curun1r 11y ago
      > I've heard some managers seriously suggest that they would not be able to manage people who got paid more than them This is just greed/pride. As a manager, the only person who knows that an engineer makes more than you is you. And it's pretty common these days for companies to have an engineering track that has a VP-equivalent top position, so it's pretty common that the most senior engineers will make more than most of the managers at the company.
- tomjen3 11y ago
  Because once they were the most skilled people and now the market is paying higher wages so either you do too or you don't get to hire managers who can work anywhere else.

makeitsuckless 11y ago

Managing developers is easy. Managing the rest of the company so the developers can do their job is the hard part.

borski 11y ago
Then you've never managed developers. Speaking as one, developers are not always right, and as human beings they are subject to emotion. Emotions make people hard to manage. Period.
- MaulingMonkey 11y ago
  Seeing the difference between effective and ineffective management, and the frequency of the latter, I'm not convinced it's easy either. Some developers aren't great at gathering requirements, estimating costs, triaging requests, saying no, or any number of other things... if only because they'd rather be coding. And that's not even getting into what they can mess up when it comes to the actual development portion. A good technical manager can help cover for their shortcomings, and let them focus on their interests - what they're good at. They're not just an ablative meat shield.
  - dlitz 11y ago
    > Some developers aren't great at gathering requirements, estimating costs, triaging requests, saying no, or any number of other things... To be fair, nobody is great at those first two.
- makeitsuckless 11y ago
  I've managed developers for years, thank you very much. You're right about that being one of the challenges, but it's still an easy challenge compared to everything else. (BTW, the biggest issue within the emotions category is that developers tend to deny, even to themselves, that an issue is an emotional rather than a rational one.)

calibraxis 11y ago

Good article. > Few developers like to write documentation. That means it’s your job. OMFG. Most traditionally-trained devs I've met in person are next to illiterate. Bizarrely incompetent at docs. Unsurprisingly their code quality stinks too. They'd probably ridicule you for mentioning "programs must be written for people to read, and only incidentally for machines to execute". (Unless you say you're quoting "the Wizard Book", because they defer to argument from authority.) Read my sourcecode, they say, as if that doesn't mean "Go fuck yourself". And they simply never want to proactively improve. That would require introspection and self-critique. Pulling teeth.

vinceguidry 11y ago
You have to work within people's limitations, that is, if you can't pick the people you work with. A team is only as good as it's most competent member's willingness to pull everything together and inspire the less-motivated to perform at a higher level. That's leadership, and there's precious little of it anywhere, even (especially!) in the products we use every day. If there's no real leadership, then you're stuck in the backwaters of being managed. My advice is if you find yourself in this situation, either use it as an opportunity to work on your leadership skills or check out and throw your passion into side projects.
- calibraxis 11y ago
  Excellent points! Maybe anyone who decides to "check out" should consider getting physically away from the team, if possible. Find those who proactively help others and apply healthy self-critical thinking. Kathy Sierra in "Badass: Making Users Awesome" said: "An important, unconscious way to develop expertise is being around high-quality, high-quantity examples of expertise." The flipside is apparently true: exposure to mediocre examples begets mediocrity.
dlitz 11y ago
No kidding. I don't know how many time I've tweaked my code after starting to write some docs (docstrings/JavaDoc/etc.) and realizing that my abstraction boundaries were wrong. If writing those docs were somebody else's problem, my code would have been crap. This is after 10+ years in industry. On the other hand, end-user documentation can be a lot of really tedious screenshotting in some markets, and it can't always be automated.

ExpiredLink 11y ago

> Managers translate the project’s Big Picture into individual tasks for developers ... As any professional translator will tell you, this means you need to understand the work more intimately than the author. Such manager doesn't exist in the current development biotope.

hkarthik 11y ago
Nor should it. As a manager, I try to let the team and the PM work out the individual tasks, and ensure there is consensus and follow through by individuals. Handling external pressures, clearing roadblocks, and resolving team conflicts are where I feel that my time is best utilized.
- Moru 11y ago
  Yes exactly. Developer and Manager is two completely different jobs. Developer to manager promoting is a brain drain. A good developer does not have to be a good manager. A good manager does not have to be a good developer.

deleted 11y ago

[deleted]

elwell 11y ago

> Not a coder yourself? Learn enough to at least write tests. No, please.

robotkilla 11y ago
Not a doctor yourself? Learn enough to at least diagnose.
- alexqgb 11y ago
  For a hospital manager, that's actually not bad advice.
  - deleted 11y ago
    [deleted]
  - taeric 11y ago
    Is it? I'd be interested in any numbers surrounding the idea.
    - alexqgb 11y ago
      You shouldn't need numbers to evaluate a proposition with a premise that is self-evident. I mean, correct diagnosis is one of the first and most fundamental things a hospital does when admitting patients. Failure at this stage cascades through every step that follows, possibly with fatal consequence. If you're "managing" a place that handles this work without a working understanding of the process involved, there's a very good chance that failures can be traced - in large part - back to your desk.
      - taeric 11y ago
        I have grown to not believe in anything as self evident, anymore. Directly to this premise. Correct diagnosis is a difficult and often error prone things that a hospital can do. To think you can train someone to be a manager and be good at diagnosis is putting a lot of trust on someone. Should they be able to help? Certainly. But, at some level, I would expect the manager to be better at knowing which doctor to get you in touch with moreso than how to do the diagnosis themselves.

mbernstein 11y ago

> Testing is really important, but few developers like to write tests. That means it’s your job. As a leader of an engineering team (and an engineer), I think the is this is entirely the wrong approach. It's a leader's job to get the team to understand why writing tests is important and have them write them. Sometimes an individual isn't a great fit on the team and you need to figure out how to handle it (i.e., they refuse to write tests but the rest of the team is). There are few points in this article that resonate - but there are many that are complete off base such as > Managers translate the project’s Big Picture into individual tasks for developers, with their details and interactions specified in minute detail I agree that leaders/managers translate the big picture to developers (provide vision) - but the team should figure out the minute detail - otherwise you're removing autonomy, the ability to fail, and are yourself falling into the pit of micromanagement.

sheepmullet 11y ago
"It's a leader's job to get the team to understand why writing tests is important and have them write them." And sometimes you shouldn't write tests, or perhaps no unit tests, or perhaps write the tests but throw most of them away, etc etc. It is all highly context specific. The real issue for managers is even if they start out technical, within a year or two they lose touch.
- chao- 11y ago
  Good discussion of this sort of thing in a series of recorded Hangouts between Martin Fowler, Kent Beck and DHH: http://martinfowler.com/articles/is-tdd-dead/ http://martinfowler.com/articles/is-tdd-dead/ The takeaway is that the usefulness of tests is the feedback it gives you about your code (and confidence, a subtype or result of feedback). All of the BDD vs. TDD vs. Test First vs. Test Whenever can get wrapped up in too much zealotry, and is ultimately secondary to the goal of getting feedback.
- mbernstein 11y ago
  Sure. I don't disagree about not writing tests at times, etc. That's different than the point I'm trying to make. Leaders aren't necessarily tasked with doing any job a developer thinks is shit. The leaders job is to help the developer understand the why behind doing it. Also, do you have anything quantitative to back your statement about being out of touch? That hasn't been my experience generally and I work quite hard to ensure I don't lose touch. That's obviously only data on my experiences - but I didn't make the assertion (I genuinely interested though).

tomelders 11y ago

I agree with a lot of this. One thing I would add - it's your job to integrate development into the rest of the organisation. UX, design, marketing, sales. Failure to do so leads to animosity between development and the rest of the organisation. Animosity undermines the goals of the organisation. In my experience, the biggest issue to deal with when managing developers is that they feel like they're tasked with implementing stupid ideas created by idiots. its never that simple, and developers are generally rational people who, given all the facts, know when to digg I. And resist something, and when to swallow a bitter pill for the greater good.

sheepmullet 11y ago

The problem with this kind of article is the author rarely considers/explains the context. E.g. Managing a team of 10 developers at a company with 30% turnover is very different to managing a team of 3 developers at a company with 5% turnover. Approaches and techniques vary drastically based on context.

gizi 11y ago

I came to the project only a few months ago. The project was "90% finished" but full of bugs too. We recently went live anyway. In the meanwhile, I have asked the manager/client for finding help with QA, because it is quite hard to maintain overall consistency in the system. The smallest changes create big bugs elsewhere. It is not enough that he or me do the testing. We never test enough anyway, and we still regularly hit the live servers with bad bugs that cost money. The system is meant to process money, actually. That is its core task. The problem is that my request for having QA people helping out, would cost resources, and that the recruitment process for QA profiles does not seem particularly easy either. Then, there's also the situation with the graphical designer who seems to hate programmers, and never shows up when he said he would. I think that a good manager will find a way to put the right people in the right place at the right time.

uptownfunk 11y ago

Is the dev-manager dynamic something like: In school, most people don't get the project done unless there's a deadline imposed upon them by someone else. And in the professional world that someone else here is the manager..?

taeric 11y ago
School is unique in that most of the questions/projects you will be faced with have a pretty solid answer. Often times a definitive one. Work... not so much.

dschiptsov 11y ago

Let's try to use the classic analogy with painters.) Suppose "your team" have to paint a cathedral for a king and you are the "manager". Of course you cannot paint yourself and hence holding an opinion that the paints and brushes are the most important things in this business. Nevertheless, you have noticed, that some guys, like Leonardo, are much better at painting of the ceilings and in order not to disappoint the king you have to hire him and all the second best guys. Of course, you are sure that these guys are just lucky and overrated. What you ougth to do, in order to not be beheaded by the king, is to be sure that Leonardo and the other painters has everything they need, of best possible quality and there is not a single obstacle on the horizon. Now imagine that instead you have decided to hold daily meetings to discuss how to mix the paints properly, about responsibility to the whole team, and importance of writing daily reports about elements finished so far, together with detailed statistics of materials spent on each element. To be sure that everything is going well, you have to climb to the ceiling few times a day and ask smart, psychological questions in orfer to avoid any possible lapse in productivity by exercising employee's morale and dedication to the project. For that reason you have short meetings in the morning. Because you have no idea why the masterpieces of these guys are so highly acclaimed, you are constantly trying to improve their decisions by introducing new elements and changing colors, which are, you have been told, are industry standard best practices, and forcing them to use not the paints they used to, but guaranteed, safe, battle-tested priducts they used to paint the walls of the king's palace and stables.