9 ms·

I am a security engineer but have been a business leader from time to time. Business leaders often need to plan around dates- eg ”should we spend $50k announci

by efitz 5y ago

I am a security engineer but have been a business leader from time to time. Business leaders often need to plan around dates- eg ”should we spend $50k announcing at conference Y in month Z, or should we wait until month A?” “Our competition just launched; will we be able to launch this quarter (the board wants to know, and we have to report material financial impact items quarterly or face SEC fines)?” Every team I have ever worked with hates planning; every team hates their methodology and thinks it’s stupid and inaccurate and why are those pinhead business people insisting on a date; it’ll be done when it’s done. One of the primary jobs of managers at all levels is to plan and then execute in accordance with the plan. Some managers are good at it, many aren’t- the world is populated with people nearer the center than the ends of the bell curve. So show me a methodology that mere mortals can implement successfully. If all you can do is complain and point out unicorn 500x engineers (yeah try hiring for that characteristic, good luck), then I don’t want to hear it. But if you have a practical idea on how to “solve” planning, then you have my full attention.

vbezhenar 5y ago
Stop using methodologies actively preventing any kind of planning (mostly agile stuff). Return to waterfall, write lots of documentations, spend time planning architecture, resist urges to rewrite non-ideal solutions. Do not allow changes. It'll take more time and result will not be as clean. Basically learn from older engineering disciplines.
- sergio 5y ago
  Also, build several prototypes of every important part of the product in order to learn how long they will take to be made and how each variant will perform, so when you make estimations they are as effective as possible; and then, make integration tests on the selected variants so you can reduce estimation risks due to integration. Just as in every other engineering discipline.
- RNCTX 5y ago
  The two replies below yours at the moment capture what you're trying to say... > This mentality of thinking is exactly the problem, I think. You want a tool that can solve an entire class of problems. We are telling you that no such tool can exist to do what you want, the problem and the tools don't work that way. Each project should be planned as a snowflake. > This is exactly right and is the biggest problem with "Management" types. They want a "cookie cutter methodology" to solve all their problems so they can be spared thinking through each one. Hence the various "Management" fads and buzzwords. Which is another way to say... if there was a system to do their thing, they wouldn't have to pay smarter people a lot of money to do it. Reliance on a system (any system) tells you that the people don't value your expertise, but rather see you as a cost to be minimized.
fractalb 5y ago
You can just give a random guess on the timelines and save the developers time.
thegrimmest 5y ago
> But if you have a practical idea on how to “solve” planning Seems pretty straightforward to me - just don't use dates in your plans. That means don't announce features which aren't complete. Don't plan marketing campaigns for unlaunched products. Embrace "Now, "Next" and "Later" as headings on your roadmap. There are many successful companies that operate like this, Nintendo being a famous example. It doesn't seem to hurt their bottom line - quite the contrary. The usual issue that folks have with planning is that business leaders are simply not willing to spend the resources to do it accurately enough to answer the questions they're asking. Think how much time it would take to break 6 months of work for several teams into detailed stories and estimate each one. It therefore seems they're basically wasting everyone's time, since dartboards and magic-8-balls are just as good as engineering estimates without details.
Afforess 5y ago
This mentality of thinking is exactly the problem, I think. You want a tool that can solve an entire class of problems. We are telling you that no such tool can exist to do what you want, the problem and the tools don't work that way. Each project should be planned as a snowflake. Each project is different. Each team is unique. Every individual performs differently, even one day to the next. Stop looking for this tool to make these plans. It can't exist. Do the hard thing and plan projects individually.
- rramadass 5y ago
  >This mentality of thinking is exactly the problem Damn right! >We are telling you that no such tool can exist to do what you want This is exactly right and is the biggest problem with "Management" types. They want a "cookie cutter methodology" to solve all their problems so they can be spared thinking through each one. Hence the various "Management" fads and buzzwords. The core of the solution lies with the Individual; understand their needs, wants, motivations, practice "Empathetic Management" and you will be successful.
