If you've been following my series "How to win with devs", a sort of "open letter" to engineering management and HR folks who want to learn more about how to better engage with the developer community, you've probably noticed that we've been covering some really heavy topics, and looking at long-standing practices that don't serve us anymore... it's been a little rough, hasn't it?

Hopefully you find that today's topic, with which I'm closing out the series, is a bit more lighthearted. Today we're talking about "Building Excitement" and how you can do this with your dev teams... and why you'd even want to!

Happy engineers are productive engineers

Most people think of "managing people" as a task that requires you as the manager to motivate them to get work done. I believe this is wrong thinking, and I'd like to illustrate it with an anecdote:

When I've had a pet project that I was really excited to work on, I've been known to abandon everything else in life until I finished it. I skipped showers. I skipped meals. I disappeared from my usual hangouts. While I was working on that project, I reoriented everything in my life around its completion. Even when I eventually took meal breaks, or walked the dog, or whatever... I was still deeply immersed in the project. I was thinking about the code I needed to write next, or how this component was going to interact with that one. I drew pictures of possible next step ideas while I sat in the waiting room at the doctor's office. I even dreamed about it regularly.

I ask you: does this sound like someone who needs to be motivated by their manager? Quite the opposite! This is someone who's likely going to hit a wall and burn out. Their manager will need to help them unplug and provide balance.

This is the first rule I want you to learn: If your developers are happy and excited by their work, they're already predisposed to obsess over it. If you find yourself having to "manage them into productivity"... you have an underlying problem to deal with!

Ask yourself: Why are they disengaged?

In late 2009, Daniel Pink published a book called Drive: The Surprising Truth About What Motivates Us. While this isn't written specifically about Engineers, its findings definitely apply! He suggests that motivation is tied to three principles for most people:

• Autonomy: We want to be responsible for our work and our choices and we have the opportunity to direct ourselves.

• Mastery: We're driven to improve ourselves, to learn our craft more deeply and grow our knowledge and skill. We seek opportunities to level up.

• Purpose: We want to connect our efforts to a greater goal, to understand that we're doing something that matters.

