5 ms·

I wonder what the perspective of other people who run businesses or manage teams are on this subject? I have managed teams at top tech companies in bay area in

I wonder what the perspective of other people who run businesses or manage teams are on this subject? I have managed teams at top tech companies in bay area in the past (although switched back to an engineering position recently). Regardless of the company, I have always wondered why everyone around me is working so slowly. Things that a good engineer should be able to do in a day gets done in a month or more. When working as an engineer people always commented that I'm very efficient. But honestly I think the reason is a lot of people just barely put 10 hours a week in the current 5 days a week routine. Lots of times I feel like you could just let 60-70% of people go at companies I've worked at and literally nothing changes. My experience has been that a handful of high output individuals at each company are responsible for 90% of things that gets done. So I wonder what happens if we reduce this even more? Probably nothing, because high output individuals usually have intrinsic motivations and will continue putting more hours than is required.

quacked 4y ago
Step 1: Give everyone many more projects than they can handle Step 2: Make everything asynchronous, so no one starts any bit of work or sub-sub-phase without permission/documentation/merge review Step 3: Hold regular status meetings This will make tasks that should take four people sitting in a room six hours to complete take a month or more, every time, guaranteed.
rektide 4y ago
> high output individuals usually have intrinsic motivations I agree a lot that intrinsic motivation is key, changes everything, and I think this is a widescale struggle. But while the motivation is intrinsic, the survival rate of intrinsic motivation is deeply governed by the organization. Many many decent-size and/or moderately-mature organizations create resistance, ongoingly tax motivation, sap our will & sense that we can influence things, can change things, can take control. Preserving your team's sense of agency is paramount, but almost always fucked over. The rest of the org (that isn't doing the actual labor) constantly worries, constantly wants to make sure things are going ok, frets & wants to do things when the waterfall product-roadmap isn't going as they hoped or expected. If things are happening off the roadmap, outside of the top-down plan, well, you betcha there's gonna be a lot of meetings & discussions. The company's extrinsic desires are what matters: you, the human resource, are there to crank out the expected work at a predictable rate. Got it? Good. Now stay intrinsically motivated & go tackle the work we've given you! Very few organizations give their employees real license to do good things, to tackle the work well & encompass broad wins. Doing obviously good & great things might impact the roadmap! Oh no! In short, there's too many "decision makers," too much management deciding, and too many people checking in & trying to help make sure everyone is spending their times wisely, that "there's not something we can do to speed this up". There's a lot of would-be highly productive people in most orgs, except the org itself is medium/low-performance, eats away & erodes at the sense of autonomy & mastery & purpose (not a huge Daniel Pink fan but this continues to be a good set of dimensions) that are integral to maintaining high output. Often in many orgs, there's an informal social agreement that some vaunted select people can just do whatever & we'll trust them, but everyone else gets the regular employee treatment. You have to slay the backlog for a couple quarters, non-stop, do only product work, and then you're off the hook. External factors confound confound confound the intrinsic motivation that we need desperately to keep fueled & stoked. There's so few people who can sympathize or go with us as we do good things, as we set ourselves & the product up for future success, beyond just getting the mundane features cranked out. There's constant skepticism about the 10x hacker, who gets great accolades & is celebrated in the org, but leaves behind them a wake of messy & terrible systems: this too speaks to the visible versus invisible pieces of our job, about what the extrinsic motivators look like and what intrinsically drives a hacker. Software is massive, & tending to this realm & keeping it technically healthy is largely invisible labor that the organization often lacks competence to see or assess. We're rated superficially, based off the tip of the iceberg that is visible, and come to feel we're living in our own shadows of greatness, unseen, hidden. Yes, the Hacker can continue to find good tasks, good work, to define their own success & enjoy chomping through tasks with abandon. But I see, so often, the distance & dissonance grows, and doing good deeds rarely seems to get easier over time in most orgs. I think there is huge potential in many many people to be high performing, to engage avidly & actively, but the organization & it's quest for certainty, it's drive for reliable consistent output- it's desire to understand while clearly never understanding- quell the ability to work well, to create high-performance.
- damagednoob 4y ago
  > Very few organizations give their employees real license to do good things, to tackle the work well & encompass broad wins. I sympathise with your argument but the problem is that the Dunning–Kruger effect exists for both the employee and the manager. I've seen 20-something, know-nothing developers relentlessly question every business decision during planning when they clearly have no idea about the larger scope of the business. The reality is that the average person is average and every organisation is setup to succeed _despite_ the lowest common denominator.
  - rektide 4y ago
    Oh for sure. I think part of the reciprocal aspect, that businesses are also terrible at, is feedback. Most technical work is unremarked upon. There's code review, but how often do your teams retrospect their own work? How often do they retrospect some system or another teams work? Businesses use their same superficial tip-of-the-iceberg views, more often than not, to assess employees. 10x hacker wins again! Let's take your scenario: > I've seen 20-something, know-nothing developers relentlessly question every business decision during planning when they clearly have no idea about the larger scope of the business. I'd like to see some stake in here. If this persons on our payroll, give them, I dunno, 3-sprints of their own work/2-times-per-year to go try to make shit they talk up real. Maybe insist they spend a sprint or two working with at least one other person on it, to make it a little more real & not independent fuck off time. Have some sort of coder council at the end that can discuss highlights & negatives of the approach. Make sure not-passing is a known & not-irregular result. But let them go at it, find out! It's weird to me how consensus is nearly the only operating paradigm for organizations. The overwhelming & singular pattern is always the same: somehow a path is picked, and everyone must hem to it. The actual cost of doing duplicate work seems low to me, given how often I think we leave massive potential gains behind. I recall a mention of 1-10-100[1] today, which is nominally about the cost of bad data: 1x if prevented, 10x if corrected, 100x if failure happens. Computer systems/code seem like a hyper-complected version of this. Finding good systems, good patterns, good ways to do things, that make things easy & simple will keep paying off, will be endlessly rewarding. It's so so hard to project, and we often pick "safe" in terms of what we know, but we rarely get to explore the opportunity cost of other paths. And we damage our employee's belief in the company by consistently rejecting bold ideas. Right now it sounds insane to develop something twice, to let two groups do a thing, and then figure out latter where to head- someone's going to get hurt probably- but I think, if we want to tame the 20-something bucks, some real world challenges like this would be very compelling intrinsic motivators. Would show us very quickly a lot of different kinds of legitimacy: the legitimacy of the organization's concerns, which are unmet by the small-scoped young mind, and the legitimacy of the young mind, which may have some great out of the box stellar wins. Right now we don't try to let people try- we reject people's sense of purpose, we deny them autonomy, we refuse to acknowledge their mastery, for a litany of well-intended & perhaps-functional concerns, but they never construct the understanding & knowledge that would clarify why they are snubbed. If they could live the experience[2] instead, it might alter their intrinsic motivations in the future, might align them differently. Instead, we use hierarchy & roadmaps to coral & drive our talent forward. It sounds daft & wild, the processes we'd need seem like they'd mostly just be spitballed together at this stage, but breaking the mold: rejecting the concensus practice of consensus based knowledge-working, allowing different people to try different things, having stronger review & higher candor & willingness/ability to try things & reject some, say no: I think there's huge wins for amplifying the highly-important intrinsic motivation, and I think it would unlock a lot of higher-performance work. Leaving mono-culture & allowing diversity into the organization sounds is an idea that sounds both radical to me, and flabbergastingly right-in-front-of-us. [1] https://news.ycombinator.com/item?id=31643434 https://news.ycombinator.com/item?id=31643434 [2] https://en.wikipedia.org/wiki/Constructivism_(philosophy_of_education) https://en.wikipedia.org/wiki/Constructivism_(philosophy_of_...
