Accept Waste
In new product development, in research, you WILL go down some dead ends. Accept it.
Similar Posts
Yes, Virginia, There IS Discrimination against Women in Technology
My work day started with a call on research design and ended ten hours later after I fixed a program that wasn’t working. I just resigned from my position as senior statistical consultant at a major research university so that I could concentrate on research. I’m on the technical staff on several projects, have a…
Survival analysis, take-out and one smart cookie
The first cool thing you should know about Dr. Patricia Berglund is that she and several others put their slides and more up at the SAS Global Forum take-out section. That is NOT, contrary to what you might believe, a place where you can pick up some really good Chinese food to eat while listening…
SAS On-Demand making statistics professors’ lives better, since, oh, Tuesday
The downward mobility of Ph.D. students is like domestic violence in many ways. That is, the people in the “family” all know it is a fact of life, but they don’t talk about it among themselves, and to outsiders they pretend it doesn’t exist. The fact is, far more people will graduate from Harvard than…
Never Believe the User
You know that guy, supposedly a program, in Tron, the one that yells, “I serve the user”. Well, he never met the first lead engineer I worked with. Reading Donald Farmer’s post “Is it really so?”, I was reminded of something that happened decades ago and it was a lesson I never forgot. I was…
PROC FREQ for data analysis (sort of)
Previously, I discussed PROC FREQ for checking the validity of your data. Now we are on to data analysis, but, as anyone who does analysis for more than about 23 minutes can tell you, cleaning your data and doing analysis is seldom a two-step process. In fact, it’s more like a loop of two steps,…
PROC COMPARE FOR VALIDATING SAS CODE
I know people who are so obsessive about testing and validating their code to the point they spend more time on testing it than actually writing it and analyzing the output. I said I know people like that, I didn’t say I was one of them. However, it is good practice to validate your SAS…
Transcript
—
Accept the fact that you’re going to waste some time.
That’s some advice I give to young people starting businesses; you’re going to waste time and you’re going to waste money. I mean that in the sense that some things you do, you’re going to have to do over. In our company, we often will start on something, get a certain way down the path and realise “you know, we really don’t want to do that in Ruby, we’re going to start over”. What you hope is that you don’t get too far down the path before you decide you have to start over, but it’s inevitable. I think sometimes larger companies – that’s why I said yesterday I was so impressed that IBM had actually written that article on Just In Time Design – larger companies often are so risk averse, in the sense of “we don’t want to ever have to throw anything away that we did”, that they’ll spend an inordinate amount of time planning something out so they don’t have to justify that we spent all this money on something we never used.
In our case, we’ll go ahead, we’ll try it; if it doesn’t work then we quit doing it. If it does work then we do some more of it. Whether it’s paying somebody to do a logo, if it’s doing 2D programming and then saying we need a combination of 2D and 3D, if it’s creating one model for a teepee and saying “it’s too cartoonish” and throwing it out. You often don’t know those things in advance and you just need to accept that as you progress you’re going to realise that some of what you do initially doesn’t fit any more. And that’s just the way it is.
I think the modern day buzzword for this notion is “pivoting”.
This is a key advantage of small business: the ability to rapidly change / adapt faster than the big boys. We aren’t as plagued with process or formalities (or “escalation of commitment” to use an OB term).
While big companies have more financial resources, SBs have more “pivoting” ability, which is a huge resource. I’ve also found it to be a huge advantage that employees wear many hats in a SB and seem to care much more about the big picture … seeing the forest for the trees if you will, vs. the typical “that’s not my job” mindset of a big corp worker.
37signals is a great company to study. They’ve purposely kept employee count as small as possible. I recommend the book “Rework” by Jason Fried and David Heinemeier Hansson (the later of which is the inventor of Ruby on Rails).
Thank you, Phil, for the transcript. I’m going to have someone type the next one for me (stealing your idea) because I need to put it up for a student.
Thanks, Clint for the book suggestion. I’ll read it when I take off next week.
To entice you a little more, here’s an excerpt from “Rework”:
“A lot of people get off on solving problems with complicated solutions. Flexing your intellectual muscles can be intoxicating. Then you start looking for another big challenge that gives you that same rush, regardless of whether it’s a good idea or not.
A better idea: Find a judo solution, one that delivers maximum efficiency with minimum effort. Judo solutions are all about getting the most out of doing the least.
Whenever you face an obstacle, look for a way to judo it.”