Maximising Engineer Value

Software engineers are curious beasts, aren’t we? On average we’ve got the logic smarts, not always the social smarts. Many (but by no means all) of us relish mental gymnastics and even spend free time trying out software development tools and techniques that we’re unlikely to ever need for our job. Impostor syndrome is common. We tend to question, by nature. And our work requires us to concentrate.

The challenge 🧩

Until some code is changed, an engineer has most likely not added much product value. But before you can change the code (assuming you don’t want to leave a mess) you need a whole lot of information available. Some is really high level, fundamental stuff, like what tools are present in your development environment. Some are specific to the area of the system you’re working on. Others are limited to the problem you’re solving right now.

Fortunately, brains are fantastic at automating common thought processes - let’s call it “habit” - so you might get some of this information more or less for free! If an engineer has been programming in the same language in the same codebase over the last few months, and is making a familiar change, it probably doesn’t need much thought at all. If there’s nothing like this new feature in the product, it might require some technical exploration and a whole lot of consideration.

As an engineer figures out their code solution, it takes form as an ephemeral, delicate spiderweb of an idea, with things to implement and things to remember and ideas for how the data will be structured and passed around. A distraction will break the chain of thought, the vision melts away and needs piecing together again later.

Time gets wasted.

Short term ideas, the variables and control flow for the specific bit of code being written, are most vulnerable, and might need figuring out again after the briefest of interruptions. Attend a meeting, or reactively switch to a piece of urgent work (user-impacting bug in prod, anyone?) and you might need to work out what set of changes were going to go into your next PR. A week’s holiday and the project and architecture might still be pretty clear, but the specific piece of work is likely a distant memory.

I’d like to let you in on a little secret: engineers love being productive! There is little greater joy than picking up work which is going to provide value and absolutely crushing it. Code rolls onto the keyboard. Tests green. Commit. Push. PR. Bliss!

So how can you squeeze as much delivered value and engineering satisfaction out of the day as possible? Here are some ideas from things we’ve tried out at Glean:

Maximise coding time ⏰

It sounds obvious - perhaps a better way to look at this is to value engineers’ time and minimise obligatory meetings:

• make scheduled meetings optional (if reasonable)

• Keep regular meetings as short and infrequent as you can while keeping their value.

• For some meetings, we keep a public agenda doc that anyone can add to. As the meeting owner, if the agenda is empty, post a message to see if people still want the meeting - you might save everyone the interruption of joining and leaving again!

• Encourage engineers to reflect on how valuable the meetings they attend are. (Note: if people are choosing not to attend the meeting, reflect on why; bring cake next time and slap “party” on the end of the meeting name!) 

Meetings are not the enemy. We’re strongly in favour of iterative improvements, and retrospectives really help bake in intentional time for that. At Glean, we experimented with the cadence and settled on every 8-10 weeks, and we set aside an hour and a half for them. Productive meeting time is still productive time.

We’re less keen on short sprints with a bunch of meeting overhead. And we’re dead set against that full-squad exploration of why time estimates were off again and how we’re going to improve their accuracy and consistency. (It’s hard to dream up a more misery-inducing waste of time!)

And this doesn’t mean that engineers should be kept glued to their IDEs! Time spent on social interaction and learning are really valuable for keeping us sane. We expect people to come to standups and see each other’s faces in the morning and we use Donut to give people explicit time to socialise if they want it. We also, for example, have a system where anyone can organise a book group and spend a half hour a week talking about a book that is relevant to their role. Giving engineers time for self-development is key for increasing their value to the company as well as for their career progression and job satisfaction.

When these things can happen optionally and organically (when people are in the mood) it’s the best of both worlds. For a time we had a ping pong table in the office and it was amazing. Every few days we’d spend 20 minutes playing and feel so much better for having moved around a bit.

Minimise interruptions 🤫

Aside from meetings, push notifications (e.g. from email or slack) can usefully highlight urgent information. However in most roles you rarely need to deal with these the moment they arrive.