jokethrowaway 4y ago
Completely agree. This is the reason I don't hire anyone for my business but partner with other developers I trust and promise part of the revenue. Without promises of passive revenue (30-50% equity), almost no engineer worth their salt would be productive. I could hire contractors for a project and get shitty code but at that point I'd rather just do it myself. I've tried hiring multiple times in my startups and little equity is essentially wasted on people, same as market rate salaries. That's why nothing gets done in mid - big companies. People are not tied to the success of the company and layers of middle management provide a way to hide.
onion2k 4y ago
Things that a good engineer should be able to do in a day gets done in a month or more. I think the fact that you put "a good engineer" in your post undermines the point you're making. People taking too long to complete simple tasks is a problem, but only where those tasks don't really require any significant ability to complete. Something simple and low risk should be completed quickly by anyone, even a terrible engineer. Good engineers don't go quickly though. Where something is complex or high risk they should take their time and go slowly. Spending more than a day just considering the task in full is fine. Honestly, for the majority of tasks beyond anything trivial, I'd be very wary of any dev who claimed to be able to go quickly.
- ramblerman 4y ago
  So... not "Things that a good engineer should be able to do in a day" then.
  - onion2k 4y ago
    The point is that things that there isn't anything that requires a good engineer that also can be done in a day. Either a job is something that can be done in a trivial amount of time because it's simple, or it's something that's hard enough to take some skill. It's never both. There are no jobs that can be done faster by being a better engineer. Good engineers do better work, not faster work. Often they're actually slower because they consider the edge cases and they don't cut corners.
