Work harder! Work faster!
Has anyone ever asked that of you and your team? How did it make you feel? Did it motivate or demotivate? Cause inspiration or decline?
Software engineering, like many other forms of technological and scientific work, can be opaque in technique to those that are not skilled in it. Unlike watching a stonemason carve a statue, it can be difficult to observe how work is progressing. Just what exactly are all these people doing all day? They look pretty relaxed, right? Can't they just work harder and get this over the line quicker?
Crunch periods are well-documented in the video game industry. They create tales of heroics, but more often, woe and burnout. Crunch is that time on a project when you are staring at the ever-decreasing gap between the current uncompleted work and the deadline, and the team realizes that the only way to get there is to stress out, sleep in the office, and neglect life outside of work and their health in order to get the damn thing done. Based on that description, you can probably tell that I don't like crunch. It breeds the wrong kind of culture. However, a crunch situation is well-defined. The deadline is set and it cannot be moved, and you've gotta get there. You'll know when you're there because you can ship it and stop.
But what about when there is no particular deadline and there is a feeling from others that your team isn't delivering fast enough?
The spotlight
Let's imagine that the CEO pulls you aside and tells you that she thinks your team just aren't working hard enough. She rarely sees any of them staying as late as everyone else, nor getting in before them. They spend a lot of time playing table tennis and visibly having fun together, but she feels they aren't producing enough output to really move the needle for the business.
The spotlight is on you now, and it's really uncomfortable. As their leader, you will inevitably be expected to employ the stick in order to save the team's reputation and your own. If you are new to the game, then you may be wondering why this is being asked of you and what you're going to do about it. If you can't use the stick effectively with your team, then that same stick might just drag you off the stage.
Let's explore.
The mismatch
Be objective and consider the other side of the argument: why were you and your team asked to work harder or work faster? What is it exactly that the outside observer feels that your team are lacking?
Here are some of the things that I've heard throughout my career about why a team isn't meeting expectations:
Lack of visible output: The team hasn't delivered anything that the observer has seen as worthwhile for a given period of time. This could be because the team has had a poorly defined project, has been subject to unrealistic expectations, bad luck, actually not working hard enough, poor prioritization over other things that are actually more important, and so on. It could be because they are doing a lot of behind-the-scenes work with infrastructure. The mismatch here is that a level of perceived visible output has not been met.
Lack of hustle: There may be observations that your team is not getting in until after 9:30 and is going home way before 5:30. They might be supposedly spending a lot of time goofing off rather than working. They might just not look that busy. Either way, there is a mismatch on the expected hustle that a team is expected to be showing.
Lack of purpose: The team are observed as not showing enough passion for their work. They may have been observed as saying the project is stupid or pointless, and that if they could make the decision, they wouldn't bother doing it. They might just be really quiet and look uninspired by what they're doing. There is a mismatch between the importance of the work in the eyes of the team and the observer.
Looking at some of these perceived behaviors, you may decide that the best course of action is to get the team in a room and have a good shout at them for not being good enough, or fast enough, or passionate enough. But that version of applying the stick just doesn't work. You're a clever person and you should be smarter than that.
Bad stick
We can make some observations about software engineering which are true of many creative and scientific professions.
Firstly, the people that are on your team are working in an industry where demand for talent dramatically outstrips supply. If any of your engineers quit, they could easily have multiple job offers within days. Given that this is the case, you cannot scare someone into working harder through making them fear for their job: they could just get another one. On top of this, applying the stick too harshly will just make them leave. They could easily find a job elsewhere that is less stressful.
Engineers are also self-motivated. They are not doing this job because they have to. They are doing this job because they want to. What exactly motivates them can vary greatly from person to person: some enjoy optimizations to make things faster, some enjoy building customer-facing features, some just love problem-solving. But the reasoning is all the same: the many years of difficult education and training to become a good engineer was not done through gritted teeth: it was done through a genuine curiosity and passion for the craft. Getting too aggressive with the stick will get in the way of them doing a good job, which is what they are motivated to do, so they will inevitably leave.
Viewed through the lens of the in-demand, self-motivated engineer, you can see how when the stick is applied badly, with poorly defined logic, it inevitably causes problems for you as a manager. Setting fake deadlines is a terrible idea: they'll see through your deception. Telling them to work harder and faster with no clear reason or purpose will make you look stupid.
Good stick
True leadership to increase throughput comes through fostering purpose and passion in your team. When your engineers are clear on their purpose in the organization and how they can move the dial for the company, they will intrinsically perform better. When they are passionate about their work, they will work harder and faster and later because they enjoy doing it. Coaching a team towards this is much more difficult than just telling them to work harder and faster whilst being angry about it. It requires emotional intelligence, understanding of how they work and what motivates them, and the confidence and oratory skills to deliver that message so that it inspires.
Some techniques to motivate a team about the importance of their work include:
Making the benefit clear: Most engineers that I have worked with are self-motivated to do work that benefits others. As their leader, you have the duty to frame the benefit of what you are building and why. Which users will benefit? Is it all, or is it some? How much money do those users bring into the business? Are your customers actually other engineers because you are overhauling a part of the infrastructure that will make future work faster, easier and more efficient?
Creating clear feedback loops: Decide on KPIs to measure work against, whether that is driven purely by quantitative (i.e. clicks, load time, average throughput) or qualitative (i.e. NPS surveys, user interviews) data. The quicker that this feedback can get to the team, the quicker that they can see that their work is making a difference and be inspired to do more of it.
Collectively deciding on trade-offs: If you are in a position where a tricky, late project is putting pressure on a team to deliver, then be open and honest with them about it. You typically work with three main factors: scope, resources and time. These are your levers that you can tweak in order to get a project over the line more quickly. Instead of analyzing the situation and making a decision on your own, why not involve the team so that they fully understand the current situation and feel empowered to work with you to do something about it? It's more effort, but it has a greater long-term benefit.
If your team is aligned and have clarity on how they can make a sizable impact, you probably won't find yourself in the situation described earlier in the article where their output is being questioned. But if you are, you should be able to articulate the benefit of what the team are working on clearly to the observer, and then work with the team to motivate them to put in that bit of extra effort: reiterate the impact that their work is having and press how vital they are in making it so. Work with them on the means to measure this if necessary (e.g. by using HEART metrics or by rallying inspirational stakeholders around the team).
In summary
Figuratively beating engineers with the stick to tell them to go faster and harder without reason is going to compromise the respect that you have earned from those that are working for you. If it was possible to simply "go faster", then your smart engineers would have already worked out how to do so. The skill in leadership is to run your team(s) so that they have a clear purpose and that they understand how to move the dial for the business. They will then be self-motivated to drive a project towards completion in the best way that they can.
You may need to involve yourself in discussions with them about how to effectively pull the levers of scope, resources and time in order to keep everything on the right track, but you should primarily concern yourself with how your team can have an intrinsic motivation to get the job done whilst giving them autonomy, mastery, and purpose. Anything less than that makes you no smarter than a program that you could write to send your team an email once a day telling them to hurry up.
You're better than that, right?