aahortwwy 5y ago
> So show me a methodology that mere mortals can implement successfully. Commit to a deliverable or a deadline, but never both.
- xvilka 5y ago
  I would say an approach closer to the Heisenberg uncertainty principle would make more sense. The more information specified that can't be changed about the expected product the less information is available about the deadline, ans vice versa. Thus, the desired balance could be used depending on the situation, goals, budget, etc.
  - eitland 5y ago
    That was briliant and is already added to my quotes list. Should I attribute it to xvilka or did you get it from somewhere else?
    - xvilka 5y ago
      I think, it's my own idea but you never can be 100% sure, some kind of uncertainty always persist.
      - deleted 5y ago
        [deleted]
- jcims 5y ago
  “Ok awesome! Glad to hear you’ve committed to deliver widget, when do you think it will be done? We have four business units that were going to use wedgie but that’s getting decommed next year and they’d much rather avoid a pivot. Oh and change restrictions start in six weeks, don’t forget that. BTW what’s your team’s vacation schedule looking like? We only get to roll over 7 days this year, hopefully they took some this summer haha! Ok so anyway really would like some estimate that i can take back to product, you thinking January? Maybe get something up in test that they can kick around in what, a month?” Etc etc.
rramadass 5y ago
>One of the primary jobs of managers at all levels is to plan and then execute in accordance with the plan "Plans" can never be set in stone. They evolve based on the people involved and circumstances. A Manager's job is to understand his people and then Plan accordingly; not the other way around. >If all you can do is complain This is exactly the wrong way to frame the discussion. Pointing out that you are clueless is not complaining but raising issues which if unaddressed, will most probably result in failure of what is attempted.
- rStar 5y ago
  >If all you can do is complain This is exactly the wrong way to frame the discussion. Pointing out that you are clueless is not complaining but raising issues which if unadd he’s pointing out that you are clueless ramadass
  - rStar 5y ago
    i would say, everyone acts in their interests, at all times, except for individual actors who may value things like the city the work in or loyalty in themselves that may artificially tie them to a situation. i say, if you identify a problem with your organization that you can’t get over, be a grown up, and find another job. seriously, it’s the best thing you can do for yourself. if you feel an organization is rotten, leave. you will never ever fix the rot. if you’ve got bad hr you’ve unfortunately got bad hr, and that’s not your fault, but that also will never, ever, change.
- alfiedotwtf 5y ago
  > "Plans" can never be set in stone Setting plans in stone was the entire Waterfall Methodology where contracts had requirements and milestones locked in and any deviation meant heavy penalties.
  - flawedbydesign 5y ago
    The first formal detailed diagram of the process later known as the "waterfall model" is often cited as a 1970 article by Winston W. Royce. However he also felt it had major flaws stemming from the fact that testing only happened at the end of the process, which he described as being "risky and invites failure". The rest of his paper introduced five steps which he felt were necessary to "eliminate most of the development risks" associated with the unaltered waterfall approach. Royce's five additional steps (which included writing complete documentation at various stages of development) never took mainstream hold, but his diagram of what he considered a flawed process became the starting point when describing a "waterfall" approach. https://en.wikipedia.org/wiki/Waterfall_model#History https://en.wikipedia.org/wiki/Waterfall_model#History
aidenn0 5y ago
> So show me a methodology that mere mortals can implement successfully. If all you can do is complain and point out unicorn 500x engineers (yeah try hiring for that characteristic, good luck), then I don’t want to hear it. But if you have a practical idea on how to “solve” planning, then you have my full attention. TFA doesn't suggest hiring 500x engineers, it suggests taking steps to retain highly effective engineers (and highly effective teams) by not ignoring the evidence that they are not fungible.
- mjmahone17 5y ago
  A point the article also alludes to: often people are only “unicorns” due to the specific context they’re working on. Move them to a different project, and your high value person may be a net negative. And it’s not possible for people who aren’t familiar with a person’s work to anticipate how making that person switch projects will affect the quality or quantity of their output.
