This Is The Way (Respecting Developers' Time)
Focused on Productivity (Part 2 of 2)
Hey, fellow Leader 🚀,
I am Artur and welcome to my weekly newsletter. I am focusing on topics like Project Management, Innovation, Leadership, and a bit of Entrepreneurship. I am always open to suggestions for new topics. Feel free to reach me on Substack and share my newsletter if it helps you in any way.
This article is a series of two pieces, containing 5 ways a Manager can respect the developers’ time. Is mostly to create awareness about some practices that might be important for the development team. Especially in situations where the project might need some extra effort from the team. The first article is available here:
3 - Plan with the team
While producing the project schedule is important to have the team’s feedback. It’s normal that after spending hours, and sometimes days, to craft the perfect project schedule, to address different dependencies and expectations, it becomes normal to feel the plan is bulletproof. However, the majority of the work will be executed by the team and the team should have an opportunity to voice their concerns. For that reason, is important to share the project schedule with the team before the official communication to key stakeholders and sponsors.
The team can provide valuable insight and be the first to know what will be communicated before becoming official. It’s normal to have some pushback from different people on the team. Some pushback can be related to the feasibility of some features, and the risk of the time not being enough. Others can be to understand why decision X or Y was made. Is important to have an honest conversation about the schedule with the team and share your insights as well.
In a previous project related to an infrastructural migration, the rollout needed to happen before a given date, no matter what. So my focus was putting in motion plans that could accommodate the objective. There was a lot of uncertainty about how things should be addressed. Most of the pushback I received was related to the risk aversion of certain team members not liking to have commitments without a clear path to a solution, and uncertainty about how much time certain configurations would take. The planning that was presented to stakeholders had several conditions and assumptions that if met, the given dates could be achieved. In addition, the schedule had several countermeasures if situations A or B couldn’t be met. It was a comprehensive plan about how to arrive at the goal within the given timeframe. This plan was made together with the team.
2 - Be careful with last-minute requests
The leadership part of any project has access to key information which is later used to define priorities. Is important to avoid constant changes in the team’s priorities, due to their consequences on the work produced and potentially trigger some fatigue or frustrations. This is done more easily in some projects than others, however, changes in priorities are bound to happen eventually. For that reason is important to avoid changing priorities on a developer by mistake.
Because of the nature of the Management job, every time a new task is requested by a developer the impression on the other side is the new request has high priority. When in practice, the manager might only assign a specific task in case the developer becomes idle or blocked on another task.
The perception from the Developer side is that everything that comes from Leadership is a priority. When in practice, this is not the case. Is important to communicate the priorities every time a new task is assigned, to specifically align expectations and avoid changing to lesser important tasks.
Is highly important as well to avoid assigning high-priority tasks that need to be completed on short notice. Changing priorities creates a certain level of mental fatigue to who is executing the task. If the change of priorities happens too often, due project nature or by mistake of assigning a new task, the manager is involuntarily increasing the project stress levels and team fatigue. Doing it too many times will result in turnover.
1 - No micromanagement
The worst thing a manager can do is micromanage the team’s member work. With constant status update requests, to go through every inch of the work that is being done trying to find a flaw or an error, or any other type of time-consuming activity that steals the team member’s valuable time to work on the project.
Managers might be blind to the effects of micromanagement, or even not realizing they are doing it. If a manager has a habit of asking about status multiple times in the day, multiple days, with multiple types of tasks, this might indicate a syndrome of micromanagement.
Another side of micromanagement is the lack of empowerment inside the team. A side effect easily detectable is if team members feel the need to ask the manager’s opinion for every simple and single decision related to the project tasks. This is particularly tricky to handle because from the manager’s perspective, having a team constantly asking for validation for decisions regarding the project, might feed a blind spot. The alert should be raised inside the manager’s head if the validations the team requests are simple and trivial, and ask him or herself why the team is not taking these decisions autonomously.
Micromanagement is a very tricky subject because can feed the manager’s validation of the work at the expense of the teams and project in the long run.
That’s it. If you find this post useful please share it with your friends or colleagues who might be interested in this topic. If you would like to see a different angle, suggest in the comments or send me a message on Substack.
Cheers,
Artur