The hardest thing to do if you’re a knowledge worker is to deliver your project on time.
It’s not actually hard to complete well-defined tasks. It’s much harder to complete a whole project. What makes it so much harder is that you have to choose day after day, week after week, what to work and in what order. As a software engineer, I’ve seen a lot of projects derailed by scope creep and working on things that really didn’t need to be done.
The bread and butter of knowledge work is figuring out what needs to be done, in what order, and what can be cut.
It’s more important to finish your project on time than to do everything but the kitchen sink.
Do you really know why you’re working on this project?
You need to clarify with whoever gave you this project, the real reason why they asked you to do it. If you know why you’re doing this project, then you can figure out how to prioritize and what to cut.
Often projects are created to satisfy some larger goal or metric that someone else is asking for. In software engineering, the most common task that derailed people would be projects to integrate with another team — migrate to a new library or system. People would inevitably play a game of phone. And by the time someone got the project, the requirements and the reasons why would be heavily distorted.
You will find that maybe you’re doing a project because someone has a goal such as to reach 80% migrations or to get load times under 200ms. You should also figure out who really cares about that goal — who’s responsible for that goal?
Negotiate with the key stakeholder.
Cut down the scope or reprioritize the project so that you deliver incrementally.
Skip the side quests.
Unnecessary work comes in two flavors: stuff people think you should do and stuff that you think would be cool. You’re doing unnecessary work because you didn’t stop to evaluate whether it was necessary. The #1 reason projects take longer than their estimate is because of scope creep.
Eliminating work is the fastest way to get it done.
You should always rearrange your project into smaller deliverables.
Phases help unblock other people sooner. And frequently the next phase isn’t necessary or isn’t the most important thing for you to be doing.
Projects develop iteratively. You do a small piece, you look, and you reevaluate. What’s still necessary? If you ran an experiment and showed that whatever you were doing wouldn’t actually help with the ultimate goal (see point 1) then you can avoid a lot of unnecessary work (see point 2).
If your project is complex, you’re bound to work with other people and other teams. You may not be able to work on that second phase until someone finishes their part.
Delivering in phases decreases the iterative cycle time so that you can reevaluate and take the next best step.
Know what’s most important, least important, and why.
People make assumptions about why something is more important than another thing. In sprint planning meetings, we would stack rank tasks for individuals or for a specific project. Regularly, our tasks were no longer necessary because their assumptions were wrong. At the end of the day, the lowest tasks would often go uncompleted because they weren’t must-haves.
When you clarify your priorities, you avoid unnecessary work.
Don’t wait for your 1-on-1s.
The biggest time-suck for software engineers is getting unnecessarily stuck. As a lead on the team, I felt bad whenever people were grinding on a problem that I knew the answer to. There might even be solutions that already exist for the problem that you’re trying to solve.
It’s okay to cheat at work. Copy from others and use what they know.
That point is to deliver your project on time. You don’t need to do it all yourself.