3 ms·

So you can never make mistakes in your commitments?

by ptr 6y ago

CuriousSkeptic 6y ago
I do. Sometimes I work harder to compensate, some times I apologize. But then it’s my mistake so I can negotiate with myself. Sometimes working harder is warranted. Some salesperson screwed up, and it’s not really possible to reneg the multi million dollar contract. “I’m sorry guys, what can we do?”
- ChuckMcM 6y ago
  FWIW, as the manager I don't feel I own the commitment date, the team does. That process has a 'content' aspect to it as well in the form, "by this date, this content, by this later date this additional content". But I understand the angst against managers who "manage up" promising impossible dates and "blaming down" when the dates aren't met. I learned early on as an individual contributor that "getting it in writing" was essential to protect myself and personally vowed never to inflict that pain on anyone that works for me.
  - tikhonj 6y ago
    I think this works, but only in cases where two things are true: - the team is actually responsible for the date—often, there's massive asymmetric pressure to aim for less time - if it's an actual deadline, the team has the autonomy to adjust scope to hit it In my experience, the worst situations happen when estimates are treated like deadlines. An estimate has to have uncertainty. Without some way to manage uncertainty, you'd have to pad estimates out to like the 99th percentile to hit them consistently, but people read estimates as averages and push back against that. If teams are consistently going over estimates, it's a problem in how you do estimates, not how you're working. (Which is also why evaluating people's performance based on how well they hit estimates—which seems common on a lot of teams—is completely misguided. Estimating is a nice skill to have, but it matters far, far less than the quality of the work people actually do!) On the other hand, a deadline is only a deadline if you're willing to adjust scope to hit it. If there is a real deadline and it looks like we might not hit it, the answer isn't "try to be more productive" (which is all that "work harder" actually means!). Instead, we should figure out how we can change what we're focusing on and what we're concretely building in order to still hit the underlying goal as well as possible with the time remaining. If we're working towards an estimate rather than a deadline, we might still adjust scope and focus, but the first step would be adjusting and sharing a new estimate. But if the culture is that estimates are hard commitments and you can't adjust the scope or the timeline, the work environment is going to be absolutely miserable, people will get stressed out for no real reason and the quality of the work is going to suffer. People will do whatever it takes to technically achieve estimates, even if that means cutting corners everywhere, sweeping bugs under the carpet, not spending any time to iterate or improve on the system and indefinitely putting off engineering work that has a small cost now but gives a massive medium- to long-term benefit in productivity. A month or two into this process and you move towards a death march that burns everyone out and, on the time scale of months, accomplishes substantially less than a less aggressive approach would have. I'm currently working with a team that has this problem to some extent—of course, the managers think of it as "accountability" and "a focus on delivery"—and in a bit over a year, they've built a codebase that already feels like a legacy mess, while accomplishing what would have been like eight months' worth of work with a better engineering approach. It's pretty frustrating to see and I'm trying to change things, but not sure whether I'm going about it effectively.
    - ChuckMcM 6y ago
      I don't disagree with you, but as you accurately infer this is a management problem not a team problem. When folks start becoming managers of managers this becomes a bigger focus of their job. I see the whole "agile" movement as a response to this problem. In an effort to mitigate the "error bars" of an estimate a process that iterates over 2 week sprints allows for estimate corrections during development. It isn't obvious to everyone but this is just upping the sample rate on the estimation signal to get a better handle on the noise and thus the signal to noise ratio.
      - tikhonj 6y ago
        This comment ended up as a bit of a rant, on a topic where you have way more experience than I do. Sorry about that! At this point, I'm just using this as a chance to gather my own thoughts on the subject, and I figure I'll post it just in case I get some interesting responses. ------------- Yeah, that's a great observation on Agile. Smaller but more accurate estimates + cheaper small course corrections. The dual is that the rest of the organization needs to adapt too—good short-term estimates don't necessarily give you good long-term estimates! So we need loosely coupled, self-sufficient teams that don't depend on accurate estimates from other teams. I've always hated formal Agile processes (especially Scrum) but I have to work with teams that use them, so I did a bunch of reading about it. The goals and even a lot of the concrete ideas behind it made a lot of sense! It's just that every single concrete instance of the process fell short. I've seen several concrete failure modes in practice: 1. Scrum-flavored micromanagement. People (not necessarily formal managers) use the process to dictate exactly what everyone else needs to work on at practically a daily granularity. 2. Siloing. People are incentivized to only work on "their" tasks—ad hoc collaboration with teammates, trying out speculative design ideas and experiments, figuring out better ways to do something, all get in the way of finishing your tickets, which makes you look flaky in inevitably awkward group meetings. 3. Loss of context. People see that the process helps the team switch priorities, so they switch focus every sprint. Couple this with micromanagement, and you get individuals moved around on wholly unrelated tasks. Too much context switching adds a lot of mental overhead and makes it much harder to build anything with a coherent design and vision (either from a product or from an engineering standpoint). 4. Performance mismeasurement. The whole process is supposed to help the team with estimates. Tracking metrics the process generates and treating them as a way to measure individual performance (whether formally, or just through peer pressure) doesn't work well and is awful for morale. I haven't seen it, but I bet it is possible to have a Scrum process—or, more likely, something lighter like Kanban—that avoids these problems. But I believe that even idealized Agile processes put too much weight on consistency for its own sake. Making consistent incremental progress helps with estimates and, I suppose, makes the team somewhat easier to manage, but none of that matters nearly as much as, say, quality of work and impact! Even if nothing from the Agile process makes it into formal performance evaluations, the ceremonies almost seem designed to create peer pressure around it. And that affects day-to-day job satisfaction a lot more than mere performance reviews. Although maybe this is another thing that goes away if you have high-trust teams that are legitimately self-organizing the way Agile is supposed to be... But I'm not sure even that would compensate for the pressure implicitly exerted by the structure of the process. I bring this up because over-emphasizing consistency imposes a cost on people—individuals get a lot less flexibility in how they work, and end up feeling stress when they're less productive than normal. I tend to think an ideal environment should embrace inconsistency day-to-day and even week-to-week or month-to-month but that requires massive differences in culture. If a team pulls it off, the process starts mattering a lot less!

