By Anna Bauer (Own work) [CC BY-SA 3.0 (http://creativecommons.org/licenses/by-sa/3.0)], via Wikimedia Commons

Why aren’t people taking initiative?

A short story

Jean Hsu
Jean Hsu
May 1 · 6 min read

A few years ago, Company X was a five-person startup. Everyone talked to everyone every day, and it was super clear what needed to get done — if someone saw something not getting done, they went ahead and did it. It was chaotic, but the early employees also found this “wear many hats” mode exhilarating and inspiring.

As Company X grew, it developed into another sort of chaos. A few levels of management were added, communication silos started to develop, and people stopped taking as much initiative.

There is a rift of understanding between those at the “top” and those at the “bottom,” and for both, it feels like a hopeless situation. Leaders are frustrated that the engineers and designers and product managers on the ground aren’t ideating, are too permission-seeking, or aren’t assertive enough. Meanwhile, those exact individuals feel stifled and resort to slogging through their tasks, with little to no context on how they impact the organization. Engineers and designers appear to be unenthused, and execution seems slow, slow, slow. Engineers say they are blocked on design, and design says they’re blocked on product direction. Tech leads and product managers start managing smaller and smaller tasks.

Management starts to reassess if they are screening for the right kind of mission-driven aggressive individuals. Engineers start to feel like their learning has plateaued, and a few of those inbound recruiter emails start to look more appealing.


Does this sound familiar? This is a hypothetical story but is a common pattern as startups scale.

The crux of the problem is this: people do not feel empowered or trusted to take initiative.

People working as individual contributors in startups are not inherently lazy. They don’t voluntarily work harder for less pay because they want to phone it in. They want to be somewhere where they can solve problems and make decisions about some things in a timely manner without being shot down every time.

So what can you do if this is your reality?


Lack of communication is the cause of many scaling challenges. When there are communication silos, not only does important context on strategy and priorities not make its way to individuals on teams, but managers and execs also don’t get valuable information about team dynamics. You may be puzzled “up top” about why certain engineers don’t seem as motivated anymore, but the why may seem super clear to someone else.

Find a few of the more well-connected and emotionally intelligent individuals and have frank conversations with them. You may discover that there’s a toxic presence on the team who shoots down ideas — two or three times per engineer is sufficient. Maybe the company’s priorities and strategy shift so often, and they don’t know current priorities until they have a sprint-worth of work already allocated. Or possibly there just isn’t enough time carved out to think about or work on anything other than already scoped-out project work.


People need to have enough context and high-level alignment to make good decisions on their own; otherwise, you get people taking initiative but doing random stuff that is not helpful at all.

When startups hit 10–20 people, suddenly not everyone can be in the room for every product and strategy meeting. And while the company’s leaders are still getting the same level of discourse and strategy discussion as before, individual contributors usually get way less, if any.

How do you know if you’re providing enough context and high-level alignment on mission and strategy? You can literally just ask someone — say, “Hey, sometimes it’s hard to figure out if I’m communicating clearly enough, so I’d like some feedback. What do you think are our biggest priorities this [week/month/quarter]?” Thank them, especially if their answer doesn’t match yours — they’ve helped you successfully identify a communication gap. And don’t make excuses — it doesn’t matter if they were out of the office for the day when you had that impromptu all-hands. Figure out what you can do to fix it. For example, next time, send out an email after the all-hands.


Everyone else will not get the message that you’ve decided it’s time for change. They’re heads down in all the work they’re doing that already fills their time. If you expect that you’ll see results just because you’ve decided there should be change, you’ll probably be disappointed, and come to the conclusion that these individuals are just not motivated. But remember when they were? When the company was smaller and they did all sorts of creative things, or when you interviewed them and saw and heard the passion in their eyes for their work?

You need a change element: something that’s the equivalent of a smack in the head (but don’t actually do that) that says, “HEY! What we were doing was OK but not great! Let’s change things up!” Maybe that’s a hack-week or a hack-few-days, or a team brainstorming offsite. This could be paired with clear communication on the most up-to-date priorities.

Changing the status quo iteratively is more difficult than introducing a change element intentionally and setting up the appropriate rewards to incentivize the desired behavior.


Empowering people to take initiative does not mean a free-for-all. If you’ve provided high-level alignment, you’ll also want some guard rails. Some examples:

  • Create a policy that experiments can be shipped to 2% of the user base, and must be analyzed and evaluated within 2 months.
  • Hold a hack-a-thon around a very specific goal (ex. increase weekly return users), and allocate time and resources to build out the best prototypes in production.
  • Specify that 80% of an engineer’s time should go towards scoped projects, and the remaining 20% should go towards explorations or projects that also fulfill the team’s purpose. Have engineers write up or present their explorations.

Another phenomenon in companies is that the loudest and most confident-seeming employees get to take initiative — or rather, they experience much less friction when they do, so people see them as leaders. People who do not fit that mold generally experience more pushback and questioning when they suggest something they feel is good for the company.

So make sure you are rewarding behavior in a way that is fair. You may also want to consult with others to get a few more opinions. If someone took the initiative to start some onboarding docs (good) but was a poor communicator and completely ignored the coding work she had committed to (not so good), be clear in private feedback about how to improve next time.

Similarly, if you’re managing managers, reward those managers who are successfully empowering their team through public praise or exciting opportunities. If they’re doing it successfully, it may feel like they’re “doing less,” so pay attention.

Remember — whatever you reward publicly is what will be emulated.


One-on-one meetings are a good time to monitor and nudge people in the right direction and debug any snafus in this process. If you’re managing managers, have 1:1s with their reports on a less frequent schedule (sometimes called skip-level 1:1s) to prevent communication silos. Identify emerging leaders and high-potential individuals, and encourage them in 1:1s to take more initiative.

As people bring up issues they’re encountering, coach them to think about what they would do, and encourage them to do so to help them make that mental leap from “someone else should do this” to “I should do this.” Or you may discover that there are still some roadblocks for them that you can help remove.

You can do this in meetings as well to make the point in a more public setting.


Of course, all this is dependent on believing the premise that empowering individuals at all levels of an organization is something that is desirable and will be beneficial to the company. If you find yourself questioning this premise, spend some time exploring why. Is it a lack of trust? Or insecurity that you’ll seem irrelevant?

A command-and-control management philosophy is frankly not going to get you the best results from your team. As L. David Marquet writes in Turn the Ship Around,

“Those who take orders usually run at half speed, underutilizing their imagination and initiative.”

Better Programming

Advice for programmers.

Thanks to Tyler Neylon

Jean Hsu

Written by

Jean Hsu

Co-founder of coleadership.com, transforming engineers into leaders. Previously engineering at @Medium, Pulse, and Google.

Better Programming

Advice for programmers.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade