What's that supposed to mean? I am just agreeing with the previous comment... early stage Facebook had a mentality in the spirit of the original article, and as they grew had to stop it. That's all. Just agreeing.
Maybe it was read as:
Move fast and break things > Move fast with stable infra
In most companies I've worked, approval process is the scar tissue of years of mistakes. In every case where you need to ask for approval to do something, you can probably trace back in the company's history and find the past mistake that some goofball made that necessitated getting approval to do something like that. Someone got us sued. Someone lost us some money. We need to take some kind of corrective action and…
Basecamp was founded in 1999 so I think they've had time to make plenty of mistakes. While I don't dispute the idea of approval processes as scar tissue, perhaps most companies scar too easily. I mean that both in the sense of being fragile and in the sense of over-reacting.
Basecamp has 50 employees. Google was founded in 1998 and has 50k employees. I think there's something more to be said about the differences in their experiences and the kind of mistakes they have made.
In most companies I've worked, approval process is the scar tissue of years of mistakes. In every case where you need to ask for approval to do something, you can probably trace back in the company's history and find the past mistake that some goofball made that necessitated getting approval to do something like that. Someone got us sued. Someone lost us some money. We need to take some kind of corrective action and…
Basecamp is a small company (~50 employees) that is headed by leaders who put an uncommonly extreme level of thought into how the company should operate. From my vantage point they feel like a "philosophical experiment" in technology company leadership. They also do things that many companies would never think of doing, like cutting most of their products and focusing on only one. Friedman and DHH are great thought l…
And yet, very importantly, Basecamp is insanely crappy.
What's that supposed to mean? I am just agreeing with the previous comment... early stage Facebook had a mentality in the spirit of the original article, and as they grew had to stop it. That's all. Just agreeing.
So you're suggesting a progression rather than one being vastly superior? I took it as the latter.
Sure, we all know the trick to startup success. Sprint as fast as you can for that cliff and hope the cliff moves before you get there.
I wonder how many programmers secretly work on their pet projects during work time.
People are being pretty friendly to this idea but honestly I've known more than one disgruntled developer, on their way out, who basically worked 90% of their time on their pet project, just doing the minimum work to not get fired. I don't think that is what people are advocating for but to answer the original question, I think this happens a lot where it isn't "practice" that the employer benefits from.
I wonder how many programmers secretly work on their pet projects during work time.
People are being pretty friendly to this idea but honestly I've known more than one disgruntled developer, on their way out, who basically worked 90% of their time on their pet project, just doing the minimum work to not get fired. I don't think that is what people are advocating for but to answer the original question, I think this happens a lot where it isn't "practice" that the employer benefits from.
This only works when you have the hiring process dialed in and you're selecting the right candidates to work from you.
Exactly. I once had the conversation about bottom-up vs top-down decision making with my CEO, and his point was essentially that the people we've hired can't be trusted with that level of responsibility. For me this was proof that our hiring process needed to improve, for him it was proof that our supervision process needed to improve. There's a great book about companies run through bottom-up decision making called…
I'm a true believer in bottom up decision making. That said, when I was in the USMC, I had to lead some Marines that I would consider incapable of making even the most basic decisions on their own. It's unfortunate but that's reason the military must have such a rigid hierarchy. If I'd been able to pick only the best Marines for my team, we'd have been able to allow more bottom up decision making. I've experienced it on some teams, others not so much.
In most companies I've worked, approval process is the scar tissue of years of mistakes. In every case where you need to ask for approval to do something, you can probably trace back in the company's history and find the past mistake that some goofball made that necessitated getting approval to do something like that. Someone got us sued. Someone lost us some money. We need to take some kind of corrective action and…
"Process is an embedded reaction to prior stupidity" -- Clay Shirky The root problem is that while process is usually something that's quickly thrown onto the pile, there's rarely any companies that continuously revisit process in order to remove as much of it as possible as soon as it doesn't make sense anymore. We do that religiously and it makes a huge difference. Recently we even got rid of our Daily Standup beca…
Please don't construe my comment as a condemnation of process. I'm talking only about "approvals". On all but the smallest (1-2 person) teams, process is vital and necessary in order to ship on time, under budget, with sufficient quality, whatever your business measurements are. This is particularly true for software. Without a clear product development process, we're all pretty much relying on chance in order to successfully ship a product.
>If you can make a decision and you don’t think it’s going to get you fired, just do it. This advice only applies to people with enough experience. I'm thinking of a certain ex-employee that followed that advice all the time, despite us constantly correcting him. Even on their final day, they was still insisting that they was doing good work. To this day, we are still finding code they wrote or modified that is wrong…
You are talking about programming, but this is about questions like "should I add feature x" or "should I try to improve the build process by using tool y". Somebody that can't program still might take the right business decision. I had the "pleasure" of maintaining the ColdFusion "programming" of a guy that sold airline ticket systems to a lot of different companies and in terms of business decisions he's about a few millions dollars better than I am.
In most companies I've worked, approval process is the scar tissue of years of mistakes. In every case where you need to ask for approval to do something, you can probably trace back in the company's history and find the past mistake that some goofball made that necessitated getting approval to do something like that. Someone got us sued. Someone lost us some money. We need to take some kind of corrective action and…
"Process is an embedded reaction to prior stupidity" -- Clay Shirky The root problem is that while process is usually something that's quickly thrown onto the pile, there's rarely any companies that continuously revisit process in order to remove as much of it as possible as soon as it doesn't make sense anymore. We do that religiously and it makes a huge difference. Recently we even got rid of our Daily Standup beca…
I think there is a lot of value when you change process so you discover what was useful and what was not. So, say 6 months from now try the daily stand up for 2 months then stop etc. Especially if your adding or removing team members.
IMO, the problem is any specific process is going to evolve to the point where people just go through the motions. But, without stability people are more likely to keep thinking from new angles.