Live data from Hacker News

How to Ruin Your Company With One Bad Process

bhorowitz.com

1–10 of 93 posts

Re: How to Ruin Your Company With One Bad Process

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

Re: How to Ruin Your Company With One Bad Process

#3
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).

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

Re: How to Ruin Your Company With One Bad Process

#4
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.

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.

Re: How to Ruin Your Company With One Bad Process

#5
post #3

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

I agree.

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.

Re: How to Ruin Your Company With One Bad Process

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

Re: How to Ruin Your Company With One Bad Process

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

Re: How to Ruin Your Company With One Bad Process

#8
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?

Re: How to Ruin Your Company With One Bad Process

#9
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 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.

Re: How to Ruin Your Company With One Bad Process

#10
post #8

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

I thought you had to show investors what you were planning to do with the money before getting it?

Of course the actual budgeting will be different, but at least have a broad outline.

Post reply on HN