Coaching high performing, senior engineers to grow by doing more Great Work

Published: Sunday, Jan 14, 2024

Coaching high performing, senior engineers is challenging because often there’s nothing they obviously need to improve. To coach them, you have to identify new opportunities which will challenge them and force them to continue growing. Oftentimes managers are able to identify these opportunities for their directs, but I’ve found it’s also possible to encourage high performing, senior engineers to work on identifying their own growth opportunities. This often leads to more exciting opportunities and more engaged engineers.

Bear with me while I take a small detour but I promise I’ll circle back to the above point.

We spend at least half our lives at work, so it makes sense we want the work we do to matter. The work we do can be grouped into 3 categories: Bad Work, Good Work, and Great Work. The key is to eliminate Bad Work as much as possible and create opportunities to do Great Work. This is great personal advice, but I’ve also found this to be a great way to coach high performers at work.

Bad Work is a waste of time and something a trained monkey should probably be doing. Think timesheets, useless processes, etc. You should look for what Bad Work is within your control to eliminate or automate and work ruthlessly to do so.

Good Work is what we spend most of our time doing. It’s beneficial to the company, it’s moderately interesting and you’re probably pretty competent at doing it. There’s nothing wrong with that per se. You could probably do it forever and be perfectly comfortable and reasonably successful, but it doesn’t help you grow as an employee. Another problem is that if you don’t do anything about it, Good Work tends to consume all available time because there’s a never ending stream of it.

Great Work work, on the other hand, is transformative. It is often not something you are told to do nor is it something obvious. It’s usually exciting and the type of thing that you’ll continue thinking about on your drive home and in the shower in the morning. It may cause some anxiety and discomfort because it’s new and uncertain, but when you’re done, it gives you a great sense of meaning and accomplishment. The challenge with Great Work, however, is that it requires that you break out of the mold of doing Good Work all the time. You have to create the space and opportunity to identify what Great Work opportunities await you and work on them.

Book Cover

There’s a lot more about these different types of work in the book “Do More Great Work” by Michael Bungay Stainier. It’s definitely worth a read to get more into this concept. But this article isn’t a book report.

Back to my original point: as I moved up into senior management and had super talented, senior engineers reporting to me, I noticed that I was repeating my explanation about Bad, Good and Great work to a lot of them when we discussed how they could level up their work. They were so good at doing Good Work that they were doing a ton of it, partially because leadership was always asking them to do more. They were happy to be contributing so much, but it wasn’t helping them grow as engineers.

In order to leverage the concept of Great Work to push high performing, senior developers to break out of the Good Work trap, I would ask them to do the following:

  1. Block off time on their calendar away from Good Work to dedicate to doing Great Work. At first this will be used for brainstorming Great Work opportunities, and later for working on them. It should be at least 2 hours/week although doing 2 hours twice a week is better. This is going to be the hardest part, since they will feel guilty not doing Good Work for their team. I’d remind them they’re already delivering more Good Work than others on the team.

  2. Start drafting a list of potential Great Work ideas. I encouraged them to think about areas of the product in which they were passionate, either because they really wanted to work in those areas or because they felt those areas needed lots of improvement. I asked them to think big and envision the end state without getting too worried about how they would get there. I’d pose questions like “what framework would make our codebase dramatically better?” or “what capability does Product always assume is too hard to build, but if we laid the groundwork, teams could finally do it quickly?”

  3. Work with me to identify which ideas had the most promise. As their manager, it’s important to review their ideas. The ideas should be exciting, challenging and something that will force the developer to stretch their skills or work outside their comfort zone (perhaps learning a new technology or architecture). Sometimes a developer would have an idea in an area that was already on leadership’s radar, but leadership didn’t know what to do about it. I would tell them to prioritize those cases because doing Great Work in that area would not only be rewarding and beneficial, it would also increase the developer’s profile with leadership. If not, then I’d use my judgment to help prioritize the ideas that best balance growth opportunities with the fewest external impediments.

  4. Create a plan. We would start with a vision, a rough timeline, and at least the next 1-2 steps to be worked on. We also would discuss realistically how much progress they could make given their other commitments, and therefore how frequently to revisit the plan and check on its status.

  5. Provide continuous feedback and accountability to ensure they stay dedicated and don’t lose steam. Reminding them that this is one of your priorities for them helps keep them on track. They will usually say that they really enjoy doing the work, but they tend to feel squeezed by Good Work. It was my job to ensure they protect the time. And as they deliver increments, as their manager it’s important to give them feedback and challenge them to keep improving.

  6. For the manager, there’s one additional step: identify when the Great Work has turned into Good Work. Usually this is ⅔ of the way through the project when the work remaining is no longer revolutionary or novel, while still being complex and challenging. At this point, I would usually look to bring other, less senior developers into the project. The remaining work may be Great Work for them, since it’d still be a level above their normal work. And mentoring and guiding the project would sometimes become a new type of Great Work for the senior dev.

At the end of the day, pushing your high performing, senior developers to identify Great Work is win-win-win. The developer benefits by getting reinvigorated about work and developing new skills. The business wins because they get greater output from the developer and something transformative that improves the product. And you win as a manager because you’ve coached your direct report to grow and accomplish more than they would have otherwise.