Sometimes teams need a little push in the right direction. Sometimes teams to be given space to find their own way. He are some brief notes on how I traverse this issue.
There is a particular dark art within engineering leadership. Nobody ever really teaches it; at least nobody ever taught it to me. And even when you think you've learned this dark art, there is always more to learn. Because the lessons learned in the context of one team almost never apply in the context of a different team.
The dark art? Push.
Engineering leadership is all about help. "How can I help my teams achieve what they need/want to achieve?" This help can come in all sorts of shapes and sizes. The amount of effort that goes into helping those goals needs to be balanced with results being achieved. This balance between effort and results is what I call "Push".
Push is a good thing. By keeping Push in mind, engineering leaders are helping to ensure that their engineers are satisfied, productive and generally happy in their work.
Whenever I see some kind of cartesian space like this my instinct is to wonder, "what is happening in the corners?" In the case of Push, I think there is a risk of seeing some of these corners as highly desirable.
Lots of effort, lots of results! Great, right?
Let's look at the corners one-by-one:
If the team is not putting in a lot of effort and is not focused on delivering results, they won't deliver results. Simple as that. At least no deliver anything that gives a sense of satisfaction in the work.
Getting results! Great! Right? If the team is not being challenged in its work, we risk boredom and all the bad "things" that come with it. Like corner cutting.
Putting in lots of effort and obtaining no tangible results is probably the most-obviously "bad" corner. It is bad for both the organisation and the team.
This is the corner that many engineering leads get tricked into thinking is A Good Thing™. There is a time and a place for stretch goals, but have you considered the impact they have on the team?
So having looked at the corners, we should probably take a look at the dimensions themselves: results (achievement) and effort. For each of these dimenions there are some clear downsides to being too far up/down the scale:
Regardless of results, always aiming to get as much effort from the team as possible is not advisable. Sustained effort makes people mentally and physically tired. After a while, this is guaranteed to have a detrimental affect on results achievement and can lead to burn-out.
Consistently requiring little effort can have a multitude of affects but, in general, it breeds laziness and/or boredom.
It's OK to fail. We all do it all the time. If all of your projects are running perfectly all the time, teams can get complacent and corners can get cut. By introducing learning opportunities into work we open ourselves up to a little risk of failure, but the trade-off is a even-more-skilled workforce.
This one is actually more common than you might think. How often have you worked with a team that asked "Why are we doing this?" Knowing why you're working on something is a crucial factor in success. In the most extreme case, when projects fail regularly (systematically?) your teams will just get demotivated.
Satisfice is an excellent portmanteaux taught to me during my PhD. It is a blend of "Satisfy" and "Sufficient":
At the heart of "Push" there is this desirable space I call "Satisfice". It is the sweet spot where we focus the engineers on achievement, but without over-excursion. Sometimes we might want to deliberately lower the focus on effort!
The trick with Satisfice is understanding how to walk about this sweet spot.
Through your interactions with your team members (1-on-1s, retrospectives etc) you get a sense of the health of the team. Teams that are "forming" or "storming" should not really be pushed up the "effort" dimension. If you have pushed a team up the "effort" scale (e.g. looming deadline). you might want to give them a break in the future.
Similarly, there are times to focus on results attainment: got a high business value project you are working on? When that project is over, you might want to load the team with more-flexible targets to leave them with headspace for personal development.
Ultimately the trick is to be mindful of the needs of both organisation and the team. Your best opportunity to apply Push is in planning sessions:
You get the picture.
Ultimately, use your senses. Use your gut feeling. Push is not something to measure formally or enact explicitly. Just be mindful of it.
This does mean we need to be careful with regards to any metrics you might be gathering. Most performance metrics assume that Push is in a fairly stable position on the Satisficery cartesian space. Certain changes to Push are guaranteed to affect certain metrics. So you need to take this into account. Don't let the numbers win! Gathering metrics is great (and important) but applying Push is about optimising the team for now not for some desired trend.
I'd say "try this out", but you already are, probably. Keep doing it. Keep being in-tune with the needs of your team. Keep reacting to those needs. Keep being in-tune with the needs of the organisation. Keep reacting to those needs, too.
Use Push to gently move your team around the Satisfice space and everyone wins.