When it comes to deadlines to technical teams, ask—don’t tell.

I recently read Mark Williams' anecdote about not assuming managers know what they're doing just because they're managers. That anecdote made me laugh, but it also made me reflect on how much stress this causes in the workplace.

I don't mean to say that most managers aren't good at what they do, I've been one and I know the stress and sense of responsibility that goes with the role, but I do think it's time to examine the role of managers in the modern workplace. This especially applies to IT projects that often suffer from unrealistic deadlines, expensive missteps and missed opportunities.

Agile can help. It offers strategies that systemise the process of consulting all team members and devolving responsibility away from a single point of control and command towards a culture of group problem solving and consensus for time estimates.

Managers can't know the details behind every task in the team

There seems to still be an outdated assumption that managers know, or should know, how to do every task their team does. This may still be possible in some industries, but in IT and any other team made up of cross-disciplined professionals, it is unreasonable to expect managers to know how to perform every role.

This assumption puts unnecessary pressure on both managers and team members. Many of us have evolved into management positions learning our management style from teachers and our own managers. It's easy to absorb the notion that strong leadership means setting aggressive deadlines, making unilateral decisions and treating our team as potential slackers.

This will cripple a team over time. This is also why a key Agile pattern involves designing solutions and estimating times as a group. Managers should be listening more than talking.

What's in a name? The word 'manager' is fraught

Managers have important roles to play in the modern workplace, but I don't think it's what many of us unconsciously assume. The words manager, boss and director all imply some level of domination. Of the 20 or so teams I've worked with, I can tell you that those that were led by people who were managing, bossy or directive were not the happy productive ones.

I wonder if it's time for a change of language. Perhaps we could replace the word manager with coordinator, facilitator or enabler? The Agile roles of Scrum master and iteration manager still imply authority over others, although hopefully the Agile rituals and philosophies help maintain a culture of consultation over control.

What are the responsibilities of managers?

So what does the new manager look like? What should we be doing? I subscribe to the basic philosophy of 'high expectations, high nurturing' with the emphasis on 'nurturing'. From both research and observation this philosophy appears to foster happy, effective, ambitious, loyal teams.

I think the key functions of a manager are to:

• Set the tone: create the right culture for the team to do their best work

• Set goals and inspire: clearly define what the team should be working towards

• Consult the team: ask the team how to achieve the group's goals

• Protect the team: minimise distractions, context switching and changing priorities

• Coordinate the team: facilitate collaboration and avoid duplicated effort (but continuously work towards a self-coordinating team)

• Manage expectations: explain deadlines, challenges and manage up the chain

Trust and consultation

I think a lot of managers feel the weight of their responsibility. Many think they need to have all the answers or they will lose the respect of their team or their own managers. The reality is, however, that most teams respect us more if we consult the team and ask for help where we need it. This also makes it OK for team members to likewise consult and seek help. Teams love to know that their managers trust them and recognise their expertise.

Always consult your team before setting deadlines

Consultation is especially critical when setting deadlines. A manager should never set important deadlines without consulting the team members directly involved.

Pretty much everyone I've ever worked with is guilty of underestimating the complexity and time a task will take to complete. This applies to our own work, and even more so to the work of others (check out the Dunning-Kruger effect that demonstrates that the less you know about something the more confident you are that it is probably quite easy). The rocks are often hidden beneath the water.

I have consistently seen people driven to misery, illness and resignation because they have managers who think they know how long tasks should take and consistently allocate unrealistic time frames.

Even in Australia, traditionally a country of easy-going rebels and larrikins, many of us struggle to push back against unreasonable workloads and time-frames. I think this is often because we assume that our managers know how long a task should take and if we can't finish a task in that time, then it's our own fault for being slow, distracted or inept.

Some of course see this as a necessary game: manager sets unrealistically short time-frames on the semi-joking/semi-serious assumption their staff will slack off a bit or are over-inflating times to manage expectations; team members 'push back' and do over-inflate times on the assumption that their manager doesn't understand the full complexity, or is likely to insert additional tasks (often admin and ad hoc), or will berate and demean them if they can't finish on time.

I see this as a very destructive game that leads to stress, division and mistrust. If you can't trust your team to estimate honestly, you have a problem. If you can't trust your team, you have a problem. Trust goes both ways, managers need to trust that they team won't over-inflate times and will come to them early with potential problems, and teams need to trust that their manager is there to help and support them, not to make them feel like failures.

Alternatively, get your hands dirty

So as a manager, if you're not willing to consult and listen to your team members, you owe it to the organisation/team/project to roll up your sleeves, take a deep breath and delve into the details. Actually take time to understand the problems and the solutions. I think this is good general advice, because often knowing the details can help managers make better decisions.

The trick is, however, that different people are good at different things. Many managers I know are good at wrangling people and 'big picture thinking' and not so great at the details. If this is the case, I suggest you find someone in the team who can explain things patiently at the right level of detail. In IT projects, I find this person is often the business analyst or dev lead.

But beware: if you dive into the details, it must be as a peer, not an authority figure. In fact, I suggest you go in with deliberate humility and remember you are learning from an expert who is doing this day in and day out. Sure you can suggest alternatives and challenge conventions, but avoid overriding people or pulling rank. I have seen managers that think they are just brainstorming with the team, but the team assumes that the manager's opinions are actually directives simply because of their rank.

Just use Agile, OK?

Agile is very close to a magic bullet for many of these issues. Specifically transparency and consultation about task complexity and expected time-frames. Agile doesn't always prevent long hours, but it does give the team a sense of accountability and focus, it encourages realistic deadlines, and it breaks down the idea of the 'manager-must-know-all' which isn't good for anyone.

I'd love to know your thoughts on this - managers and team members alike.

Kylie Weaver

Founder of Clearly Focused Pty Ltd