6 ms·

In case you missed it in the article, the author seems to address this in the section titled 'Effectively Managing the Norm'.

riazrizvi 3y ago
Personally I use a show-don't-tell approach, and what I saw in the article was a few words at the beginning telling how we should trust people, followed by a giant section of showing how we actually don't.
pxue 3y ago
The author went from "trust them to do the right thing" to "Set clear deadlines and regularly check in on their progress. Make them accountable for those deadlines" real fast
- gemstones 3y ago
  The opposite is “set vague deadlines and don’t check in on their progress.” You’ll be accountable for team deadlines regardless - would you rather be allowed to sail over a deadline you didn’t know existed and be reprimanded for it by higher ups, or have a clear picture of deadlines and someone checking up on progress?
  - ukj 3y ago
    I am always incredibly surprised when people are surprised when I miss deadlines. I said I was going to do it for the following (rather good!) reasons. It is around that time when I am usually informed that I have zero autonomy over such decisions. Now I know. If I am not allowed any autonomy then could you please be explicit and upfront with all the trade-offs I am allowed to make, all the risks I am allowed to accept and the technical debts I am allowed to accrue? Oh, don't be a perfectionist! I am not - I have no autonomy on such decisions. Here's a list of known defects - tell me which ones I am allowed to ignore. Аpparently I am a difficult enginer. Meanwhile the leadership is outstanding.
    - vasco 3y ago
      I've had 1-1's with about 500 engineers between working with them or interviewing them. I honestly think you are being difficult under this described situation, yes. I mention the number only in case you'd trust that you are not alone in thinking this but: A competent professional understands from context the amount of time available, the absolute requirements of the role (ie regulatory compliance, internal engineering practices, whatever), and their own sense of "would I put my name on this crap" and then says a number. If you hire a plumber he doesn't ask you if you give him 2 days or 2 weeks or if he should use copper or plastic or if he should bring his good tools or his bad tools. He just gives you a reasonable estimate and does a reasonable job. If he is asked for better, he knows how to make it more robust by spending a little more time or using better materials, the same way you should know to make it scale up to more users or spend time refactoring into some better abstractions. But there is a bar that he won't go under and no amount of company policy or explicit bosses are gonna fix the fact that at the end of the day, it's a professional's job to predict how they are going to go about their work and how long they think it'll take.
      - ukj 3y ago
        A competent project manager in this undustry also understands that software engineering is not plumbing. And the variance in effort due to lack of standardization, technical intricacy and hidden complexity is orders of magnitude greater than plumbing so our initial estimates always suck. Most competent proffessional in this insdustry know that nobody knows how to do accurate time estimates on delivering complex software projects, so why don't you know this and why do you want me to lie to you about the crudeness of my estimates? Frankly, I've worked with hundreds of managers too and you sound difficult to work with. You seem to have unreasonable expectations that are impossible to manage with facts.
        gemstones 3y ago
        Eh, for the majority of cases, software engineering is more like plumbing than like R&D. There are exceptions, like building a new DB, or similar. But if the tools you need to solve the problem are postgres + Django + react, there shouldn't really be that much hidden complexity for you to uncover.

riazrizvi 3y ago

Personally I use a show-don't-tell approach, and what I saw in the article was a few words at the beginning telling how we should trust people, followed by a giant section of showing how we actually don't.

pxue 3y ago

The author went from "trust them to do the right thing" to "Set clear deadlines and regularly check in on their progress. Make them accountable for those deadlines" real fast

gemstones 3y ago
The opposite is “set vague deadlines and don’t check in on their progress.” You’ll be accountable for team deadlines regardless - would you rather be allowed to sail over a deadline you didn’t know existed and be reprimanded for it by higher ups, or have a clear picture of deadlines and someone checking up on progress?
- ukj 3y ago
  I am always incredibly surprised when people are surprised when I miss deadlines. I said I was going to do it for the following (rather good!) reasons. It is around that time when I am usually informed that I have zero autonomy over such decisions. Now I know. If I am not allowed any autonomy then could you please be explicit and upfront with all the trade-offs I am allowed to make, all the risks I am allowed to accept and the technical debts I am allowed to accrue? Oh, don't be a perfectionist! I am not - I have no autonomy on such decisions. Here's a list of known defects - tell me which ones I am allowed to ignore. Аpparently I am a difficult enginer. Meanwhile the leadership is outstanding.
  - vasco 3y ago
    I've had 1-1's with about 500 engineers between working with them or interviewing them. I honestly think you are being difficult under this described situation, yes. I mention the number only in case you'd trust that you are not alone in thinking this but: A competent professional understands from context the amount of time available, the absolute requirements of the role (ie regulatory compliance, internal engineering practices, whatever), and their own sense of "would I put my name on this crap" and then says a number. If you hire a plumber he doesn't ask you if you give him 2 days or 2 weeks or if he should use copper or plastic or if he should bring his good tools or his bad tools. He just gives you a reasonable estimate and does a reasonable job. If he is asked for better, he knows how to make it more robust by spending a little more time or using better materials, the same way you should know to make it scale up to more users or spend time refactoring into some better abstractions. But there is a bar that he won't go under and no amount of company policy or explicit bosses are gonna fix the fact that at the end of the day, it's a professional's job to predict how they are going to go about their work and how long they think it'll take.
    - ukj 3y ago
      A competent project manager in this undustry also understands that software engineering is not plumbing. And the variance in effort due to lack of standardization, technical intricacy and hidden complexity is orders of magnitude greater than plumbing so our initial estimates always suck. Most competent proffessional in this insdustry know that nobody knows how to do accurate time estimates on delivering complex software projects, so why don't you know this and why do you want me to lie to you about the crudeness of my estimates? Frankly, I've worked with hundreds of managers too and you sound difficult to work with. You seem to have unreasonable expectations that are impossible to manage with facts.
      - gemstones 3y ago
        Eh, for the majority of cases, software engineering is more like plumbing than like R&D. There are exceptions, like building a new DB, or similar. But if the tools you need to solve the problem are postgres + Django + react, there shouldn't really be that much hidden complexity for you to uncover.