This is certainly an interesting article to read about but I'm not sure his suggestions or analysis are that substantive. Complex institutions develop rules to simplify decision making and streamline information flows. They choke otherwise. "Develop an innovation doctrine" isn't really effective advice.
There are various articles on developing a culture of innovation, e.g. https://hbr.org/2019/01/the-hard-truth-about-innovative-cult.... Probably some books too. Even ChatGPT probably has decent advice. Management is not technically complex, it just requires putting in the work. But of course it is not easy, e.g. the first advice in the HBR article is to fire incompetent people, whereas the example here was government where firing incompetent people is notoriously hard.
It seems... practical? But not really rocking the boat. Just using Jira though seems like a big step for a government organization. I wouldn't eat my hat but I'd maybe nibble on it and play with the prompts more.https://chatgpt.com/share/13585d1b-a781-49fc-aa42-a7322b6f32...
I agree. I am in aerospace. When times are good, there's money to bring in speakers like this every couple of months to talk to our management. We get the slides afterward and they are refreshingly free of content. All of them essentially repeat the cliche, "Think outside the box!"
We even got one of those Innovation Forums where people could propose ideas, get them upvoted, with the promise of tchotchkes at the end for success. Not a single one got funded. Every efficiency improvement, every streamlining suggestion affects someone's budget and headcount. When that person has to approve, nothing will happen. And, in this industry, a lot of rules are actually law. They have to be followed.
But, the consultants and professional keynote speakers seem to be making good money off of it.
I favor the general point here, but the leading anecdote doesn’t really fit with the lessons learned. A government organization generally does not need an innovation doctrine to avoid being outcompeted because they are a monopoly provider. They maintain that monopoly through force.
If you want to get a government agency to perform better, fix the incentives.
> A government organization generally does not need an innovation doctrine to avoid being outcompeted because they face no meaningful competition
Maybe true for some government organizations, but not true on the whole.
Governments spend billions (and sometimes trillions) on innovation to compete with each other. Collectively, government programs probably account for 99.99% of all "innovation" spending.
And they have the highest stakes when it comes to being "outcompeted".
Doesn't the leading anecdote give an example of a (dis)incentive that needs fixing? That it takes 10 months and lots of head-banging and then you get a $100 bonus, that would certainly disincentivise me to do any type of innovation.
> All large organizations – both government and corporate—need an innovation doctrine or else risk being outpaced by competitors.
I don’t think the anecdote fits conclusion. The reasons to innovate are many, but being outcompeted is not that salient to, say, an IT person in some agency.
Incentives matter, certainly, but you must suss out what those incentives are and what they need to be to arrive at the desired outcome. Look no further than the US Digital Service and 18F (within GSA). You are not paid top dollar, but you are put in front of meaningful work and enabled to deliver (although that in itself is an incentive for the practitioners recruited). From the bottom of the impact report I cite: "We need you. Let’s help millions of people together." right above the Call to Action to apply.
The USDS is enabled to succeed in this mission through the support of the Executive Office of the President, the equivalent of corporate executive sponsorship. Culture comes from the top.
> The USDS is enabled to succeed in this mission through the support of the Executive Office of the President, the equivalent of corporate executive sponsorship. Culture comes from the top.
That sentence is the essence of generic corpo-speak. Doesn't really mean anything without specifics.
I immediately thought of the government. I interned for the transportation department. I was one of these "innovation heros". It was a budget thing as explained to me. If I didn't have work to do, they told me to do homework, I wasn't even allowed to help people on things outside of my department, since they'd have to report on that in budgeting details and be accountable of it to the taxpayer.
Can you really imagine a military that didn't have and celebrate heroes?
If a large organization can't have those that sacrifice themselves and break rules to achieve the greater goal, then they're unlikely to succeed against a significant foe. At the same time communication within large organizations is challenging and leadership is unlikely to know what the challenges at the front line are. Fostering all innovation is as likely to lead to regularly scheduled mediocre "improvements" and "features" that nobody really wants in order to meet whatever metric is in place (to the detriment of what is not explicitly measured).
The argument of the article seems to be, just be so good and well directed by both senior and middle managers that exactly the "right" innovations occur within the process. That likely means those in the trenches aren't getting what they need.
The most effective rapid innovation method I've seen (though painful and challenging to implement) is having separate teams competing to several performance milestones (which allow more generic goals and targeted metrics). At the milestones they share their results and innovations, which competing teams can then use/combine to compete against them. Management needs real goals with known tradeoffs, 2-3x more people than a single team, and it's stressful hitting deadlines knowing that failure is an option. The failure mode is putting all the "best" people on one team which is supposed to win, though I've seen even that get broken by a team of underdog "heroes" who embarrassed the chosen team, and luckily senior management rewarded that.
It's similar to "red" vs "blue" pen-testing or wargaming, but you can have more than 2 teams and the goals can be aligned against the status quo (sometimes a tweaked current solution is the winner).
"Innovation Doctrine" sounds like something you put next to your Mission Statement. How about fostering an internal discussion board where employees can pitch ideas and get hooked up with others who know how to implement them? If you need guard rails around the anarchy, then you can tie action items to a ticket tracking system that's readable by the whole company. I can file a bug in JIRA against any product my company makes, why not the company itself?
Because in large companies, any helpful suggestions get lost in the noise. Everyone has opinions on how things could be done better, but very few of them are good.
The discussion forum still has to be managed (I said "anarchy" facetiously) and at least minimal standards of professionalism would still have to apply. And if the board still devolves into a swamp of griping and bickering, then well, they can nuke it and at least say they tried.
Most ideas are indeed crap, and the good ones have to be picked out. But reducing the total number of ideas doesn't raise the percentage of good ones.
I remember a company I worked at that an internal website for suggesting ideas. The problem is that the management never looked at it. And because of that, employees stopped posting to it. And that was that.
I could name some companies where you don't need to be an "innovation hero" to feel like the "innovation hero" from the anecdote and "Please ask next quarter" seems to be the motto :)
The basic idea here seems pretty sound. I remember years ago critiques about some Microsoft "Heroes" campaign along a similar line. While organizations often have superstars or whatever you want to call them, if you require them to at least minimally function you're probably doing something wrong.
That shouldn't mean that you don't celebrate those superstars. They're not a bad thing certainly--which is probably where I differ with the post a bit. But understand that we shouldn't be depending on them all the time.
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.
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.
> 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.
> 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?
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.
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.
This message encapsulates why so many software jobs are terrible. Put your heart and soul into doing your best, earnestly combat NIH and pursue meaningful productivity, and _still_ the culture is such that at many companies, there will never be trust because the prevailing culture is that management is "usually right" that grunts can't be trusted.
I've worked for good bosses that aren't like this, but they're hard to find.
I still blame the management here for not building a team where quality and foresight matter enough to avoid large messes.
Trust from management isn’t all that is needed for good work to be accomplished, good managers of software development also should not shockingly know good software development.
I swear software and tech related roles are one of the few places where the managers don’t also know how to do the job of their reports.
Concur. It's an unfortunate race to the bottom which is just indicative of the dilution of ability in this godforsaken industry. Why can't a team of grunts manage a basic CRUD web app? That's what's so frustrating: most of these problems aren't even _hard_, and yet devs screw them up anyway.
For what it's worth, I'm actually a senior IC who's cleaned up plenty of messes over decades and who enjoys migrating legacy systems. In my experience, it's the management-level architecture astronauts who don't understand loose coupling who do the most harm. The damage done by low level individuals can be contained if they're working on properly isolated subsystems (which of course requires competent management to set up).
And I'm cynical all right. I used to believe that I could be part of a "we're all in this together" team. But I've realized how rare that is after bad experiences at multiple companies where management sees an antagonistic relationship with engineering as inevitable — because they agree with you that "grunts can't be trusted".
What's difficult is that usually half the team of grunts can be trusted to run their own race, the other half can be completely clueless and need explicit guidance, even if they are decent programmers otherwise.
If you were to allow everyone to innovate freely, some would spend several weeks learning the latest shiny fad and creating things of no or negative value, like using AI to generate commit messages or adding service mesh to your single container kubernetes cluster. The disconnect from business value and writing code for the sake of writing code can be astonishing. Conversely, if you let loose one smart guy in the team, it may seem unfair to the rest of the team.
A good leader is the one who balances the need and utilizes the best of both these sides.
You’d think from this thread that the messes inevitably originate from ”grunts” wandering off the reservation. In my experience the source has often been “innovation” imposed from above, in the form of buzzword-driven development championed by semi-technical leadership enamored of this poisonous “grunts can’t be trusted” ideology.
> This all, imo, is simply a trust problem primarily from leadership. Leadership does not trust the grunts to do productive work.
Which, IME, stems from a deep-seated classism that sees "grunts" today as being essentially no different than assembly-line workers in the Industrial Revolution: you're just a pair of hands who not only doesn't know enough to make changes in the process, you shouldn't even think of it, because it's not your place.
In this worldview, it's managers (and up) who have the education, intelligence, and breeding to know best, and lowly workers just need to shut up and do what they're told.
...This attitude is also responsible for a lot of other really destructive problems in the modern world of work.
What bothers me about the rest of this thread is not that "grunts" are seen as fallible, but that management is implicitly infallible. Blaming everything on the "grunts" is irresponsible garbage in an industry where leadership, of necessity, often doesn't have a deep understanding of what's going on and the ability to make generally correct decisions with incomplete information is a critical management skill.
> 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.)
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.
I agree to the overall tone, but there are also counter points.
One of them is the Google example. To get promoted beyond a certain level, you must have brought some new product over the finish line. Result? They have so many new things happening all the time, all of them suck, and then just move on to the next. Eg how many chat products do they need to invent before they settle on one and let it mature?
100 %. There's a sweet spot. I worked for both, start-ups and huge corporations. It's not one or the other, you want the right combination of maturity and fresh attitude. We often don't realize it can take years to steer back to find the balance again, but not oversteer, which is usually the default :) Just as with any other organism.
> To get promoted beyond a certain level, you must have brought some new product over the finish line
This always confused me. It looked from the outside like Google does so many things right on the innovation front, but after some early success they have had a rough streak.
I'd argue that one thing that Google is doing wrong is gatekeeping promotions based on (overly) well-defined criteria such as new products. Goodhart's Law applies to this situation: you're sure to see lots of new products if its highly rewarded - a lot more than you'd see naturally. As the author mentioned - this might still be desirable depending on the market conditions, but there is a lot more to this discussion, and it's not entirely clear that Google has it wrong.
I'd argue that they emphasize comparability of assessment results(e.g. being able to quantify someone's output like a percentage grade in a course) over the actual relevancy of the assessment criteria/work/kpi to the company's bottom line(e.g. does the course's test actually prepare students for the real world). This probably comes as a by-product of the organization's heavily academic-focused staff - so it might actually be the best culture choice for them given that context - but it might also lose to companies that can successfully put a bigger weighting on the right "intangibles".
So only 2/5 of the ones you mentioned were started in-house, and all were pre-2010 (pre-Sundar) creations.
edit: Sundar joined Google in 2004 and apparently led Maps, Chrome, and eventually Android before becoming CEO. So "pre-Sundar" is technically incorrect.
This characterization is pretty misleading. For example, the Google Maps that was acquired was a C++ desktop application. What most people think of as Google Maps (the AJAX web app) was built and launched by Google.
You're kidding right? Maps, android, camera, calendar, hangout, pay/wallet, docs, sheets, slides, voice to text stuff, YouTube, chrome/debugger, kubernetes, grpc, Gmail, music, ads... Pretty ubiquitous suite of products both consumer facing and business facing... I don't think you can question that Google has been successful at innovation. You can question if they could be doing it better but impossible to say they aren't having some success doing what they're doing...
Acquisition, acquisition, basic OS feature (and therefore part of the Android acquisition), Google EEE of thing you could already do (and developed by an individual Google developer without the approval of Google management), Google CADT, Google EEE of something you could already do, acquisition, acquisition, actual Google creation, don't know, Google EEE of something that already existed (Firebug was first), not good, too trivial to count, actual Google creation that I already mentioned, don't know what you mean, not good.
Flights were acquisition and to this day are a bit of unlikely island internally (AFAIK QPX engine is still in use, and it's written in language otherwise verboten at Google)
The promotion thing seems severely overstated. At the higher levels for IC and management this is basically how all tech companies that build products are run. But you don't see this said about Microsoft or Amazon, even though they also have hundreds of new features and discrete new products per year.
My theory for why Google is different remains unpopular, however.
I think it's because Google has created an insular, navel-gazing culture that is excessively engineer driven rather than customer driven, to the extent of thinking people not at Google are just inferior.
beyond just launching a product, the launch has to have some sort of "impact" (at least, this was true in the time period where I was trying to get promoted, roughly 2010-2013). Something that is not perceived as impactful by the promo committee is likely not going to count towards promotion. It's the job of the employee and manager to document the "impact".
If your manager is a director or higher, they can appeal the promo denial and an appeals committee can be manipulated into giving a promotion. That's what happened to me- promo saw no impact to my launch. Then my director went to appeals and basically said "promote him, he's doing good work".
Everything about Google messed up my expectations and planning around career. To work anywhere else (a startup, or a pharma) I had to unlearn all the bad habits of self-promotion and cookie-licking and impact-demonstration.
Of course many people joke the best way to get promoted at Google is to leave, get promoted elsewhere, and return to Google at a higher level (using all your newly learned negotiation skills).
> Why Innovation Heroes are a Sign of a Dysfunctional Organization
Because often you can solve 99% of companies problems with boring software.
I am reminded of this blog post from earlier this week:
> Most organizations cannot ship the most basic applications imaginable with any consistency, and you're out here saying that the best way to remain competitive is to roll out experimental technology that is an order of magnitude more sophisticated than anything else your I.T department runs,
"Innovation" in this context does not mean cutting-edge technology. It just means changing processes to deliver better results. The tech is often the easy part, and there's plenty of room for boring software.
The hard part is navigating the bureaucracy and building consensus toward a change. This management-craft is where the clever thinking and emergent solutions are found and deployed.
A backhoe is orders of magnitude more complex than a shovel. A team struggling to dig a pit with shovels would probably benefit immensely from a backhoe. The idea that workers shouldn't get better tools until they can succeed without them is insane.
Reminds me of the Drucker quote about “culture eats strategy for breakfast.”
The problem is that large organizations naturally drift toward inertia and ossification. If a forward-looking leader wants the culture to change, they are faced with a conundrum:
- use a strategy like this (e.g. some top-down “innovation center” approved at the C level) which reinforces the rigidity and process-oriented thinking that needs to change, or
- create an insurgent skunkworks group that hopes to prove a different approach via undeniable results. This usually ends with back-alley knives getting unsheathed.
Innovation means potential for failure and waste. The larger the company the more it's investors want it for steady predictable returns. Even shrinking returns as long as they are steady and foreseeable. A large company becomes about control. Look at summer blockbusters. They know the demographics that will see it and have a pretty good (not absolute) idea of how much they can make.
This can be by design, sure. But I think it is also an inexorable tendency for people in large groups. Once your company is 10x Dunbar’s number, it is very hard for “we” to mean the entire company.
I’m currently working with the NHS in a Quality Improvement role in a hospital. The team exists to give grass-roots folks the tools they need to make change happen when they spot something in the system which is less than ideal. We offer training, help with setting aims, running projects, finding stakeholders, analysing data etc. These aren’t huge system transformation projects, in fact some of them can be quite small - but as a way of working it feels quite effective.
> what we just witnessed was leadership rewarding and perpetuating a dysfunctional and broken system.
It's not clear that it is dysfunctional. If innovation is not a particularly high priority, but risk reduction is, then the system is working as designed - all of the checks are necessary. Compare to the "innovative" Boeing-type company which streamlines production by removing all safety checks.
Lacking a method to implement continuous improvement is the dysfunction.
“When [W. Edwards Deming] came to spread the gospel of continuous improvement in 1950, he was preaching to the choir. Toyota already believed in it. [Deming] simply gave them a process to better understand how to progress from failure. The idea of ever-improving coupled with what they learned from Deming—especially the Theory of Knowledge and shorter feedback loops via the PDSA loop, as well as the Theory of Variation and the accompanying statistical process control—let them succeed in their failure.”
From “Deming’s Journey” by John Willis. Solid recommended new read.
This is exactly why the common advice is to automate your own tasks on your own time, with your own resources, don’t tell anyone, and enjoy working less.
One addendum to this that I have observed: In many organizations, no one is "in charge." If change needs to happen, there are 100 checkboxes, 100 reasons not to change, 100 people who are concerned about their career, resume, budget, department, relevance, etc.
For every "innovation hero" that wins an award, there are 5 who are "managed" into leaving, marginalized, or disenfranchised. The high nail gets the hammer. I have been into and out of the startup space for the last 20 years, and most of the times that I was an "innovation hero" it was because there was one person in a corner office who was using me as a proxy for a change they wanted to see happen.
The American system of organizational management is...basically glue.
I'm reminded of the article "Layers of Management == Layers of Veto" [0]. In the article the author explains that each layer of management is likely to veto each idea coming from below. Each idea that didn't come from above is "insubordination" and likely to be vetoed.
Relate to the four stages of employment:
1) This is the new person "X" - they are amazing and are going to solve everything!
2) "X" is pretty good, but maybe not as good as we thought.
3) "X" turned out to just be another average performer.
4) "X" is obviously terrible or they would have left for someplace that would treat them better than we do.
I've never seen this written down, but I've definitely seen it in action.
Experienced leaders try to avoid deluding themselves at step 1, and work to prevent things transitioning from step 2 to step 3.
But sometimes it's impossible (or I'm not experienced enough!). Some employees really do start off strong and then fade out, even if the incentive structures are "good" / "above market" / etc.
Honestly, I've seen the roots of this in myself too, in classes, jobs, relationships: initial enthusiasm wanes and at some point it's time to make a different decision. Personally I prefer to move on instead of stagnate, but some people are perfectly happy to ride the suboptimal until a decision is made for them!
Sometimes the new employee's superpower is all the good ideas they have seen in their previous jobs that they are now bringing to your company. But the fact that they work for you now means that they no longer get new experience about how things work in other companies.
Sometimes it is the fact that as a new employee, they are expected to still be learning new things, so they are given less work and responsibilities, which leaves them some time to think. Later, they will probably be given as much work and responsibility as possible, which leaves no time and energy to think about things. Especially with daily agile meetings, which make sure that everyone is only thinking about the things the management wants them to think about (hint: fixing technical debt is not one of those things).
I'll qualify one though -- if the "management" who is present on daily standup does not prioritize fixing tech debt, then that person is simply at the wrong level of management to be present.
It's possible to do standups productively, though often they certainly are not.
> It's possible to do standups productively, though often they certainly are not.
The original idea of Scrum was that the daily standups are for developers alone. And they are supposed to be very short; literally while standing up to discourage people from starting long debates. Just say, briefly, what did you work on yesterday, what are you going to work on today, and whether you have any problems. To prevent developers from starting to work on something that other team member already did or is currently doing.
But of course, "Scrum in practice" usually differs dramatically from "Scrum in theory", and the managers are often happy to invite themselves to the daily standups, so what was supposed to become a simple coordination between peers becomes a progress report and an invitation to micromanage.
I have seen it done the right way, but more often I have seen it done the wrong way.
Not sure that you can fix a calcified bureaucracy with "doctrine". I sort of get the angle, I think -- if the org operates within a rigid rule framework, you need to speak their language to get anywhere -- so, doctrine is best, because everyone is used to being told what to do? I feel like that approach is counter to the spirit of innovation, that's akin to being forced to have fun; nothing truly innovative will come from it.
I think it's more of a lost cause, really. If you want to work on cool new stuff, don't work at a large org. I play the "innovation hero" role often enough, and the diversity of pushback we encounter is impressive. It ranges from thinly veiled hostility, the sdev equivalent of NIMBY, lies through omission, through nonviolent noncompliance, all the way to blithely unaware absurdity.
One amazing moment stands out to me - we were jumping through the usual hurdles as described in the article, trying to get a prototype to prod, and in one meeting the head of IT indignantly exclaimed "I am not here to solve problems!". To paraphrase a scene from the Big Short: he wasn't confessing, he was bragging. The top brass exist to stifle any and all deviation from the norm.
Another commenter in this thread makes a very good point: most of these innovation initiatives die stillborn, because the existing power structures exist, their MO is to maintain, and the C-suites would rather buy a successful startup than take any political risks internally.
"Innovation doctrine" is a contradictory phrase on its face, really. Going, "Oh we need a static, unchanging set of rules for innovation" doesn't exactly sound like a good way to attract and retain innovative thinkers lmao
> so, doctrine is best, because everyone is used to being told what to do?
I think they mean doctrine as in military doctrine (https://en.wikipedia.org/wiki/Military_doctrine), which is a somewhat different idea than, say, religious doctrine. Religious doctrine can easily get rigid and legalistic, and compliance with it can become an end unto itself. Military doctrine is something a military would use in order to make the organization effective at a certain kind of task or endeavor.
The problem with this particular anecdote is that 'innovation' and 'government agency' are used in the same sentence.
Most people do not equate any government agency with an innovative environment. Bureaucracy is the watchword where the status quo is not only encouraged but fiercely protected.
Any new hire or politician who threatens to reform the process is treated as the enemy.
>> Why is it that innovations require heroics to occur in our organization?
Why do we immediately assume that innovation = progress? Sure, the things that SURVIVE are useful, but that's just the tip of the iceberg. The vast majority of ideas are just like mutations in evolution more likely to be at best useless and probably damaging in various ways.
You see, social constructs are not as dumb as they appear to be to the armchair intellectual. "Why, we should embrace innovation and immediately adopt any idiocy that Mary from accounting is suggesting as our global company policy". I assure you that by natural law, if "random idea from random guy" were profitable on average, we'd have a system that would encourage such ideas. The sad fact is that they aren't and will never be.
Friction (named in the article as "Dysfunctional Organization") is an unfortunate but necessary process which ensures "survival of the fittest", even among "innovation". It's as simple as that.
Second, innovation is a new idea, product, strategy, etc. Stagnation is lack of movement or lack of growth. There are alternatives to stagnation that are not innovation. Consider satisficing.
Third, the end result of stagnation may be other than death. It may be a steady state. Surviving, but not growing, is not death.
Don't sell short progress that has already been made.
I would estimate that for most people born in the 21st century, before they were born there were already more promising undeployed innovations that can't be beat, than new ones that will actually be deployed during their lifetime.
That's not all I do, but just about. Experimentation & discovery is like that. When I started out innovation was still as highly valued as it should be, up until the mid 1970's when people lost interest since nobody could afford to deploy anything any more anyway, unless they were among the most well-heeled who had weathered the economic devastation.
I worked for a large company and started seeing opportunities for automation immediately. I proposed some solutions to my boss, and he told me that he agreed that these tasks could be automated, but that we have 10,000 other tasks that could be automated, and each one takes a few months to get the resources provisioned and also set aside developer (me) time to get it done, which could be spent on other projects.
What was interesting to me was the self-fulfilling prophecy of dysfunction: because there was so much manual process and red tape, the cost of fixing a particular problem is larger than than the benefits (i.e: time spent on the task exceeds time saved by automating it).
But because the tasks do not get automated, the amount of time required to fix things increases bit by bit due to the processes in place. The cost of fixing a task increases marginally every day, and so the cost/benefit ratio increases every day, becoming further justification NOT to fix things. At a certain point you have to look at the bigger picture and recognize that there is a much larger problem in your company than a few excel spreadsheets that could be better automated.
So much feel this and have seen it many times. A complete unwillingness to spend a few hours to save hundreds of hours later, because too much is urgent. It's a little bit like a thrashing OS, too many competing resources so the result is everything slows to a crawl or breaks.
I've clawed my way out of situations like this but it does require some heroics in the beginning and probably longer hours than your role requires. I am the kind of person that will ask to slow a project down or delay it if it means we get a chance to do things correctly and in a maintainable way, but certain types in management will not really understand enough to completely buy in.
I know that feeling all too well. And it's such a hard truth that devoting just a little time, letting some projects slip just a bit, to fixing those systemic problems could make lots of others go away, it's just next to impossible to get people to want to change. I've found because people don't want to, they want to keep doing what they're doing and are scared of anything new because that may mean either they'd have to retrain, or more pathologically, that their position is threatened.
It all comes down to the people. The right people can make all the difference in something like that, the wrong people make it miserable for the rest.
I honestly don't know where innovation exists that doesn't require "fighting the system" to some degree.
There are a lot of bad ideas out there and the "system" is there to weed out the bad ideas. However, you can have too much system where it will defeat even the good ideas too, so there's a sweet spot.
IMO it's comes down to how much leftover budget (time or money) the organization has. You don't need processes or procedures for innovation... you need people with enough leftover money and time who can "screw around" a little.
> There are a lot of bad ideas out there and the "system" is there to weed out the bad ideas. However, you can have too much system where it will defeat even the good ideas too, so there's a sweet spot.
Innovation means figuring out which are good and which are bad. It's hard to tell which is which from the beginning. Failure is inevitable. It's just whether there's a net benefit to the company instead of a net cost.
The problem is that the people and processes resist ANY failure, which necessarily throws out any innovation along with it.
> you need people with enough leftover money and time who can "screw around" a little
And this is about right. There needs to be enough slack to not strangle ANY idea that can possibly fail. The author just went so far as to say that the "leftover" needed to be part of the budget.
> Also a place where everyone is not grumpy.
Quite right. We need a place where some people are optimistic about new ideas instead of rejecting everything.
To be fair, creating a process for innovation is hard and expensive - especially if you want it to apply across the board at a large organization.
I have been on multiple "incubator" development teams in the past and although we did move faster, my times at smaller startups still felt significantly more productive.
You want something that is the right balance of bespoke and standardized/transferable. Its not easy, but there is so much room for improvement at these bigger organizations that there is huge value to getting it right.
Lack of innovation is of course a problem in industry, but it’s a particular problem in the public sector where many employees are attracted by the “can’t get fired” rather than the “let’s make things better” nature of the job.
Even this reply is too late but I want to make sure you see https://news.ycombinator.com/item?id=40783859. If you'd please read that moderation comment I'd appreciate it. You're welcome to participate on HN but we need you not to break the rules that badly.
Author clearly has no understanding of why startups move quickly. Startups have the same Legal, Procurement, Security, etc. needs and responsibilities as any large company or government agency - its just that these responsibilities are looked after by generalist founder-executives, not whole departments filled with specialists. Any "innovation department", if it ever wants to actually ship anything, still needs to get BigBureaucracy on board, which is where the vast majority of time gets eaten up to ship anything. Startups don't need buy-in and alignment from whole departments full of specialists, just the executive-founders with unrelated titles and experience who are still nonetheless nominally responsible for those areas.
> what we just witnessed was leadership rewarding and perpetuating a dysfunctional and broken system.
Leadership's first responsibility is to keep the system happy and running smoothly. The first responsibility is not to shareholders, not to attempting to seize potentially higher profits, but to the organization itself. The organization may be "dysfunctional" and "broken" but this is completely irrelevant - the Fortune 500 is still generating massive profits and the public institution is still nominally discharging its duties. This is why the vast majority of Fortune 500 CEOs are "caretaker" CEOs and why deep cultural change of public institutions is so difficult.
Culture is fundamentally a question of who you hire, who you promote, and who you fire. Those decisions do not happen overnight in healthy organizations. That's why it's slow.
Some orgs of Fortune 500 caliber have innovation units that help to process ideas and changes. To be efficient, these units must have buy in on senior leadership level and high level of exec sponsorship, ideally they would also have C-level representation in a form of dedicated “innovation officer” or similar role.
It is definitely not a new area, and author is on point with one key idea: organisations where heroes are praised as miracles generally don’t give a damn about continuous improvement, innovation units just never happen there. Praising individuals who swam against the flow for a year is pure virtue signalling in these orgs. In 2024 “running things smoothly” is almost a synonym for “continuous improvement”; building latter requires intent, not miracles.
> Author clearly has no understanding of why startups move quickly.
He also appears to have no understanding of why government agencies and large corporations don't have to. Multiple times he says that such organizations need an innovation strategy or they will be out-competed. But government agencies and large corporations (which are mainly large because of the advantages of being large in an environment heavily regulated by government) don't have to worry about being out-competed, because they have insulated themselves from competition.
I fully agree with the sentiment, as I immediately get discouraged of doing anything as soon as it requires the approval from someone in another organization, which in large companies will often take weeks, if it happens at all.
There's an argument to be made for bureaucracy: once you reach a certain scale (of complexity and/or size), the law of large numbers makes that you're prone to more risks than when you're a startup. It's "fine" for a startup to not be aware of the latest development of privacy policies in Finland, and if you provision a couple resources in the cloud everything's fine because when looking at the bill, you can simply ask around "who owns that thing?". At enterprise size, you're much more prone to be audited by governments, to be attacked by hackers, to be the target of lawsuits, to have runaway costs that get hard to diagnose ; and the complexity of your systems (wet or hard) doesn't increase linearly. I don't think you can avoid having some processes to control that.
The problem is when the enterprise gets into a vicious cycle in which the only fix to any process issue is to slap on more process rather than rethink the existing ones. Such as illustrated in that post, where the solution to a lack of innovation is the creation of innovation heroes to incentivize the behaviour. I've been in three enterprise organizations, two of them have policies where you need to ask for permission, the other grants permission by default but reviews what's been done. That second policy is much better, as the level was quite high, people tend to respect the rule, and get caught if they don't. That allows for faster work.
But then there's also the matter of recruitment. As a startup you can handpick people, create a team that's functional and with an edge. In an enterprise, recruiting is done at an industrial scale, where your inbound fresh flesh exposes you to the simple truth that, by definition, half of humanity is below the mean.
169 comments
[ 5.3 ms ] story [ 308 ms ] threadThis is certainly an interesting article to read about but I'm not sure his suggestions or analysis are that substantive. Complex institutions develop rules to simplify decision making and streamline information flows. They choke otherwise. "Develop an innovation doctrine" isn't really effective advice.
If chatGPT has anything other than banal platitudes, I'll eat my hat.
We even got one of those Innovation Forums where people could propose ideas, get them upvoted, with the promise of tchotchkes at the end for success. Not a single one got funded. Every efficiency improvement, every streamlining suggestion affects someone's budget and headcount. When that person has to approve, nothing will happen. And, in this industry, a lot of rules are actually law. They have to be followed.
But, the consultants and professional keynote speakers seem to be making good money off of it.
If you want to get a government agency to perform better, fix the incentives.
Maybe true for some government organizations, but not true on the whole.
Governments spend billions (and sometimes trillions) on innovation to compete with each other. Collectively, government programs probably account for 99.99% of all "innovation" spending.
And they have the highest stakes when it comes to being "outcompeted".
> All large organizations – both government and corporate—need an innovation doctrine or else risk being outpaced by competitors.
I don’t think the anecdote fits conclusion. The reasons to innovate are many, but being outcompeted is not that salient to, say, an IT person in some agency.
The USDS is enabled to succeed in this mission through the support of the Executive Office of the President, the equivalent of corporate executive sponsorship. Culture comes from the top.
https://www.usds.gov/impact-report/2024/
https://www.usds.gov/impact-report/2024/by-the-numbers/
(full disclosure: went through a USDS interview cycle and was extended an offer, no other affiliation)
That sentence is the essence of generic corpo-speak. Doesn't really mean anything without specifics.
Can you really imagine a military that didn't have and celebrate heroes?
If a large organization can't have those that sacrifice themselves and break rules to achieve the greater goal, then they're unlikely to succeed against a significant foe. At the same time communication within large organizations is challenging and leadership is unlikely to know what the challenges at the front line are. Fostering all innovation is as likely to lead to regularly scheduled mediocre "improvements" and "features" that nobody really wants in order to meet whatever metric is in place (to the detriment of what is not explicitly measured).
The argument of the article seems to be, just be so good and well directed by both senior and middle managers that exactly the "right" innovations occur within the process. That likely means those in the trenches aren't getting what they need.
The most effective rapid innovation method I've seen (though painful and challenging to implement) is having separate teams competing to several performance milestones (which allow more generic goals and targeted metrics). At the milestones they share their results and innovations, which competing teams can then use/combine to compete against them. Management needs real goals with known tradeoffs, 2-3x more people than a single team, and it's stressful hitting deadlines knowing that failure is an option. The failure mode is putting all the "best" people on one team which is supposed to win, though I've seen even that get broken by a team of underdog "heroes" who embarrassed the chosen team, and luckily senior management rewarded that.
It's similar to "red" vs "blue" pen-testing or wargaming, but you can have more than 2 teams and the goals can be aligned against the status quo (sometimes a tweaked current solution is the winner).
Most ideas are indeed crap, and the good ones have to be picked out. But reducing the total number of ideas doesn't raise the percentage of good ones.
That shouldn't mean that you don't celebrate those superstars. They're not a bad thing certainly--which is probably where I differ with the post a bit. But understand that we shouldn't be depending on them all the time.
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.
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.
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.
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?
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.
This message encapsulates why so many software jobs are terrible. Put your heart and soul into doing your best, earnestly combat NIH and pursue meaningful productivity, and _still_ the culture is such that at many companies, there will never be trust because the prevailing culture is that management is "usually right" that grunts can't be trusted.
I've worked for good bosses that aren't like this, but they're hard to find.
Trust from management isn’t all that is needed for good work to be accomplished, good managers of software development also should not shockingly know good software development.
I swear software and tech related roles are one of the few places where the managers don’t also know how to do the job of their reports.
Signed, a greybeard sick of cleaning up messes.
And I'm cynical all right. I used to believe that I could be part of a "we're all in this together" team. But I've realized how rare that is after bad experiences at multiple companies where management sees an antagonistic relationship with engineering as inevitable — because they agree with you that "grunts can't be trusted".
If you were to allow everyone to innovate freely, some would spend several weeks learning the latest shiny fad and creating things of no or negative value, like using AI to generate commit messages or adding service mesh to your single container kubernetes cluster. The disconnect from business value and writing code for the sake of writing code can be astonishing. Conversely, if you let loose one smart guy in the team, it may seem unfair to the rest of the team.
A good leader is the one who balances the need and utilizes the best of both these sides.
Which, IME, stems from a deep-seated classism that sees "grunts" today as being essentially no different than assembly-line workers in the Industrial Revolution: you're just a pair of hands who not only doesn't know enough to make changes in the process, you shouldn't even think of it, because it's not your place.
In this worldview, it's managers (and up) who have the education, intelligence, and breeding to know best, and lowly workers just need to shut up and do what they're told.
...This attitude is also responsible for a lot of other really destructive problems in the modern world of work.
> 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.)
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.
One of them is the Google example. To get promoted beyond a certain level, you must have brought some new product over the finish line. Result? They have so many new things happening all the time, all of them suck, and then just move on to the next. Eg how many chat products do they need to invent before they settle on one and let it mature?
This always confused me. It looked from the outside like Google does so many things right on the innovation front, but after some early success they have had a rough streak.
I'd argue that one thing that Google is doing wrong is gatekeeping promotions based on (overly) well-defined criteria such as new products. Goodhart's Law applies to this situation: you're sure to see lots of new products if its highly rewarded - a lot more than you'd see naturally. As the author mentioned - this might still be desirable depending on the market conditions, but there is a lot more to this discussion, and it's not entirely clear that Google has it wrong.
I'd argue that they emphasize comparability of assessment results(e.g. being able to quantify someone's output like a percentage grade in a course) over the actual relevancy of the assessment criteria/work/kpi to the company's bottom line(e.g. does the course's test actually prepare students for the real world). This probably comes as a by-product of the organization's heavily academic-focused staff - so it might actually be the best culture choice for them given that context - but it might also lose to companies that can successfully put a bigger weighting on the right "intangibles".
There's search, obviously. Gmail, if that wasn't an acquisition.... What else?
The issue is that most of these originated a long time ago and recent Google creations, like Bard/Gemini, tend to be mediocre copies of other things.
Android: acquired in 2005
Google Sheets: acquired in 2006
Translate: launched in 2006
Chrome: launched in 2008
So only 2/5 of the ones you mentioned were started in-house, and all were pre-2010 (pre-Sundar) creations.
edit: Sundar joined Google in 2004 and apparently led Maps, Chrome, and eventually Android before becoming CEO. So "pre-Sundar" is technically incorrect.
Re "too trivial to count"? We're commenting on a thread that involves an award given out for someone who wrote an excel script...
Re "not good": From whose perspective? If it makes company more profit then it's hard to say that it's a bad thing...
Dismissing something innovative and hugely impactful as “kubernetes” as “not good” says all you need to know about the quality of this comment.
Also your point that none of the acquisitions have been innovated on since their acquisition? Android was originally an OS for a handheld camera.
Or are you going to bundle all the innovation into your clearly ignorant “not good” bucket as well?
My theory for why Google is different remains unpopular, however.
May we hear it?
If your manager is a director or higher, they can appeal the promo denial and an appeals committee can be manipulated into giving a promotion. That's what happened to me- promo saw no impact to my launch. Then my director went to appeals and basically said "promote him, he's doing good work".
Everything about Google messed up my expectations and planning around career. To work anywhere else (a startup, or a pharma) I had to unlearn all the bad habits of self-promotion and cookie-licking and impact-demonstration.
Of course many people joke the best way to get promoted at Google is to leave, get promoted elsewhere, and return to Google at a higher level (using all your newly learned negotiation skills).
Because often you can solve 99% of companies problems with boring software.
I am reminded of this blog post from earlier this week:
> Most organizations cannot ship the most basic applications imaginable with any consistency, and you're out here saying that the best way to remain competitive is to roll out experimental technology that is an order of magnitude more sophisticated than anything else your I.T department runs,
https://ludic.mataroa.blog/blog/i-will-fucking-piledrive-you...
The hard part is navigating the bureaucracy and building consensus toward a change. This management-craft is where the clever thinking and emergent solutions are found and deployed.
The problem is that large organizations naturally drift toward inertia and ossification. If a forward-looking leader wants the culture to change, they are faced with a conundrum:
- use a strategy like this (e.g. some top-down “innovation center” approved at the C level) which reinforces the rigidity and process-oriented thinking that needs to change, or
- create an insurgent skunkworks group that hopes to prove a different approach via undeniable results. This usually ends with back-alley knives getting unsheathed.
This is all by design.
I’m currently working with the NHS in a Quality Improvement role in a hospital. The team exists to give grass-roots folks the tools they need to make change happen when they spot something in the system which is less than ideal. We offer training, help with setting aims, running projects, finding stakeholders, analysing data etc. These aren’t huge system transformation projects, in fact some of them can be quite small - but as a way of working it feels quite effective.
The biggest changes always start with someone taking one small step towards their goal.
Some of the biggest software (used by billions of people) I've ever worked on started as a simple script made by a teenager.
It's not clear that it is dysfunctional. If innovation is not a particularly high priority, but risk reduction is, then the system is working as designed - all of the checks are necessary. Compare to the "innovative" Boeing-type company which streamlines production by removing all safety checks.
“When [W. Edwards Deming] came to spread the gospel of continuous improvement in 1950, he was preaching to the choir. Toyota already believed in it. [Deming] simply gave them a process to better understand how to progress from failure. The idea of ever-improving coupled with what they learned from Deming—especially the Theory of Knowledge and shorter feedback loops via the PDSA loop, as well as the Theory of Variation and the accompanying statistical process control—let them succeed in their failure.”
From “Deming’s Journey” by John Willis. Solid recommended new read.
https://www.amazon.com/Demings-Journey-Profound-Knowledge-In...
For every "innovation hero" that wins an award, there are 5 who are "managed" into leaving, marginalized, or disenfranchised. The high nail gets the hammer. I have been into and out of the startup space for the last 20 years, and most of the times that I was an "innovation hero" it was because there was one person in a corner office who was using me as a proxy for a change they wanted to see happen.
The American system of organizational management is...basically glue.
I'm reminded of the article "Layers of Management == Layers of Veto" [0]. In the article the author explains that each layer of management is likely to veto each idea coming from below. Each idea that didn't come from above is "insubordination" and likely to be vetoed.
[0] https://slott56.github.io/2010_02_12-layers_of_management_la...
This reminds of that.
Experienced leaders try to avoid deluding themselves at step 1, and work to prevent things transitioning from step 2 to step 3.
But sometimes it's impossible (or I'm not experienced enough!). Some employees really do start off strong and then fade out, even if the incentive structures are "good" / "above market" / etc.
Honestly, I've seen the roots of this in myself too, in classes, jobs, relationships: initial enthusiasm wanes and at some point it's time to make a different decision. Personally I prefer to move on instead of stagnate, but some people are perfectly happy to ride the suboptimal until a decision is made for them!
Sometimes it is the fact that as a new employee, they are expected to still be learning new things, so they are given less work and responsibilities, which leaves them some time to think. Later, they will probably be given as much work and responsibility as possible, which leaves no time and energy to think about things. Especially with daily agile meetings, which make sure that everyone is only thinking about the things the management wants them to think about (hint: fixing technical debt is not one of those things).
I'll qualify one though -- if the "management" who is present on daily standup does not prioritize fixing tech debt, then that person is simply at the wrong level of management to be present.
It's possible to do standups productively, though often they certainly are not.
The original idea of Scrum was that the daily standups are for developers alone. And they are supposed to be very short; literally while standing up to discourage people from starting long debates. Just say, briefly, what did you work on yesterday, what are you going to work on today, and whether you have any problems. To prevent developers from starting to work on something that other team member already did or is currently doing.
But of course, "Scrum in practice" usually differs dramatically from "Scrum in theory", and the managers are often happy to invite themselves to the daily standups, so what was supposed to become a simple coordination between peers becomes a progress report and an invitation to micromanage.
I have seen it done the right way, but more often I have seen it done the wrong way.
I think it's more of a lost cause, really. If you want to work on cool new stuff, don't work at a large org. I play the "innovation hero" role often enough, and the diversity of pushback we encounter is impressive. It ranges from thinly veiled hostility, the sdev equivalent of NIMBY, lies through omission, through nonviolent noncompliance, all the way to blithely unaware absurdity.
One amazing moment stands out to me - we were jumping through the usual hurdles as described in the article, trying to get a prototype to prod, and in one meeting the head of IT indignantly exclaimed "I am not here to solve problems!". To paraphrase a scene from the Big Short: he wasn't confessing, he was bragging. The top brass exist to stifle any and all deviation from the norm.
Another commenter in this thread makes a very good point: most of these innovation initiatives die stillborn, because the existing power structures exist, their MO is to maintain, and the C-suites would rather buy a successful startup than take any political risks internally.
I think they mean doctrine as in military doctrine (https://en.wikipedia.org/wiki/Military_doctrine), which is a somewhat different idea than, say, religious doctrine. Religious doctrine can easily get rigid and legalistic, and compliance with it can become an end unto itself. Military doctrine is something a military would use in order to make the organization effective at a certain kind of task or endeavor.
Most people do not equate any government agency with an innovative environment. Bureaucracy is the watchword where the status quo is not only encouraged but fiercely protected.
Any new hire or politician who threatens to reform the process is treated as the enemy.
Why do we immediately assume that innovation = progress? Sure, the things that SURVIVE are useful, but that's just the tip of the iceberg. The vast majority of ideas are just like mutations in evolution more likely to be at best useless and probably damaging in various ways.
You see, social constructs are not as dumb as they appear to be to the armchair intellectual. "Why, we should embrace innovation and immediately adopt any idiocy that Mary from accounting is suggesting as our global company policy". I assure you that by natural law, if "random idea from random guy" were profitable on average, we'd have a system that would encourage such ideas. The sad fact is that they aren't and will never be.
Friction (named in the article as "Dysfunctional Organization") is an unfortunate but necessary process which ensures "survival of the fittest", even among "innovation". It's as simple as that.
First, define “progress.”
Second, innovation is a new idea, product, strategy, etc. Stagnation is lack of movement or lack of growth. There are alternatives to stagnation that are not innovation. Consider satisficing.
Third, the end result of stagnation may be other than death. It may be a steady state. Surviving, but not growing, is not death.
I would estimate that for most people born in the 21st century, before they were born there were already more promising undeployed innovations that can't be beat, than new ones that will actually be deployed during their lifetime.
That's not all I do, but just about. Experimentation & discovery is like that. When I started out innovation was still as highly valued as it should be, up until the mid 1970's when people lost interest since nobody could afford to deploy anything any more anyway, unless they were among the most well-heeled who had weathered the economic devastation.
What was interesting to me was the self-fulfilling prophecy of dysfunction: because there was so much manual process and red tape, the cost of fixing a particular problem is larger than than the benefits (i.e: time spent on the task exceeds time saved by automating it).
But because the tasks do not get automated, the amount of time required to fix things increases bit by bit due to the processes in place. The cost of fixing a task increases marginally every day, and so the cost/benefit ratio increases every day, becoming further justification NOT to fix things. At a certain point you have to look at the bigger picture and recognize that there is a much larger problem in your company than a few excel spreadsheets that could be better automated.
I've clawed my way out of situations like this but it does require some heroics in the beginning and probably longer hours than your role requires. I am the kind of person that will ask to slow a project down or delay it if it means we get a chance to do things correctly and in a maintainable way, but certain types in management will not really understand enough to completely buy in.
It all comes down to the people. The right people can make all the difference in something like that, the wrong people make it miserable for the rest.
There are a lot of bad ideas out there and the "system" is there to weed out the bad ideas. However, you can have too much system where it will defeat even the good ideas too, so there's a sweet spot.
IMO it's comes down to how much leftover budget (time or money) the organization has. You don't need processes or procedures for innovation... you need people with enough leftover money and time who can "screw around" a little.
Also a place where everyone is not grumpy.
Innovation means figuring out which are good and which are bad. It's hard to tell which is which from the beginning. Failure is inevitable. It's just whether there's a net benefit to the company instead of a net cost.
The problem is that the people and processes resist ANY failure, which necessarily throws out any innovation along with it.
> you need people with enough leftover money and time who can "screw around" a little
And this is about right. There needs to be enough slack to not strangle ANY idea that can possibly fail. The author just went so far as to say that the "leftover" needed to be part of the budget.
> Also a place where everyone is not grumpy.
Quite right. We need a place where some people are optimistic about new ideas instead of rejecting everything.
I have been on multiple "incubator" development teams in the past and although we did move faster, my times at smaller startups still felt significantly more productive.
You want something that is the right balance of bespoke and standardized/transferable. Its not easy, but there is so much room for improvement at these bigger organizations that there is huge value to getting it right.
> what we just witnessed was leadership rewarding and perpetuating a dysfunctional and broken system.
Leadership's first responsibility is to keep the system happy and running smoothly. The first responsibility is not to shareholders, not to attempting to seize potentially higher profits, but to the organization itself. The organization may be "dysfunctional" and "broken" but this is completely irrelevant - the Fortune 500 is still generating massive profits and the public institution is still nominally discharging its duties. This is why the vast majority of Fortune 500 CEOs are "caretaker" CEOs and why deep cultural change of public institutions is so difficult.
Culture is fundamentally a question of who you hire, who you promote, and who you fire. Those decisions do not happen overnight in healthy organizations. That's why it's slow.
It is definitely not a new area, and author is on point with one key idea: organisations where heroes are praised as miracles generally don’t give a damn about continuous improvement, innovation units just never happen there. Praising individuals who swam against the flow for a year is pure virtue signalling in these orgs. In 2024 “running things smoothly” is almost a synonym for “continuous improvement”; building latter requires intent, not miracles.
He also appears to have no understanding of why government agencies and large corporations don't have to. Multiple times he says that such organizations need an innovation strategy or they will be out-competed. But government agencies and large corporations (which are mainly large because of the advantages of being large in an environment heavily regulated by government) don't have to worry about being out-competed, because they have insulated themselves from competition.
There's an argument to be made for bureaucracy: once you reach a certain scale (of complexity and/or size), the law of large numbers makes that you're prone to more risks than when you're a startup. It's "fine" for a startup to not be aware of the latest development of privacy policies in Finland, and if you provision a couple resources in the cloud everything's fine because when looking at the bill, you can simply ask around "who owns that thing?". At enterprise size, you're much more prone to be audited by governments, to be attacked by hackers, to be the target of lawsuits, to have runaway costs that get hard to diagnose ; and the complexity of your systems (wet or hard) doesn't increase linearly. I don't think you can avoid having some processes to control that.
The problem is when the enterprise gets into a vicious cycle in which the only fix to any process issue is to slap on more process rather than rethink the existing ones. Such as illustrated in that post, where the solution to a lack of innovation is the creation of innovation heroes to incentivize the behaviour. I've been in three enterprise organizations, two of them have policies where you need to ask for permission, the other grants permission by default but reviews what's been done. That second policy is much better, as the level was quite high, people tend to respect the rule, and get caught if they don't. That allows for faster work.
But then there's also the matter of recruitment. As a startup you can handpick people, create a team that's functional and with an edge. In an enterprise, recruiting is done at an industrial scale, where your inbound fresh flesh exposes you to the simple truth that, by definition, half of humanity is below the mean.