4 ms·

"All doers, no talkers" Some of the absolute worst teams I have been on were like that. Full of self-proclaimed "doers". Always doing things without thinking e

"All doers, no talkers" Some of the absolute worst teams I have been on were like that. Full of self-proclaimed "doers". Always doing things without thinking even the basics through, no coordination whatsoever. Creating complete shitshows and clown-fiestas that others then have to fix somehow and always, always (did I say always already?) with the dumb excuse "well, at least I did something". These are the "net negatives" on your projects. P.S. And no, "be smart gets things done" people do not refer to themselves as "doers".

BigJono 7y ago
I assume 'talkers' means people that only talk. OP isn't making a case for or against planning, just saying that if you're taking a small team approach, once the planning is sufficient, the people who do the planning also have to jump in and produce. Your 'small team' can't be one programmer with a team of BAs, POs and designers looking over their shoulder for 40 hours a week.
- lucideer 7y ago
  This obviously doesn't apply across the board (but what does), but in my experience, on engineering teams I've been on, so-called & self-proclaimed "doers" are only doers of highly visible work, whereas the "talkers" are the real behind-the-scenes doers. They do the invisible maintenance work and a part of the reason they "talk" so much is because they know from experience what the burden of managing technical debt. is (and that they'll be stuck doing it) and they want to talk/plan out/advise people on the least burdensome options. They invisibly help/mentor the self-proclaimed "doers" on the projects they've eagerly taken on without any clue as to how challenging it will end up being (the same project the "talkers" cautioned others about because their knowledge gave them some degree of foresight). The truth is, you probably need both breeds. The "doers" for ambition and the ability to actually start something (without getting lost in months of talking/planning) and the "talkers" to insist on the limited amount of talking/planning needed and actually have the knowledge to follow through.
  - varjag 7y ago
    There's always more people willing to tell you what to code than the people who can code. You are not mentoring anything if you can't step in and do the job yourself.
    - watwut 7y ago
      I would point out he described people who do the most uncomfortable work on the project and therefore also talk to other people. The "does" he described cherry pick easy, fun, highly visible work, refuse to coordinate with others, dont help with integrating other peoples parts and then take offense when people doing integration complain.
  - username90 7y ago
    Hiring armchair architects will not do you any good, you want doers with enough experience doing things that they can plan when needed.
    - watwut 7y ago
      He did not des armchair architect: > They do the invisible maintenance work and a part of the reason they "talk" so much is because they know from experience what the burden of managing technical debt This is literally the people who deal with consequences of bad code. If you fire on bad code and then you leave maintennance on others, you are the "armchair" one. Because you are not dealing with consequences.
      - username90 7y ago
        Everyone who does maintenance work thinks they could do better than the original creators, most of the time they are wrong. They go and decide to do a rewrite by committee to ensure everything is clean now, sit in endless meetings discussing the best way to do things, end up with a product doing half the things of the old one since they make even slower progress than the pace they would go at even with massive amounts of technical debt, and because their clean solutions actually are less flexible than the old "ugly" ones. Now we have two versions of the products to maintain since we couldn't migrate everything meaning we now have more technical debt than before. The result is roughly the same as if someone just sat and churned through everything on his own, just that you now don't have a clear culprit to blame.
- ashtonkem 7y ago
  OP indeed does seem to be making a fairly anti-planning case. Banning anyone telling anyone else what they should be making is very anti-planning.
  - username90 7y ago
    It didn't really say you shouldn't tell people what to build, but that they should build what they want. This means instead of ordering them to build something you should convince them to build it, this ensures they are fully on board with the shared vision and possibly they might even have good arguments and convince you that their version is better.
    - ashtonkem 7y ago
      I agree that in general it’s better to persuade than it is to order. But once you cross a certain organizational size, it becomes indistinguishable from just not planning at all. Once your company and product crosses a certain size, planning on persuading every single team in the critical path to care about every single product feature is a fool’s errand; a certain amount of “we need X by Y” must come in to play.
raghava 7y ago
All of us have dealt with those kinds. 1. Overzealous ActionJockeys, who would just do shit - bothered only about local maxima ("I did mine! His thing is not yet done!" or "My code is superb; others' is total poop") Few variants are BrilliantJerk, who is supersmart but nobody wants to work with him. Also on same lines are some appreciation junkies and hero-role-playing characters , who always want to "save the day" - the LastMinuteHero types; but they'll never ever train others to hold their own as that could pose a peril to their heroism. 2. Dr AnalysisParalysis and his gang of bikeshedders. Could spend a week to choose the color of a button and while doing so earn a PhD in color theory. 3. Clueless Jimmy who just does what the leads ask him to do. He's a sure shot follower (in the lead-follow-or-get-outta-way kind) who just does NOT want to know the big picture. 4. Albatross managers. They come, they scream, they poop and fly away. Caw-caw caw Ca-caw! 5. IndifferentManagement - Anything goes as long as money comes in timely. "All doers, no talkers" is just absolute peak Silicon Valley - may be the does should talk often and properly, to do things well. And do it well. Collaboration over competition - it's 2020 FFS! One approach is building a team that actively prohibits bad characters (like those listed above) and empower them by treating them like adults, and things would just work? But very few would do it - cause "the SV prophets said otherwise! "
- arethuza 7y ago
  That reminds of a colleague who used to refer to a project manager he worked with as "Mr On Time and On Budget" - because that was all he cared about. Keen observers will have noticed that something is missing....
lojack 7y ago
More broadly, there are finders, minders, and grinders. Different companies need different compositions of those characteristics, but startups tend to lean towards finders (people that can sell) and grinders (the aforementioned "doers"). I don't think it's good for any individual to be an extreme with any trait. Thats how you end up with a sales team that sells the world with no regard for how it'll get done, or a developer who can crank out features with no ability to support those features, or product folk that spend hours every day with meetings full of people toiling over all the accessories that may one day need to fit inside your bike shed.

BigJono 7y ago

I assume 'talkers' means people that only talk. OP isn't making a case for or against planning, just saying that if you're taking a small team approach, once the planning is sufficient, the people who do the planning also have to jump in and produce. Your 'small team' can't be one programmer with a team of BAs, POs and designers looking over their shoulder for 40 hours a week.

lucideer 7y ago
This obviously doesn't apply across the board (but what does), but in my experience, on engineering teams I've been on, so-called & self-proclaimed "doers" are only doers of highly visible work, whereas the "talkers" are the real behind-the-scenes doers. They do the invisible maintenance work and a part of the reason they "talk" so much is because they know from experience what the burden of managing technical debt. is (and that they'll be stuck doing it) and they want to talk/plan out/advise people on the least burdensome options. They invisibly help/mentor the self-proclaimed "doers" on the projects they've eagerly taken on without any clue as to how challenging it will end up being (the same project the "talkers" cautioned others about because their knowledge gave them some degree of foresight). The truth is, you probably need both breeds. The "doers" for ambition and the ability to actually start something (without getting lost in months of talking/planning) and the "talkers" to insist on the limited amount of talking/planning needed and actually have the knowledge to follow through.
- varjag 7y ago
  There's always more people willing to tell you what to code than the people who can code. You are not mentoring anything if you can't step in and do the job yourself.
  - watwut 7y ago
    I would point out he described people who do the most uncomfortable work on the project and therefore also talk to other people. The "does" he described cherry pick easy, fun, highly visible work, refuse to coordinate with others, dont help with integrating other peoples parts and then take offense when people doing integration complain.
- username90 7y ago
  Hiring armchair architects will not do you any good, you want doers with enough experience doing things that they can plan when needed.
  - watwut 7y ago
    He did not des armchair architect: > They do the invisible maintenance work and a part of the reason they "talk" so much is because they know from experience what the burden of managing technical debt This is literally the people who deal with consequences of bad code. If you fire on bad code and then you leave maintennance on others, you are the "armchair" one. Because you are not dealing with consequences.
    - username90 7y ago
      Everyone who does maintenance work thinks they could do better than the original creators, most of the time they are wrong. They go and decide to do a rewrite by committee to ensure everything is clean now, sit in endless meetings discussing the best way to do things, end up with a product doing half the things of the old one since they make even slower progress than the pace they would go at even with massive amounts of technical debt, and because their clean solutions actually are less flexible than the old "ugly" ones. Now we have two versions of the products to maintain since we couldn't migrate everything meaning we now have more technical debt than before. The result is roughly the same as if someone just sat and churned through everything on his own, just that you now don't have a clear culprit to blame.
ashtonkem 7y ago
OP indeed does seem to be making a fairly anti-planning case. Banning anyone telling anyone else what they should be making is very anti-planning.
- username90 7y ago
  It didn't really say you shouldn't tell people what to build, but that they should build what they want. This means instead of ordering them to build something you should convince them to build it, this ensures they are fully on board with the shared vision and possibly they might even have good arguments and convince you that their version is better.
  - ashtonkem 7y ago
    I agree that in general it’s better to persuade than it is to order. But once you cross a certain organizational size, it becomes indistinguishable from just not planning at all. Once your company and product crosses a certain size, planning on persuading every single team in the critical path to care about every single product feature is a fool’s errand; a certain amount of “we need X by Y” must come in to play.

raghava 7y ago

All of us have dealt with those kinds. 1. Overzealous ActionJockeys, who would just do shit - bothered only about local maxima ("I did mine! His thing is not yet done!" or "My code is superb; others' is total poop") Few variants are BrilliantJerk, who is supersmart but nobody wants to work with him. Also on same lines are some appreciation junkies and hero-role-playing characters , who always want to "save the day" - the LastMinuteHero types; but they'll never ever train others to hold their own as that could pose a peril to their heroism. 2. Dr AnalysisParalysis and his gang of bikeshedders. Could spend a week to choose the color of a button and while doing so earn a PhD in color theory. 3. Clueless Jimmy who just does what the leads ask him to do. He's a sure shot follower (in the lead-follow-or-get-outta-way kind) who just does NOT want to know the big picture. 4. Albatross managers. They come, they scream, they poop and fly away. Caw-caw caw Ca-caw! 5. IndifferentManagement - Anything goes as long as money comes in timely. "All doers, no talkers" is just absolute peak Silicon Valley - may be the does should talk often and properly, to do things well. And do it well. Collaboration over competition - it's 2020 FFS! One approach is building a team that actively prohibits bad characters (like those listed above) and empower them by treating them like adults, and things would just work? But very few would do it - cause "the SV prophets said otherwise! "

arethuza 7y ago
That reminds of a colleague who used to refer to a project manager he worked with as "Mr On Time and On Budget" - because that was all he cared about. Keen observers will have noticed that something is missing....

lojack 7y ago

More broadly, there are finders, minders, and grinders. Different companies need different compositions of those characteristics, but startups tend to lean towards finders (people that can sell) and grinders (the aforementioned "doers"). I don't think it's good for any individual to be an extreme with any trait. Thats how you end up with a sales team that sells the world with no regard for how it'll get done, or a developer who can crank out features with no ability to support those features, or product folk that spend hours every day with meetings full of people toiling over all the accessories that may one day need to fit inside your bike shed.