How to Build Deep Focus Into Your Organizational Culture(getflow.com)
getflow.com
How to Build Deep Focus Into Your Organizational Culture
https://www.getflow.com/blog/deep-focus-organizational-culture
34 comments
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.
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.
"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
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
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.
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.
Good point that metrics for prioritization are revenue and customer satisfaction. You can cut a lot of cruft when applying these filters.
If you appreciate the industrial angle, I strongly recommend Mary Poppendieck's books on applying Lean Manufacturing to software. They've deeply influenced me over the years.
One easy place to start is her 7 principles: https://nzdunic.info/2015/05/12/mary-and-tom-poppendieck-on-...
Also good are her 7 wastes of software development, created to parallel the Lean Manufacturing wastes:
* Partially Done Work
* Extra Features
* Relearning
* Handoffs
* Delays
* Task Switching
* Defects
One easy place to start is her 7 principles: https://nzdunic.info/2015/05/12/mary-and-tom-poppendieck-on-...
Also good are her 7 wastes of software development, created to parallel the Lean Manufacturing wastes:
* Partially Done Work
* Extra Features
* Relearning
* Handoffs
* Delays
* Task Switching
* Defects
Joel Test, #5: Do you fix bugs before writing new code?
http://www.joelonsoftware.com/articles/fog0000000043.html
0 hits for "shit early, shit often" development.: https://www.google.com/?#q=shit+early+shit+often+development
Were you mocking "ship early, ship often"?https://en.wikipedia.org/wiki/Release_early,_release_often
That's about when you ship, not what you work on. It's not the opposite of fixing bugs.
0 hits for "shit early, shit often" development.: https://www.google.com/?#q=shit+early+shit+often+development
Were you mocking "ship early, ship often"?https://en.wikipedia.org/wiki/Release_early,_release_often
That's about when you ship, not what you work on. It's not the opposite of fixing bugs.
Never heard the phrase, but it is what bad managers mean when they say "ship early, ship often".
"Shit early, shit often" is what usually happens with the "ship early, ship often" in real life. See also, "move fast and break things" as implemented in a typical startup.
But then again, business incentives are usually against software that works well and is useful - what matters is whether software works just enough to look sellable.
But then again, business incentives are usually against software that works well and is useful - what matters is whether software works just enough to look sellable.
Spot on. The best team I ever worked with used Pivotal Tracker. When you delivered a story, you picked the next story off the top of the backlog. No cherry picking of stories.
We paired on all but the simplest stories. You were constantly learning new tricks from other devs and since you could only take from the top, you quickly got a taste of most of the major components of the system.
In short, you could actually take a fucking vacation because there's no longer the situation of being the only designated "backend guy". Everyone had some backend experience.
We paired on all but the simplest stories. You were constantly learning new tricks from other devs and since you could only take from the top, you quickly got a taste of most of the major components of the system.
In short, you could actually take a fucking vacation because there's no longer the situation of being the only designated "backend guy". Everyone had some backend experience.
> In short, you could actually take a fucking vacation
This is key. With the team in my article, I had to take some extended time off to help with a sick family member. Even though it was a startup and I was the CTO, I could go away for a couple of weeks unexpectedly and my team could handle everything. That's partly because they were great developers and stellar human beings. But pairing with small units of work and frequent pair rotation made it possible because there was no critical knowledge in my head.
This is key. With the team in my article, I had to take some extended time off to help with a sick family member. Even though it was a startup and I was the CTO, I could go away for a couple of weeks unexpectedly and my team could handle everything. That's partly because they were great developers and stellar human beings. But pairing with small units of work and frequent pair rotation made it possible because there was no critical knowledge in my head.
I can see the merits, but it also seems a rather joyless environment -- just do what Pivotal tells you. Was there any feeling of autonomy?
Sounds like the worry I used to have for a long time about todo lists and calendars in personal life.
I eventually realized that those tools are not meant to be your boss - they're only means of storing what you figured out when you had more time to focus on something. You can disobey them at any time, freely, but if you find yourself constantly disagreeing with your own todo list, it suggests you need to work on what you put in there in the first place. They're meant to optimize, not take away your autonomy.
(Shared todo lists, as it's what all those project planning / issue tracking tools essentially boil down to, is a little different thing because other people put stuff in it too, but the principle is still the same - it's not there to limit your autonomy, it's there to improve your focus and free up your memory.)
I eventually realized that those tools are not meant to be your boss - they're only means of storing what you figured out when you had more time to focus on something. You can disobey them at any time, freely, but if you find yourself constantly disagreeing with your own todo list, it suggests you need to work on what you put in there in the first place. They're meant to optimize, not take away your autonomy.
(Shared todo lists, as it's what all those project planning / issue tracking tools essentially boil down to, is a little different thing because other people put stuff in it too, but the principle is still the same - it's not there to limit your autonomy, it's there to improve your focus and free up your memory.)
This is a good point.
I think, for me, the possibility of a little bit of cherry picking is quite important for keeping it clear that the list isn't boss, and that's what I found so rigid about the original comment.
I think, for me, the possibility of a little bit of cherry picking is quite important for keeping it clear that the list isn't boss, and that's what I found so rigid about the original comment.
The Lean folks draw a distinction between controlling bureaucracy and supportive bureaucracy. I had never even known the second kind existed, but then I realized that whenever I made a personal to-do list, I was creating supportive bureaucracy.
We had the same "pick the next thing" rule:
http://williampietri.com/writing/2015/the-big-board/#toc3
We still had a sense of control, because the team jointly decided the order of the cards every week. If we thought there was a business or a technical reason why A should come before B, the product manager was great at hearing our notions. We all believed that the ordering was our best guess as to business value order.
But what we also got out of the rule was a sense of fairness. If I could go up and skip to the second card because I didn't like the first one, I'd be making a colleague take something I didn't want to do. Always taking the first card meant that unpleasant tasks were randomly distributed.
I should add that we were in a pairing environment and would switch pairing partners once or twice a day, so everybody ended up working on a variety of things anyhow. If you really wanted to work on something, you could just say so and get the swap to go in your favor.
So basically, we weren't just doing what Pivotal told us. We were doing what we thought was the most important work first, and we were handing it out in a way that was fair to everybody.
We had the same "pick the next thing" rule:
http://williampietri.com/writing/2015/the-big-board/#toc3
We still had a sense of control, because the team jointly decided the order of the cards every week. If we thought there was a business or a technical reason why A should come before B, the product manager was great at hearing our notions. We all believed that the ordering was our best guess as to business value order.
But what we also got out of the rule was a sense of fairness. If I could go up and skip to the second card because I didn't like the first one, I'd be making a colleague take something I didn't want to do. Always taking the first card meant that unpleasant tasks were randomly distributed.
I should add that we were in a pairing environment and would switch pairing partners once or twice a day, so everybody ended up working on a variety of things anyhow. If you really wanted to work on something, you could just say so and get the swap to go in your favor.
So basically, we weren't just doing what Pivotal told us. We were doing what we thought was the most important work first, and we were handing it out in a way that was fair to everybody.
(I work at Pivotal)
Tracker is only a communication medium. In such an environment you don't "do what Pivotal tells you", you do what you decided to do as a team, because as a team you prioritized stories in the backlog. That means, as a team, you have pretty high autonomy. You also have autonomy when working on stories, because they should only tell you what and why to do something, not how.
If have to compromise a lot to take team decisions, your team is probably not aligned very much. Do you share the same goals with everybody else?
For most people around me, joy comes from being productive, helping your team to make good products at a fast pace, and from interacting with people the whole day.
Tracker is only a communication medium. In such an environment you don't "do what Pivotal tells you", you do what you decided to do as a team, because as a team you prioritized stories in the backlog. That means, as a team, you have pretty high autonomy. You also have autonomy when working on stories, because they should only tell you what and why to do something, not how.
If have to compromise a lot to take team decisions, your team is probably not aligned very much. Do you share the same goals with everybody else?
For most people around me, joy comes from being productive, helping your team to make good products at a fast pace, and from interacting with people the whole day.
Interesting. Who puts the tasks in? How do engineering and product work together to prioritize short term business value vs long term business value?
I'm sure people do it many ways, but here's my approach:
Anybody can put a story in. (A story is some shippable unit of work that creates business value or otherwise improves things for some user.) Once a week, the team (by which I mean a cross-functional group of people committed to delivering value together, in the Balanced Team style [1]) sits down and talks about what should happen next.
This happens in the context of some agreed-upon set of long-term goals. In a startup, that's usually clear. In larger companies, a process like OKR [2] is a good way to make sure that a team has a clear purpose that meshes with the rest of the org.
The only hard rule is that the product manager has the final say on backlog order. But that's a power that should be rarely used; disagreement is usually a sign that people understand things differently, and that's worth sorting out. Often disagreements are worked out by proposing experiments. Questions of short- and long-term get worked out dynamically; in sane environments people are pretty good at striking that balance.
[1] http://www.balancedteam.org/
[2] e.g.:http://eleganthack.com/radical-focus-is-here/
Anybody can put a story in. (A story is some shippable unit of work that creates business value or otherwise improves things for some user.) Once a week, the team (by which I mean a cross-functional group of people committed to delivering value together, in the Balanced Team style [1]) sits down and talks about what should happen next.
This happens in the context of some agreed-upon set of long-term goals. In a startup, that's usually clear. In larger companies, a process like OKR [2] is a good way to make sure that a team has a clear purpose that meshes with the rest of the org.
The only hard rule is that the product manager has the final say on backlog order. But that's a power that should be rarely used; disagreement is usually a sign that people understand things differently, and that's worth sorting out. Often disagreements are worked out by proposing experiments. Questions of short- and long-term get worked out dynamically; in sane environments people are pretty good at striking that balance.
[1] http://www.balancedteam.org/
[2] e.g.:http://eleganthack.com/radical-focus-is-here/
Very insightful and well stated. Doing fewer things is a great way to define focus. Too many tasks in progress seems to lead to cognitive drain, perhaps due to all the context switching.
Sounds rather brilliant actually and a good rule of thumb.
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.
They forgot another step: uninstall Slack ;)
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.
Great read.
Anyone had a chance to read their book?
Do they back their practice by research?
Tired of pseudo sciency stuff...
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/...
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
I took some rough notes if you don't have time to read the whole book right now:
http://jamesstuber.com/deepwork
One more +1 to that. It's easily the most impactful book I've read in years.
+1 for "Deep Work" - very good!
Yea, whenever I see an article with that much sales copy mixed in I start to question everything that they're saying.
I noticed this too. They started off with a good paragraph about focus and mindfulness, and then they started embedding links to tweet stuff and download their free e-book.
Is this not the opposite of the intended effect?
Is this not the opposite of the intended effect?
Read Cal Newport's https://www.amazon.com.br/Deep-Work-Focused-Success-Distract....
I didn't read the free ebook, but it seem another one based on this book.
[deleted]
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.
Add status reports twice a day and you are on your way to eternal greatness!
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
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.