downWidOutaFite 5y ago
I'm really confused what this comment has to do with the article (not about planning) and why it's the top comment on HN.
lmm 5y ago
Leaders may need to know some specific dates for some specific purposes. Responding to that need by demanding your methodology deliver a schedule for everything in case you need it is lazy and wasteful. If your engineers are part of the same team, working on the same business goals, they'll be glad to contribute what you need to the decision about whether to announce at conference Y, and may even be able to suggest relevant aspects you haven't thought of.
mobjack 5y ago
A lot of my planning is making sure the most effective engineers are working on the most important things. It is about making sure resources are most efficiently allocated to meet the business objectives.
- noduerme 5y ago
  I'd imagine the corollary to this is assigning each of them the task you think they're most suited to. I think that's what used to be called "management".
deleted 5y ago
[deleted]
watwut 5y ago
> One of the primary jobs of managers at all levels is to plan and then execute in accordance with the plan. Yep, just as I thought. This is why those teams hated plans - because once there is plan they will be beaten and abused to make it, despite the plan being unrealistic from the start. > Every team I have ever worked with hates planning; every team hates their methodology and thinks it’s stupid and inaccurate and why are those pinhead business people insisting on a date; it’ll be done when it’s done. In that case, teams in which you worked had stupid methodology about planning. It sounds like your plans did not accounted for uncertainty at all. They did not accounted for what if we are not making it, which features will be cut. > Some managers are good at it, many aren’t- the world is populated with people nearer the center than the ends of the bell curve. And many of them are abusive or exploitative about it and there is nothing in business organization to prevent or at least acknowledge that.
deleted 5y ago
[deleted]
deleted 5y ago
[deleted]
atoav 5y ago
I can't really speak about managment here, but when I organize projects the three most important things are: 1. Create the room for every member of the team to comfortably do their job (what this means depends on the persons needs and at the work environment, communication structure, tools you provide them). Room not only means physical room, but also time, frame of mind etc. If everybody has 10 other daily things on their list they won't have the (mental) room to work on the project. 2. Communicate clearly why you think this is a workable plan and ask for feedback whether this is realistic. Communicate what happens if you are faster, what happens if you are slower. They are helping you, you are helping them, ideally both sides take away something from the project beyond purely finishing it. 3. Adapt, Improvise, Overcome. The primary goal should always be to finish the project in a good way, especially if the deadline is not a hard deadline, but one arbitrarily set by someone else. Defend the team, create the room for them. Don't let them slack around too much. A bit of slacking around is not too much, but precisely the right amount – this is the space needed if something goes terribly wrong.
dharmab 5y ago
A technique I read once (and lost the link) was to track both the estimated time metrics and the error in estimation for every engineer. Over time you could build reasonable error bars around every engineer's estimations, and then sum the estimates _with the confidence intervals_ together and figure out the probability of achieving a certain ship date.
- DocTomoe 5y ago
  That's what Fog Creek Software's FogBugz tried to do. I liked it a lot, it also allowed for some team structure planning (e.g. giving you a chance to see if your team consists of pessimistic estimaters or positive ones, and mix accordingly). Unfortunately, their marketshare got gobbled up by Jira.
  - noduerme 5y ago
    I feel like pessimistic estimators are way more accurate and probably more intelligent than optimistic ones. I'd probably use software like that to fire half the team. (edit: of course then I'd have to fire half the team again... and again... until only one or two incredibly depressed pessimists remained... tough call)
    - Jensson 5y ago
      Why would you fire the team? The software shows you how their estimates relates to real world timelines, just adjust their estimate accordingly and the problem is fixed. I never understood why managers get so upset over consistent time under estimates, just track it and add the relevant factor without telling the team and it should on average be on point.
      - noduerme 5y ago
        I was sort of just reducing the idea to absurdity. I only work in small teams - everything I do is by feel. It's easy to tell if things are behind or not. Easy to tell if someone is wasting time, or if they're stuck on a problem, and extrapolate a new ETA. Honestly, the idea of trying to feed that into software seems heartless and inevitably wrong, but if I were going to do it, I'd opt for the pessimistic analysis.
