"As a technologist, you know that the worst thing that you can do is over-constrain the problem before you start. You'll kill creativity and prevent yourself from getting a truly great outcome."
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.
To borrow from another field, there's a great 1969 interview with Charles Eames [1] (famed furniture designer) in which he discusses design, and constraints as being a necessary component of design. A pleasure to read.
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.
I agree, but for me it's important that the constraints be real. Sometimes when people hear that constraints are good and people love doing the impossible, they just make up arbitrary impossible constraints for their team.
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.
"constraints are what breed elegance"
This; 1000x this.
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.
I remember the 'old school' and there were plenty of poor quality games; its just that very few of these have survived 20 years or more to be shopped around as examples of the past.
"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
Great comment (and quote!) -- totally agreed. But my having used a mediocre example doesn't counter the gist, that constraints can and do breed elegance. (shrug)
I do agree with your conclusion that constraints can lead to elegance. I just think that your point about old video games wasn't a good argument in favor of it.
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.
Constraints gave us Facebook instead of Myspace. Constraints gave us Twitter. Constraints gave us Snapchat.
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.
I agree and would add that constraints gave us Star Wars: A New Hope instead of Star Wars: The Phantom Menace.
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.
I doubt it was constraints that made Facebook become more popular, or any other technical reason. It's too bad MySpace isn't what people use anymore. I'd like having all the customization of my home page on Facebook.
4chan has constraints: There are only 20 pages per board (if I recall correctly) and if a thread does not get new posts and drops from page 20, it's gone forever. Just like the twitter 140 characters limit, 4chan has a history limit.
So 4chan perfectly fits in the parent's list of social network like things based on arbitrary contraints
It's entirely not true that no-contraints gave us 4chan. 4chan is definitely constrained: In manpower and financials. Every time the 4chan people post a clever hack that makes 4chan work with what they have, I'm impressed. The fact that they don't filter the content doesn't mean that there are no constraints to the system. The constraints are just different from facebook and myspace.
By the time an engineer is tasked with implementation, a sufficiently-constrained problem or set of problems should be established. Execution risk tends to increase significantly when engineers are tasked with building solutions to an unwieldy set of problems.
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.
In art school they say "form is liberating". It gives you direction and relieves you of the oppression of infinite choices. It can give you something concrete to fit into, or subvert.
I recently read "The Goal", may I ask what you found interesting about TOC?
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.
I think the "constraints" he had in mind were more like what we would call "implementation details." What if someone told you, "sort this list of a million words as fast as you can, but the constraint is you have to use a bubble sort." Think of a CEO with $50M in the bank telling his CTO, "build a best-of-breed product, but you can only hire two new engineers this year."
The thing we don't always recognize is, there are constraints either way. Part of the process or designing or solving any problem is to realize what the constraints are - you're unlikely to fulfill any constraints you're not sure about! By focusing on what the constraints should be from the start, you have a clear idea of what problem you're trying to solve
> "As a technologist, you know that the worst thing that you can do is over-constrain the problem before you start. You'll kill creativity and prevent yourself from getting a truly great outcome."
> 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.
>But its still a critical failure to over-constrain
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.
This also neatly ties in with the Mythical Man Month. You cannot increase the headcount to in the hope that you can accelerate. There is a great deal of domain knowledge that is locked up, and initially - growing involves having a person who is wearing multiple hats to give up one of their hats.
I agree that having constrains makes the problem simpler to think about, which as a programmer/engineer is great. It makes the problem look more like a puzzle.
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.
Plus-one - constraints are absolutely vital. I'd say the absence of constraints has killed more projects as I have seen. It's difficult to determine wants v.s. need without some thinking, and constraints help with that.
> 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.
I always think about it from an artistic standpoint. Art forms are almost defined by their constraints: movies can't use text, literature can't use pictures, ice sculpting can't use clay, mosaics can't use paint.
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.
The post opposes excessive constraint. An example of that would be making your examples hard and fast, inviolable rules: there are movies that use text and books that use pictures and illustrations to great effect. The constraint may be "presentation should be primarily visual and auditory, and not require much reading". The over-constraint would be "presentation must be exclusively visual and auditory, and no text may be displayed on screen".
Add to that: people who can successfully "break out of those constraints" are pretty rare. Most painters will get better results on the canvas than the mountainside.
I can't help but read between the lines on that quote: "As a businessperson, you know that deciding a direction is hard. Foist your half-baked ideas off on the technologists, and blame any shortcomings on over-constraint, on their failure to accomodate all possible pivots."
Great article. I've come to believe that Ben Horowitz is the best management writer today. He comes from a technical place, and has learned the ways of management via the school of hard knocks. And every interesting project worth doing comes from the school of hard knocks.
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."
"If you quadruple your engineering headcount in a year, you will likely have less absolute throughput than if you doubled headcount. As an added bonus, you will burn way more cash."
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.
A mentor of mine, David Kathan, said something more colorful, "Of course, you can have a baby in a month if you use 9 women". People should read Mythical Man Month more.
Another section of MMM directly related to this article would be the chapter "ten Pounds in a Five-Pound Sack".
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'm not sure I follow. I see the constraint of the first system as the natural fear of failure that comes from doing something new. It is an implicit constraint. The second system is less constrained in my view than the first.
The author of the essay linked seemed to be asserting that freedom from constraints will produce more wonderful solutions.
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.
Read a story once where someone said at a company wide meeting with the CEO, if you continue to refer to us as "headcount" then we're going to start calling you "overhead".
Budgeting is particularly interesting in a situation where you receive funding. It seems it would be much easier to budget in a bootstrap situation, where growth is likely happening a bit more slowly. You're slowly adding a person(engineer, marketer, salesperson, etc.) here and there as you go along(as needed), buying more servers, etc.
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?
I would assume so. But if the idea or company fails or the planned trajectory falls short, how would the company know it was the budgeting process at fault versus some other factor?
Not so much a "process" as much as a bad planning strategy, or a company structural deficiency (in which the incentive of "tell me what budget you need" is exacerbated).
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.
I saw where it was going right at the start, I've seen it a lot in various startups I've worked with. Growing a company past certain sizes often winds up failing due to unbridled optimism. Reason goes out the window as growth seems it will never end; people buy into it and want to expand their role for when it hits the big time. The end is often a mess. Eventually either sanity prevails or it goes bust.
This is an excellent warning to any startups looking at growing quickly. I am living through such a growth effort, and I can definitely see how the culture is changing for the worse in the company.
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.
Currently in a project situation with no budget and blue sky dreams. I can't say how much I love this article enough.
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.
As a technologist, you know that the worst thing that you can do is over-constrain the problem before you start. You'll kill creativity and prevent yourself from getting a truly great outcome.
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.
> Note that this does not apply to you if you have very small numbers. It's fine to grow engineering from one to four people or from two to eight. However, if you try to grow from 50 to 200, you will cause major issues if you are not extremely careful.
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.
"Well, that's the beauty of the game. It only takes one player to opt in, because once someone starts playing, everybody is going in -- and they are going in hard."
As per Frans de Waal's, this is true even for chimps ;)
off-topic: why does Ben Horowitz always include rap music and a quote which aren't relevant to the article in question? (other than that he just likes rap)
When I asked my managers what they needed, I unknowingly gamified the budgeting process. The game worked as follows: The objective was for each manager to build the largest organization possible and thereby expand the importance of his function. Through the transitive property of status, he could increase his own importance as well.
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.
Can you name open allocation companies that aren't operating with massive free cashflow? Because you always bring up Valve when raising your theory that open allocation is the magical escape hatch from economics, and it always seems to me that's the only major example you have.
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.
Isn't SuperCell (Clash of Clans) using open allocation as well ? They did it before becoming a cash fountain.
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.
> Obviously when the number of employee grows, these two conditions are much harder to met.
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.
Have you ever considered that Valve is successful because of open allocation? It's not like this massive cashflow was conferred upon them by God.
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 ever considered that Valve is successful because of open allocation? It's not like this massive cashflow was conferred upon them by God.
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.
Interesting article for sure and I think it highlights exactly how you get unwanted bloat and how to prevent it. Budgeting has always been a dark art, especially for creative work, and adding smart constraints on the front end are some ways to reign things in - however I think this largely applies to the companies who can say the following: "we had plenty of cash in the bank." I know for us our budgeting process is, what is on fire and can our limited amount of cash put it out?
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.
You may also like The Tanning of America, Horowitz is interviewed in parts and it's a really interesting documentary, but none of that story is mentioned in it
This attitude baffles me. He's quoting lyrics. Lyrics are lyrics, and the ones he quoted in particular have no racial overtones. And even if they did, who cares?
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.
> 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.
Of course. But many people would also be offended at the word "fuck", such as in "that's fucking great". It's impossible to not offend someone, that's why you write and speak with a target audience in mind. And Horowitz is speaking to the tech and startup industry, which is generally fairly relaxed when it comes to profanity of that nature.
> Lyrics are lyrics, and the ones he quoted in particular have no racial overtones.
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 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.
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.
> 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).
On a literal basis it is racist because you invoke race. On a logical basis it is racist because you ignore context and treat the use of a word based on the color of the skin of the person using it. On a moral basis it is racist because one group getting offended is not any more or less valid than some other group getting offended.
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.
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.
To be clear you're drawing a comparison between a white person getting offended by not being allowed to use an offensive word, and a black person getting offended by a word which has strong connotations to literally generations of oppression including but not limited to being bought and sold as property?
I really like the article, but I don't see any connection between the lyric and the article. For me, if you're going to use a quote to lead off an article, it needs to setup the article. This lyric adds nothing for me (and I'm a hip-hop head).
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.