In competitive gaming, this explains what David Sirlin calls “scrubs”—players who play by their own made-up rules rather than the true ones, and thus find themselves unprepared to play against people without the same constraints. It isn’t that the scrub is a fundamentally bad or incompetent player—it’s just that they’ve chosen the wrong paradigm, one that greatly limits their ability when they come into contact with the real world.
I suspect that in software development, trying to develop a good, bug-free program makes you a “scrub”. A more reliable path to victory is to quickly make something that can be sold to the customer, and fix it later when necessary. While your competitor develops a bug-free solution, you already own the market. Furthermore, you can spend the money you made to create an improved version 2.0 of your program, so now you have both money and quality. (But maybe even this makes you a “scrub”, and you should be developing another application and taking over yet another market instead.)
This is a really good example of when the organization does gets it right on the big picture, but it seems like they didn’t pick the right paradigm. An observation of mine is that organizations often seem dysfunctional to a lot of participants because they aren’t part of the profit center or privy to the overall strategy. A company can be fully aware of dysfunction or inefficiencies within, and find it acceptable, because fixing it or making someone happy isn’t worth the resources.
Unfortunately, for people who are not members of the inner circle this kind of optimization may be indistinguishable from mere incompetence, or malice. Do we produce sloppy code? Maybe delivering the code fast is more important than the code quality. Do we have an incompetent person on the team? Maybe he or she is a relative of someone important, and it is very important to gain a favor from that person. Did we actually deliver the sloppy code late? Maybe the delay way strategic somehow; maybe the company is paid by hour so delivering the product late was used as an excuse to extract more money from the customer; or maybe it made them more dependent for us; or maybe it was somehow strategically important to deliver it on Thursday. Is the company financially in loss? Maybe the key people are actually transferring company money to their private accounts, so everything goes according to the plan.
I don’t know where is the balance between understanding that there may be some higher strategy that I am not aware of, and simply blindly trusting the authorities (it is easy to rationalize the latter as the former). I guess it is important to notice that the “higher strategy” is not necessarily optimizing in my favor, so in some sense from my point of view there sometimes needs not to be a difference between “it is all going to hell” and “it all goes according to the plan, but a part of the plan is sacrificing me”. That means that unless I trust the secret wisdom and benevolence of the people behind the wheel, I should treat all apparent dysfunction as potentially bad news.
As you say, the inner circle certainly may have reason to do non-obvious things. But while withholding information from people can be occasionally politically helpful, it seems usually best for the company to have the employees on the same page and working toward a goal they see reason for. Because of this, I would usually assume that seemingly poor decisions in upper management are the result of actual incompetence or a deceitful actor in the information flow on the way down.
Broadly agreed—this is one of the main reasons I consider internal transparency to be so important in building effective organizations. in some cases, secrets must exist—but when they do, their existence should itself be common knowledge unless even that must be secret.
In other words, it is usually best to tell your teammates the true reason for something, and failing that you should ideally be able to tell them that you can’t tell them. Giving fake reasons is poisonous.
I suspect that in software development, trying to develop a good, bug-free program makes you a “scrub”. A more reliable path to victory is to quickly make something that can be sold to the customer, and fix it later when necessary.
That’s the lean startup movement is about. Rush for the minimum viable product.
I suspect that in software development, trying to develop a good, bug-free program makes you a “scrub”. A more reliable path to victory is to quickly make something that can be sold to the customer, and fix it later when necessary. While your competitor develops a bug-free solution, you already own the market. Furthermore, you can spend the money you made to create an improved version 2.0 of your program, so now you have both money and quality. (But maybe even this makes you a “scrub”, and you should be developing another application and taking over yet another market instead.)
This is a really good example of when the organization does gets it right on the big picture, but it seems like they didn’t pick the right paradigm. An observation of mine is that organizations often seem dysfunctional to a lot of participants because they aren’t part of the profit center or privy to the overall strategy. A company can be fully aware of dysfunction or inefficiencies within, and find it acceptable, because fixing it or making someone happy isn’t worth the resources.
Unfortunately, for people who are not members of the inner circle this kind of optimization may be indistinguishable from mere incompetence, or malice. Do we produce sloppy code? Maybe delivering the code fast is more important than the code quality. Do we have an incompetent person on the team? Maybe he or she is a relative of someone important, and it is very important to gain a favor from that person. Did we actually deliver the sloppy code late? Maybe the delay way strategic somehow; maybe the company is paid by hour so delivering the product late was used as an excuse to extract more money from the customer; or maybe it made them more dependent for us; or maybe it was somehow strategically important to deliver it on Thursday. Is the company financially in loss? Maybe the key people are actually transferring company money to their private accounts, so everything goes according to the plan.
I don’t know where is the balance between understanding that there may be some higher strategy that I am not aware of, and simply blindly trusting the authorities (it is easy to rationalize the latter as the former). I guess it is important to notice that the “higher strategy” is not necessarily optimizing in my favor, so in some sense from my point of view there sometimes needs not to be a difference between “it is all going to hell” and “it all goes according to the plan, but a part of the plan is sacrificing me”. That means that unless I trust the secret wisdom and benevolence of the people behind the wheel, I should treat all apparent dysfunction as potentially bad news.
As you say, the inner circle certainly may have reason to do non-obvious things. But while withholding information from people can be occasionally politically helpful, it seems usually best for the company to have the employees on the same page and working toward a goal they see reason for. Because of this, I would usually assume that seemingly poor decisions in upper management are the result of actual incompetence or a deceitful actor in the information flow on the way down.
Broadly agreed—this is one of the main reasons I consider internal transparency to be so important in building effective organizations. in some cases, secrets must exist—but when they do, their existence should itself be common knowledge unless even that must be secret.
In other words, it is usually best to tell your teammates the true reason for something, and failing that you should ideally be able to tell them that you can’t tell them. Giving fake reasons is poisonous.
There is a very old essay about that.
That’s the lean startup movement is about. Rush for the minimum viable product.