6 ms·

This a million times! I’ve been in the position of the “innovation hero” but also was unfortunate enough to work on “innovation pipeline” implementations within

by Jun8 2y ago

This a million times! I’ve been in the position of the “innovation hero” but also was unfortunate enough to work on “innovation pipeline” implementations within a large company. These never work because: 1. (99% of) employees don’t care. They have their own job to do and working on other things is an eyebrow raise from their manager (see 3). And what’s the e benefit? Mostly it’s a pat on the back or some “points” in the company award system that you can use to buy shitty merch at the end of the year. 2. Executive leadership doesn’t care because for the most part they don’t trust their own tech team to innovate. Why take the risk when you can buy a startup which comes with a bona fide certificate of innovation. 3. But the real problem (as commonly identified) is middle mgmt, who not only don’t care but are generally hostile to nonstandard work. The reasons for this are complex, partly it’s the aging manager suffering from Peter Principle, partly it’s the fear of negative pushback from senior leadership. PS: Steve is amazed, but 10 months for the sort of setup he describes which includes HW buy and setup, in a Big Corp is very fast.

cogman10 2y ago
This all, imo, is simply a trust problem primarily from leadership. Leadership does not trust the grunts to do productive work. So in order to make sure productive work is done, they build elaborate systems of cases, reviews, meetings, planning, scheduling, fighting, readjusting when the schedules are invariably missed, and finger pointing. All almost always completely devoid of input from the grunts. The middle management problem is they are right in the worst place possible. They are removed from the actual work being done so they don't know what it actually takes to do anything and they are blamed for things not accomplished. Further, they are rewarded for every little stupid thing done. It hyperintensities them to do lots of small safe initiatives and vehemently oppose anything with any sort of risk. All while being almost completely disconnected from what actually needs to be done. This all leads to a culture meant to squash innovation. Middle management isn't rewarded for implementing a grunt's idea, they are rewarded for delivering CEO initiatives. Anything that takes time away from that is seen as waste.
- foobarian 2y ago
  > Leadership does not trust the grunts to do productive work Not only that, but unfortunately they are usually right. Without oversight the in-house team has high likelihood of building NIH spaghetti, which causes more problems down the line. To avoid the negative outcome leadership needs to be technically competent and resourced, and that's the other side of the coin - usually they don't have the expertise so in a way they also do not trust themselves to lead the project to a positive outcome.
  - danaris 2y ago
    > Without oversight the in-house team has high likelihood of building NIH spaghetti I think when you see this you need to start digging deeper and questioning why this is happening. Is it because the "grunts" are genuinely bad at their jobs? If this is the case, then who hired them? Or is it because they have been conditioned to believe that if they ask for permission to use an outside tool/library/etc, they will be told "no, we don't have the budget for that" or "that has to go through 12 layers of approval" or "great idea! we'll get it into a committee to talk about the best way to implement it and get back to you (in 6-12 months)"? In other words: Are they building NIH spaghetti not because they lack oversight, but because they have too much, that hampers them from actually doing their damn jobs?
    - cruffle_duffle 2y ago
      Don’t forget incentive structures that award developers for “org wide impact”. Often the way to do that is to roll your own crap instead of use off the shelf stuff. This is how you wind up with developers creating their own key-value databases or billing systems… it sounds much better to write these from scratch.
    - Terr_ 2y ago
      I'd like to add that NIH spaghetti sometimes comes from customer relationships rather than from exuberant developers. The important customer wants just one tiny convenience-feature that fits their use case and it sorta makes sense... Which somehow keeps scope-creeping over time into a cancerous unplanned product which is expensive to support. With the benefit of hindsight, you realize it's something the customer should have bought directly for themselves from a completely separate and more-qualified vendor. However they either didn't realize what they wanted or they were able to trick you into building an over-specialized product for their use case--for much cheaper than if they had hired a contractor to customize another better offering.
