How to Ruin Your Company With One Bad Process
bhorowitz.com
bhorowitz.com
As an engineer, I love hearing firm constraints from the beginning. The constraints are what breed elegance; there is no such thing as an elegant solution when there is no shape to the problem. It's nice if the constraints are prioritized so you know what to give up if you can't satisfy them all. But there's nothing quite like saying "Yeah, we did this thing in two weeks that everyone assumed was impossible, and we did it without a binary push" or "Through our clever architecture, we accomplished with one server what everyone thought required a whole rack."
I believe design is the same way. The designs I've seen where the dictum is "Let your creativity run wild!" tend to be uninspired, while the ones I've seen where it's "This is what the user is trying to accomplish, and we have a 4 inch screen and 10 seconds to hook them" are often much more creative.
As a manager, the constraints are annoying. But one consequence of that is that setting firm constraints will tend to shift your culture from being manager-centric to being engineer- and designer-centric, which IMHO is a good thing.
I think this is also the reason so many really old-school video games are still not just playable, but can actually (arguably, of course) be even more fun than most of the current-gen eye candy. I'm thinking of Pac-man, Joust, and their ilk. Talk about embracing constraints.
EMBRACE CONSTRAINTS!
"If all our airplanes keep getting japanese bullets in the wings and tail, don't put more armor there--that's were we don't need it. Put it where the airplanes that don't survive get shot." - Abraham Wald
I also think there is a better point to be made about what sorts of constraints produce elegance and which ones are just frustrating and produce hacky workarounds. I think in order to make that point, someone would have to do some engineering history research and some insightful thought to see how an engineer's mindset and a projects constraints interact to produce elegance. I suspect the development of those video games could be a fruitful place to look for that history.
Excerpts:
Interviewer: Does the creation of Design admit constraint?
Eames: Design depends largely on constraints.
Interviewer: What constraints?
Eames: The sum of all constraints. Here is one of the few effective keys to the design problem: the ability of the designer to recognize as many of the constraints as possible, his willingness and enthusiasm for working within these constraints. The constraints of price, size, strength, balance, time and so forth. Each problem has its own peculiar list.
Interviewer: Does Design obey laws?
Eames: Aren’t constraints enough?
[1] http://blog.designersrevolt.com/post/52143068880/the-definit...
Also, their interview set in a beautiful layout by House Ind, sure did help drive the point better - http://eames.houseind.com/objects/catalog.html
It might still be freely available as a catalog to those interested in their products. I highly recommend that one.
Social networks have thrived on obvious constraints. When looking for a startup idea, sometimes I try to reimagine a popular tool or service with additional constraints.
Which is to say that creatively working within hard constraints being a good thing is a universal creative rule, not specific to tech or social networks at all.
So 4chan perfectly fits in the parent's list of social network like things based on arbitrary contraints
But at the earliest stages, when exploring a market and business opportunity, premature constraints can be deadly because they often encourage you to ignore feedback from the market and make assumptions that aren't necessarily correct. The result, in many cases, is that companies end up solving problems that don't exist, or that aren't painful enough to support a real business.
In my experience, there are just as many engineers trying to make their jobs easier (by pushing to constrain scope at all costs) as there are product managers/business owners who aren't very good at defining problems and crafting sensible solutions to them.
Your manager-centric versus engineer-centric comment suggests that managers are inherently less capable of developing solutions to problems than engineers but in reality, the real issue is that there are relatively few product-savvy engineers and relatively few engineering-savvy product managers.
> As an engineer, I love hearing firm constraints from the beginning.
Sure, but note that these two points aren't in conflict. As someone building solutions, of course you want as firm a definition of the problem as possible, and constraints are part of that. But its still a critical failure to over-constrain the problem at the start (or any other time) -- constraints are essentially just a different way of phrasing requirements, and overconstraining a problem is exactly specifying superfluous requirements. Extra, unneeded constraints make the ultimate solution worse, because they mean you are solving the wrong problem -- and a more complicated problem than the one you actually needed to solve.
Well yes tautologies are tautological and all, but the point is that GP and the people agree with it suspect that their definition of "over-constrain" happens way way past where the article's author does.
I totally agree with you on shifting away from manager-centric approaches. I really like the Lean focus on customer value. Out from that center are people who directly add value: line workers, engineers, designers. Managers become necessary overhead (when they're just coordinating) or indrect value-adders (when they're helping tune the processes that actually add value). That's in contrast to the traditional western approach, where managers are bosses, people whose opinions win because they're big kahunas.
Form is liberating.
Constraints (e.g. player class systems) reduce the raw number of choices you can make, but the ones left behind are more interesting and meaningful.
As far as I could see, it seemed to boil down to finding and fixing bottlenecks. Focusing on the critical paths in a process whether project schedules or chip designs is just par for the course. I don't know whether I missed something.
However the truth is that constrains can be broken as long as you realize that doing so has a cost. Taking this into account expands the solutions space hugely, which both means that if you can take advantage of this you might find overall better solutions, while at the same time it can be overwhelming and paralyzing.
Edit to add: sometimes when the solutions space is too big artificially and arbitrarily limiting it might help.
> As a technologist, you know that the worst thing that you can do is over-constrain the problem before you start.
From what I've read on this subject, this is not the worst thing you can do. The absolute worst thing you can do from a creativity standpoint is be completely unconstrained. That "blue sky" thinking leads to a lack of focus that prevents you from coming up with good solutions. The startup mentality of "embracing constraints" is more than just a rationalization that tries to turn a negative into a positive...it's an observation of how to best creatively problem solve.
There's no doubt that over-constraining can also have negative consequences, but if you've got little to no natural constraints, it's almost always best to invent some reasonable constraints prior to diving in and trying to solve the problem. It's okay to document those constraints and, perhaps, make changes if you find the problem you've created to be intractable. But operating without those constraints, whether real or self-imposed, is the absolute worst way to approach any creative problem solving endeavor.
Of course, art is also about breaking out of those constraints and creating new mediums. But that seems more about finding a new set of constraints rather than eliminating them entirely. Decide to break free from the canvas and paint an entire mountainside? Great, now you have to consider things like the angles from which you can see the work, the way the lighting will fall, how long you have to complete the work and show people before the work succumbs to the weather, etc.
So I agree that creativity is strongest when operating within constraints.
Ice sculpting, for instance, isn't defined by a lack of clay; they're defined by a block of ice, ice-shaving tools, and a will to apply imagination.
And... you're less likely to get me to go "but graphic novels!" or "but opening textual narration!" and so on.
I've seen this problem in organizations many times. When you do bottom-up organization design, the most persuasive people win. Then people start justifying promotions and pay based on the size of their teams. And those who were more disciplined in the process lose, because they could have done more with more people, just optimally.
The other perverse side effect of this is some people who are great with 4-5 people teams (good player-coaches) are disasters as the head of 30 person organizations. Their style doesn't scale, but they feel the need to grow because of the poor incentives.
This type of issue comes up in consulting quite a bit, where "Fees managed" can be the key metric rather than "Customer ROI" or "Customer Satisfaction."
This is a great point (although I hate the term "headcount"). It takes time to get engineers up to speed in any organization, and it usually cuts into the productive time of current engineers.
*On average.
My interpretation of Brooks' observation on second systems is that they're what happens when the first system has been enough of a success to give people a relatively free hand to solve problems with it - so they try to solve all the things and wind up with an over-ambitious and unusable system, from which a pared-back third system emerges.
It talks about allocating memory to the various components of the OS. It begins with a delightfully outdated section on the cost of memory: if the OS weighs 400ko it costs the user $4800 per month when renting just for that memory!
His take-aways on allocating a limited resource (memory here but it could be $) are:
* Budget every aspect, not just the resource itself. Otherwise implementers will end up swapping to disk to respect the limit, killing performances.
* Define what must be achieved along with the budget. Otherwise things will be thrown over the fence to a neighbour.
* Perspective and overall integrity must be watched : "The project was large enough and management communication poor enough to prompt many members of the team to see themselves as contestants making brownie points, rather than as builders making programming products. Each suboptimized his piece to meet his targets; few stopped to think about the total effect on the customer. [...] Fostering a total-system, user-oriented attitude may well be the most important function of the programming manager".
I would assume budgeting is a bit different in a situation where you receive a massive cash infusion. You want to spend all of it to grow even more quickly but the effects of spending may be harder to measure(because you're spending soo much soo quickly). So do you just replicate the growth strategy used in the "bootstrap" phase or do you adopt a new one?
In a situation involving a massive round of funding(relative to the current size of the company), wouldn't it be difficult to attribute any problems supposedly associated with the increased budget to a "bad budgeting process"? That is to say, if the growth isn't happening, then there's no guarantee that just by adding more money to "growth" that "growth" will happen. You may have just pointlessly hired managers, salespeople, engineers and bought more servers and whatnot, for growth that wasn't going to happen in the first place.
To put it a different way, when the profits don't catch up with spending, was the problem really the budgeting process? Or with the market itself? Or some other factor entirely?
Basically, how do you identify a bad budgeting process in a situation where some entity just externally infused a bunch of capital?
Of course the actual budgeting will be different, but at least have a broad outline.
When I think of "one bad process" that could ruin any company...I think of something like, stack rankings, or, partially-automated deployment (e.g. http://www.zerohedge.com/news/2013-10-22/how-lose-172222-sec...)
This seems more like a good example of the kind of mistakes/challenges that an inexperienced manager would encounter.
People are people, which is to say that people will always attempt to game the system, in one way or another. The keyword here being "attempt". Strong and experienced leadership should be capable of not only managing the human nature of the workforce and help bring out people's best, but also have enough experience to understand how to maintain the integrity of the company's culture. There is no perfect system for structuring a group of human beings. You have to deal with things as they come up.
Counter to the author's general point, I would add that I think well-defined budgeting exercises that lead to clear targets of the kind described in the article, where people are "made accountable," appear hubristic to me. There are so many unknowns that will come up that even to pretend to be able to meet such goals feels off. I'm waiting for management science to catch up with agile development.
I think one of the unspoken insights here is: give your projects a budget.
I've been with two startups now that didn't do this and see them either think there is no budget or there is infinite budget. Ultimately both CEOs would say "Just come ask me" which means that you now have to pester the busiest person at the company to get a budget. It is effectively giving the project no budget.
Perhaps "artificially constrain" is the real problem. Constraints that are rooted in real world limitations lead to the elegant design that others are commenting on here. Constraints that are kind of made up BS can, in fact, mess things up pretty badly, just as the author suggests.
I mean, if there is solid logic behind the constraints, it helps foster good problem-solving and good design. But constraints that lack that solid logic can very definitely cause things to go awry.
That's why I haven't bought his book. It just doesn't seem relevant for the kinds of smaller companies I'm interested in.
As per Frans de Waal's, this is true even for chimps ;)
That's the whole point of the article. He's saying don't do it.
This will always happen with closed allocation, no matter how much it is tweaked. It's an inherent property of closed allocation systems that the definition of work is driven by managerial status assertions rather than the needs of the business, which can only be assessed, at the lower levels, organically.
Closed allocation doesn't invariably destroy a company, and it's only in software that open allocation is obviously superior. (An open-allocation nuclear plant may not be the best idea.) Most industrial efforts can tolerate the inefficiencies that come with closed allocation. Software often can't, because software efforts tend to be binary in outcome (most lose, a few are big winners) and closed allocation generally creates enough needless complexity to cripple the company before it really succeeds.
Google and Microsoft also have massive free cashflow and they don't use open allocation. So perhaps the magic of Valve's "open allocation" is that they're just sitting on a cash fountain and it doesn't matter that much how they spend it.
My feeling is that open allocation is the most efficient with very dedicated employee and strong constrains. The manpower limitation being one of these constrains. Self organization is also more efficient with few people because communication is then more efficient. Obviously when the number of employee grows, these two conditions are much harder to met. Cashflow can only hide the inefficiency.
This is what I mean about the "magical escape hatch from economics". Coordination is easy if you have massive surplus, because you can recover from any fuckups.
In constrained environments on large problems, it falls to bits. Toyota delegates serious authority to its workers, but they are still working inside a system they help to design. It's not an ivory tower sitting next to a golden brook.
I'd be interested to see how many companies use open allocation that have succeeded and how many have failed. I'm going to guess that the failure rate is pretty close to the mean failure rate for all new businesses.
That success exists because they're doing things right.
If you look at closed-allocation software companies that succeed, what you find is that a politically fortunate subset does exist on essentially open-allocation terms. They work on what they want, where they want, aren't penalized for creative output, and get shit done. That small percentage ends up driving the whole company. That being the case, why not improve the odds by giving more people (or, even, all the engineers) that freedom?
Google and Microsoft also have massive free cashflow and they don't use open allocation.
Microsoft has been in decline for 15 years and a large part of that is stack-ranking, which goes hand-in-hand with closed allocation.
Google is doing OK, but it's in cultural decline and has been since the ~2009 introduction of more traditional management... which is around when Google's engineering organization became more rigidly closed. (From 2002-2007, Google was somewhere between open and closed allocation, solidly mid-spectrum because it was engineer-driven.)
Have you considered that every company which stumbles into a network-effects monopoly is successful regardless of how they run the place? "Conferred by lucky timing" is still an exogenous cause. We've learnt from the Windows and mobile App Stores that you can wind up in this position with and without creative output penalties and management bullshit.
> Microsoft has been in decline for 15 years and a large part of that is stack-ranking, which goes hand-in-hand with closed allocation.
It's definitely declining. It's been declining for decades. This decline has taken the form of a business so profitable that 4 out of 5 divisions by themselves would qualify as Fortune 500 entries.
And Google has been drinking cash from the same river for its entire life. The only diversification from advertising revnue they have is mobile devices, and it's only because they bought Motorola outright.
If you own a gold mine, you make profits because the market demands gold. Not because you are good to your staff, or bad to your staff. What makes you successful is the ownership of the gold mine.
Like I said, you have (so far as I can tell) one and only one example of any seriousness. One data point does not uphold a theory which completely ignores that economics is the subject of satisfying unlimited wants with limited means in the face of unlimited arrangements.
Changing gears though, I have to say that I was immediately turned off by Ben quoting a rap lyric at the beginning of his article. Not because I don't like rap, I do, but because of the lyric he chose.
I think this one is particularly egregious given that the quote includes the term "nigga" - even though it was of course self censored - which I don't think is particularly appropriate coming from a white man.
Not really a big thing, and it doesn't impact the overall message (which is why I think it only hurts things) but it may strike others wrong too.
Lots of songs have the words "cunt" and "motherfucker", but quoting those lyrics does not mean you are intending to insult a woman or accuse someone of having an Oedipus complex.
And yet many people (women and men) will find them insulting and offensive nevertheless, regardless of what you say your intent is.
Except they do, and it matters because they signal group membership. Especially as is concerned with this particular word, there is too much history to throw it around haphazardly.
>Lots of songs have the words "cunt" and "motherfucker"
Both of which have basically no social stigma beyond simply being vulgar
I think it's fine that you don't like the word 'nigga'. If you don't like hearing something, it's your prerogative to tell people that so they'll stop saying it.
But realize that by giving white people a double standard in terms of how they can express themselves, you're being racist against white people, and for black people, furthering the racial and cultural divide. Rationalizing treating people differently based on the color of their skin isn't any less racist just because you're on the populist, politically-correct side.
No you're not, you're being entirely consistent. The rule is simple - don't be offensive and context counts.
Taking race out of it - you can say something to or about your wife, girlfriend, husband or boyfriend which if I were to say it would be offensive. That's not a double standard, that's context. There is relationship (or lack of), a history (or lack of) and so on, all of which contributes.
Sadly, this does mean that simple, easy rules often aren't possible but that fact that those rules are complicated doesn't mean white people get to cry "racism" over a word which has historically been both offensive and oppressive, regardless of whether there is an attempt to reclaim that word.
All that's not to say that there can't be racism against white people - there can - just that this isn't it.
For what it's worth, I think if you're quoting a song (or work of literature, poetry or whatever), I think there is little reason to censor whoever you are, so long as you're doing it genuinely and reasonably (as opposed to just using it as an excuse to say something you wouldn't otherwise be able to).
Most importantly, the fact that the word is offensive to someone does not invalidate the racist double-standard. That's what context means: that the use of a word or phrase has multiple properties. On the one hand, use of the word by a white person is offensive. On the other hand, saying a white person can not use that word is racist. Both of these things are true at the same time.
You can attempt to gloss over these facts by saying "oh, historical use" or "oh, it's offensive" and many other reasons, but that does not remove the racism inherent to the double standard which is based on the color of the skin of the speaker. If the word was not offensive, it would still be a racist double standard.
Seriously?
You need to check the definition of racism. It's not simply discrimination on the grounds of race, it includes that there is a belief in the superiority / inferiority of the race(s) under discussion. Maybe it's just me but I really don't see how that applies here. No one is saying you can't use the word because only black people are good enough to use it so on a logical basis, no, it's not racism, at least not by the real definition.
In terms of the double standard, it's not a double standard at all, it's a standard that exists in all conversations which is that the context and the relationships and history between the two people involved matter. I can say things to my daughter which would be massively offensive for you to say. I can insult my best friend using an unambiguously obscene word and he'll laugh at me, you do it and he'd likely swing for you. In both these cases it's entirely clear that the context is important so I don't see why these are fine but it becomes a double standard to invoke context elsewhere.
These are very, very old arguments that have been attempted time and time again but they simply don't hold water.