Ineffective pushback to a pushy manager?

How do you deal with a manager who believes that a software development team needs to go faster and should be pushed? I want to review some of the responses to my earlier blog and test the idea that they would create a productive conversation that would lead to effective outcomes.

Just an ordinary reflection
How does our advice look if others reflect it back to us?

What were the responses?

I got responses from the the earlier post’s comments, twitter and the DZone Agile centre that were mostly from the team’s perspective.

I believe that the responses were intended to be helpful to someone in the manager’s position and raise some important issues. I’ve seen the results of teams accepting a request to “push harder” and in the majority of cases these have been ineffective, demoralising and created more problems down the track. My intent with the earlier post was to encourage a manager with these views to find a way to discuss differences in views in public in order to jointly design productive ways forward.

When handling issues that generate strong points of view it’s important to focus on not just ‘what is right’ but ‘how can I communicate this effectively?’

I’ve summarised some of the responses under headings from the three assumption level ‘rungs’ of the ladder of inference

Explanations:

  • Thinking that pushing a team to go faster is a dysfunctional view and implies little intention to help
  • The causes of poor performance are a management issue
  • It’s probably not a speed of development issue, usually it’s about prioritisation and communications

Evaluations:

  • There are too many assumptions in the question “how can I push the team to go faster?”
  • Just going faster is the wrong goal
  • Going faster or pushing wont help you reach your goal

Predictions / Proposals for Action

  • Pushing has never worked and will never work
  • Talk about it differently – say “pulling or enabling” to remind you that it’s about you helping remove impediments
  • Focus on removing obstacles not “pushing people”
  • The first step is for you to ask the team what you as a manager can change or what you can do to help.
  • Ask yourself “is it a pattern that I keep having to push teams to go faster?” If lots of projects require a push then it’s not the team that’s the problem, it’s your planning!

Unjust high-level negative assumptions?

Looking at the comments from a manager’s point of view, they come across as high-level assumptions that are often negative towards the manager.

My assumption is that the responses were in reaction to the perceived unjust negative evaluation implied by a manager even considering “how could I push a team to go faster?” (the headline of the earlier post).

This highlights the importance of a manager with these views clarifying what’s behind them, and sharing them with specific concrete examples, to avoid creating defensiveness in the responses and becoming stuck in a point-counter-point argument.

It intrigues me that some of the responses may have created the same impact for a manager that they felt manager’s views had on them.

What would a manager think if told these views?

I realise that many of the responses were not intended to be directly said to the manager, but if they were I believe it would create defensiveness in the manager.

I doubt that the manager would feel listened to or understood.

The views were mainly stated in strong, rather than tentative terms. There was no mention of asking for more detailed observable data from the manager or any inquiries into what was behind the manager’s view.

How would people would avoid these negative views “leaking out” into the conversation through body language or tone of voice? As a manager (share your views in the comments) I could imagine thinking:

“These responses show people reacting defensively before they’ve listened or understood my view. They are telling me I’m wrong to think this way and I should start by asking how I could be different. It just shows that you can’t talk to a team about these issues”

Skilled unawareness and skilled incompetence?

Some comments advised the manager to take the team’s perspective and ask the team what they might be unintentionally doing to hinder the team and how they as a manager could help. This is useful as other people have a great ability to spot gaps or inconsistencies in our behaviour. Learning how to honestly ask for help from others is a worthwhile practice.

Yet, there was limited evidence in the responses of following that advice and thinking things through from the manager’s perspective and asking how they might be unintentionally contributing or how they could help.

This is an example where people, acting with good intentions, may be skilfully unaware of the fact they’re not following their own advice to others. This relates to the skilled incompetence demonstrated at a recent Agile workshop

I’d welcome your views in the comments. How productive do you think the responses would be if communicated to a manager? If you wanted to respond more productively to a manager who thought it was necessary to push the team what would you say or do?

