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 the easiest solution is to simply require oversight next time.
A place where you can "do whatever you want" strikes me as a place with a very short history of mistakes.
My company has been getting a lot of talent from Amazon and Microsoft, so we are getting their "scar tissue" without any of the context, jacking up our culture. I have to do a detailed doc and plan for everything.
It wouldn't be a big deal but we've gone from 700 to 1500 employees in just 2 years, so its been fast change.
I find it almost required to try and jolt these people out of it if they move between organizations. There is definitely a value to procedure but it often comes up that the underlying assumptions have moved as well. You have to encourage people to reevaluate eventually or the third or four generation handling the bureaucracy does not understand the why and does the same thing covered by the first procedure on some grand new thing that looks about the same.
> I have to do a detailed doc and plan for everything.
I find spending a few days writing a detailed, in-depth design document for a given implementation often saves weeks or more of development. In the immediate term it takes longer. In the medium to longer term a thorough design can often lead to fewer bugs, less severe bugs, and less complicated enhancement development.
What you describe is what engineering is, at least partly. Your attitude, which is quite common, is why I scoff at calling what this industry does "software engineering". It's rarely as thoughtful, careful and detailed as engineering requires.
Not that that is a bad thing. Often what a business in this industry is making just isn't complicated enough to need much beyond simplistic hacking at a terminal.
This is the best solution when you are building a whole system from scratch.
If you have to build a feature or whatever it is then it already got implicit permission from the jira sponsor or the product owner or whatever stakeholders are in charge.
And for a feature I don't have to lose days writing long documents.
I just think how it should work, I discuss it with the senior members of the team and with the stakeholders if needed.
From that point on I just speak with the users to understand exactly what they want showing them whatever I'm building to have an early feedback.
I think that is much more productive spending several days in a tight feedback cycle with your users than spending the same amount of times drafting the architecture in a document.
How do you get from "I just think how it should work" to "discuss it with the senior members"? You've got notes, at the very least, that you've jotted down about the proposed changes. Guess what: that's the draft of a design document! If you've taken any reasonably thoughtful approach you'll have just a little more work to make it formal, invite formal comments and feedback, etc. Not weeks "drafting an architecture" document, just days (or possibly hours, if it's a small change). That's a small price in time to pay for such a big dividend down the road.
I don't think this is an argument for requiring plans, though: you can always encourage them, but in the end it should be up to the person doing the design. Otherwise you end up with the absurdity of having to write a detailed plan and wait a month for approval just to change the positioning of a button slightly.
What I'm saying is that depends on the nature of the code that's being written. Many small improvements can be made with a simple code change that has clear meaning on its own -- a long approval process would just make these changes less likely to happen.
The point of having an approval process of any length or complexity is precisely to make changes less likely to happen ad hoc. That's a Good Thing (tm)!
Sometimes "small improvements" have ramifications outside of the context of the change (potentially significant ones). The person implementing these improvements has to understand the scope of the change (including side effects on external systems, if any), and that effort should be documented somewhere or at the very least reviewed by peers for correctness, especially for truly mission-critical or sensitive systems.
It doesn't have to be a "fill out these forms in triplicate and don't forget the new cover on your TPS report mmmkay" kind of documented effort: it's not one extreme or another.
I agree with documentation, but detailed "plans" are different. Its a doc about what my product/feature/quarter/sprint will entail and almost never matches up to reality because things change. Documentation, on the other hand, it written after or during the code and has nothing to do with planning.
"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 because we saw it wasn't bringing any value with the way we already communicated.
Process needs to be continuously lived, renewed and owned by the team, otherwise it tends to rot and negatively impact speed, morale and innovation.
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.
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.
Though, having human judgment manage the approval is another form of organizational immaturity..
When the decision is in the domain of the actor, you should make it your organization's goal that though computers, policy documents, or documentation process that they can try to make the decision without outside human intervention. Outside of very unusual requests, escalation up management or other stakeholders shouldn't even be required.
Places where I've seen pushback on actually documenting these choices have usually fallen into one of two camps:
- too much approval required for just about anything, to document it is to admit they have a problem and would take a long long time (hint: this is a lot of engineering groups).
- making the policies public would be embarrassing to management in some form (prejudice, illogical, half-baked, etc).
Both of these are "fish rots from the head first" type of problems, and unfortunately I haven't seen good ways for people down the ladder to fix them.
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 leaders in this space, but a lot of what they do wouldn't work as-is in a larger corporation.
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.
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.
In my experience, a lack of process or roadblocks in the way of developers is mostly orthogonal to how willing you are to break things in the pursuit of speed / agility. I've worked in process heavy places where people were content to throw things over the wall, and shipping a feature with less than 200 known bugs was considered a good thing.
I've also worked in places with near absolute freedom, right down to the level of individual engineers building out new products without approval where a single crash meant all hands on deck.
A place where you can "do whatever you want" strikes me as a place with a very short history of mistakes.