I do whatever I want at work and I haven’t been fired yet | Hacker News Reader

I do whatever I want at work and I haven’t been fired yet

m.signalvnoise.com

106 pointsriqbal69 comments

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.

If you have a floorplan, and get to draft a process, you can use that to draw turtlegraphics with emails.

I just left a place where nobody writes design documentation. I requested that several teams write documentation for their tasks and they refused.

As your company grows from small-sized to medium-sized, your technical processes need to grow, too.

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.

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

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.

If the implementation outlives the implementer it most certainly shouldn't be up to him whether he does the design or not.

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.

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.

It also indicates to me a certain broader immaturity (in terms of product and engineering process) than simply a short history of mistakes.

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.

Move fast and break things => Move fast with stable infra

Easy to say when you don't hold the pager.

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

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.

Yes, sorry my bad. Edited

The >> operator indicates that moving fast, and breaking things, is much better than moving slowly with stable infrastructure.

What do you mean with ">>"? "much greater than" or "becomes"?

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.

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

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.

No one gets fired for adding process, that's why it's so common yet a slow death.

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.

I wasn't comparing it to Google. I was just saying that 18 years is long enough for many companies to develop lots of process scar tissue.

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.

And yet, very importantly, Basecamp is insanely crappy.

I'm curious what you mean by "crappy" - I don't find Basecamp useful for my needs, but lots of people do.

Are you saying you don't personally enjoy using it? Or that you think it's poorly engineered?

I think it is a UX abomination.

Can you go into greater detail? I'm curious on how you arrive at your conclusion.

>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 or broken in horrible ways.

Why? Because they didn't have the experience to know the difference between a quick fix and a good fix, and when to employ them. (Hint: The "quick fix" is almost never good enough.)

My personal line is a long way away from "Will it get me fired?" and I've got decades of experience.

I've always said that programming is all about making assumptions. And I'll frequently send off an email stating some assumption I'm making and start coding based on that assumption. If I get corrected, I can change pretty quickly. But I'm usually right.

But just not asking? Forget it. If I'm unsure enough to bother with sending a 2-line email, it's worth asking.

Isn't the solution to this a good code review process? Even the author of the article states "I either wrote up a plan and shared it beforehand, or I just announced what I’d done after it was completed". This is very similar to asking someone review your code.

Again, my comment was about having the experience to make these decisions properly. I'm sure he didn't tell people about every single decision he made, only the ones he needed validation on.

However, I noticed that he only told others after it was completed sometimes, which is often far too late.

Experience lets you know which ones that's okay for, and which ones it isn't.

> I'm thinking of a certain ex-employee that followed that advice all the time, despite us constantly correcting him.

The natural addendum then is, "listen to feedback".

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.

My examples were programming, but I also make decisions about processes and tools. They follow the same logic. If I'm unsure, I ask and go ahead instead of sitting and doing nothing.

Only if I'm very, very certain do I not bother asking.

And I've certainly got non-programmers around me that make business decisions all the time. It's their job. I'm not sure how that's relevant?

The same thing applies: They should only be doing it without consultation if they have the experience to back it up.

I think this depends a lot on two people - your immediate manager, and their immediate manager. I've been lucky to have great management, and I've been able to do a lot of stuff that the article talks about, and I work in a stodgy BigCo (old school tech co).

I once went to 99Designs and paid $2000 for a designer to redo a certain set of pages on our corporate site. Start to finish, the project took 27 days. This is insanely fast in our context - the usual process would have taken 6-8 months, and at least $100,000. The large agency we work with would have dedicated a team, spun up a project, set up a series of meetings...

To be fair, I get the need for process and I totally get the value of working that way, but it's nice to have management that backs you up when you really need to get something done fast. And yes, once the need for those pages was over (conference related), I made sure they were handed over to the right team for long term management, and not just abandoned as orphan pages.

Well played hacking the system.

Assuming the people doing this have experienced and are trustworthy, this is honestly what companies need in a limited capacity, even if they don't think they need it.

Over the course of my relatively short career so far (7 years?), almost every single "big win" has been because something was bugging the crap out of me, and I just decided to do something about it.

The key is to do this kind of autonomous stuff while still delivering things people expect you to do, unless/until your peers and management are clear on the value you bring just doing stuff on your own all the time.

Also, the two things that push most people towards entrepreneurship is money and autonomy in their work.

If you can give employees these things, they will stick around longer.

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 Reinventing Organizations. My take away was that bottom up can work at any scale, but it requires true believers at the top who are constantly working hard at making themselves unnecessary. Once the true believers walk out organizations naturally revert to hierarchical decision-making.