Benjamin Mitchell's Twitter ProfileHi, I’m Benjamin. I hope that you enjoyed the post. I’m a consultant and coach who helps IT teams and their managers consistently deliver the right software solutions. You can find out more about me and my services. Contact me for a conversation about your situation.

Image Credit: Steve-h on flickr

About Benjamin Mitchell

Hi, I’m Benjamin. I hope that you enjoyed the post. I’m a consultant and coach who helps IT teams and their managers consistently deliver the right software solutions. You can find out more about me and my services. Contact me for a conversation about your situation.

10 responses to “Ineffective pushback to a pushy manager?”

  1. Matthew Cooke says :

    Twitter is not the easiest place to discuss this due to max tweet length.

    When I said “it’s usually a management issue, so a first step is asking them what management should change to help them be more productive.”
    I was suggesting to you, that in situations where a manager is asking “how do I push my software development team to go faster?” to an external advisor, there are *likely* to be more serious problems in how the dev team and dev process is managed. In all likelihood these problems probably need addressing more urgently than the question he wishes to ask. Whilst the dev team may be able to help, I suggest the manager may need substantial assistance beyond what they are actually asking for help with!
    I was giving this advice largely as someone who manages a team and not as a developer.

    You say:
    “It intrigues me that some of the responses may have created the same impact for a manager that they felt manager’s views had on them.”

    This is another good reason to try and help the manager understand that asking the developer this specific question, phrased in this way may not have the effect he wants. The question as phrased is unlikely to have a positive impact on the developers and the feedback received from any honest developers is also unlikely to have a positive impact on the manager.

    With good managers running good teams it feels like they are within the dev team, working on it’s behalf against external problems, helping the team run as efficiently as possible, and helping make sure they are working on the most useful stuff for the business. In this situation the question would be be “how can we run faster?” “how can I help you guys to run faster?”

    Of course all this is guess work, based largely on my experience of the kind of manager who would ask this question. Similar questions that I’ve heard in the past “Won’t the dev team run faster if we just make them all work overtime?” Well, to me, the lack of understanding involved to be asking these questions is just astounding for someone managing a development team.
    Perhaps a good starting point for managers who want to push teams to run faster or force people to work overtime, would be the book: Peopleware – Productive Projects & Teams

    • benjaminmitchell says :

      Hi Matthew. Thanks for engaging with me on this topic on twitter and now in the comments. I’m with you that it’s stretching Twitter to the limits to try and have this kind of multi-perspective, reflective conversation in 140 characters. It hasn’t stopped me doing it though :)
      I agree with many of the points you raise, such as:

      • that improving the team’s productivity can involve issues related to the development team and development process is managed
      • the problems related to the management may have more impact and may need to be addressed before looking at actions within the team
      • if the manager were to ask “how can I push you to go faster?” directly to the team it would be unlikely to have a positive impact on the team or lead to an effective response from the team
      • in well managed situations there is a sense of managers working with the team to help achieve the best results

      My interest is in how to create conditions and guidance for teams and managers that would be more likely to lead to a productive dialogue and good outcomes.
      I love the Peopleware book and I’ve had situations where I was “astounded” reaction when managers didn’t see things the way I did. My experience has been that simply telling managers I’m astounded and they should read a book to understand the way I see the world wasn’t effective for me, the manager or the team. If you’ve had a different experience I’d welcome you sharing more about it – I’m open that the way I’ve handled it could have contributed to my outcomes and am keen to improve.
      My view is that seeking to ensure the manager with the view that “going faster” is needed and “pushing” might work feels at least that I’ve listened and understood their point of view. I find this challenging when people don’t see the world the way I see it, but I think that’s my issue to deal with – to look for ways to explain my view in a way that makes sense to them, and inquire into their view so that we could jointly design a way forward.
      Thanks again for contributing.
      Benjamin

      • Matthew Cooke says :

        The very negative sounding things I was saying to you are obviously not things I would say directly to the manager if I was advising them! It would be like my wife telling me I should clean the house more, and by the way I didn’t even really understand the concept of cleaning so I should learn that first because I’m crap. Whilst my wife may be right, of course this doesn’t put me in the best phrase of mind to start discussing all my new cleaning chores :)

        I think if I were in your situation (and I honestly don’t envy you much!) I would:

        Try and find out what they really mean when they say “run faster” (let’s ignore the “push” bit initially because in this case “push” is some vaguely implied solution to a not very clearly defined problem)
        Step one is probably just to get a clearer understanding of the perceived problem.

        Perhaps he thinks the developers are wasting their time on things he doesn’t think is important, perhaps things are taking longer than the predicted estimates, perhaps he thinks the estimates are too big, perhaps he thinks they spend all day on email, etc,

        After you understand the problems as he perceives them in more detail, how to move forward with the team may become more clear.

        If he simply wants to improve long term performance of the team, then the developers (if they are good) are likely to be full of suggestions, most people want to do a good job! Typically good ideas that developers may come up with in a discussion about improving performance:
        Fix bugs first (or more bugs)
        Test driven development.
        More automated testing and monitoring.
        Code review or pair programming.
        Investing time in tools.
        Improving processes.
        Working closer with stakeholders to make sure that highest value work is done first.
        Invest more time in refactoring and improving long term code quality.
        Leave code as you would want to find it.
        etc, etc,

        A common issue is that developers often feel pushed by management and have either dropped or failed to implement a lot of things that they know are actually good idea, this results in very very short term wins but huge slow downs in longer term performance. (Again, this is probably not something for you to say, but perhaps it would come up in a discussion with developers).

        It is hard for me to avoid jumping ahead and make the suggestions (purely because the same problems span so many software teams) but as an advisor I think it’s probably best to go slowly!

      • benjaminmitchell says :

        I like how you’ve used the analogy of your wife talking to you about cleaning to demonstrate what the impact of saying some of the views you’ve written might have had on the “pushy” manager.

        I still frequently jump to (negative) conclusions when I hear certain terms – “gantt chart” used to be one of them but I’m better now :)

        The question I ponder is “if we have these thoughts that we couldn’t share publicly with the person involved, what is the value of them?” I worry that holding onto thoughts like these will mean that we fall into a confirmation bias position where we naturally start filtering what we see and hear so that we only look for things that support our negative view of the other person.

        I can relate to the concerns from a developers point of view – I think there is a future blog in “how to response to a pushy manager” that might cover the topic of helping developers avoid feeling pushed into a situation that they predict wont be effective.

        Thanks again for continuing the conversation with such a rich response!

  2. Jesper Boeg says :

    What?? Are you claiming that managers are real people? What a crazy concept :-)

    Unfortunately I have been guilty of all of the above mentioned anti-patterns when trying to make managers realize not to push, stress and force the software delivery system beyond its capacity.

    It’s just too easy referring to various studies and theory proving them wrong and stuffing it down their throat rarely helps. What you need to do is actually talk to them and try to see the world from their perspective, but first and foremost you need to offer them a valid alternative (helping them reduce scope, more data or whatever they need) Sometimes it even turns out they know it won’t work but they are pressured from others to show some kind of action. And really action is a key word here, push is almost always the result of some kind of problem (only once have I seen real push in a situation where everything went well) and as a manager you are expected to fix the situation somehow. Not doing anything is therefore not really a valid alternative though it might be the most sensible thing to do. Since pushing is the easiest and traditional thing to do most managers revert to this anti pattern when faced with difficulty and it is up to you to offer them a valid alternative if you want to change the situation.

    As always, it has a lot more to do with people than process. If you do not try to look at the situation from the other person’s perspective and find a common ground, no amount of Agile and Lean product development theory will change the situation.

    • benjaminmitchell says :

      Hi Jesper,
      I really enjoyed your comment! I find it a challenge to practice having empathy or compassion for the possible reasons behind a request, such as needing to appear like they are “responsive” or “doing something”. Working out how to present the case that not reacting is the most effective strategy in a situation is a formidable challenge, and one I’d welcome hearing others experiences with.
      Benjamin.

    • Matthew Cooke says :

      I agree very much with this advice. When lot’s is going wrong, scope reduction, prioritisation and focussing on small concrete deliverable “wins” gives something concrete to cling on to.

      Imagine there is a guy riding an exhausted donkey that hasn’t eaten or been looked after and the guy wants to get to the ‘city of gold’ but actually it looks more likely the donkey is going to collapse and he’s asking “how can I flog the donkey in a more effective way so that I can get to the city of gold faster?”

      Probably I would say “look, you think the city is that direction right? Let’s give the donkey some water, and a bit of food, stop flogging it for a minute, and just focus on getting it into the next village by mid afternoon”

      If you can achieve that, the guy is happy, gives the donkey a carrot, the donkey is happy and well they aren’t at the city of gold yet, but perhaps they are one step along the way.

      Okay after that ridiculous last two paragraphs I’m going to eat dinner.

  3. Gus Power says :

    I’ve been in this situation on occasion :) Two things come to mind.

    Firstly, the goal of ‘go faster’ is a poor definition of purpose, i.e. “do more of the same”. A conversation outlining what specific expectations need to be met, for who and by when would help frame the conversation with example and create some common ground. If the work isn’t tied to the big picture – with measurement – then the risk of pursing targets rather than purpose abound. Unfortunately agile shops can easily fall foul of this with story points / velocity being used as a false measure of purpose. Also, a discussion to generate different options for meeting the customers’ needs can often reveal cheaper and better solutions to the one already planned – an opportunity to satisfy demand with less investment.

    Secondly, the term ‘push’ is an interesting one. It’s easy for the recipients to infer that the manager has a negative attribution towards them – that people aren’t putting their full attention into their work or aren’t ‘up-to-speed’ (i.e. aren’t competent). It may be that the same term is used towards that manager at his/her weekly RAG report / status meeting and it’s being passed on. Or maybe they think you’re lazy. Or incompetent. Regardless, without understanding where they are coming from it’s going to be hard to counter it, even with solid rational arguments about negative medium to long term effects due to cutting corners, burnout and so forth.

    This can be a really tough situation. I’ve witnessed team managers say one thing to senior management and another to the team in question, committing the team to unreasonable deliverables and then stating that it came from ‘on high’, generating the pressure and putting people in un-winnable situations. I think this is the exception though, thankfully. If the conversation can be brought back to purpose from speed – why are we here – and to how could we improve the way the work works rather than how do we push people then I’d say you’ve been successful :)

    • benjaminmitchell says :

      Thanks for contributing to the discussion Gus!

      I like that you’ve highlighted the problem of viewing software development as “shipping kilos of software by the due date!” when you talk of the false lure of points over purpose.

      As you say, it’s important to understand where the manager is coming from. Although hard to accept it may be that they think you’re lazy. It’s difficult work to slow down the (natural?) reaction to this kind of negative evaluation so that we can uncover more about their point of view. If they really think this way then it’s better to have this information than not. Once you’ve got it then there’s the challenge of working out whether it’s accurate or not and how you could jointly work this out going forward.

      My view is that in order to have a productive conversation, which is likely to based around the underlying interests of both sides (“bring it back to purpose rather than speed” as you say) it’s important that the manager at least feel listened to and understood first. What’s your view?

      • Gus Power says :

        Yes, absolutely, I think it’s a requirement for most people to feel that they have been listened to and understood before they can engage constructively (“those convinced against their will are of the same opinion still”).

        It’s easy to be hostile in this situation. Sterotypes abound, from Dilbert-style managers who are clueless to the realities of software development to software developers that lack ‘soft skills’ and care only about technology.

        The question is ultimately whether the manager and the developers can define mutually compatible goals and develop a shared understanding or model of how things work. Personally held assumptions, attributions and generalizations that are untested and unshared will only work against that aim.

        Of course saving ourselves from our own behaviour isn’t easy, especially in adversarial situations :)

Follow

Get every new post delivered to your Inbox.

Join 72 other followers

%d bloggers like this: