In my career so far as a software engineer one of my biggest issues is planning and accounting for my work. I fall into a couple of common traps that I think most people do including underestimating work and not splitting work apart enough. Both issues come down to not enough planning though. I’ve noticed and been told by more senior engineers that these are key issues that will prevent you from taking on more significant roles. In fact, as engineers progress higher up the ladder more of their time will be spent on planning work and splitting it out for other engineers to work on. So to be a more successful engineer and provide more value to my team this is a soft skill I’m actively working on.
A key method that helps me is always starting with a write-up. The writing doesn’t have to be a full document, it can just be a paragraph in a ticket with the steps I think it can be split into, but for any decently sized piece of work a document is almost always helpful. Writing a document then clearly shows what the problem is, if you’re writing it correctly, and gives detail on how you plan to solve it. This alone is a key amount of work because you can generate buy-in from teammates, have issues pointed out you may have overlooked, and split work for other people to work on. It’s a common issue for an engineer to be assigned something to work on and progress linearly through the work without future planning. This means at most one person can work on this project at a time. If it’s a large project it means it could take someone a whole year or more. Additionally, once the project is done no one else will feel comfortable in maintaining it. However, it’s easy to fall into because engineers feel attachment to their project and a sense of pride for delivering it.
Depending on your team the planning methods will vary widely, and no one planning method will work for every team. However, I’ve recently been experimenting with one size tasks. With this approach our team takes an issue and splits it into more issues until the task can be accomplished at it’s smallest unit. Typically, at this point it will be a day or two of working. This isn’t perfect as sometimes new issues will be encountered only when you start working on it, but then the issue can once again be split. This can be a better way to show progress across a team as if someone takes one ticket for a huge feature it will seem like progress is never made. Additionally, its then harder to get up to date on a feature if you have to look through a large backlog of work for an entire service. The added bonus to this is that a more senior engineer can spend time disambiguating complex tasks and then junior engineers with less state on a project can pick up tasks that build towards completion. Overall, I’ve preferred this method to simply setting a day value (this bug will take 4 points) as I have a greater feeling of accomplishment and I can check with my teammates to ensure I’m on the right track, or give someone else a bug to help me out with my workload.
I hope some of my thoughts on developing my planning skills help you out!
Leave a Reply