Jan 21, 2026
The most valuable scarce resource in software development is enthusiasm. A software engineer with enthusiasm is about ten times more productive than the same person without enthusiasm - yes a completely made up number, but there definitely is a huge difference. The strange thing is this fundamental fact does not appear to be understood at all by the vast majority of engineering managers.
Now that I'm retired I'm free to howl into the void without having to worry about being disinvited to meetings or given damning with faint praise performance reviews. If you, dear reader, happen to be a software engineering manager, or aspire to be one, then I claim you may benefit from reading the following. At the very least learning how people like me think will be of some use.
A state of enthusiasm drives an engineer to work longer hours, to focus much more, spend less time on reading news and other distractions, and they sometimes need to be reminded to have a break for lunch, or go home. The enthusiastic engineer will write whatever design documentation is needed and host whatever meetings are needed to drive the subject of their enthusiasm forwards, and will pro-actively explore new ideas. They will be constantly thinking about their problem, in the shower, while eating, while walking from place to place, and may come up with insights at any time. Enthusiasm is what gets important software built. The alternative is an engineer who has no investment in the project, sits back and waits to be told what to do, diligently takes regular lunch/coffee/bathroom breaks, makes sure they are informed about world events, and clocks off at whatever time is considered acceptable, if not slightly earlier. These two engineers can be the same person, at different times - even sometimes from one day to the next. A manager who understands how to keep their engineers enthusiastic is going to be successful - and one who doesn't, well I would accuse them of malpractice, but in my experience that is almost all of them, so it's probably not helpful to say that, but certainly they are passing up an opportunity to succeed.
Enthusiasm is slow to build, but quick to destroy. I'm going to try to identify the things that build and destroy enthusiasm - probably won't get them all, it probably varies from person to person to some degree, but I'll do my best. It is likely to be possible to build enthusiasm without doing well on all of the following, but you definitely need most of them.
Everyone likes to work on something they think is important. Several factors can lead to the perception of importance. Knowing that your code will be running on a billion iPhones is one example. Doing something new and cool, where you can see that this new thing will change people's lives, is another. Just working on something the engineer really wants to use themselves can be enough. No matter what it is, it's helpful if the project leaders (usually the overseeing managers) can devote effort to building a sense of mission. Make everyone involved feel like they are working on something important. Keep reminding everyone that this will change the world. State the purpose, the thing everyone is working to achieve, and repeat it periodically. Don't exaggerate, at least not excessively, engineers aren't as stupid as many managers sometimes seem to think, but a modicum of self-delusion can work. The Steve Jobs Reality Distortion Field is an example, though not everyone can pull that off. Even for something mundane, find some way in which this project is going to push some boundary - eg the fastest whatever ever, or the least memory-hungry - and make that one of the main goals of the project. Celebrate the achievement of those goals.
To maintain enthusiasm you need to be able to get on with the job, without having to get permission from lots of people. Too many gatekeepers gets us firmly back in clock-watching and doing-what-I'm-told territory. An engineer who feels like they own the thing they are working on and has the ability to make things happen will make those things happen. Don't let momentum be lost to having to stop for anything. When multiple engineers are working on something the obvious potential issue is how do they share ownership - they can't all own everything, you would think. That depends - engineers who respect each other and aren't too desperate for recognition can be generous with co-operation and a team like that really can share ownership. If they are deprived of recognition and feel like they have to somehow stand out to be noticed, then they won't, they will try to hoard whatever ownership they can. Work towards a team where everyone is recognised, and where helping one's team-mates is an expected part of the job. If you have a team that just won't work together, then the thing to do is divide the project into manageable parts and manage the ownership of the constituent parts separately, and then invent some way of ensuring the different parts work consistently and the project as a whole holds together. The latter is usually harder than you think.
The ideal number of people at a meeting is three. That can be a productive meeting, real discussion can occur. More than that only works if there is some important announcement to make, otherwise it's just taking people away from the thing they are enthusiastically working on and dissipating the enthusiasm.
Unless your organisation is quite small, there are probably people or bodies outside your team upon whose co-operation you will need to rely. If that co-operation isn't forthcoming then everything can grind to a halt and the enthusiasm of all involved dissipates, so this needs careful attention. Large companies have entire management chains created to try to manage this problem - if you have this (eg a group of EPMs) then make good use of them and engage with them early and often - otherwise make direct contact with whoever you need to engage with. Make sure everyone understands why what you are working on is important - try to infect them with your sense of mission. Develop contingency plans for what happens if some external requirement doesn't eventuate so that engineers can keep being productive and don't have to slow down. A useful side-effect of keeping your EPMs busy helping you engage with other teams is they have less time for inviting your own team members to meetings, or reminding them about administrative documentation requirements, which slows everything down and destroys enthusiasm.
Nothing is more destructive to enthusiasm than firing everything up, building the momentum, making detailed plans, starting on some prototypes, and then being told by management never mind, change of plan, stop what you're doing. Every time that happens to a software engineer they die a little inside. Each time around it becomes incrementally harder to fire up the enthusiasm next time. It can be hard for a manager to solve this problem, particularly if decisions come down from further up the chain, but it's so important that one must try. Find ways to decouple senior management directives from the task set the engineers. Start by sticking to the subset of the project that you know is going to be important no matter what final form the product or service takes. Put people to work building lower-level infrastructure at first - senior managers tend to be much more interested in the high-level user-visible aspects of the software, and more inclined to change their minds about what that should look like, but building a solid foundation first will insulate the team from a lot of that.
There is a physical limit to how long an engineer can work at high enthusiasm levels. There needs to be some way to periodically let them slow down, take time for proper eating, sleeping, and relating to the other people who might live in their home. This is something management has to initiate because the engineers themselves may not be able to. One effective way I've seen this work is with a project where we had defined phases, each with a name (in this case named after constellations), a schedule (generally 6 weeks or so) and a list of things we wanted to achieve. The schedule occasionally moved a week or two, and the list of deliverables generally got shorter once we found out things were harder than we thought. At the end of the phase we would have some large meetings to demonstrate what we had working, and to discuss next steps. It was a useful chance to just slow down for a while, before starting the next phase. No doubt there are other ways to do this, but the principle is important - having built up the enthusiasm of the engineers you need a way to gently let them return back to normality before they burn out.
This is related to the first point about the importance of the project, but I think it's worth calling out separately. It is true that in software engineering almost everything turns out to be harder than you thought, and to take longer than you thought. Many engineering managers see this as a problem to be solved, and try to solve it in various ways, like just automatically tripling any estimates from their staff, or reducing scope. I would argue that this, particularly scope reduction, is a mistake. Most worthwhile things are achieved by people who weren't sure whether they could do them. If you stick to what you are confident you can do, you only ever make incremental improvements. Give people licence to attempt the impossible and they will more often than you think surprise you by succeeding. This is an effective way to fire up enthusiasm. Steve Jobs seemed to understand this very well - demand the impossible, infect people with the Reality Distortion Field, instill the sense of mission, and then wait for the miracle. Even without the SJ RDF, the same procedure can be attempted. Be realistic - when you set ambitious goals you won't always achieve them, but setting the goals is still worthwhile because you will end up with more than you would get from a scope limitation exercise.