vishnugupta 5y ago
I'm speaking as someone who has handled a fair share of timelines (with reasonable success) you have pointed out. To begin with, it is interesting to see you lumping up different kinds of timelines. For example, the cost of not meeting SEC timeline different one compared to demo to be shown in a press conference. > should we spend $50k announcing at conference Y in month Z, or should we wait until month A? What is it that you want to announce? Product launch perhaps? Then let's work with the product folks to design it and then take it to engineers to figure out work estimate. Give them time to estimate; if the timelines don't match then reduce the scope. > Our competition just launched; will we be able to launch this quarter Sure, they launched this quarter. Do you know how long have they been working on it? If not then it's a similar exercise as above. > we have to report material financial impact items quarterly or face SEC fines Why are you telling me this? SEC doesn't ask for such reports overnight. You messed up by not telling us so fine it is. OR there is some human at the SEC with whom you negotiate. > So show me a methodology that mere mortals can implement successfully. If there were such a methodology we wouldn't be having this discussion to begin with. It would have been commoditised, similar to a car manufacturing assembly line. What business people don't understand (or internalise) is software is a truly a new beast. It is a tool that can be applied in just about every domain. No such tool has existed ever in human history. If you want to disrupt a domain then you either develop expertise in it or hire them from the industry. > If all you can do is complain and point out unicorn 500x engineers (yeah try hiring for that characteristic, good luck), then I don’t want to hear it. In some cases that is indeed the reality. If you don't even want to acknowledge the reality then good luck hiring good people. If you say point out how Apple launches products like clockwork then I'll point out how they have had close to 50 years worth of experience and all the associated optimisations they have done with their supply chain and what not. Reality is, whether you acknowledge or not, is full of detail[1]. It can't be bent to your convenience, unfortunately. [1] http://johnsalvatier.org/blog/2017/reality-has-a-surprising-amount-of-detail http://johnsalvatier.org/blog/2017/reality-has-a-surprising-...
- m_eiman 5y ago
  > What business people don't understand (or internalise) is software is a truly a new beast. It is a tool that can be applied in just about every domain. No such tool has existed ever in human history. That's not quite true: the inventions of mathematics, writing and especially affordable material to write on were probably even larger culture shifts, but software and computers are of the same magnitude - perhaps it's easier to realize the shift needed in corporate culture when you compare it to those earlier changes.
jiggawatts 5y ago
I just went through this, like... today. "Tell me what date task X will occur on." -- where task 'X' takes 5 minutes, but has a long list of pre-requisites that take 1-4 weeks each, sequentially, of which 100% our out of our control. ... That's not planning, that's fortune-telling. You may as well ask an Ouija board. Planning is making sure the the pre-requisites happen before you attempt to start the things that depend on them. It is making sure that everyone is unblocked. It is making sure that nobody is wasting time going down a dead end. It is making sure that everyone is rowing in the same direction. What I see from PMs is that they just want facts from the future, instead of solving problems in the here and now. Until today, weeks into the project, I could not access the system that I needed. This was the key pre-requisite for 4x FTEs progressing on their own tasks. The only thing the PM did is repeatedly ask me if he needed to move the date for the completion ETA. I solved the problem. He did nothing to expedite progress. Does it really matter which specific date this occurred on? No. It just had to happen as soon as possible. The trick is to make it possible, not to try to pin down exactly when "soon" will occur by repeatedly asking the same question in every daily stand up. Why do we pay these people, again? Remind me?
- biztos 5y ago
  That was the glory of the good ole Gannt Chart in what I might call Microsoft Project Based Project Management. If you set your dependencies right, the dates would just slip by themselves, and it was easy to tell the bosses what slipped. Required a lot of printing and taping every week, and caused a ton of headache whenever people lied about their progress, and didn’t really work without a FTE project manager, but I have yet to see a supposedly better system actually work better on big projects.
- notpachet 5y ago
  Like the parent poster said, people are on a bell curve. It sounds like you may only have been exposed to mediocre, passable, or plain bad PM's so far in your career. So I'll remind you: the reason we pay PM's is because good PM's can, and do, exist. I've only worked with a few great PM's, but they outshone their competition with just as much brilliance as the 10x among us engineers outshine the 1x. It's ironic that you would reduce PM's to a single heterogeneous caricature in reply to an article that is essentially saying that it's harmful to do so.