laszlojamf 4y ago
This applies to a surprising amount of things: https://en.wikipedia.org/wiki/Pareto_principle https://en.wikipedia.org/wiki/Pareto_principle
hgomersall 4y ago
I often think a particular problem is a day's task. Then a week later I'm still working on it. For sure, it might be me being lazy, but I suspect I've also underestimated the complexity of the task. Other factors play in as well, like if I'm tired my ability to solve tricky problems goes waay down. Perhaps I should always be not tired, but sometimes life has a habit of getting in the way.
_fat_santa 4y ago
> Regardless of the company, I have always wondered why everyone around me is working so slowly. The barrier is never the code, always the communication. Depending on the feature, you will have to work across a few teams, delegate, coordinate, etc. Writing the code is the easy part, the hard part is getting everyone on the same page.

quacked 4y ago

Step 1: Give everyone many more projects than they can handle Step 2: Make everything asynchronous, so no one starts any bit of work or sub-sub-phase without permission/documentation/merge review Step 3: Hold regular status meetings This will make tasks that should take four people sitting in a room six hours to complete take a month or more, every time, guaranteed.

rektide 4y ago

> high output individuals usually have intrinsic motivations I agree a lot that intrinsic motivation is key, changes everything, and I think this is a widescale struggle. But while the motivation is intrinsic, the survival rate of intrinsic motivation is deeply governed by the organization. Many many decent-size and/or moderately-mature organizations create resistance, ongoingly tax motivation, sap our will & sense that we can influence things, can change things, can take control. Preserving your team's sense of agency is paramount, but almost always fucked over. The rest of the org (that isn't doing the actual labor) constantly worries, constantly wants to make sure things are going ok, frets & wants to do things when the waterfall product-roadmap isn't going as they hoped or expected. If things are happening off the roadmap, outside of the top-down plan, well, you betcha there's gonna be a lot of meetings & discussions. The company's extrinsic desires are what matters: you, the human resource, are there to crank out the expected work at a predictable rate. Got it? Good. Now stay intrinsically motivated & go tackle the work we've given you! Very few organizations give their employees real license to do good things, to tackle the work well & encompass broad wins. Doing obviously good & great things might impact the roadmap! Oh no! In short, there's too many "decision makers," too much management deciding, and too many people checking in & trying to help make sure everyone is spending their times wisely, that "there's not something we can do to speed this up". There's a lot of would-be highly productive people in most orgs, except the org itself is medium/low-performance, eats away & erodes at the sense of autonomy & mastery & purpose (not a huge Daniel Pink fan but this continues to be a good set of dimensions) that are integral to maintaining high output. Often in many orgs, there's an informal social agreement that some vaunted select people can just do whatever & we'll trust them, but everyone else gets the regular employee treatment. You have to slay the backlog for a couple quarters, non-stop, do only product work, and then you're off the hook. External factors confound confound confound the intrinsic motivation that we need desperately to keep fueled & stoked. There's so few people who can sympathize or go with us as we do good things, as we set ourselves & the product up for future success, beyond just getting the mundane features cranked out. There's constant skepticism about the 10x hacker, who gets great accolades & is celebrated in the org, but leaves behind them a wake of messy & terrible systems: this too speaks to the visible versus invisible pieces of our job, about what the extrinsic motivators look like and what intrinsically drives a hacker. Software is massive, & tending to this realm & keeping it technically healthy is largely invisible labor that the organization often lacks competence to see or assess. We're rated superficially, based off the tip of the iceberg that is visible, and come to feel we're living in our own shadows of greatness, unseen, hidden. Yes, the Hacker can continue to find good tasks, good work, to define their own success & enjoy chomping through tasks with abandon. But I see, so often, the distance & dissonance grows, and doing good deeds rarely seems to get easier over time in most orgs. I think there is huge potential in many many people to be high performing, to engage avidly & actively, but the organization & it's quest for certainty, it's drive for reliable consistent output- it's desire to understand while clearly never understanding- quell the ability to work well, to create high-performance.

