
How to Build Deep Focus Into Your Organizational Culture - cameronconaway
https://www.getflow.com/blog/deep-focus-organizational-culture
======
wpietri
I'm going to ignore the high levels of content marketing here and share my
favorite trick: minimize work-in-process.

At my last startup, we limited WIP (that is, the number of open tasks) to be
smaller than the number of developers. You can see a picture of our task board
here:

[http://williampietri.com/writing/2015/the-big-
board/#toc4](http://williampietri.com/writing/2015/the-big-board/#toc4)

This was great. It really forced us to focus and collaborate. It helped
management to accept the true capacity of the team, preventing them from
flooding us with requests. It also let us get things done at a lively pace,
creating a continuous sense of progress that built trust.

I've visited so many teams that have a dozen things going on at once, which
leaves everybody scattered. Especially when people then sneak in another dozen
"unofficial" requests because they have learned not to trust the main work
queue. And then another dozen urgent bugs, most of which happened because of
the chaotic work environment, because nobody has enough time to focus and do
something right.

In some: if you want to get more done, do fewer things. And then fewer things
still. It seems crazy, but it works.

~~~
Animats
Someone is from an industrial environment. Work in process, in the form of
partially complete goods, is a curse of badly organized factories. It's more
visible in a factory environment; you have to walk around the stuff on the
shop floor. It also costs real money - you've bought the parts, but can't sell
the product yet.

One form of limiting work in progress is this: if you want reliable software,
insist that no new features go in until all the reported bugs have been fixed.
A weaker form of this is to have a master branch, which gets bug fixes only,
and a development branch, into which new features go. Merging can happen only
when there are no open issues in the master branch.

This is the opposite of "shit early, shit often" development.

~~~
zaidf
"If you want reliable software, insist that no new features go in until all
the reported bugs have been fixed."

That is a massive oversimplification. In fact, a key job of a product manager
is differentiating between critical bugs that must be fixed, bugs that should
be fixed but can wait and bugs that don't need fixing in the near term.
Otherwise, for any mature piece of software (particular enterprise software),
you will be fixing almost an infinite number of bugs that add little value at
the expense of critical features that make the needle move.

This is one of the biggest lessons I got when working on a decade old
enterprise software. At first, I was shocked that our VP of Product put
certain bugs in the "won't fix any time soon" category. But now, I see how
much more value we'be been able to drive _because_ we decided to ignore
certain category of bugs for new feature or other feature improvements.

Insisting on blindly prioritizing bug fixes over any thing else does nothing
more than satisfy our engineering ego. Don't assume it automatically making
the product more useful for the user or driving more value to the company or
its customers

~~~
wpietri
You ignore how there got to be an infinite number of bugs in the first place.
It's people following exactly the rule you suggest: chase the sugar high of
metrics bumps while leaving maintenance for "later".

What this misses is that a buggy code base with a lot of technical debt makes
it very hard to get anything new done. Worse, because you've spent years
teaching people that being sloppy is the way to go, even when they rewrite
something or build something new, it won't be very good and will still have a
high maintenance cost.

Whereas if you follow a quality-first approach from the beginning, you never
build up those mountains of technical debt. You can have a sustained pace of
innovation that's much higher because you aren't working on top of a garbage
heap. And you have people with excellent habits and a good working
environment, meaning high productivity and low turnover.

------
zipfle
It is hard to take an article about "focus" seriously on a site that pops up
an email subscription request as soon as you start to read it.

------
brian-armstrong
They forgot another step: uninstall Slack ;)

------
borkabrak
I apologize if this is too far off-topic, but all this talk of "focus" lately
keeps reminding me of A Deepness in the Sky, by Vernor Vinge, where a much
more sinister (and more sci-fi) version of it is called exactly that - they
forcibly "Focus" a group of people into the office equivalent of slave labor.

Great read.

------
therusskiy
Anyone had a chance to read their book? Do they back their practice by
research? Tired of pseudo sciency stuff...

~~~
zlalanne
Haven't read it, but would highly recommend Cal Newport's book on the same
subject. Made me really think about how I spend down time and it's affect on
my ability to focus when I really need to.

[https://www.amazon.com/Deep-Work-Focused-Success-
Distracted/...](https://www.amazon.com/Deep-Work-Focused-Success-
Distracted/dp/1455586692)

~~~
uberstuber
I'd second the recommendation, it made me reschedule my day to ensure I
consistently have 'deep work' time.

I took some rough notes if you don't have time to read the whole book right
now:

[http://jamesstuber.com/deepwork](http://jamesstuber.com/deepwork)

------
thefastlane
just put everyone in a big bullpen, and make sure everyone sits as close
together as possible for maximum collaboration -- that's basically what deep
focus is, right? bonus points if you're right next to a heavily traffricked
walkway, which will foster 'drive-by testing', or something. another CTO was
telling me about drive-by whatever-it-was at the CTO conference in Hawaii that
I attended last week. good stuff.

~~~
maxxxxx
Add status reports twice a day and you are on your way to eternal greatness!