solatic 5y ago
> So show me a methodology that mere mortals can implement successfully. There's an impedance between "Bob can do task of type A really quickly" and "we need to make sure that people other than Bob can do the task or else we have bus factor = 1 and this poses systemic risk". Clearly these goals are not really in conflict. In general, assign the work to Bob, but understand the effect on timeline in case Bob is unavailable. How long would it take if Bob isn't available? Is it worth the inefficiency from cross-training Mike? Is Mike even interested? Modern militaries are not majority staffed by combat soldiers. Less than 10%. The rest are support of one kind or another. Smart engineering leadership in large companies, if they care about shipping on-time, eventually realize that roles like PMs are less effective if they understand themselves to be bosses and more effective if they understand themselves to be support staff.

by efitz 5y ago

vbezhenar 5y ago

Stop using methodologies actively preventing any kind of planning (mostly agile stuff). Return to waterfall, write lots of documentations, spend time planning architecture, resist urges to rewrite non-ideal solutions. Do not allow changes. It'll take more time and result will not be as clean. Basically learn from older engineering disciplines.

sergio 5y ago
Also, build several prototypes of every important part of the product in order to learn how long they will take to be made and how each variant will perform, so when you make estimations they are as effective as possible; and then, make integration tests on the selected variants so you can reduce estimation risks due to integration. Just as in every other engineering discipline.
RNCTX 5y ago
The two replies below yours at the moment capture what you're trying to say... > This mentality of thinking is exactly the problem, I think. You want a tool that can solve an entire class of problems. We are telling you that no such tool can exist to do what you want, the problem and the tools don't work that way. Each project should be planned as a snowflake. > This is exactly right and is the biggest problem with "Management" types. They want a "cookie cutter methodology" to solve all their problems so they can be spared thinking through each one. Hence the various "Management" fads and buzzwords. Which is another way to say... if there was a system to do their thing, they wouldn't have to pay smarter people a lot of money to do it. Reliance on a system (any system) tells you that the people don't value your expertise, but rather see you as a cost to be minimized.

fractalb 5y ago

You can just give a random guess on the timelines and save the developers time.

thegrimmest 5y ago

> But if you have a practical idea on how to “solve” planning Seems pretty straightforward to me - just don't use dates in your plans. That means don't announce features which aren't complete. Don't plan marketing campaigns for unlaunched products. Embrace "Now, "Next" and "Later" as headings on your roadmap. There are many successful companies that operate like this, Nintendo being a famous example. It doesn't seem to hurt their bottom line - quite the contrary. The usual issue that folks have with planning is that business leaders are simply not willing to spend the resources to do it accurately enough to answer the questions they're asking. Think how much time it would take to break 6 months of work for several teams into detailed stories and estimate each one. It therefore seems they're basically wasting everyone's time, since dartboards and magic-8-balls are just as good as engineering estimates without details.

Afforess 5y ago

This mentality of thinking is exactly the problem, I think. You want a tool that can solve an entire class of problems. We are telling you that no such tool can exist to do what you want, the problem and the tools don't work that way. Each project should be planned as a snowflake. Each project is different. Each team is unique. Every individual performs differently, even one day to the next. Stop looking for this tool to make these plans. It can't exist. Do the hard thing and plan projects individually.

rramadass 5y ago
>This mentality of thinking is exactly the problem Damn right! >We are telling you that no such tool can exist to do what you want This is exactly right and is the biggest problem with "Management" types. They want a "cookie cutter methodology" to solve all their problems so they can be spared thinking through each one. Hence the various "Management" fads and buzzwords. The core of the solution lies with the Individual; understand their needs, wants, motivations, practice "Empathetic Management" and you will be successful.

aahortwwy 5y ago

> So show me a methodology that mere mortals can implement successfully. Commit to a deliverable or a deadline, but never both.

xvilka 5y ago
I would say an approach closer to the Heisenberg uncertainty principle would make more sense. The more information specified that can't be changed about the expected product the less information is available about the deadline, ans vice versa. Thus, the desired balance could be used depending on the situation, goals, budget, etc.
- eitland 5y ago
  That was briliant and is already added to my quotes list. Should I attribute it to xvilka or did you get it from somewhere else?
  - xvilka 5y ago
    I think, it's my own idea but you never can be 100% sure, some kind of uncertainty always persist.
    - deleted 5y ago
      [deleted]