jmull 2y ago
Mostly agree, but this > aging manager suffering from Peter Principle, partly it’s the fear of negative pushback from senior leadership is not typically the reason, in my experience. I've seen a lack of full comprehension on the part of the team pushing the innovation as to the actual benefit and cost of the innovation to all the affected teams. And as a result, the lack of a plan to address those issues... I've seen a lot of incomplete innovations, where the benefit is real and useful, but the plan leaves various concerns of different teams unaddressed -- no doubt due to the innovation team being unaware. Strangely, the innovation team often wants to push forward anyway, which is not good since the plan is basically unworkable with critical issues unresolved (I can tell they kind of think the issues aren't critical but only because they don't understand them -- leading with ignorance when the processes and products actually have to work at the end is always doomed to fail.) The most common way plans are incomplete that I've seen is when they don't account for the schedule. The plan will take X time away from other work to implement, but the schedule for delivery of that other work isn't moved back X, nor are there other compensating measures. That's an unworkable plan, and any half-decent manager will push back on it. (Schedule impact is usually a tough one... at least at larger places, in my experience, the high-level delivery schedule is negotiated at a high level, and it hard to change for political reasons. That means time for any innovation plans has to be included from the start. Yet slack in any schedule tends to get gobbled up at the team level or below, addressing their concerns -- who doesn't have tons of technical debt they are dying to resolve? There's a way to handle this, but it has to be planned for and done at a high level, and done correctly. The fruits of any innovation team that doesn't have this are gong to be minimal.)
specialist 2y ago
Yes and: As legendary methodologist Alistair Cockburn teaches us: People hate change. They really, really hate change. (paraphrasing) > not only don’t care but are generally hostile to nonstandard work Most persons have an immunological-like response to any and all change. Our minds (personalities?) strive to maintain an equilibrium at all costs. Even when the status quo sucks. Even when we intellectually commit to changing. We keep getting pulled back into the rut, foiling our own best intentions. This trait makes change very, very hard (for most people). Now multiply that by 10, 100, or 1000 persons. Organizational (cultural) change is that much harder. Noob me was belligerently intolerant of apathy and inaction. A total wrecking ball. Elder me now appreciates notions like patience, deep listening, radical empathy. Like trying to empower people to improve their own situation, instead of always running them over.

by Jun8 2y ago

cogman10 2y ago

This all, imo, is simply a trust problem primarily from leadership. Leadership does not trust the grunts to do productive work. So in order to make sure productive work is done, they build elaborate systems of cases, reviews, meetings, planning, scheduling, fighting, readjusting when the schedules are invariably missed, and finger pointing. All almost always completely devoid of input from the grunts. The middle management problem is they are right in the worst place possible. They are removed from the actual work being done so they don't know what it actually takes to do anything and they are blamed for things not accomplished. Further, they are rewarded for every little stupid thing done. It hyperintensities them to do lots of small safe initiatives and vehemently oppose anything with any sort of risk. All while being almost completely disconnected from what actually needs to be done. This all leads to a culture meant to squash innovation. Middle management isn't rewarded for implementing a grunt's idea, they are rewarded for delivering CEO initiatives. Anything that takes time away from that is seen as waste.

foobarian 2y ago
> Leadership does not trust the grunts to do productive work Not only that, but unfortunately they are usually right. Without oversight the in-house team has high likelihood of building NIH spaghetti, which causes more problems down the line. To avoid the negative outcome leadership needs to be technically competent and resourced, and that's the other side of the coin - usually they don't have the expertise so in a way they also do not trust themselves to lead the project to a positive outcome.
- danaris 2y ago
  > Without oversight the in-house team has high likelihood of building NIH spaghetti I think when you see this you need to start digging deeper and questioning why this is happening. Is it because the "grunts" are genuinely bad at their jobs? If this is the case, then who hired them? Or is it because they have been conditioned to believe that if they ask for permission to use an outside tool/library/etc, they will be told "no, we don't have the budget for that" or "that has to go through 12 layers of approval" or "great idea! we'll get it into a committee to talk about the best way to implement it and get back to you (in 6-12 months)"? In other words: Are they building NIH spaghetti not because they lack oversight, but because they have too much, that hampers them from actually doing their damn jobs?
  - cruffle_duffle 2y ago
    Don’t forget incentive structures that award developers for “org wide impact”. Often the way to do that is to roll your own crap instead of use off the shelf stuff. This is how you wind up with developers creating their own key-value databases or billing systems… it sounds much better to write these from scratch.
  - Terr_ 2y ago
    I'd like to add that NIH spaghetti sometimes comes from customer relationships rather than from exuberant developers. The important customer wants just one tiny convenience-feature that fits their use case and it sorta makes sense... Which somehow keeps scope-creeping over time into a cancerous unplanned product which is expensive to support. With the benefit of hindsight, you realize it's something the customer should have bought directly for themselves from a completely separate and more-qualified vendor. However they either didn't realize what they wanted or they were able to trick you into building an over-specialized product for their use case--for much cheaper than if they had hired a contractor to customize another better offering.

jmull 2y ago

Mostly agree, but this > aging manager suffering from Peter Principle, partly it’s the fear of negative pushback from senior leadership is not typically the reason, in my experience. I've seen a lack of full comprehension on the part of the team pushing the innovation as to the actual benefit and cost of the innovation to all the affected teams. And as a result, the lack of a plan to address those issues... I've seen a lot of incomplete innovations, where the benefit is real and useful, but the plan leaves various concerns of different teams unaddressed -- no doubt due to the innovation team being unaware. Strangely, the innovation team often wants to push forward anyway, which is not good since the plan is basically unworkable with critical issues unresolved (I can tell they kind of think the issues aren't critical but only because they don't understand them -- leading with ignorance when the processes and products actually have to work at the end is always doomed to fail.) The most common way plans are incomplete that I've seen is when they don't account for the schedule. The plan will take X time away from other work to implement, but the schedule for delivery of that other work isn't moved back X, nor are there other compensating measures. That's an unworkable plan, and any half-decent manager will push back on it. (Schedule impact is usually a tough one... at least at larger places, in my experience, the high-level delivery schedule is negotiated at a high level, and it hard to change for political reasons. That means time for any innovation plans has to be included from the start. Yet slack in any schedule tends to get gobbled up at the team level or below, addressing their concerns -- who doesn't have tons of technical debt they are dying to resolve? There's a way to handle this, but it has to be planned for and done at a high level, and done correctly. The fruits of any innovation team that doesn't have this are gong to be minimal.)

specialist 2y ago

Yes and: As legendary methodologist Alistair Cockburn teaches us: People hate change. They really, really hate change. (paraphrasing) > not only don’t care but are generally hostile to nonstandard work Most persons have an immunological-like response to any and all change. Our minds (personalities?) strive to maintain an equilibrium at all costs. Even when the status quo sucks. Even when we intellectually commit to changing. We keep getting pulled back into the rut, foiling our own best intentions. This trait makes change very, very hard (for most people). Now multiply that by 10, 100, or 1000 persons. Organizational (cultural) change is that much harder. Noob me was belligerently intolerant of apathy and inaction. A total wrecking ball. Elder me now appreciates notions like patience, deep listening, radical empathy. Like trying to empower people to improve their own situation, instead of always running them over.