At Glean, on any given day, we have 1 or 2 engineers allocated who tackle urgent issues that come up and minimise such interruptions for others. Every engineer is on this rota to spend a day on duty, and when not dealing with issues, we address noisy logs and make other small quality of life improvements. If they are overwhelmed, they have total freedom to delegate work, but if one urgent thing arises it doesn’t immediately distract everybody.

We also have an Engineering Effectiveness squad, who aim to actively address our greatest sources of developer pain, distraction and interruption. It might sound like a big sacrifice in terms of features, but they multiply the effectiveness of all other engineers, so at some scale it becomes the most effective use of time. As a role, It is also extremely motivating for some people.

Of course, once more, there are exceptions. We would generally recommend unblocking your colleagues over most other tasks. It’s great for team-building, an opportunity for coaching and sharing good practice and a bit of human interaction if you’re remote, to boot. It’s usually worth the productivity cost of an interruption. One tactic if you are being interrupted is to take 20 seconds to jot down whatever it is you were going to do next, before losing that train of thought.

It might be important for you to see some notifications - perhaps to keep a PR moving by addressing some feedback. Use what configuration you have available to avoid getting bombarded with more than you need to. You can even set a timer to give yourself a regular break from work and go through all the notifications you’ve not been addressing (pomodoro).

Maintain mood and momentum 🚦

If you sit down to work dejected about what you’re trying to get done, uninspired by the technology and codebase, distracted by non-work issues and tempted by distractions, it’s deadly for productivity. The act of forcing your attention on it becomes a source of stress and frustration.

If you can sit down with a clear mind, with the feeling that you’re about to do something that will be noticed and valued by your users (or peers/principal/manager), the odds of nailing the work item are stacked in your favour.

The signals displayed by a trusted authority figure have a significant impact on squad mood. If a squad lead regularly expresses helplessness and frustration, it will steadily sap the squad’s satisfaction. If they regularly express credible excitement and belief in the tickets waiting to be picked up, it gives a significant morale boost. Note that the “trusted” is critical - an untrusted authority figure is going to have pretty limited influence in this way. It’s got to be genuine too - try to actually get interested and excited!

Make sure that the team is praised and recognised from time to time in wider group settings like an All Hands. If something is worth celebrating, do it loudly and proudly! Praising the group rather than individuals in those will help to generate group identity and foster collaboration. Private praise of the group among your peers and seniors is important too - teams rely on their leads to represent and advocate for them in the wider company.

Establishing a broad sense of momentum, that the team is working sustainably and productively, is also motivating. There will always be large items that need doing, but if nothing is released to users for a while, it can make the business edgy, which feeds down through the product team to squads. So when prioritising work, try to ensure something the company will value can be released on a fairly regular basis, even if it is a small item. And if technical debt is growing and starting to impact productivity, it’s time for a chat with the business about what the squad’s velocity needs to look like in a year’s time, and how you can make that happen.

Nothing stifles momentum like a growing pile of technical debt. This accrues naturally as new requirements arise and the surrounding code ecosystem changes and introduces friction. Reserve a slice of feature team engineering time for tackling tech debt and prioritise the most impactful changes. More generally, encourage engineers to improve the code around the change they’re making. If everyone drops one piece of litter every day, you drown in a sea of litter; if everyone picks up one piece of litter every day, you are left with a great environment that is easier to build on later.

Roundup 🧠

We’re aiming for a win-win here! Capable and motivated engineers who have the trust to organise themselves and the time to focus on their work without regular interruptions will be happier, more engaged, more productive engineers. They will produce more features and provide maximum value to the business.

I’ve focused very much on how we currently try to give our engineers the best chance of feeling like doing their work, getting into the most productive state of mind to do so and being able to work without interruption until they need a break. However, at Glean we regularly revisit our processes, identify issues and experiment to try to make them better.

What I’ve described here might not be the best way for your team to work, but hopefully it’s given you some ideas to try out!