My goto example of a dysfunctional and bureaucratic organization is an example I saw in a finance company I worked for.
I was a on team that we were doing a major project. We basically ran Kanban but had to run "sprints" so we chose 4 week sprints to get it out of the way and we put everything on the board we had to get done that month to stay on track. Our pipeline was setup in such a way that you were required to have a jira ticket to push a commit. We were really crushing our timeline, doing 2x the work we were expected, a really great team honestly. But we opened up bugs and additional features in the middle of our sprints to track our work as we did it.
What this amounted to was maybe us saying we have to do 40 tickets this month, and wed be closing like 80. Everyone should have been thrilled by this development! Well we had a sprint review where some "Senior Project Manager" That wasn't really affiliated with our project but was some manager higher up was mad that us opening up new tickets mid sprint and closing them was ruining the org level burn down charts and expected delivery. They wouldn't give up on this, and said it was our fault for not estimating better (which sure, but we were beating expectations!). So we did the reasonable thing and improved our estimates! No of course not, we doubled our number of tickets and filled in "placeholder" on half of them, and used them as needed then closed everything out at the end of the sprint, where we were congratulated by everyone for our phenomonal estimation.
I also work at a large financial institution and have had many similar situations. Fortunately, I'm the one in charge (team lead of sorts) and I have a pretty standard response to such "high level" nonsense:
"Your inability to adequately track my team's weekly or monthly performance is not my problem."
Every "project" has plans, deliverables, and due dates and those are the ultimate arbiters of a team's performance. Not the weekly/monthly statistics! If we open 10 or 10,000 tickets it makes no difference. It's entirely arbitrary and only carries meaning for the team in question (not upper management).
Like some high-level manager/PM is going to be able to make any difference whatsoever on some software development task by watching weekly Jira ticket statistics. Sounds like they're giving themselves busywork to justify their role. Because having fancy charts and statistics at meetings of managers makes you look like you know what you're doing (LOL).
That is amazing. I worked with a (different?) finance company that did the same thing - every team was judged on their burndown charts.
From what I saw, it did no good. Teams simply did not use tickets to track work. If a story surfed sprints, its “ticket” was closed at the end of one sprint and a new one was opened for next. If a priority bug came in mid-sprint, we simply worked on it without a ticket.
I have seen this multiple times before. Management chastising good work because some externality of that work shows up on a graph that they have to talk about at some weekly meeting. It doesn't even have to make the graph look bad, just stick out.
I am dealing with this as a Senior Product Manager, explaining to execs, and defending my engineers when they started introducing metrics, and one of the keys was "Planned points delivered".
My team gets and triages all the escalated bugs.
It's not accurate, not fair, and demoralizing for that team to be "red" because the metrics look like: "Story Points Planned: 30. Planned points delivered: 5." when they delivered bug fixes on what amounted to 20-30 unplanned points.
"If they have to do that work, they need to get credit for it, planned or not. You can't have work that is required but counts for nothing in KPIs".
The issue of HOW MUCH unplanned work is being required is a separate and valid discussion, but not in the realm of "engineering cadence/velocity".
It's funny that my anecdote also comes from a kanban team, but amongst mostly waterfall people and one Scrum nutjob.
When you are showing people up they throw the book at you. Yes you're getting a lot done but you're cutting corners so that's cheating! In an org that is perpetually behind schedule they rely on one team being a scapegoat for why all the other teams are behind schedule, and when your team has never been more than 10 days behind it stings.
One of my proudest moments on that project was when I figured out a judo move to meet (and exceed) the documentation requirements for our part of the project with less than 3 man hours per milestone after I got it working (and half of that was typesetting fixes by one of our tech writers). I got the impression that the person who called it out was really hoping it would cost us 20-60 hours per milestone. I think I spent about 30 hours total, including the initial set up time for the tools and templates. So their gambit only worked for a single milestone and then it was back to the races.
> we had a sprint review where some "Senior Project Manager" That wasn't really affiliated with our project but was some manager higher up was mad that us opening up new tickets mid sprint and closing them was ruining the org level burn down charts and expected delivery.
This is giving me flashbacks of a company I worked for (for a very short period of time).
For some reason, they decided that planning accuracy was the most important metric for the software organization. This was the headline metric they talked about in executive meetings and it was primarily how the program managers' bonus structure was determined.
So everything in the company revolved around planning accuracy. Opening new tickets within a sprint was strongly discouraged. Doing work from the next sprint was heavily discouraged. Trying to take on big projects within a sprint was heavily discouraged, because if you couldn't 100% guarantee that it would be done by the end of the sprint it posed an existential threat to the Program Managers' charts, and therefore their bonuses.
Program Managers wouldn't come out and say any of this, of course. They knew the situation was at odds with delivering software quickly. However, if you deviated from the plan they would pull you into meeting after meeting for hours and hours to try to keep you in line.
If you opened a new ticket mid-sprint, you'd get pulled into meetings with Program Managers to justify it. They'd argue and debate and cajole you into deleting the ticket and rolling it into something halfway related. They'd CC your manager on 5 different e-mails and check in multiple times a day to make sure you'd fallen in line. It was hell.
Weirdest part to me was how many people around me seemed to enjoy that structure. They recognized the game and gladly played along, delivering a couple hours of work each day and then sitting in meetings to talk about it for the rest of the time.
It all came crashing down about 18 months in, when management brought in someone who actually understood software development and started actually looking into what people were doing. I was gone by then, but they went slash and burn on the remaining department. They cut it down to 1/5th of the size and started delivering, as far as I can tell, the same amount of work.
>we doubled our number of tickets and filled in "placeholder" on half of them, and used them as needed then closed everything out at the end of the sprint
Seems like someone has become aware of the power of liquidity and delayed decision making giving one the ability to respond to future information.
I like how the response was "falsify the metric data" because an ape in a suit somewhere demanded a "correct" metric. And were rewarded for their falsification. There's an Aesop's Fables story in there somewhere. I wonder how many metrics people depend on, like jobs data, get the "change the data" to suit ape in suit's needs?
> Everyone should have been thrilled by this development! Well we had a sprint review where some "Senior Project Manager" That wasn't really affiliated with our project but was some manager higher up was mad that us opening up new tickets mid sprint and closing them was ruining the org level burn down charts and expected delivery.
Why should they be thrilled that you were running on Kanban but claiming to do otherwise and therefore ruining the burn down charts?
I experienced something like this for many years across several of the big five defense contractors and smaller SBIR contractors working for the US DoD and IC. As someone who 20 years ago had a slightly better understanding of how computers and networks actually work than an average developer and was comfortable at the command line in an era when juniors increasingly couldn't leave their IDE without becoming hopelessly lost, as DevOps, SRE, and platform engineering started to become things, my career drifted in that direction.
The problem being on teams like that was always the same. You're responsible for developing software products of some sort, but they're software that runs, tests, or delivers other software or even orchestrates the operations of an entire environment shared by many different applications. This inevitably means a whole lot of your work is the classic incident response/post-mortem of operations, plus some level of customer support given to other development teams because internal platform teams never get a separate support organization. To this day, the government has no idea how to handle this in light of how DFARS (administrative law governing acquisition) works.
Every labor hour a contractor charges has to be tied to a specific line of accounting which is itself tied to some unit of planned work tracked in an issue tracker or project management system of some sort. Most of the time, this is an Epic in Jira. This is logical insofar as you consider the intention of acquisition as a category of appropriations bill. A budget proposal with line items tied to measurable product features is presented to and approved by Congress. You have to demonstrate you're spending the money they gave you on what they approved you to spend it on, because per the Constitution, that's how power of the purse works. The executive branch can't just do whatever it wants.
But it falls apart as contractor labor increasingly replaces federal civil servants. When your job is anywhere from half to all running and maintaining an operational system, that isn't really acquisitions any more. It's operations and maintenance, which is an entirely separate appropriation. Soldiers manning a defensive perimeter have no idea when they're going to be attacked or how much work they'll be putting in. Software operations is effectively just the less lethal civilian equivalent of that. The government arguably even recognizes this in many ways. Typically, running and maintaining the production system is a separate contract from the development contract and it uses separate work tracking systems, and if someone spends 8 hours watching a screen while producing no quantifiable work outputs, so be it. They charge 8 hours because that's what the contract says they're supposed to do.
But as we're increasingly expected to be modern software organizations with things like CI/CD, test and staging environments, and you inevitably need to run at least some of your own development infrastructure, well now what? You have a lot of people whose job is the same. Be on constant lookout and respond as needed, but now it's part of a development contract and they need to have quantifiable work outputs that be tied to a budgetary line item with an associated product feature.
So we convolute nonsense out of thin air like cloning the same monthly "Support" Epic in Jira, month after month. "As a developer, I want my tooling to work so I can do my job and deliver value to the government." Plug in some SWAG number vaguely guessed at based on how much of this kind of work you ended up doing last year. Every 90 days, play planning poker with it. LARP a product team even though that isn't what you are.
>No of course not, we doubled our number of tickets and filled in "placeholder" on half of them, and used them as needed then closed everything out at the end of the sprint, where we were congratulated by everyone for our phenomonal estimation.
Are you sure this is a negative example? You even have a work around which makes everyone happy.
This isn't what a dysfunctional organization looks like.
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.
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.
> 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.)
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.
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.
> 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.
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?
> 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".
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).
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.
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.
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.
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.
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.
Last year, an Innovation Hero championed a completely new build system based on their homegrown version of asdf, essentially.
I was the one who had to stay late multiple Fridays making sure our Formal Builds would still work. I've been working to roll back the least well executed portions of this innovation for the past year because it doubled the amount of time required to release our software in the last stages of the pipeline (which was already five days, another rant, I work at VeryBigCo on a mixed HW/SW product).
I believe in this story the entrepreneur referenced worked to clear all similar hurdles, but it's hard to feel bad for folks who view themselves as Innovation Heroes when in many cases they're applying solutions in search of a problem. It's also very not fun to be "that person" aka "The Adult in the Room".
Yes, today the "Innovation" is part of our processes, but in stripped down form and it cost us two missed formal builds with the corresponding loss of credibility in our customer's eyes... in addition to my own sour grapes and missed dinners with my kid. It also cost me a personal friendship with the hero (my fault, but it's really hard for me to get past the fact this individual put their ego over my time with my family).
Agree it's a sign of a dysfunctional organization but it goes both ways. As an Innovation Hero, you should be aghast at how inefficient your org is, but as a part of that org, you should stop and ask, "How did we get this way and am I sure my solution truly solves all aspects of this situation?"
A long time ago I burned out and took a few years of leave from tech and instead took a document processing / generation job at a very large non tech travel / leisure focused company. Company used an archaic document generation system that had to have templates built by hand. then there was a significant amount of manual work moving data from microsoft excel to word. All Manual. My group consisted of myself, 4 other document processors, 2 leads and a director.
This team generated all of the sales documents for the company; thousands of templates.
Within weeks I wrote some VBA macros that automated 75% of the process and they promoted me to manager a couple months later.
What I found fascinating though was the group of existing document specialists were not suddenly capable of doing 2 - 3x the work. They just appeared to move slower. It was like pulling blood from a stone. They had no interest in learning new work which they were now free to do, they just wanted to clock in, turn their mind off for 8 hours, click the button and clock out.
40% of the staff at large companies are likely not needed and can be automated away.
> What I found fascinating though was the group of existing document specialists were not suddenly capable of doing 2 - 3x the work. They just appeared to move slower. It was like pulling blood from a stone. They had no interest in learning new work which they were now free to do, they just wanted to clock in, turn their mind off for 8 hours, click the button and clock out.
The ability to barely function and slowly grind was what made them good at the job. Either they were hired for those "aptitudes" or they developed them on the job. what did you expect?
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!
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.
Counterpoint: most innovation sucks. Sure, innovation is necessary for improvement and adaptation to changing circumstances. Sure, sometimes innovative change is stifled to the point that organizations crumble under the stasis. But the larger and more stable the organization, the higher the bar should be between “I have a great idea that will make things better!” and its implementation. Most ideas of change do not take into account the complex, multiplicitous, overlapping, crossed-purpose systems that conspire to bring an organization to life. They account for only locally perceived changes, not weird, unpredictable knock-on effects that can arise from introducing an optimization. Adopting every ostensible innovation that comes along is inviting only chaos. Change should be hard. Not impossible, but hard.
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.
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".
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.
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.
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).
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.
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.
>> 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.
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.
The thing is there's a lot of dysfunctional organizations, and being an innovation hero is an easier and more fun career path than fixing dysfunctional organizations, which seems (as someone that only half-heartedly tries to keep insane decisions from the top from ruining things) to not necessarily be possible; there are often hidden agendas and people more interested in their cash out than the viability of the organization long term.
[+] [-] ecshafer|1 year ago|reply
I was a on team that we were doing a major project. We basically ran Kanban but had to run "sprints" so we chose 4 week sprints to get it out of the way and we put everything on the board we had to get done that month to stay on track. Our pipeline was setup in such a way that you were required to have a jira ticket to push a commit. We were really crushing our timeline, doing 2x the work we were expected, a really great team honestly. But we opened up bugs and additional features in the middle of our sprints to track our work as we did it.
What this amounted to was maybe us saying we have to do 40 tickets this month, and wed be closing like 80. Everyone should have been thrilled by this development! Well we had a sprint review where some "Senior Project Manager" That wasn't really affiliated with our project but was some manager higher up was mad that us opening up new tickets mid sprint and closing them was ruining the org level burn down charts and expected delivery. They wouldn't give up on this, and said it was our fault for not estimating better (which sure, but we were beating expectations!). So we did the reasonable thing and improved our estimates! No of course not, we doubled our number of tickets and filled in "placeholder" on half of them, and used them as needed then closed everything out at the end of the sprint, where we were congratulated by everyone for our phenomonal estimation.
[+] [-] riskable|1 year ago|reply
"Your inability to adequately track my team's weekly or monthly performance is not my problem."
Every "project" has plans, deliverables, and due dates and those are the ultimate arbiters of a team's performance. Not the weekly/monthly statistics! If we open 10 or 10,000 tickets it makes no difference. It's entirely arbitrary and only carries meaning for the team in question (not upper management).
Like some high-level manager/PM is going to be able to make any difference whatsoever on some software development task by watching weekly Jira ticket statistics. Sounds like they're giving themselves busywork to justify their role. Because having fancy charts and statistics at meetings of managers makes you look like you know what you're doing (LOL).
[+] [-] apozem|1 year ago|reply
From what I saw, it did no good. Teams simply did not use tickets to track work. If a story surfed sprints, its “ticket” was closed at the end of one sprint and a new one was opened for next. If a priority bug came in mid-sprint, we simply worked on it without a ticket.
[+] [-] tokyolights2|1 year ago|reply
[+] [-] FireBeyond|1 year ago|reply
My team gets and triages all the escalated bugs.
It's not accurate, not fair, and demoralizing for that team to be "red" because the metrics look like: "Story Points Planned: 30. Planned points delivered: 5." when they delivered bug fixes on what amounted to 20-30 unplanned points.
"If they have to do that work, they need to get credit for it, planned or not. You can't have work that is required but counts for nothing in KPIs".
The issue of HOW MUCH unplanned work is being required is a separate and valid discussion, but not in the realm of "engineering cadence/velocity".
[+] [-] hinkley|1 year ago|reply
When you are showing people up they throw the book at you. Yes you're getting a lot done but you're cutting corners so that's cheating! In an org that is perpetually behind schedule they rely on one team being a scapegoat for why all the other teams are behind schedule, and when your team has never been more than 10 days behind it stings.
One of my proudest moments on that project was when I figured out a judo move to meet (and exceed) the documentation requirements for our part of the project with less than 3 man hours per milestone after I got it working (and half of that was typesetting fixes by one of our tech writers). I got the impression that the person who called it out was really hoping it would cost us 20-60 hours per milestone. I think I spent about 30 hours total, including the initial set up time for the tools and templates. So their gambit only worked for a single milestone and then it was back to the races.
[+] [-] Aurornis|1 year ago|reply
This is giving me flashbacks of a company I worked for (for a very short period of time).
For some reason, they decided that planning accuracy was the most important metric for the software organization. This was the headline metric they talked about in executive meetings and it was primarily how the program managers' bonus structure was determined.
So everything in the company revolved around planning accuracy. Opening new tickets within a sprint was strongly discouraged. Doing work from the next sprint was heavily discouraged. Trying to take on big projects within a sprint was heavily discouraged, because if you couldn't 100% guarantee that it would be done by the end of the sprint it posed an existential threat to the Program Managers' charts, and therefore their bonuses.
Program Managers wouldn't come out and say any of this, of course. They knew the situation was at odds with delivering software quickly. However, if you deviated from the plan they would pull you into meeting after meeting for hours and hours to try to keep you in line.
If you opened a new ticket mid-sprint, you'd get pulled into meetings with Program Managers to justify it. They'd argue and debate and cajole you into deleting the ticket and rolling it into something halfway related. They'd CC your manager on 5 different e-mails and check in multiple times a day to make sure you'd fallen in line. It was hell.
Weirdest part to me was how many people around me seemed to enjoy that structure. They recognized the game and gladly played along, delivering a couple hours of work each day and then sitting in meetings to talk about it for the rest of the time.
It all came crashing down about 18 months in, when management brought in someone who actually understood software development and started actually looking into what people were doing. I was gone by then, but they went slash and burn on the remaining department. They cut it down to 1/5th of the size and started delivering, as far as I can tell, the same amount of work.
[+] [-] imtringued|1 year ago|reply
Seems like someone has become aware of the power of liquidity and delayed decision making giving one the ability to respond to future information.
[+] [-] araes|1 year ago|reply
[+] [-] siva7|1 year ago|reply
Why should they be thrilled that you were running on Kanban but claiming to do otherwise and therefore ruining the burn down charts?
[+] [-] nonameiguess|1 year ago|reply
The problem being on teams like that was always the same. You're responsible for developing software products of some sort, but they're software that runs, tests, or delivers other software or even orchestrates the operations of an entire environment shared by many different applications. This inevitably means a whole lot of your work is the classic incident response/post-mortem of operations, plus some level of customer support given to other development teams because internal platform teams never get a separate support organization. To this day, the government has no idea how to handle this in light of how DFARS (administrative law governing acquisition) works.
Every labor hour a contractor charges has to be tied to a specific line of accounting which is itself tied to some unit of planned work tracked in an issue tracker or project management system of some sort. Most of the time, this is an Epic in Jira. This is logical insofar as you consider the intention of acquisition as a category of appropriations bill. A budget proposal with line items tied to measurable product features is presented to and approved by Congress. You have to demonstrate you're spending the money they gave you on what they approved you to spend it on, because per the Constitution, that's how power of the purse works. The executive branch can't just do whatever it wants.
But it falls apart as contractor labor increasingly replaces federal civil servants. When your job is anywhere from half to all running and maintaining an operational system, that isn't really acquisitions any more. It's operations and maintenance, which is an entirely separate appropriation. Soldiers manning a defensive perimeter have no idea when they're going to be attacked or how much work they'll be putting in. Software operations is effectively just the less lethal civilian equivalent of that. The government arguably even recognizes this in many ways. Typically, running and maintaining the production system is a separate contract from the development contract and it uses separate work tracking systems, and if someone spends 8 hours watching a screen while producing no quantifiable work outputs, so be it. They charge 8 hours because that's what the contract says they're supposed to do.
But as we're increasingly expected to be modern software organizations with things like CI/CD, test and staging environments, and you inevitably need to run at least some of your own development infrastructure, well now what? You have a lot of people whose job is the same. Be on constant lookout and respond as needed, but now it's part of a development contract and they need to have quantifiable work outputs that be tied to a budgetary line item with an associated product feature.
So we convolute nonsense out of thin air like cloning the same monthly "Support" Epic in Jira, month after month. "As a developer, I want my tooling to work so I can do my job and deliver value to the government." Plug in some SWAG number vaguely guessed at based on how much of this kind of work you ended up doing last year. Every 90 days, play planning poker with it. LARP a product team even though that isn't what you are.
[+] [-] constantcrying|1 year ago|reply
Are you sure this is a negative example? You even have a work around which makes everyone happy.
This isn't what a dysfunctional organization looks like.
[+] [-] Jun8|1 year ago|reply
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|1 year ago|reply
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.
[+] [-] specialist|1 year ago|reply
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.
[+] [-] jmull|1 year ago|reply
> 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.)
[+] [-] novagameco|1 year ago|reply
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.
[+] [-] JohnMakin|1 year ago|reply
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.
[+] [-] theideaofcoffee|1 year ago|reply
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.
[+] [-] btbuildem|1 year ago|reply
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.
[+] [-] adrianmonk|1 year ago|reply
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.
[+] [-] tredigi|1 year ago|reply
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?
[+] [-] adverbly|1 year ago|reply
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".
[+] [-] dekhn|1 year ago|reply
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).
[+] [-] nutrie|1 year ago|reply
[+] [-] laidoffamazon|1 year ago|reply
My theory for why Google is different remains unpopular, however.
[+] [-] loceng|1 year ago|reply
[+] [-] debacle|1 year ago|reply
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.
[+] [-] justin_oaks|1 year ago|reply
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...
[+] [-] shermantanktop|1 year ago|reply
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.
[+] [-] nlawalker|1 year ago|reply
[+] [-] anders30|1 year ago|reply
I was the one who had to stay late multiple Fridays making sure our Formal Builds would still work. I've been working to roll back the least well executed portions of this innovation for the past year because it doubled the amount of time required to release our software in the last stages of the pipeline (which was already five days, another rant, I work at VeryBigCo on a mixed HW/SW product).
I believe in this story the entrepreneur referenced worked to clear all similar hurdles, but it's hard to feel bad for folks who view themselves as Innovation Heroes when in many cases they're applying solutions in search of a problem. It's also very not fun to be "that person" aka "The Adult in the Room".
Yes, today the "Innovation" is part of our processes, but in stripped down form and it cost us two missed formal builds with the corresponding loss of credibility in our customer's eyes... in addition to my own sour grapes and missed dinners with my kid. It also cost me a personal friendship with the hero (my fault, but it's really hard for me to get past the fact this individual put their ego over my time with my family).
Agree it's a sign of a dysfunctional organization but it goes both ways. As an Innovation Hero, you should be aghast at how inefficient your org is, but as a part of that org, you should stop and ask, "How did we get this way and am I sure my solution truly solves all aspects of this situation?"
[+] [-] wonderwonder|1 year ago|reply
This team generated all of the sales documents for the company; thousands of templates.
Within weeks I wrote some VBA macros that automated 75% of the process and they promoted me to manager a couple months later.
What I found fascinating though was the group of existing document specialists were not suddenly capable of doing 2 - 3x the work. They just appeared to move slower. It was like pulling blood from a stone. They had no interest in learning new work which they were now free to do, they just wanted to clock in, turn their mind off for 8 hours, click the button and clock out.
40% of the staff at large companies are likely not needed and can be automated away.
Kind of made me feel sad.
[+] [-] drewcoo|1 year ago|reply
The ability to barely function and slowly grind was what made them good at the job. Either they were hired for those "aptitudes" or they developed them on the job. what did you expect?
[+] [-] EncomLab|1 year ago|reply
[+] [-] quesera|1 year ago|reply
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!
[+] [-] solatic|1 year ago|reply
> 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.
[+] [-] obelos|1 year ago|reply
[+] [-] adolph|1 year ago|reply
“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...
[+] [-] setgree|1 year ago|reply
If you want to get a government agency to perform better, fix the incentives.
[+] [-] MeetingsBrowser|1 year ago|reply
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".
[+] [-] betenoire|1 year ago|reply
[+] [-] toomuchtodo|1 year ago|reply
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)
[+] [-] kurthr|1 year ago|reply
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).
[+] [-] tredigi|1 year ago|reply
[+] [-] lawlessone|1 year ago|reply
This reminds of that.
[+] [-] ghaff|1 year ago|reply
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.
[+] [-] MichaelRo|1 year ago|reply
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.
[+] [-] nathan_compton|1 year ago|reply
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.
[+] [-] lanstin|1 year ago|reply