2 ms·

I think we agree. My point would be that any framework which calls for or normalizes imposter roles is going to stifle productive output. The Agile manifesto

I think we agree. My point would be that any framework which calls for or normalizes imposter roles is going to stifle productive output. The Agile manifesto clearly does that. https://agilemanifesto.org/principles.html https://agilemanifesto.org/principles.html > Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. This basically normalizes product managers being incompetent. Anyone can jerk the engineers around and be reactive. It takes expertise to not waste resources on the wrong thing. > Business people and developers must work together daily throughout the project. We know this is bad for engineering output empirically. You need to leave people alone to get work done. But giving the "business people" something to do legitimizes their imposter roles. Better check in on the engineers every day. > The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Imposters are adept at feigning value creation in meetings. Ask for details in writing: no shot. In a meeting, where they can nod along with people who actually know what they are doing, is where imposters really shine. Also another work activity to legitimize the imposter role.

AnimalMuppet 2y ago
Well, you know, engineers are famous for "can't code their way out of a wet paper bag" even though they sounded great in an interview. That's what FizzBuzz is for - to find out quickly if candidates can code at all. So it's not like imposters are only in non-technical roles. > > Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. > This basically normalizes product managers being incompetent. No, it normalizes product managers doing their jobs. If external circumstances change, do you want to keep building the wrong thing, or do you want to respond? Agile is all about responding when things change. But you need a product manager who is competent to do the right changes, and only those, rather than changing with every morning headline. But if you're not doing agile, you still have the same problem. If your product manager isn't competent to steer the delivery as circumstances change, how are they competent to get the requirements correct enough that they won't need to change for a year-long project? Answer: They aren't. (But agile may make their incompetence more frustrating day-to-day to the engineers, instead of letting them enjoy the sense of accomplishment of happily building something to completion, even though it's the wrong something.)

AnimalMuppet 2y ago

Well, you know, engineers are famous for "can't code their way out of a wet paper bag" even though they sounded great in an interview. That's what FizzBuzz is for - to find out quickly if candidates can code at all. So it's not like imposters are only in non-technical roles. > > Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. > This basically normalizes product managers being incompetent. No, it normalizes product managers doing their jobs. If external circumstances change, do you want to keep building the wrong thing, or do you want to respond? Agile is all about responding when things change. But you need a product manager who is competent to do the right changes, and only those, rather than changing with every morning headline. But if you're not doing agile, you still have the same problem. If your product manager isn't competent to steer the delivery as circumstances change, how are they competent to get the requirements correct enough that they won't need to change for a year-long project? Answer: They aren't. (But agile may make their incompetence more frustrating day-to-day to the engineers, instead of letting them enjoy the sense of accomplishment of happily building something to completion, even though it's the wrong something.)