The best advice I received from an old manager when I moved into management was that if I wanted to achieve anything my primary goal was to make myself and my position redundant. Hiring and empowering the right people is the only way to achieve this, its not easy but its definitely worth it. When you can truly trust the people you are responsible for its a different game.

On the other hand, if you can make an organization work with a lower grade of employees, you will scale much more easily and cheaply. Maybe its a pipe dream to accomplish this but I think it's probably somewhere in between. At the scale of a multinational corporation with hundreds of thousands of employees, it surely comes into play more.

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.

Ummm... I beg to differ. Well, I will admit that you need to avoid inept people. But I assert that the key to success is for management to have clear goals for the organization and articulate them clearly. Most people, if they understand the goals clearly, will make good decisions. If everyone knows the goals, and you encourage them to "think above their paygrade" (solve your manager's problems, not yours..) and a lot of good work will happen.

Management in 3 bullet points: 1. Have clear goals. 2. Articulate your goals clearly. 3. Go to 1.

This wouldn't work for 90% of companies. You cannot do whatever you want in a PCI environment, or a HIPAA compliant environment. It also boils down to your managers, product managers etc.. Do they micromanage? Is your focus shifting all the time because new high priorities tasks are coming your way?

If so, I would never feel confident in doing whatever I want, as I know I wouldn't be able to put 100% of my focus on it, and probably forget something important that could screw a lot of things up.

I wonder how many programmers secretly work on their pet projects during work time.

And I wonder how many companies have benefited from the experience said programmers gained while working on pet projects...

I look at it like taking a walk, or a smoker taking a smoke break. That small reprieve, the 15 minutes I take working on a side project, or tinkering with something for fun, rejuvenates me and gets me jazzed about the task at hand when I get back to it. That's a productivity booster, and ultimately a benefit.

A rationalization that's likely to get you fired if you were to own up to it publicly. Although it's true, the company would benefit from you feeling excited about the task at hand.

Probably a lot, but despite the title, that's not what this article is about.

I would just view pet projects as practice time. Its like getting mad at a musician for playing when the mics are turned off.

Well, doing it on work time is more like getting mad at the musician because they're supposed to be in the next room recording a track...

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 can’t help but think having such autonomy is tied to profitability. I’m sure there are plenty of examples where an employee at a profitable company doesn’t have autonomy. But how many have autonomy where there's not profitability?

Think about a financial trader (stock, commodities, etc) that place big, but risky, bets on their own initiative. The times we know about this sort of thing happening have all been disastrous to the companies they work at. Of course, what we hear about in this regard selects out all but the disasters (nature of news reporting)... and as far as I know were almost certainly not the de facto sanctioned actions of a bottom-up culture. But these cases of autonomy were anything but profitable.

I think you're close to the mark, but it's less about profitability specifically, and more about growth. A company that is focused on growing as fast as possible, dominating a market, and generating a favourable outcome for investors is only going to get there through big audacious bets in terms of product strategy. If you need to get 3x as large as you are a year from now, no amount of small tweaks for better user experience from individual developers is going to get you there. Instead, you'll find large numbers of developers (or maybe even the entire team at smaller shops) all working towards big, flashy advancements.

There's a relationship here with profitability, for sure - companies that are profitable are likely not prioritizing growth over profit, and aren't beholden to investors who want a big exit, but the profitability is more of an indicator than the cause.

Sounds like an awesome place to work. I love autonomy and the ability to make my own plans and follow through with them. However, if it's a team effort then you definitely need buy in from everyone involved!

His boss trusts him enough to let him take his own decisions, good for him! It's definitely not great advice for every employee, or for every company though...

I mean, it's great to be able to discuss things with your boss and colleagues and take collegial decisions...

I don't understand the idea behind the post...

From the perspective of basecamp/37 signals, they've made it a point to do things which most people say "wouldn't work". And they do it and prove that it is possible.

A lot of objections one might have to their choices are usually deeply rooted in other organizational dysfunctionalities. Other companies for example may choose to hire weaker employees due to the urgency to get people sooner. Sooner is more important than correct and then you have employees you can't trust to be autonomous. Or you put people in managerial positions whose purpose is to delegate, or approve tasks as part of their monitoring duties. This goes against autonomy entirely. Basecamp for example doesn't have any real managers.

While you are right that this won't work for many larger established companies, from the perspective of people starting out (and there are a lot of them), these posts serve a purpose of raising a middle finger to the established norms of running a business. There's a purpose built around tearing down bad decisions that lead to other bad decisions that eventually lead to ineffective teams.

And that's the idea behind this post.... Probably :)

It's marketing.

Their company has good cash flow and a small number of very talented employees. I don't feel like this paradigm is easily applied to organizations that either can't afford their level of talent or have thousands of employees.

Reply on news.ycombinator.com