
I do whatever I want at work and I haven’t been fired yet - riqbal
https://m.signalvnoise.com/i-do-whatever-i-want-at-work-and-i-havent-been-fired-yet-7aae85aa3586
======
ryandrake
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.

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

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

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

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

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

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

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

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

~~~
toomuchtodo
Well played hacking the system.

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

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

------
RUG3Y
This only works when you have the hiring process dialed in and you're
selecting the right candidates to work from you.

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

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

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

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

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

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

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

------
shawnbaden
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?

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

------
haburka
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!

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

~~~
nstart
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 :)

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

