41–50 of 61 posts
It works surprisingly well to keep me focused on the task at hand :)
In sideprojects that are early stage, I have a todo.txt in my repo with one line, the thing I have to focus on. I keep this thing small in scope. Once it's done I replace it with another thing that's in my head. It works surprisingly well to keep me focused on the task at hand :)
But once I'm done I have lots of options to choose from. This helps me pick something that I have the energy for instead of getting stuck in 1 tangenital task after another which can feel a bit repetitive.
These days I just have a list of weekly objectives (TODOs), and a daily list of things that I'm "doing". The doing list is based mostly on gut feel about what's important right now, and is in part - based on what my team / the business feels is important right now.
All the things in the weekly objective list are always high priority / important, if it isn't, then it doesn't go on a list.
Earlier quoted context omitted.
Strongly agree with this. One thing I realised is, startups should spend more time optimising the decision of their top priority, and less time optimising efficiency. There's no point working on the wrong thing with 100% efficiency.
I have seen teams spending most of their time on working on the highest priority (by a single measure) and not spending any time on overall delivery efficiency. So having a balanced prioritisation approach would seem to be pretty important.
A good bit of literature is starting to dispel the notion of the iron triangle, speed is quality, quality is speed.
In the first phase, there are a ton of unknowns. You don't know what all the technical challenges are, so it's difficult to even estimate how long the project will take. As such, I think it's more important to take on tasks that have the most number of unknowns. Your goal here is to unearth any "unknown unknowns". You end up prototyping a lot at this stage to prove out ideas, and the work here will naturally generate even more tasks for you, but that's a good thing as it's better to find that out now rather than later, when you think "you're almost done" and then have to push out the schedule a ton because you find some technical limitation that would sidetrack your entire project.
Eventually, once you get through this "discovery" phase, you get to a phase where you generally know the big pieces and have a way better idea of what the big technical challenges are.
You now have a long list of tasks and how long it would take if you did absolutely everything. You won't do everything though since you don't have all the time in the world. Now you enter the "get it over the finish line" phase. I think at this point you just draw a line in the sand and say "we ship on this date" based on what you think you can ship for your MVP and given the list of tasks. You prioritize things would prevent you from getting across the finish line.
This is a pretty coarse way of looking at things, for sure, and there is a middle phase in there where you just execute through tasks based on lighting up features or demo'ing progress to stakeholders, but I think looking at it as "discovering" and "finishing" is a simpler way to ensure you're not just spinning your wheels doing tasks just because they're there.
I see these kinds of posts a lot on here. This one is just like all the others. Trying to reduce effort/reward down to some kind of scoring method.
It's probably correct, but now the problem just moved to accurately scoring each task on a variety of scales. What I find more and more is that it's very hard to see beyond the tasks and figure out side effects of finishing some task or feature because it quickly gets very complex and if you spend time on really thinking it all through to the point where you're certain about the right order, you probably could've kno…
There's no reason why picking any one of them would give a reasonable priority of tasks, other than some mysterious mathematical astrology, while aimed to reduce the amount of intuitive guessing is composed entirely of intuitive guessing.
For me, I think of projects as sort of having two phases: the discovery phase and the "get it over the finish line" phase. In the first phase, there are a ton of unknowns. You don't know what all the technical challenges are, so it's difficult to even estimate how long the project will take. As such, I think it's more important to take on tasks that have the most number of unknowns. Your goal here is to unearth any "…
The right people in the right room Most tasks on most task lists are not tasks - they are wishes or outcomes Prioritising outcomes is easy. Do we get five new corporate customers this month or do we build a web scaling system on AWS. One is a task, one is an unknown project with no clear definitions or starting process. Which is why many startups have great infrastructure and not enough customers. So, unless you know…
It's interesting that I worked with a company that had a strong sales department but a weak (or non existent?) IT department. Getting five new corporate customers was a task for them. But setting up an AWS EC2 instance with an RDS server? That was an investigation that is requiring a trip to Singapore.
For me, I think of projects as sort of having two phases: the discovery phase and the "get it over the finish line" phase. In the first phase, there are a ton of unknowns. You don't know what all the technical challenges are, so it's difficult to even estimate how long the project will take. As such, I think it's more important to take on tasks that have the most number of unknowns. Your goal here is to unearth any "…
https://basecamp.com/shapeup/3.4-chapter-13#work-is-like-a-h...