damagednoob 4y ago
> Very few organizations give their employees real license to do good things, to tackle the work well & encompass broad wins. I sympathise with your argument but the problem is that the Dunning–Kruger effect exists for both the employee and the manager. I've seen 20-something, know-nothing developers relentlessly question every business decision during planning when they clearly have no idea about the larger scope of the business. The reality is that the average person is average and every organisation is setup to succeed _despite_ the lowest common denominator.
- rektide 4y ago
  Oh for sure. I think part of the reciprocal aspect, that businesses are also terrible at, is feedback. Most technical work is unremarked upon. There's code review, but how often do your teams retrospect their own work? How often do they retrospect some system or another teams work? Businesses use their same superficial tip-of-the-iceberg views, more often than not, to assess employees. 10x hacker wins again! Let's take your scenario: > I've seen 20-something, know-nothing developers relentlessly question every business decision during planning when they clearly have no idea about the larger scope of the business. I'd like to see some stake in here. If this persons on our payroll, give them, I dunno, 3-sprints of their own work/2-times-per-year to go try to make shit they talk up real. Maybe insist they spend a sprint or two working with at least one other person on it, to make it a little more real & not independent fuck off time. Have some sort of coder council at the end that can discuss highlights & negatives of the approach. Make sure not-passing is a known & not-irregular result. But let them go at it, find out! It's weird to me how consensus is nearly the only operating paradigm for organizations. The overwhelming & singular pattern is always the same: somehow a path is picked, and everyone must hem to it. The actual cost of doing duplicate work seems low to me, given how often I think we leave massive potential gains behind. I recall a mention of 1-10-100[1] today, which is nominally about the cost of bad data: 1x if prevented, 10x if corrected, 100x if failure happens. Computer systems/code seem like a hyper-complected version of this. Finding good systems, good patterns, good ways to do things, that make things easy & simple will keep paying off, will be endlessly rewarding. It's so so hard to project, and we often pick "safe" in terms of what we know, but we rarely get to explore the opportunity cost of other paths. And we damage our employee's belief in the company by consistently rejecting bold ideas. Right now it sounds insane to develop something twice, to let two groups do a thing, and then figure out latter where to head- someone's going to get hurt probably- but I think, if we want to tame the 20-something bucks, some real world challenges like this would be very compelling intrinsic motivators. Would show us very quickly a lot of different kinds of legitimacy: the legitimacy of the organization's concerns, which are unmet by the small-scoped young mind, and the legitimacy of the young mind, which may have some great out of the box stellar wins. Right now we don't try to let people try- we reject people's sense of purpose, we deny them autonomy, we refuse to acknowledge their mastery, for a litany of well-intended & perhaps-functional concerns, but they never construct the understanding & knowledge that would clarify why they are snubbed. If they could live the experience[2] instead, it might alter their intrinsic motivations in the future, might align them differently. Instead, we use hierarchy & roadmaps to coral & drive our talent forward. It sounds daft & wild, the processes we'd need seem like they'd mostly just be spitballed together at this stage, but breaking the mold: rejecting the concensus practice of consensus based knowledge-working, allowing different people to try different things, having stronger review & higher candor & willingness/ability to try things & reject some, say no: I think there's huge wins for amplifying the highly-important intrinsic motivation, and I think it would unlock a lot of higher-performance work. Leaving mono-culture & allowing diversity into the organization sounds is an idea that sounds both radical to me, and flabbergastingly right-in-front-of-us. [1] https://news.ycombinator.com/item?id=31643434 https://news.ycombinator.com/item?id=31643434 [2] https://en.wikipedia.org/wiki/Constructivism_(philosophy_of_education) https://en.wikipedia.org/wiki/Constructivism_(philosophy_of_...

