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.
"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?
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.
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.
"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.
Setting plans in stone was the entire Waterfall Methodology where contracts had requirements and milestones locked in and any deviation meant heavy penalties.
This has been so endlessly repeated without thought that people assume it is a fact when the Truth is far from it.
Excerpts from wikipedia - https://en.wikipedia.org/wiki/Waterfall_model ;
* In 1983 the paper was republished with a foreword by Benington explaining that the phases were on purpose organised according to the specialisation of tasks, and pointing out that the process was not in fact performed in a strict top-down fashion, but depended on a prototype.
* 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.
* In 1985, the United States Department of Defense captured this approach in DOD-STD-2167A[citation needed], their standards for working with software development contractors, which stated that "the contractor shall implement a software development cycle that includes the following six phases: Software Requirement Analysis, Preliminary Design, Detailed Design, Coding and Unit Testing, Integration, and Testing.
The "Waterfall" is what is imagined as a "Ideal and Rational" process (see D.L.Parnas' paper A Rational Design Process: How and Why to Fake it for motivation - https://ieeexplore.ieee.org/document/6312940). The stages in the model and the issues to be considered in each stage are what is important NOT their order. In practice it was always a iterative spiral model described by Barry Boehm - https://en.wikipedia.org/wiki/Spiral_model
FYI, D.L.Parnas and Barry Boehm defined the field of Software Engineering. Almost all Govt./DoD standards are based on their research and writings.
https://en.wikipedia.org/wiki/Waterfall_model#Modified_water...
Interesting because that's definitely not what's taught in the handful of Software Engineering books I've read, and steps backward are not canon (rather, they're called something besides Waterfall i.e Spiral or Iterative).
Looking at that page again, it looks like what I describe is called "pure waterfall".
Instead of getting lost in the comments, You should post it to HN and invite discussions with a title like "Most of what you have heard about the Waterfall Development Model is Wrong!" or "How the Agile folks have misled you about the Waterfall Development Model" :-)
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.
"Waterfall" specifies the What while "Spiral and Iterative" specify the How.
Do the hard thing and plan projects individually.
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.
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.
Commit to a deliverable or a deadline, but never both.
Should I attribute it to xvilka or did you get it from somewhere else?
So we committed to a deadline, but not a single deliverable. Scope would shrink and grow as delivery of each component progressed. Well in advance, for each major sporting event in each country where we operated, we would scope out literally every single thing we'd like to deliver, and then start work on the components in priority order. In each planning session as the event approaches we'd appraise whether we still have time to realistically deliver the next priority thing, and if not we'd skip it and move to the next - those that got missed out could wait until the following year (when the major features already delivered would need to evolve, not be implemented from scratch).
I learnt a lot from working on sports. Having third party deadlines that no-one could bitch about made us an extremely effective team at planning, estimating, and ruthless scope reduction.
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.
It's remarkably powerful.
It'll take more time and result will not be as clean.
Basically learn from older engineering disciplines.
> 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.
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.
To do this you need to communicate very clearly why are you doing it, and if it will have any influence on performance reviews. But I do think that monitoring estimates in this way will affect the quality of estimates.
A manager in my previous company noted everyone's estimations during sprint planning in an Excel sheet. No-one knew why, so I found myself thinking more about that Excel sheet than about making an well-founded estimation.
(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)
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.
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.
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.
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.
It is about making sure resources are most efficiently allocated to meet the business objectives.
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-...
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.
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.