“One of the signals that managers might need more training is when their engineers aren’t taking initiative.”

That fascinating take is from Jean Hsu, Engineering Leadership Coach at jeanhsu.com, who we spoke with about the curious transition to becoming an engineering manager.

We felt that topic deserved its own conversation, so we asked Hsu to elaborate about managerial approaches that lead to lack of motivation. Sure enough, she had more to say about why engineers don’t take initiative – and what you can change about your approach to management.

The slow(ing) status quo

As a startup scales from a garage band to several dozen engineers, new layers of management are introduced, responsibilities change, and new processes are put in place. While it’s an exciting time for the organization as a whole, the rapid growth usually translates to a relatively new engineering environment. That in itself is not good or bad. It’s just the nature of the beast.

But it can be shocking for engineers that have been around since the beginning, and for those who have quickly shifted into a management role. As a result, “people tend to micromanage a lot,” Hsu observes. And while micromanaging is also a habit of many seasoned managers, it can be a real problem when a manager starts implementing unnecessary processes as a response to rapid growth. The rationale: ‘I’ve seen this process work elsewhere before, so we’re going to implement it here.’

“In many teams, a process will often get introduced because people have seen it work somewhere else — usually at a larger company where it was necessary.”

When you’re working with computers and technology, that approach actually makes sense: see the solution, implement the solution. But when you’re managing people, there’s no one solution or process that fits all.

“I’ve been in this situation before,” Hsu says, “engineers feel like they had free reign to make decisions, and now their manager is telling them what to work on, and to follow a specific process in doing so.” Instead of focusing on getting the job done, the engineer now suddenly needs to spec everything out, wait for approval, then break it down into Jira or Asana tasks, wait for it to be reviewed, and so on.

“In many teams, a process will often get introduced because people have seen it work somewhere else — usually at a larger company where it was necessary,” Hsu says.

Hsu has seen plenty of clients in this situation. “Their engineers feel like they can’t make decisions about anything,” she says. “and as an engineer, when someone has an opinion that you’re doing it the wrong way, that can be incredibly stifling. People who are naturally driven, creative and motivated, just kind of shut down.”

In this environment, you have engineers just plugging away at tasks instead of investing in the creative process. That’s bad for productivity, and soon enough, super slow becomes your status quo. An order of magnitude slower – that’s what Hsu sees happen when people are not excited about their work. And from the outside, that looks like an engineer not taking initiative.

A seamless solution

Fortunately, there are ways to course correct—and preventative measures you can take to keep these problems from even happening.

“When introducing process, lean towards over-communicating, and be receptive to the team,” Hsu says. That way, your methods don’t feel like decrees handed down from on high. It also helps everyone get onboard quickly.

Of course, there are best practices for teams of various sizes. But for any team, the team needs to understand the why behind a process change. Just because isn’t good enough.

“I think that ‘process’ gets kind of a bad name because a lot of times it’s introduced as this seemingly unnecessary and bulky thing,” Hsu says. “It’s extra overhead, and engineers feel they aren’t getting anything out of it.”

That’s why she likes to introduce process when the team feels the need. Don’t wait until the need is terrible – but when it’s self-evident. That way, changes are more expected.

“Any additions or changes in process should feel natural,” Hsu says. “Being responsive to this – and to the team – is really important.”

She shares an example from a large team she recently worked with. “Daily stand-ups were fifteen people,” she says. “And there wasn’t any clear separation of who was working on which project. It was just this big pool of people.”

The pain the team felt here? They felt they were wasting their days in meetings that didn’t have anything to do with their individual work.

So she tried to figure out how to untangle the knot and give people accountability for the projects they were leading or working with. Then she split the stand-ups so that the participants in each meeting felt like it was actually relevant to them.

She didn’t revamp the team. And she definitely didn’t impose more process on everyone for this daily stand-up. She went with the flow to maximize her engineers’ ownership and engagement while valuing their time and contributions.

“Any additions or changes in process should feel natural,” Hsu says. “Engineers shouldn’t feel like this big process is being imposed on the team, especially as a startup. I don’t think it’s necessary.”

And if a process doesn’t work? The answer will sound familiar: “Being responsive to people is really important,” she reiterates. “You are going to make mistakes as an engineering manager. Being able to recover quickly is far more valuable than not making changes due to fear of making mistakes.” It’s all about having an experimental mindset — with product, people, and processes — and communicating that to the team.

If it seems your engineers aren’t taking initiative, look first at your processes and listen to your people. It may be that the initiative is yours to take. Exhibit the same resilience and agility you want from your engineers, and you’ll enable theirs in return.