jcims 5y ago
“Ok awesome! Glad to hear you’ve committed to deliver widget, when do you think it will be done? We have four business units that were going to use wedgie but that’s getting decommed next year and they’d much rather avoid a pivot. Oh and change restrictions start in six weeks, don’t forget that. BTW what’s your team’s vacation schedule looking like? We only get to roll over 7 days this year, hopefully they took some this summer haha! Ok so anyway really would like some estimate that i can take back to product, you thinking January? Maybe get something up in test that they can kick around in what, a month?” Etc etc.

rramadass 5y ago

>One of the primary jobs of managers at all levels is to plan and then execute in accordance with the plan "Plans" can never be set in stone. They evolve based on the people involved and circumstances. A Manager's job is to understand his people and then Plan accordingly; not the other way around. >If all you can do is complain This is exactly the wrong way to frame the discussion. Pointing out that you are clueless is not complaining but raising issues which if unaddressed, will most probably result in failure of what is attempted.

rStar 5y ago
>If all you can do is complain This is exactly the wrong way to frame the discussion. Pointing out that you are clueless is not complaining but raising issues which if unadd he’s pointing out that you are clueless ramadass
- rStar 5y ago
  i would say, everyone acts in their interests, at all times, except for individual actors who may value things like the city the work in or loyalty in themselves that may artificially tie them to a situation. i say, if you identify a problem with your organization that you can’t get over, be a grown up, and find another job. seriously, it’s the best thing you can do for yourself. if you feel an organization is rotten, leave. you will never ever fix the rot. if you’ve got bad hr you’ve unfortunately got bad hr, and that’s not your fault, but that also will never, ever, change.
alfiedotwtf 5y ago
> "Plans" can never be set in stone Setting plans in stone was the entire Waterfall Methodology where contracts had requirements and milestones locked in and any deviation meant heavy penalties.
- flawedbydesign 5y ago
  The first formal detailed diagram of the process later known as the "waterfall model" is often cited as a 1970 article by Winston W. Royce. However he also felt it had major flaws stemming from the fact that testing only happened at the end of the process, which he described as being "risky and invites failure". The rest of his paper introduced five steps which he felt were necessary to "eliminate most of the development risks" associated with the unaltered waterfall approach. Royce's five additional steps (which included writing complete documentation at various stages of development) never took mainstream hold, but his diagram of what he considered a flawed process became the starting point when describing a "waterfall" approach. https://en.wikipedia.org/wiki/Waterfall_model#History https://en.wikipedia.org/wiki/Waterfall_model#History

aidenn0 5y ago

> So show me a methodology that mere mortals can implement successfully. If all you can do is complain and point out unicorn 500x engineers (yeah try hiring for that characteristic, good luck), then I don’t want to hear it. But if you have a practical idea on how to “solve” planning, then you have my full attention. TFA doesn't suggest hiring 500x engineers, it suggests taking steps to retain highly effective engineers (and highly effective teams) by not ignoring the evidence that they are not fungible.

mjmahone17 5y ago
A point the article also alludes to: often people are only “unicorns” due to the specific context they’re working on. Move them to a different project, and your high value person may be a net negative. And it’s not possible for people who aren’t familiar with a person’s work to anticipate how making that person switch projects will affect the quality or quantity of their output.

downWidOutaFite 5y ago

I'm really confused what this comment has to do with the article (not about planning) and why it's the top comment on HN.

lmm 5y ago

Leaders may need to know some specific dates for some specific purposes. Responding to that need by demanding your methodology deliver a schedule for everything in case you need it is lazy and wasteful. If your engineers are part of the same team, working on the same business goals, they'll be glad to contribute what you need to the decision about whether to announce at conference Y, and may even be able to suggest relevant aspects you haven't thought of.

mobjack 5y ago

A lot of my planning is making sure the most effective engineers are working on the most important things. It is about making sure resources are most efficiently allocated to meet the business objectives.

noduerme 5y ago
I'd imagine the corollary to this is assigning each of them the task you think they're most suited to. I think that's what used to be called "management".

deleted 5y ago

[deleted]

watwut 5y ago