jokethrowaway 4y ago

Completely agree. This is the reason I don't hire anyone for my business but partner with other developers I trust and promise part of the revenue. Without promises of passive revenue (30-50% equity), almost no engineer worth their salt would be productive. I could hire contractors for a project and get shitty code but at that point I'd rather just do it myself. I've tried hiring multiple times in my startups and little equity is essentially wasted on people, same as market rate salaries. That's why nothing gets done in mid - big companies. People are not tied to the success of the company and layers of middle management provide a way to hide.

onion2k 4y ago

Things that a good engineer should be able to do in a day gets done in a month or more. I think the fact that you put "a good engineer" in your post undermines the point you're making. People taking too long to complete simple tasks is a problem, but only where those tasks don't really require any significant ability to complete. Something simple and low risk should be completed quickly by anyone, even a terrible engineer. Good engineers don't go quickly though. Where something is complex or high risk they should take their time and go slowly. Spending more than a day just considering the task in full is fine. Honestly, for the majority of tasks beyond anything trivial, I'd be very wary of any dev who claimed to be able to go quickly.

ramblerman 4y ago
So... not "Things that a good engineer should be able to do in a day" then.
- onion2k 4y ago
  The point is that things that there isn't anything that requires a good engineer that also can be done in a day. Either a job is something that can be done in a trivial amount of time because it's simple, or it's something that's hard enough to take some skill. It's never both. There are no jobs that can be done faster by being a better engineer. Good engineers do better work, not faster work. Often they're actually slower because they consider the edge cases and they don't cut corners.

laszlojamf 4y ago

This applies to a surprising amount of things: https://en.wikipedia.org/wiki/Pareto_principle https://en.wikipedia.org/wiki/Pareto_principle

hgomersall 4y ago

I often think a particular problem is a day's task. Then a week later I'm still working on it. For sure, it might be me being lazy, but I suspect I've also underestimated the complexity of the task. Other factors play in as well, like if I'm tired my ability to solve tricky problems goes waay down. Perhaps I should always be not tired, but sometimes life has a habit of getting in the way.

_fat_santa 4y ago

> Regardless of the company, I have always wondered why everyone around me is working so slowly. The barrier is never the code, always the communication. Depending on the feature, you will have to work across a few teams, delegate, coordinate, etc. Writing the code is the easy part, the hard part is getting everyone on the same page.