There are two schools of thought in technology development.
School one is the tech development is full of little robots working at little stations. Your job is to optimize the robots, work, queues, and pathways in order to optimize flow. In this school, tech development is a big factory. Ideas come in on one side, finished tech goes outside on the other. You can see this in Product Development in “The Principles of Product Development Flow”. For DevOps the keystone book is probably “The Goal”. DevOps even goes so far as to literally call the thing a “pipeline” I guess we should be lucky nobody used the phrase “conveyor belt”
School two is that tech development is all about scoping, identifying, and understanding a problem well enough that it “goes away”, ie, computers do everything and people are free. In this school, you want to kill the robots, the flow, the workstations, and the rest of it. The more complicated it is, the more complicated it is. And it’ll only get worse. Tech development is about combining creativity, logic, and problem-solving. It’s nothing like building Toyotas at all. We’re destroying the factory, not trying to make it run better.
Traditional managers, directors, and C-level folks are all taught school one. After all, they couldn’t understand or do school two even if they wanted to. So whatever BigCorp you’re in, you’re most likely going to be stuck in some kind of Toyota Production System knockoff. Sometimes it doesn’t hurt too much, but it’s always suboptimal. Building cars ain’t creating new tech solutions. It never will be.
And if you’re a cofounder of a bootstrapped product company, it seems obvious to me that you should implement school two all the way. Any recommended resources for learning to do this?
Anecdotes follow, but I’d love to here data both for and against!
They forget the art of engineering. The science is supposed to be repeatable, but the art is knowing what will be easy to enhance and maintain, while also being satisfying to work on so that you don’t encounter negative emotion turnover.
You also have to factor in “wanderlust” that occurs from doing the same basic thing for a while. Be ready for your team members to just get bored with what they’re doing, and encourage them to branch out and move!
Generally speaking, the teams I led this way would be more relaxed, didn’t have to work nights and weekends, and were CONSISTENTLY better and faster than the “people are robots driven by arbitrary quotas and dates” crews.
Any time someone started throwing out constant arbitrary fixed goals, we did better when I REFUSED to dump that pressure on the team. If they’re possible to hit, they’ll get hit whether we focus on the random date or not. Most of the time arbitrary quotas/dates make people rush to the quota and stop when they hit it, or slack until the date looms and rush to hit it. In both cases quality or cost suffers.
Anecdotes follow, but I’d love to here data both for and against!
They forget the art of engineering. The science is supposed to be repeatable, but the art is knowing what will be easy to enhance and maintain, while also being satisfying to work on so that you don’t encounter negative emotion turnover.
You also have to factor in “wanderlust” that occurs from doing the same basic thing for a while. Be ready for your team members to just get bored with what they’re doing, and encourage them to branch out and move!
Generally speaking, the teams I led this way would be more relaxed, didn’t have to work nights and weekends, and were CONSISTENTLY better and faster than the “people are robots driven by arbitrary quotas and dates” crews.
Any time someone started throwing out constant arbitrary fixed goals, we did better when I REFUSED to dump that pressure on the team. If they’re possible to hit, they’ll get hit whether we focus on the random date or not. Most of the time arbitrary quotas/dates make people rush to the quota and stop when they hit it, or slack until the date looms and rush to hit it. In both cases quality or cost suffers.
Grabbing some system from a different field and trying to apply it whole cloth to programming while missing the point and failing to recognize where things don’t match is a long tradition in the field. Design patterns are the biggest other example that comes to mind. I think it’s “real engineering” envy.
The really important idea, which goes back to Deming, who taught it to the Japanese manufacturers after WWII, was that people work in a system. That system accounts for most of their performance or lack thereof. It has random variation. And you should be looking at the system and thinking about how to make it better.
There are bits and pieces that are sometimes useful. From Goldratt, we get the idea of looking at unshipped code as a cost we are bearing, but chasing bottlenecks is rarely that helpful. From lean, standardized work lists are a really useful tool because we can look at them and say, “This is nuts” and automate large hunks of it, and having easy to track and update visuals of what’s going on (kanban) are a big help as long as we don’t try to imitate the particular visual representations of a factory floor. So it’s worth reading all this stuff, but only as a source of ideas. No one should expect the systems to directly translate.
Thanks for sharing this. It’s the first time I’ve ever heard from someone who reports the Toyota Production System as anything short of utopic. The only objections I have heard to “kanban” or “katas” are that using the terms the way we do is an act of cultural appropriation. This set of complaints is one that I’d never heard or considered before.
Does anyone have examples of the kind of Toyota-worshipping devops discussion the post is complaining about?
I’ve read a lot of material about agile methodologies in software, and aside from books and articles that are specifically focused on the historical roots of agile practices, I don’t think I’ve ever seen one that lingers on the specifics of Toyota’s processes for long enough to warrant a reaction this strong. Usually Toyota gets a paragraph or two at most before the author moves on, and it’s often just a sentence or two.
You will find much of buried in corporate training material. To this day I hate Toyota cars for no reason other than that their stupid logo was practically on the first slide of every agile course I had no choice but to attend gladly attended of my own volition between 2009 and 2014 or so.
Ah, that explains it. My only exposure to corporate training material about agile processes has been in the form of writing it as part of dev onboarding documentation.
I hear it mentioned in many of the devops books, articles, blogs, videos I’ve consumed. I can’t give you an exhaustive list but it’s mentioned for sure in The DevOps Handbook, and (I think) Jez Humble’s other books, which are probably the most popular in the field. Here’s another blogger who I’ve heard talk about it in multiple articles/reviews.
Toyota love in devops is definitely a real phenomenon.
I am confused by this post. It seems to go all over the place from mentioning “DevOps” (probably in the current marketing speak sense, no details though instead of the original meaning), going into detail for lean and Toyota and ending with a link to the Agile Manifesto. I’m not sure if it’s criticizing the right thing with the wrong labels or if it’s about the wrong things. I also never personally experienced this Toyota process worshipping, not even in the hey day of Agile, before DevOps even was a thing! Kanban is useful, but it’s a tool with a few criteria, not a philosophy of life. (Well, it shouldn’t be.)
I really enjoyed the distinction between tatemae (marketing masking as idealism) and honne (reality). It’s a dynamic you see especially in somewhat larger corporations. People just quietly work at a place but don’t buy the management story while speaking in a way that seems like they actually do, because you’d be considered “not a team player” when going counter to the proposed idealism. And then, of course, they suddenly quit.
I don’t know much about it, but according to the Wikipedia article about these terms, it’s quite fundamental to Japanese culture. Fascinating!
There’s a three year waiting list on Landcruiser, it’s so bad the company had to abandon the US market entirely for that model. The Supra is 80% BMW parts. These are their two flagship models. Tell me again about how we should ape their production models.
That’s pretty much the case across most manufacturers these days, isn’t it? Lots of higher end, especially EVs have a massive waiting list, coming from a number of issues over the last few years.
Our industry is full of false prophets who advertise flashy ideas. Maybe it’s inevitable: large software projects are so big, and (typically) so secretive, that no one can have deep experience with more than a handful in a lifetime, and no one is really collecting global statistics to get any perspective on which practices work. But many companies are willing to pay for slick-sounding advice that promises to solve their problems.
It’s not about having happy workers. We need to get to the point where our tools and processes are so easy, we don’t need to do them anymore. To get there, the Toyota procedures will do just fine. And once we are there, our jobs are done even as the work we’ve done will continue.
There are two schools of thought in technology development.
School one is the tech development is full of little robots working at little stations. Your job is to optimize the robots, work, queues, and pathways in order to optimize flow. In this school, tech development is a big factory. Ideas come in on one side, finished tech goes outside on the other. You can see this in Product Development in “The Principles of Product Development Flow”. For DevOps the keystone book is probably “The Goal”. DevOps even goes so far as to literally call the thing a “pipeline” I guess we should be lucky nobody used the phrase “conveyor belt”
School two is that tech development is all about scoping, identifying, and understanding a problem well enough that it “goes away”, ie, computers do everything and people are free. In this school, you want to kill the robots, the flow, the workstations, and the rest of it. The more complicated it is, the more complicated it is. And it’ll only get worse. Tech development is about combining creativity, logic, and problem-solving. It’s nothing like building Toyotas at all. We’re destroying the factory, not trying to make it run better.
Traditional managers, directors, and C-level folks are all taught school one. After all, they couldn’t understand or do school two even if they wanted to. So whatever BigCorp you’re in, you’re most likely going to be stuck in some kind of Toyota Production System knockoff. Sometimes it doesn’t hurt too much, but it’s always suboptimal. Building cars ain’t creating new tech solutions. It never will be.
And if you’re a cofounder of a bootstrapped product company, it seems obvious to me that you should implement school two all the way. Any recommended resources for learning to do this?
Anecdotes follow, but I’d love to here data both for and against!
They forget the art of engineering. The science is supposed to be repeatable, but the art is knowing what will be easy to enhance and maintain, while also being satisfying to work on so that you don’t encounter negative emotion turnover.
You also have to factor in “wanderlust” that occurs from doing the same basic thing for a while. Be ready for your team members to just get bored with what they’re doing, and encourage them to branch out and move!
Generally speaking, the teams I led this way would be more relaxed, didn’t have to work nights and weekends, and were CONSISTENTLY better and faster than the “people are robots driven by arbitrary quotas and dates” crews.
Any time someone started throwing out constant arbitrary fixed goals, we did better when I REFUSED to dump that pressure on the team. If they’re possible to hit, they’ll get hit whether we focus on the random date or not. Most of the time arbitrary quotas/dates make people rush to the quota and stop when they hit it, or slack until the date looms and rush to hit it. In both cases quality or cost suffers.
Anecdotes follow, but I’d love to here data both for and against!
They forget the art of engineering. The science is supposed to be repeatable, but the art is knowing what will be easy to enhance and maintain, while also being satisfying to work on so that you don’t encounter negative emotion turnover.
You also have to factor in “wanderlust” that occurs from doing the same basic thing for a while. Be ready for your team members to just get bored with what they’re doing, and encourage them to branch out and move!
Generally speaking, the teams I led this way would be more relaxed, didn’t have to work nights and weekends, and were CONSISTENTLY better and faster than the “people are robots driven by arbitrary quotas and dates” crews.
Any time someone started throwing out constant arbitrary fixed goals, we did better when I REFUSED to dump that pressure on the team. If they’re possible to hit, they’ll get hit whether we focus on the random date or not. Most of the time arbitrary quotas/dates make people rush to the quota and stop when they hit it, or slack until the date looms and rush to hit it. In both cases quality or cost suffers.
This was posted as a dupe of the parent. Consider deleting.
Grabbing some system from a different field and trying to apply it whole cloth to programming while missing the point and failing to recognize where things don’t match is a long tradition in the field. Design patterns are the biggest other example that comes to mind. I think it’s “real engineering” envy.
The really important idea, which goes back to Deming, who taught it to the Japanese manufacturers after WWII, was that people work in a system. That system accounts for most of their performance or lack thereof. It has random variation. And you should be looking at the system and thinking about how to make it better.
There are bits and pieces that are sometimes useful. From Goldratt, we get the idea of looking at unshipped code as a cost we are bearing, but chasing bottlenecks is rarely that helpful. From lean, standardized work lists are a really useful tool because we can look at them and say, “This is nuts” and automate large hunks of it, and having easy to track and update visuals of what’s going on (kanban) are a big help as long as we don’t try to imitate the particular visual representations of a factory floor. So it’s worth reading all this stuff, but only as a source of ideas. No one should expect the systems to directly translate.
Thanks for sharing this. It’s the first time I’ve ever heard from someone who reports the Toyota Production System as anything short of utopic. The only objections I have heard to “kanban” or “katas” are that using the terms the way we do is an act of cultural appropriation. This set of complaints is one that I’d never heard or considered before.
Does anyone have examples of the kind of Toyota-worshipping devops discussion the post is complaining about?
I’ve read a lot of material about agile methodologies in software, and aside from books and articles that are specifically focused on the historical roots of agile practices, I don’t think I’ve ever seen one that lingers on the specifics of Toyota’s processes for long enough to warrant a reaction this strong. Usually Toyota gets a paragraph or two at most before the author moves on, and it’s often just a sentence or two.
You will find much of buried in corporate training material. To this day I hate Toyota cars for no reason other than that their stupid logo was practically on the first slide of every agile course I
had no choice but to attendgladly attended of my own volition between 2009 and 2014 or so.Ah, that explains it. My only exposure to corporate training material about agile processes has been in the form of writing it as part of dev onboarding documentation.
I hear it mentioned in many of the devops books, articles, blogs, videos I’ve consumed. I can’t give you an exhaustive list but it’s mentioned for sure in The DevOps Handbook, and (I think) Jez Humble’s other books, which are probably the most popular in the field. Here’s another blogger who I’ve heard talk about it in multiple articles/reviews.
Toyota love in devops is definitely a real phenomenon.
I am confused by this post. It seems to go all over the place from mentioning “DevOps” (probably in the current marketing speak sense, no details though instead of the original meaning), going into detail for lean and Toyota and ending with a link to the Agile Manifesto. I’m not sure if it’s criticizing the right thing with the wrong labels or if it’s about the wrong things. I also never personally experienced this Toyota process worshipping, not even in the hey day of Agile, before DevOps even was a thing! Kanban is useful, but it’s a tool with a few criteria, not a philosophy of life. (Well, it shouldn’t be.)
I really enjoyed the distinction between tatemae (marketing masking as idealism) and honne (reality). It’s a dynamic you see especially in somewhat larger corporations. People just quietly work at a place but don’t buy the management story while speaking in a way that seems like they actually do, because you’d be considered “not a team player” when going counter to the proposed idealism. And then, of course, they suddenly quit.
I don’t know much about it, but according to the Wikipedia article about these terms, it’s quite fundamental to Japanese culture. Fascinating!
We pretend to work. They pretend to pay us.
There are many ideas from Toyota which would be nice to see more often in our line of work. I often think about andon cords.
There’s a three year waiting list on Landcruiser, it’s so bad the company had to abandon the US market entirely for that model. The Supra is 80% BMW parts. These are their two flagship models. Tell me again about how we should ape their production models.
That’s pretty much the case across most manufacturers these days, isn’t it? Lots of higher end, especially EVs have a massive waiting list, coming from a number of issues over the last few years.
Yes. So maybe we shouldn’t be aping their methods.
Our industry is full of false prophets who advertise flashy ideas. Maybe it’s inevitable: large software projects are so big, and (typically) so secretive, that no one can have deep experience with more than a handful in a lifetime, and no one is really collecting global statistics to get any perspective on which practices work. But many companies are willing to pay for slick-sounding advice that promises to solve their problems.
It’s not about having happy workers. We need to get to the point where our tools and processes are so easy, we don’t need to do them anymore. To get there, the Toyota procedures will do just fine. And once we are there, our jobs are done even as the work we’ve done will continue.