> One of the primary jobs of managers at all levels is to plan and then execute in accordance with the plan. Yep, just as I thought. This is why those teams hated plans - because once there is plan they will be beaten and abused to make it, despite the plan being unrealistic from the start. > Every team I have ever worked with hates planning; every team hates their methodology and thinks it’s stupid and inaccurate and why are those pinhead business people insisting on a date; it’ll be done when it’s done. In that case, teams in which you worked had stupid methodology about planning. It sounds like your plans did not accounted for uncertainty at all. They did not accounted for what if we are not making it, which features will be cut. > Some managers are good at it, many aren’t- the world is populated with people nearer the center than the ends of the bell curve. And many of them are abusive or exploitative about it and there is nothing in business organization to prevent or at least acknowledge that.

deleted 5y ago

[deleted]

deleted 5y ago

[deleted]

atoav 5y ago

I can't really speak about managment here, but when I organize projects the three most important things are: 1. Create the room for every member of the team to comfortably do their job (what this means depends on the persons needs and at the work environment, communication structure, tools you provide them). Room not only means physical room, but also time, frame of mind etc. If everybody has 10 other daily things on their list they won't have the (mental) room to work on the project. 2. Communicate clearly why you think this is a workable plan and ask for feedback whether this is realistic. Communicate what happens if you are faster, what happens if you are slower. They are helping you, you are helping them, ideally both sides take away something from the project beyond purely finishing it. 3. Adapt, Improvise, Overcome. The primary goal should always be to finish the project in a good way, especially if the deadline is not a hard deadline, but one arbitrarily set by someone else. Defend the team, create the room for them. Don't let them slack around too much. A bit of slacking around is not too much, but precisely the right amount – this is the space needed if something goes terribly wrong.

dharmab 5y ago

A technique I read once (and lost the link) was to track both the estimated time metrics and the error in estimation for every engineer. Over time you could build reasonable error bars around every engineer's estimations, and then sum the estimates _with the confidence intervals_ together and figure out the probability of achieving a certain ship date.

DocTomoe 5y ago
That's what Fog Creek Software's FogBugz tried to do. I liked it a lot, it also allowed for some team structure planning (e.g. giving you a chance to see if your team consists of pessimistic estimaters or positive ones, and mix accordingly). Unfortunately, their marketshare got gobbled up by Jira.
- noduerme 5y ago
  I feel like pessimistic estimators are way more accurate and probably more intelligent than optimistic ones. I'd probably use software like that to fire half the team. (edit: of course then I'd have to fire half the team again... and again... until only one or two incredibly depressed pessimists remained... tough call)
  - Jensson 5y ago
    Why would you fire the team? The software shows you how their estimates relates to real world timelines, just adjust their estimate accordingly and the problem is fixed. I never understood why managers get so upset over consistent time under estimates, just track it and add the relevant factor without telling the team and it should on average be on point.
    - noduerme 5y ago
      I was sort of just reducing the idea to absurdity. I only work in small teams - everything I do is by feel. It's easy to tell if things are behind or not. Easy to tell if someone is wasting time, or if they're stuck on a problem, and extrapolate a new ETA. Honestly, the idea of trying to feed that into software seems heartless and inevitably wrong, but if I were going to do it, I'd opt for the pessimistic analysis.

vishnugupta 5y ago

