How To Do Less
alexturek.com
How To Do Less
1–10 of 74 posts
Re: How To Do Less
#2Great article and thanks for sharing; great applications in one’s personal life too. The author is very focused on hows of managing expectations of the technology team, and would love to hear his/her thoughts on how to manage expectations with the business.
Re: How To Do Less
#3Great article and thanks for sharing; great applications in one’s personal life too. The author is very focused on hows of managing expectations of the technology team, and would love to hear his/her thoughts on how to manage expectations with the business.
This is the authors take on that:
“Here are some concrete ways to tell management or stakeholders no.
This isn’t MAIN_PRIORITY, so we aren’t going to do it until at least ESTIMATED_DONE_DATE.
Right now our priority is MAIN_PRIORITY because of ONE_SENTENCE_JUSTIFICATION, and this is 100% our shipping focus.
I agree this sounds like a really useful feature - once we finish MAIN_PRIORITY, should we consider dropping SECOND_PRIORITY and do it?”
Re: How To Do Less
#4> unless you work at a 10 person company, the CTO has less context than you about reality “on the ground.”
From my experience people "on the ground" often miss out on the strategic long term goals.
Neither my take on it, nor the author's approach will be the silver bullet. Both are too extreme. And might appeal to different audiences on paper but not survive reality imho.
Re: How To Do Less
#5This could be a guide of "How to quickly get on the wrong side of a CTO".
Seen it happen.
Re: How To Do Less
#6This could be a guide of "How to quickly get on the wrong side of a CTO". Seen it happen.
What should someone do differently to have a more realistic workload?
Re: How To Do Less
#7> unless you work at a 10 person company, the CTO has less context than you about reality “on the ground.” From my experience people "on the ground" often miss out on the strategic long term goals. Neither my take on it, nor the author's approach will be the silver bullet. Both are too extreme. And might appeal to different audiences on paper but not survive reality imho.
This is the result of the "Us vs Them" mentality that so many developers have these days and boils down to a lack of trust.
If your CTO lacks context about your reality on the ground, then tell them the context. How else can they readjust what the priorities are? If you tell them and they refuse to adjust your priority then it's probably you that lacks context about what the goals actually are.
If you still disagree with that, then it's because you don't trust your CTO. If you don't trust your CTO then you should leave and find a better one.
If you have worked in a few places and have never trusted the CTO anywhere you have worked, perhaps you need to sit down and take a hard look at your yourself rather than others.
Re: How To Do Less
#8This could be a guide of "How to quickly get on the wrong side of a CTO". Seen it happen.
What should someone do differently to have a more realistic workload?
If history is any guide, commit to X, deliver X/5, then start Y. There's always time to fix stuff, never time to do it right.
A project manager inadvertently laid this out for me when I was new in my career; he didn't mean to put it like this, but this is what came out. (Note that I'm a software developer, and at the time the software I wrote was not "shelfware", but rather installed into big enterprises' data centers. Pre cloud)
NO ONE wants software done right the first time. Because, when you slam the happy paths out there for the customer as fast as you can:
* Sales wins because they can claim "Feature X" being sold and get their commission
* The customer wins because they get to complain about x or y being bad, incomplete, or whatever they want to whinge about and feel like they're part of the solution
* Customer Support/Sales Engineering/etc wins because they get to appear to be "responsive" to the customer by quickly reorganizing ongoing work to take care of the "urgent need"
* The Project Manager wins (2x!) because they can now a) do the same "response" dance for the C-levels, and b) berate the software development staff and show their authority and working under pressure skills
* Software Development wins because they can now work on the secondary features, fixes, "skunk works" tech debt, etc. since this is now more important.
Re: How To Do Less
#9This could be a guide of "How to quickly get on the wrong side of a CTO". Seen it happen.
What should someone do differently to have a more realistic workload?
I'm not sure. The business unit is always demanding more. I don't have a solution for that.
I just know enough from my brief stint in management that always saying "No" is a great way to get people to say you're "difficult to work with" or "aren't a team player".
That was a hard lesson to learn: "team player" means different things at different org levels.
Re: How To Do Less
#10Earlier quoted context omitted.
What should someone do differently to have a more realistic workload?
If history is any guide, commit to X, deliver X/5, then start Y. There's always time to fix stuff, never time to do it right. A project manager inadvertently laid this out for me when I was new in my career; he didn't mean to put it like this, but this is what came out. (Note that I'm a software developer, and at the time the software I wrote was not "shelfware", but rather installed into big enterprises' data center…
z) Customers are gonna complain anyway and ask for more, so better make 80% of the feature and see what they focus on.
z’) If we deliver 20% of the wrong feature, the customers are going to say it and we can reorient before we make the other 50%. #Agile
I’m not very satisfied either but the history of programming is riddled with us building overengineered solution to the wrong problem.