This could be a guide of "How to quickly get on the wrong side of a CTO". Seen it happen.
For what it's worth, the author's CTO is the one that shared this article ;)
Former* CTO. That is no longer accurate
How To Do Less
71–74 of 74 posts
Re: How To Do Less
#72It sounds like this is just an exercise in, not learning, but being forced to say "No" (a lot) out of a need for mental survival...in a work culture where priorities are constantly shifted (and this is the key).
Instead, foster change where you can say "Yes, and" or "Yes, but", where there is a common understanding that sure we can work on it, eventually, as it's going into the backlog, that will need to be prioritised, or it goes at the bottom of the queue as any new thing should - as what is already in the queue, should already be prioritised.
Obviously what is already in the stack can be shifted around as the business needs may necessitate the change in priority...but popping shit at the top of the stack constantly...that's not where you need to learn to say "No"...that's where you need to learn to say "Bye".
Re: How To Do Less
#73The prioritization tip reminded me of "Final Version" productivity system that I personally like. It's just one big-ass list of everything and you pick and do stuff at random (more or less). Yes, it sounds silly, but I found out that it works better than constantly re-ordering goals. :-) http://markforster.squarespace.com/final-version-faqs/
Mark Forster is a hidden gem!
Re: How To Do Less
#74I'm currently reading through Johanna Rothman's "Manage Your Project Portfolio" and related literature and a bunch of this resonates: * Finishing work is more important than starting it * Teams working together on a single priority ("swarming") seem to be more successful than teams where each person is doing 1-2 things on their own A few subtle points in this article that made me think: * Keeping existing features wo…
> Teams working together on a single priority ("swarming") seem to be more successful than teams where each person is doing 1-2 things on their own It's an interesting one, same as e.g. pair programming; people (and I'm speaking for myself but I'm sure others will agree) prefer to work alone, because software engineering is difficult, brainy work, whereas swarming and pair programming are social activities. If you're…
I think this is not referring to swarm-, or pair-programming. Think of it as the team focusing on a single feature/problem at a time. It just means the team going in the same direction.