Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Ruin Your Company With One Bad Process

bhorowitz.com

Post reply on HN
Print view View original

21–30 of 93 posts

Re: How to Ruin Your Company With One Bad Process

#21

Post by michaelochurch »

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.

Re: How to Ruin Your Company With One Bad Process

#22

Post by saraid216 »

jeffdavis wrote: post #9
curun1r wrote: post #6

One part of his conclusion struck me as wrong: > 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 w…

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…

It's arguably more useful to define constraints as "the materials available to you" rather than "strictures on what you may not do".

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.

Re: How to Ruin Your Company With One Bad Process

#23

Post by rmason »

jobu wrote: post #2

"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.

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".

Re: How to Ruin Your Company With One Bad Process

#24

Post by meowface »

AndrewKemendo wrote: post #14

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,…

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.

Re: How to Ruin Your Company With One Bad Process

#25

Post by carbocation »

nostrademons wrote: post #7

"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 ar…

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.

Re: How to Ruin Your Company With One Bad Process

#26

Post by true_religion »

chrisweekly wrote: post #16
nostrademons wrote: post #7

"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 ar…

"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. EMBRACE 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.

Re: How to Ruin Your Company With One Bad Process

#27

Post by minimax »

nostrademons wrote: post #7

"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 ar…

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."

Re: How to Ruin Your Company With One Bad Process

#28

Post by mturmon »

trefn wrote: post #15
AndrewKemendo wrote: post #14

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,…

http://www.bhorowitz.com/the_legend_of_the_blind_mc

Thanks for that. Context is everything with these explosive words.

Re: How to Ruin Your Company With One Bad Process

#29

Post by afarrell »

true_religion wrote: post #26
chrisweekly wrote: post #16

Earlier quoted context omitted.

"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. EMBRACE 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.

Survivorship bias.

"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

Re: How to Ruin Your Company With One Bad Process

#30

Post by 7Figures2Commas »

nostrademons wrote: post #7

"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 ar…

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.

Post reply on HN