I'm speaking as someone who has handled a fair share of timelines (with reasonable success) you have pointed out. To begin with, it is interesting to see you lumping up different kinds of timelines. For example, the cost of not meeting SEC timeline different one compared to demo to be shown in a press conference. > should we spend $50k announcing at conference Y in month Z, or should we wait until month A? What is it that you want to announce? Product launch perhaps? Then let's work with the product folks to design it and then take it to engineers to figure out work estimate. Give them time to estimate; if the timelines don't match then reduce the scope. > Our competition just launched; will we be able to launch this quarter Sure, they launched this quarter. Do you know how long have they been working on it? If not then it's a similar exercise as above. > we have to report material financial impact items quarterly or face SEC fines Why are you telling me this? SEC doesn't ask for such reports overnight. You messed up by not telling us so fine it is. OR there is some human at the SEC with whom you negotiate. > So show me a methodology that mere mortals can implement successfully. If there were such a methodology we wouldn't be having this discussion to begin with. It would have been commoditised, similar to a car manufacturing assembly line. What business people don't understand (or internalise) is software is a truly a new beast. It is a tool that can be applied in just about every domain. No such tool has existed ever in human history. If you want to disrupt a domain then you either develop expertise in it or hire them from the industry. > If all you can do is complain and point out unicorn 500x engineers (yeah try hiring for that characteristic, good luck), then I don’t want to hear it. In some cases that is indeed the reality. If you don't even want to acknowledge the reality then good luck hiring good people. If you say point out how Apple launches products like clockwork then I'll point out how they have had close to 50 years worth of experience and all the associated optimisations they have done with their supply chain and what not. Reality is, whether you acknowledge or not, is full of detail[1]. It can't be bent to your convenience, unfortunately. [1] http://johnsalvatier.org/blog/2017/reality-has-a-surprising-amount-of-detail http://johnsalvatier.org/blog/2017/reality-has-a-surprising-...

m_eiman 5y ago
> What business people don't understand (or internalise) is software is a truly a new beast. It is a tool that can be applied in just about every domain. No such tool has existed ever in human history. That's not quite true: the inventions of mathematics, writing and especially affordable material to write on were probably even larger culture shifts, but software and computers are of the same magnitude - perhaps it's easier to realize the shift needed in corporate culture when you compare it to those earlier changes.

jiggawatts 5y ago

I just went through this, like... today. "Tell me what date task X will occur on." -- where task 'X' takes 5 minutes, but has a long list of pre-requisites that take 1-4 weeks each, sequentially, of which 100% our out of our control. ... That's not planning, that's fortune-telling. You may as well ask an Ouija board. Planning is making sure the the pre-requisites happen before you attempt to start the things that depend on them. It is making sure that everyone is unblocked. It is making sure that nobody is wasting time going down a dead end. It is making sure that everyone is rowing in the same direction. What I see from PMs is that they just want facts from the future, instead of solving problems in the here and now. Until today, weeks into the project, I could not access the system that I needed. This was the key pre-requisite for 4x FTEs progressing on their own tasks. The only thing the PM did is repeatedly ask me if he needed to move the date for the completion ETA. I solved the problem. He did nothing to expedite progress. Does it really matter which specific date this occurred on? No. It just had to happen as soon as possible. The trick is to make it possible, not to try to pin down exactly when "soon" will occur by repeatedly asking the same question in every daily stand up. Why do we pay these people, again? Remind me?

biztos 5y ago
That was the glory of the good ole Gannt Chart in what I might call Microsoft Project Based Project Management. If you set your dependencies right, the dates would just slip by themselves, and it was easy to tell the bosses what slipped. Required a lot of printing and taping every week, and caused a ton of headache whenever people lied about their progress, and didn’t really work without a FTE project manager, but I have yet to see a supposedly better system actually work better on big projects.
notpachet 5y ago
Like the parent poster said, people are on a bell curve. It sounds like you may only have been exposed to mediocre, passable, or plain bad PM's so far in your career. So I'll remind you: the reason we pay PM's is because good PM's can, and do, exist. I've only worked with a few great PM's, but they outshone their competition with just as much brilliance as the 10x among us engineers outshine the 1x. It's ironic that you would reduce PM's to a single heterogeneous caricature in reply to an article that is essentially saying that it's harmful to do so.

solatic 5y ago

> So show me a methodology that mere mortals can implement successfully. There's an impedance between "Bob can do task of type A really quickly" and "we need to make sure that people other than Bob can do the task or else we have bus factor = 1 and this poses systemic risk". Clearly these goals are not really in conflict. In general, assign the work to Bob, but understand the effect on timeline in case Bob is unavailable. How long would it take if Bob isn't available? Is it worth the inefficiency from cross-training Mike? Is Mike even interested? Modern militaries are not majority staffed by combat soldiers. Less than 10%. The rest are support of one kind or another. Smart engineering leadership in large companies, if they care about shipping on-time, eventually realize that roles like PMs are less effective if they understand themselves to be bosses and more effective if they understand themselves to be support staff.