One of the surprising points that came out of Pink's work was that money didn't make the list. Well, with a caveat - when you don't have enough to cover your necessities, money is perhaps the strongest factor in motivation. But once you reach a salary level where you're not just scraping by anymore, this Autonomy/Mastery/Purpose triangle takes over. (It's also important to note: that even though money doesn't have as strong an influence on motivation after the inflection point, it's not an excuse to get cheap! Everyone can smell a 🐀!)

This is counterintuitive, particularly in business where management often assumes that the only lever they have to pull is "pay increases" to incentivize their workforce... they're shocked that it stops working, because they don't realize that their folks have shifted into that alternative mindset!

What does it mean to offer autonomy, mastery, and purpose? How would a company give that to its people? If these factors affect developer happiness and motivation, and therefore their productivity, how do I make changes that could influence a developer team?

Autonomy

"Engineers being autonomous" can be a scary thing for managers. I mean, we're managers. Isn't it our role to manage?

When a manager develops their relationship with their team to promote mutual trust & understanding, it creates a breeding ground for autonomy. The manager doesn't feel the need to micromanage because their team does a great job of managing themselves.

On the other hand, when a manager interprets their role as "I tell the team what to do and they do it", it continually and rapidly erodes the trust between them until the only way anyone gets anything done is that the manager sits over their shoulder like a vulture and watches, continually adjusting direction and micromanaging. For an engineer, this is soul-crushing, y'all.

I'm... not there yet, blink. How can I begin to promote autonomy?

You're probably talking too much.

I'm not throwing shade... we all tend to talk too much! The wisdom here is to try listening. As the manager, the authority inherent in your position causes your opinion to carry more weight than theirs; therefore when you talk over them or interrupt them, you're shutting down the creative process. The implication you create is something like "Well, the boss knows what they want done and my opinion is just noise".

I heard Jeff Bezos say something in an interview once that stuck with me: "Leaders speak last". The idea behind this is that when the "leader" speaks, everyone else makes the unconscious assumption that a decision has been reached.

It leaves them thinking their input doesn't matter! By waiting until the end to add your own input to the discussion, you're offering a chance for everyone else to be heard. This is something you also need to train your senior team members on - because they also may squash their teammates' input unwittingly.

Your role is to clear obstacles, not design solutions

If you're managing engineers, you have a tremendous amount of creative problem-solving ability on your team. It might seem obvious, but it's worth saying: You aren't there to tell them how to solve the problem! Instead, focus your own personal efforts on finding the organizational hurdles - the dumb processes that prevent them from solving the problem, or the tools they need but don't have - and removing those barriers so they can focus on their problem. Most engineers hate doing paperwork, it's often a disruption in their day. Something as simple as "hey, I opened that ticket for you to get access to the database" might keep your engineer "in the zone" for an extra 30 minutes one day, and you can't begin to fathom the value of that!

Ask the dumb questions

One of the most valuable skills that I've learned is how to be willing to ask the "stupid questions" when problem solving in a group. Many people are afraid to ask questions for fear of looking like they're incompetent, but asking questions is a critical skill in solving problems. So even if you already have some idea what the answer is, ask the question for the benefit of the others on your team!

Mastery

The second motivating factor for people in Pink's research was the concept of mastery. That is, people are motivated by a desire to level up their skills! There's a "secret" corollary to this desire: EVERYONE has some skills that can be leveled up!

Mastery's opposite is boredom. And that's one thing that most engineers absolutely cannot stand! They're motivated to learn and grow and improve, and if they're constrained from doing those things, it's devastating.

What are some ideas to promote mastery?

• Observe.

I see mastery working hand-in-hand with autonomy - an autonomous engineer is going to find problems they want to solve, projects they want to work on. Your role as their manager is to study them... see if you can identify what kinds of problems they love to work on, and then give them more of those kinds of things.

• Make it safe.

Learning requires failure. If your opportunities to level up are always on high-priority, high-visibility efforts with scary ramifications for failing, you're doing your team a disservice. Make sure they have plenty of lower-stakes places to work on their skills and improve. You can't always avoid the high-pressure situation, but try to ensure it isn't the only path to leveling up.

• Budget for it.

If you don't already have one... build a professional development budget, and put it to good use. Supporting your team as they learn new skills that they can put to valuable use at work should be a no-brainer, but it's frightening how many companies either don't invest at all in this, or do it haphazardly. Do you have a plan for how you're going to help each person on your team level up a skill this year?

Purpose

This motivator is the most abstract, and it will be very different for each person. Some of it you may not have any control over at all. What the heck is "Purpose"?

Purpose could mean:

• They relate strongly to the mission of the company
• They have a deep passion for a certain type of skill set
• They care about a certain persona of customer

Any "higher meaning" in their work can become a Purpose, but it will be highly subjective. Your role in this motivator is to help them find it.

Helping your team find their Purpose

• Relationship, Relationship, Relationship.

Any assistance you can render here will come directly from how well you know your team. Cultivating a strong personal relationship with each of your engineers will give you the insight into their characters and desires and guide you toward their Purpose.

• Not everything is an assignment.

This one is scary for managers who tend to want to micromanage... but have you considered leaving your team some free time to work on things that they choose?

It seems counterintuitive, but the best way to increase efficiency is actually to build in idle time! If you run the shop at 100% constantly, you create contention when two projects collide (instead of having some slack where they can easily shift to accommodate unexpected turbulence). You also create a culture of burnout (because your team never gets to breathe, you're always on to the next thing with no chance to regroup).

Good engineers, when given a workload that has a bit of idle time built in (15-20% is mathematically ideal!), will occupy themselves with productive tasks whenever that idle time arrives... they just aren't assigned tasks, and that makes all the difference. Remember our first motivator? Autonomy! Your engineers will begin to find their purpose when they have a chance to be autonomous.

Wrapping up

There are ultimately two ways for people to be motivated: extrinsically and intrinsically. You can bribe, cajole, nudge... even beat them with a stick... but you'll never be able to match the output of someone who's motivated from within themselves. As a manager, you have tremendous influence in this space - and while you'll be tempted to take the quick path and provide extrinsic motivation, I want to encourage you to stick with your "gardening efforts"... cultivate that motivation from within your teams and watch amazing things happen!

Speaking of "Building Excitement"...

Next week we're going to delve back into the world of AI! This next Adventure is probably my favorite episode so far, because I get to have a chat with...

Nah. Not spoiling it. 😏 Make sure you give me a follow so that you'll be reminded to tune in next week when we start to play with Large Language Models!