So you can never make mistakes in your commitments?

by ptr 6y ago

So you can never make mistakes in your commitments?

I do. Sometimes I work harder to compensate, some times I apologize. But then it’s my mistake so I can negotiate with myself. Sometimes working harder is warranted. Some salesperson screwed up, and it’s not really possible to reneg the multi million dollar contract. “I’m sorry guys, what can we do?”

ChuckMcM 6y ago
FWIW, as the manager I don't feel I own the commitment date, the team does. That process has a 'content' aspect to it as well in the form, "by this date, this content, by this later date this additional content". But I understand the angst against managers who "manage up" promising impossible dates and "blaming down" when the dates aren't met. I learned early on as an individual contributor that "getting it in writing" was essential to protect myself and personally vowed never to inflict that pain on anyone that works for me.
- tikhonj 6y ago
  I think this works, but only in cases where two things are true: - the team is actually responsible for the date—often, there's massive asymmetric pressure to aim for less time - if it's an actual deadline, the team has the autonomy to adjust scope to hit it In my experience, the worst situations happen when estimates are treated like deadlines. An estimate has to have uncertainty. Without some way to manage uncertainty, you'd have to pad estimates out to like the 99th percentile to hit them consistently, but people read estimates as averages and push back against that. If teams are consistently going over estimates, it's a problem in how you do estimates, not how you're working. (Which is also why evaluating people's performance based on how well they hit estimates—which seems common on a lot of teams—is completely misguided. Estimating is a nice skill to have, but it matters far, far less than the quality of the work people actually do!) On the other hand, a deadline is only a deadline if you're willing to adjust scope to hit it. If there is a real deadline and it looks like we might not hit it, the answer isn't "try to be more productive" (which is all that "work harder" actually means!). Instead, we should figure out how we can change what we're focusing on and what we're concretely building in order to still hit the underlying goal as well as possible with the time remaining. If we're working towards an estimate rather than a deadline, we might still adjust scope and focus, but the first step would be adjusting and sharing a new estimate. But if the culture is that estimates are hard commitments and you can't adjust the scope or the timeline, the work environment is going to be absolutely miserable, people will get stressed out for no real reason and the quality of the work is going to suffer. People will do whatever it takes to technically achieve estimates, even if that means cutting corners everywhere, sweeping bugs under the carpet, not spending any time to iterate or improve on the system and indefinitely putting off engineering work that has a small cost now but gives a massive medium- to long-term benefit in productivity. A month or two into this process and you move towards a death march that burns everyone out and, on the time scale of months, accomplishes substantially less than a less aggressive approach would have. I'm currently working with a team that has this problem to some extent—of course, the managers think of it as "accountability" and "a focus on delivery"—and in a bit over a year, they've built a codebase that already feels like a legacy mess, while accomplishing what would have been like eight months' worth of work with a better engineering approach. It's pretty frustrating to see and I'm trying to change things, but not sure whether I'm going about it effectively.
  - ChuckMcM 6y ago
    I don't disagree with you, but as you accurately infer this is a management problem not a team problem. When folks start becoming managers of managers this becomes a bigger focus of their job. I see the whole "agile" movement as a response to this problem. In an effort to mitigate the "error bars" of an estimate a process that iterates over 2 week sprints allows for estimate corrections during development. It isn't obvious to everyone but this is just upping the sample rate on the estimation signal to get a better handle on the noise and thus the signal to noise ratio.
    - tikhonj 6y ago
      This comment ended up as a bit of a rant, on a topic where you have way more experience than I do. Sorry about that! At this point, I'm just using this as a chance to gather my own thoughts on the subject, and I figure I'll post it just in case I get some interesting responses. ------------- Yeah, that's a great observation on Agile. Smaller but more accurate estimates + cheaper small course corrections. The dual is that the rest of the organization needs to adapt too—good short-term estimates don't necessarily give you good long-term estimates! So we need loosely coupled, self-sufficient teams that don't depend on accurate estimates from other teams. I've always hated formal Agile processes (especially Scrum) but I have to work with teams that use them, so I did a bunch of reading about it. The goals and even a lot of the concrete ideas behind it made a lot of sense! It's just that every single concrete instance of the process fell short. I've seen several concrete failure modes in practice: 1. Scrum-flavored micromanagement. People (not necessarily formal managers) use the process to dictate exactly what everyone else needs to work on at practically a daily granularity. 2. Siloing. People are incentivized to only work on "their" tasks—ad hoc collaboration with teammates, trying out speculative design ideas and experiments, figuring out better ways to do something, all get in the way of finishing your tickets, which makes you look flaky in inevitably awkward group meetings. 3. Loss of context. People see that the process helps the team switch priorities, so they switch focus every sprint. Couple this with micromanagement, and you get individuals moved around on wholly unrelated tasks. Too much context switching adds a lot of mental overhead and makes it much harder to build anything with a coherent design and vision (either from a product or from an engineering standpoint). 4. Performance mismeasurement. The whole process is supposed to help the team with estimates. Tracking metrics the process generates and treating them as a way to measure individual performance (whether formally, or just through peer pressure) doesn't work well and is awful for morale. I haven't seen it, but I bet it is possible to have a Scrum process—or, more likely, something lighter like Kanban—that avoids these problems. But I believe that even idealized Agile processes put too much weight on consistency for its own sake. Making consistent incremental progress helps with estimates and, I suppose, makes the team somewhat easier to manage, but none of that matters nearly as much as, say, quality of work and impact! Even if nothing from the Agile process makes it into formal performance evaluations, the ceremonies almost seem designed to create peer pressure around it. And that affects day-to-day job satisfaction a lot more than mere performance reviews. Although maybe this is another thing that goes away if you have high-trust teams that are legitimately self-organizing the way Agile is supposed to be... But I'm not sure even that would compensate for the pressure implicitly exerted by the structure of the process. I bring this up because over-emphasizing consistency imposes a cost on people—individuals get a lot less flexibility in how they work, and end up feeling stress when they're less productive than normal. I tend to think an ideal environment should embrace inconsistency day-to-day and even week-to-week or month-to-month but that requires massive differences in culture. If a team pulls it off, the process starts mattering a lot less!