In this post, you will learn to manage your time to take the stress out of software management. You will learn about the Eisenhower principle and how to prioritize work, how to gracefully say no to work that cannot be done, continually identify and assign quadrants to all work, and regularly question yourself.
As a manager, you have plenty of work coming in, in many cases, more than you or the team can handle. This incoming work needs to be regularly triaged and evaluated for whether it is important and continues to align with your team's goals or whether it should be stopped or avoided.
What is the goal of a Software Development Manager?
- Meet Deliverables
- Maintain Team Health
- Maintain Product (or codebase) Health
- Prepare the Team for the Future
- Triage Incoming Work/Communicate Risks (a.k.a., establish a reasonable workload)
This maps very well to the management themes we established in the previous post: Customer Service/Experience, Growth, Excellence, Vision, & Delivery.
Anything that fits into one of the above categories is important, or in other words, aligned to what your team should be doing.
The Eisenhower Principle - Effective Time Management
Eisenhower recommended that we continually focus on what's important, not just on what's urgent. Work that's urgent is just work that's being asked for (or due) right away. In my case, I like to substitute the word aligned for the word important, because after all, what's the point of doing something that's not important?
So, what is work that's aligned? Work is aligned when it meets one of these categories:
- One of the management themes above
- One of your deliverables (yes, this is duplicated as the last item in the themes, but worth calling out separately since these often have timelines associated with them)
- Something your boss cares about - before you decide something is not worth doing, think about how your boss would feel if that work wasn't done: side-requests from marketing, cleanup of old records requested by another team, etc. If your boss wouldn't care if that gets dropped, you probably don't need to worry about doing it.
Example Scenario: Given the above chart, what items would you work on after finishing that crash and the critical feature? Marketing has been pinging you about how many of those fancy new devices are being used in production, Product wants to know how long it would take to develop a new feature that's not currently on the roadmap, and you've been getting regular emails about some improperly filed records from another team that wants to close out their notes.
Work in Order: 1, 2, 3, 4
If you follow the Eisenhower principle, you'll work first on the aligned items 1 then 2, and then the less important items 3, then 4. Yes, this means that improving your build times beats out those last minute side requests from other teams. Improvements are often overlooked because of deadlines, but if we allow ourselves time to improve regularly, we'll be able to get a larger payback than the original investment making the team faster and stronger in the process.
I would also advise to not even note down items from quadrant 4 since if they are not aligned and not urgent, who cares if they get done? You already have enough to do.
NOTE: For an excellent talk on prioritization plus an aside on the benefits of allocating dedicated time to do work, see Chuck Greb's well-timed talk (from Droidcon NY 2019) that beautifully illustrates this time-management principle in realtime. For tips to avoid procrastination on those tough tasks, read Bartek Franek's article: Pomodoro or Eat That Frog technique.
Gracefully Say No
Preventing additional scope is critical to keeping the team on track. Pressure comes from all kinds of places and it's so easy to just say yes when asked if we can bring in 'just one more' item. Learning how to push back gracefully or at least alert that the request is scope creep can sometimes be the difference between delivering on time versus not.
This varies greatly depending on your relationship with the requester and what's being asked. Each company has its own hang-ups around this topic. In many cases, not responding at all isn't appropriate. It's only fair to let people know you don't have time to work on a particular request right now and to not leave them hanging. Just flat out saying 'no' might not be an option either. You also need to be considerate and let them know you are not ignoring them, it's just in conflict with your top priorities right now and could be considered after that work is done. It's easy to ask them to check back in later.
Some examples:
- When a product or program manager asks for extra work, you could ask what work can be removed to accommodate the new request (very typical in a sprint/Agile setting). New work isn't free and you can't just keep squeezing more work out of a team without something giving. Ask what can be pushed back. If there isn't anything, maybe that request isn't needed right now.
- If it's a request from another team that doesn't align with your teams goals, maybe this work could be coordinated into a deliverable so at least the work is accounted for in a planned way as opposed to being taken on as an unexpected side request. It also might be good to examine why you are being asked to do work that doesn't align with the team's goals.
- If keeping documents or statuses up to date is a problem, maybe there is someway to automate the process or make it more efficient so those extra clean-up efforts are no longer needed.
Continually Identify and Assign Quadrants to All Work
A famous quote from Eisenhower is "Plans Are Worthless, But Planning Is Everything". To me, this means regularly triaging your incoming tasks so you don't get bogged down by the unimportant things just because they are the newest.
As new work comes in throughout the day, figure out which quadrant it needs to go it and place it in there accordingly. When you have time, you'll get to it. This prevents you from just jumping onto to the latest and shiniest new feature or task. Think about how important it is before working on it and whether or not it's something your boss would care about.
It's useful to have a list for each of the main topics you need to focus on in your favorite note taking tool (Joplin is a wonderful cross-platform tool for this) and have an entry for each quadrant (again, skipping 4 - because really who cares?) for each main focus area. In my case, throughout the day, I'll scan through this list starting at number 1 and working my way downwards to make sure I'm on track.
Regularly Question Yourself
Your boss wants to know two main things: what are your deliverables and how well you are doing towards meeting those deliverables (i.e., your risks). Start your week getting a handle on where your deliverables are at: if there are blockers, then find out when they will be unblocked, if timely work is due, then what is the estimate of it being finished, if you have a dependency on another team, then when will they finish their work? Always ask for a date and if one can't be provided, then ask for a date when you should check back again. Setup a calendar reminder right then to check on that particular time to follow up and update the plan accordingly. If your boss is always clued in, then this will be seen as being proactive and you will be asked for fewer updates. Err on the side of sharing too much.
How is the team health? Do people enjoy what they do? No idea? Run a health check retro to baseline what the team is feeling and use that feedback to make improvements. It needs to be specific though something general like "We have too many meetings" isn't that helpful. Which meeting? Can it be streamlined, made asynchronous, etc.? Do you have regular one-on-one sessions setup with all your reports (I prefer every other week, but individuals will vary and some may not want to meet at all - let the team tell you what they prefer).
What about the product(s) that you support? How is performing? If it's end-user facing, what does customer feedback tell you? If the product supports another team, ask them for feedback and what they'd like to see improved. Otherwise, product and marketing teams can help out a great deal here to find out if customer needs are being met and what gaps are there. If the crash rate is too high or performance too slow, create tickets to address them and get that work on the backlog.
Thinking about the future, what are the bigger trends? Are there certain features that are frequently requested that could be made easier in the future? Are there any looming technical updates needed? There's no easy answers here, lean on your engineers. Guide them to think about what would help them make development easier in the future and put them in a position to act on it.
