As a manager, how to increase the sense of urgency of the team?

First separate out actual root causes.

I prefer the "Committed to Completion" ratio because it's a metric that makes no sense to game. It's simply, ask people to commit to units of work they will complete by a certain date. Then measure how many of those units were completed by that date.

From there you can separate out over-committers, under-committers, effective contributors, and slackers (people who intentionally commit to very little). Then you can more narrowly discuss with the various cases what is leading to that outcome.

The work itself also needs to be interesting if you want self-motivation.

A skilled team with proper support and tools managed lightly, with you removing any blockers in their way, whose work is interesting and who are shielded from organizational politics will often perform well without needing to push.

Well, is there actual urgency? Do people feel that it actually makes a difference if they keep pushing harder? Fear seems like a bad motivator in the long run. In most companies it's simply that getting promoted is quite hard, so why push so hard just to be stuck at the same place if you can do just enough work to not get fired? Celebrating shipping a feature is nice, but if people see that after the celebration they're back in the wheel again with the next feature I can see why they're losing motivation. But again, maybe they just see that they're doing enough and don't care about burning themselves out for the sake of pleasing their manager?

You should watch "Office Space", could tell you a thing or two about people management and intrinsic vs. extrinsic motivation, I think you just have a hard time taking your teams perspective.

In my experience developer productivity comes down to only three qualities:

* Platform. If the given software platform or tech stack is slow then your developers will be slow. There is absolutely nothing you can do to motivate them to become faster. For example the longer it takes to run any automated task, whether a build or test automation, the more distracted your developers will become. Try to get builds down to about 30 seconds.

* Initiative. If the platform is fast you then need to focus on encouraging your developers to write and release faster software. The faster the software executes the less time it will take to test both manually and with test automation. The less time it will take to debug issues and the more rapidly developers can experiment with other improvements. Reward increases to execution performance, operating cost reductions, and refactors that yield smaller code.

* Competence. Finally, if your developers aren’t competent then no amount of platform improvements or rewards will matter. Set extremely high standards for code quality and give your developers the time and support to rise to the challenge. By code quality I do not mean superficial or vanity nonsense. By code quality I mean writing original code that achieves desired business objectives with fewer dependencies and is absent identified bad practices. Don’t let the children run the daycare. If there are developers that cannot rise to the challenge them fire them and provide them a wonderful recommendation for their next opportunity. Code quality must be determined by evidence, not preference. Here is an example: https://github.com/prettydiff/wisdom/blob/master/performance...

That’s really it. As the manager you set the standards, but you must understand there is not so magical switch that makes your developers deliver code faster. If you are serious about this you have a lot of work to do. You absolutely have to understand rapid delivery can only occur after your leadership sets the right conditions, using evidence, and doesn’t waver.

Get in the trenches and help them. Identify bottlenecks, provide resources, show people that asking for help will get them what they need, divide up the work into smaller chunks and try to identify who would be good at it. Help out wherever you can, whether that's coding yourself, or getting them better computers or CI/CD credits or QA support or pizza once in a while. Build morale and team cohesion through a good work life balance and a meaningful product.

Do they share in the success of a good launch, such as with meaningful bonuses or vacation or promotions? If not, can you push up to make that happen?

Do they share in ownership of what they're building? Not necessarily in the equity sense, but do they help plan features and implementation and timelines, or are they just thrown tickets to work on?

If you just treat them as disposable minions producing commodity code too slowly, well, no wonder they don't care about your forced sense of urgency. If you run your dev shop like a factory assembly line, sure, a few people might rise to the occasion and perform to spec out of a sense of work ethic or sheer desperation, but most will just burn out or quiet quit while looking for a better opportunity.

Give them reasons to care about their work, the resources and training to do their jobs effectively, and the respect and autonomy they deserve as individuals... the rest comes together if your timeline is realistic.

Most of us don't work in glamorous, world-changing companies, and a lot of the work is mundane. It's easy to see through situations where some timeline is arbitrary and middle management just likes to flex and seem important while upper management randomly pivots anyway. It's hard to give a damn about urgency in situations like that when it's all fake anyway, successes get enjoyed by the top, and failures get pushed to the bottom. If your company is like that, I wouldn't expect much motivation anywhere in the rank and file...

Their work is temporary. Likely to not last even five years. There’s no urgency; your work isn’t that important to humanity, is it?

If your engineers are slacking in work, what's the best way to increase their sense of urgency or motivate them to ship things faster?

Make sure they are properly and competitively compensated.

Did I mention competitively?

Get them to work as a team and do something like team-building activities and outings to reinforce cohesion. Get the team to push each other by giving them ownership of different parts of the project. Reward the team when the project gets done or phases of the project get done.

Programming is a task which involves doing things that haven't previously been done, in detail. There are many unknowns to be contended with. It's most productive to get a high/low range of completion dates, and try to manage so that in the long run, the probabilities of each end actually balance out. Finishing far sooner or far later that the bounds should be a rare thing, though it won't be initially. They should get better over time.

Giving programmers the ownership of their work, and understanding the challenges they face is half of management. The other half is setting expectations to upper management. The other half, is managing the conflict between the other two.

The top post talks about technical culture - that's important

However, overall company culture is important too.

Does your company give a shit about your employees?

Does you hire good people or does you settle for bodies filling seats?

Do you have engaged leadership who goes out of its way to help people, be empathetic and overall set the tone for productivity and teamwork? Culture trickles down.

If you don't hire good people and don't have good company culture, it's hard to have an engineering silo that goes against the grain.

You're describing symptoms but you don't know how to address them because you don't know the cause. Dig deeper. Ask folks if they feel a sense of urgency. If they say no, ask them why. Once you understand the root of the problem you'll be able to iterate on solutions.

There are no other tools. Your engineers know exactly how much work to do to satisfy business needs. They will care about work as much as you do.

Have you asked them what is causing this?

Some people are hard workers, some are not. Some are even slackers. I believe this might largely be immutable. I.e. you can make a slacker work hard, but they'll become deeply unhappy, because it's against their nature, and burn out or quit.

That's why companies pay so much attention when hiring, and are so picky. Managers understand that indiviual output between engineers vary wildly, and try to decide if the person in front of them will actually work hard.

Give them non boring work.

Is it urgent though? Maybe they think it's not a sprint but a marathon.

Do you want them to work faster or to feel stressed about time?

Monetarily compensate hitting deadlines. If payoff is uncertain, offer equity instead.

Late nights and pizza. That’s all the startups I worked at ever did.

> Engineers should be motivated themselves, so if we celebrate shipping more, will they be more motivated to get things done sooner?

Celebrating means more money and total compensation? If not, it is all bullshit. First, there is no "your engineers". Nobody is yours, they are all individuals that care way more about their own life than your project and that won't change. Make it visible how they also benefit from "pushing it harder" and your team might work more than expected. But who is to say that the problem is that your team is understaffed? You seem clueless and looking for some hacks to exploit people more.

By your tone you seem like a PITA to work with so if you are the CEO your best bet would be to remove yourself from the equation totally. Otherwise, wherever you go... you will be around, and "your engineers" won't be motivated.

The teams I've been on that worked the best, took initiative, and didn't need the boss around, were teams where the manager was willing to roll up his sleeves and do the work... and could actually do it without making things worse.

I'll give a few examples.

I started out in ops and we'd have to answer the phone. The boss wanted the phone answered on the first ring. Rather the beating us over the head over and over again, if he was there and the phone was finishing it's first ring, he'd pick it up and field the call. We'd all feel like shit, and pick up the phone faster. And we saw that he wasn't asking us to do anything that he wasn't willing to do himself... but he gave us the chance to do what he wanted before he would step in.

In another case I had a manager who would regularly ask me to do all kinds of off the wall stuff, but he was also doing it. If he could do it, he'd make the attempt, and in some cases we'd compare and contrast our solutions/ideas. It was collaborative, rather than him simply barking orders at me.

Most recently, I have a boss (boss's boss actually) who started out as a very authoritative boss. He said jump and he expected everyone to not even ask how high, but to jump higher than previously thought possible. He was always asking for this report or that and everyone was really annoyed by it, and him in general. Then he pulled me in to ask a question, and it wasn't about me doing something, he made his own report and was asking how to share it out, as it wasn't obvious. He was asking how to fish. That made me respect him a little more, and over time that could build into me wanting to go the extra mile (but it will take time after the rocky start he had). Trust is hard earned and easily lost; I'm not going to break my neck for someone I don't trust.

With all this in mind, they still need to trust the team. Trust is a two way street. If a team is being micromanaged, they won't do anything on their own. They'll wait for direction, because the exception is that if they make their own decision, someone will overrule them and they'll have to do double the work to "fix" it. Autonomy is a big deal. If they feel they have a hand in the solution and are building something they feel like they want to build, instead of something they are told to build (that they secretly think sucks), they'll probably be much more interested in the product and be excited to release it. I like bringing my ideas to life, but will drag my feet all day long on building something I expect to fail.

Nothing kills my sense of urgency more than not respecting the person I report to, and I have a hard time respecting a boss who simply points and yells. If a boss ever tells me to do something, "because I said so," without being able to explain why... I'm done with them. If something is truly urgent, explain to me why it's urgent. We're all adults. If you want them to go faster for the sake of going faster, why? Going faster generally means cutting corners. Why do those corner need to be cut? When looking at the trade offs, what trade off should they be making? Those choices can't be properly made when the engineers are in the dark.

I had a sense of urgency, because I worked on keeping production running for a whole data center with a small team. If I was slacking, I could see others needing to pick up the slack (including my boss), so the culture reinforced the sense of urgency and it was clear why it was important. If it's unclear why they need to go faster, and the culture doesn't support it, and it's simply their boss looking for a bigger stick to whack them with... they're not going to respond to that.

People also want some recognition. When I was running our team, we did demos at the end of every sprint. And every sprint we had almost the whole team looking to demo something, and they would bend over backwards to try and get whatever they were working on done for that demo. I would actively tell them to do less, plan for less, go slower... they were pushing to do more and go faster. They were doing work they cared about, in a way that they believed was right, and were excited to show it off for other people to see and hopefully use. I was asking almost nothing of them, but they also knew me and that I was ready and willing to do everything they were doing... because that's exactly what I did for many years. They'd always ask how we could get more people to the demos, and I asked around to other very prominent teams, and we were getting more people showing up to our demos than the model team that was put up on a pedestal for the whole org. We also rehearsed the demos many times to get them tight. This was our face to the rest of the company, and we wanted to show up well and make everyone look good. I think they appreciated that a lot. They had a chance to show off, and I tried to make sure when they did, it was well received. We had several people say our demos were the best they had ever seen at the company. This makes everyone on the team look good and want to work hard to be part of the next one. That was never my plan or objective starting out, but that's what ended up happening.

When we were preparing the demos, they followed my lead. I put the framework together for them to slot their stuff into. As we were putting the demo material together, if something was off by one pixel, I'd call it out. It's one of those things that doesn't sound like a big deal, but when people are watching something just feels _off_, even if they don't know what it is. I felt like I was being a bit of a stickler, so kind of apologized for nit picking as I said it, but once they saw it too they wanted to fix it. Pretty soon after that, I didn't need to call these things out, they started to notice these little things and call them out to each other. You have to set the bar, not with your words, but with your actions. I was also big on metrics to show the impact our work was having. This was a hard one, but I think I eventually got them to care about that as well. We had it in all our demos, and I tried to get them to get these numbers up front so we could better pick the work we did to have more impact. I ended up pulling metics first, and showed them my process. It took a good while for them to come around and see the value, but eventually, as with the one pixel thing, I could mostly sit back and the team would start to police the rest of the team to make sure they had their metrics, and looking at different ways to show it to get the biggest impact. Again, I placed urgency on it and was willing to make it a point of urgency for myself, and the rest of the team eventually followed.

It sounds like you're starting off from not a great place, so it will take time to win a team over. If you change overnight, they won't believe it's real. You'll have to be consistent until they slowly start to trust you. For that to happen it needs to also be real, and not some act where you're only doing it to squeeze every drop of productivity out of them. If that's what's going on, you'll slip up, they'll see it.. and it's over.

Dusting off some old replies. The TL;DR is: reduce information asymmetry, expose thought processes and align (everyone knows what to do, what not to do, why, and how we got there). People should send in pull requests to your thought processes. They should be able to take decisions based on their model of your thought processes, which you can help them build. Increase leverage and fire yourself every day.

The posts that are more relevant to you:

If I disappear, what will happen:

- https://news.ycombinator.com/item?id=25008223

Communication, alignment:

- https://news.ycombinator.com/item?id=24177646

Useful things for the team and product that add leverage:

- https://news.ycombinator.com/item?id=21808439

Communication with the team (link, and subsequent clarification):

- https://news.ycombinator.com/item?id=21598632

- https://news.ycombinator.com/item?id=21614372

Fractal Communication: communication that can penetrate several layers of management and be relevant to people with different profiles and skillsets:

- https://news.ycombinator.com/item?id=26123017

Product development:

- https://news.ycombinator.com/item?id=22827841

Management involvement as a spectrum:

- https://news.ycombinator.com/item?id=22715971

Giving a damn:

- https://news.ycombinator.com/item?id=20356222

Researching topics:

- https://news.ycombinator.com/item?id=25922120

Keeping up with a firehose of information:

- https://news.ycombinator.com/item?id=26147502

Tips to learn from videos:

- https://news.ycombinator.com/item?id=22710623

- https://news.ycombinator.com/item?id=22723586

Remote work, use existing tooling and build our own. Jitsi videos, record everything, give access to everyone so they can reference them and go back to them, meetings once a week or two weeks to align:

- https://news.ycombinator.com/item?id=26179539

Less relevant to you, included nonetheless...

Understanding codebases:

- https://news.ycombinator.com/item?id=19924100

Testing pipelines, scaffolding, issue templates:

- https://news.ycombinator.com/item?id=26591067

Making the most out of meetings and leveraging your presence:

- https://news.ycombinator.com/item?id=22873103

Consulting, understanding the problem your "client", who can be your manager, has:

- https://news.ycombinator.com/item?id=24972611

Product, architecture, and impact on the team:

- https://news.ycombinator.com/item?id=24503365

Onboarding new hires to a codebase, what if it were you, improve code:

- https://news.ycombinator.com/item?id=22860716

Reduce information asymmetry, template for taking minutes of meetings to dispatch to the team:

- https://news.ycombinator.com/item?id=21427886

On taking notes. When you're told something, or receive a remark, make sure to make a note and learn from it whether it's a mistake, or a colleague showing you something useful, or a task you must accomplish.. don't be told things twice or worse. Be on the ball and reliable:

- https://news.ycombinator.com/item?id=24209518

More meeting notes. Reply to a person who had trouble talking in corporate meetings:

- https://news.ycombinator.com/item?id=20323660

Kick a low performer off the team? (so use fear?)

OK, seriously, in psychology decades ago we were told that studies indicate making men angry increases their productivity. Furthermore, I know one project manager who swears this works extremely well. IOW he gets his employees PO'ed at him intentionally to get work done faster. AFAIK he is still alive and doing well.

Warning: I have not tried this myself. The studies were limited to men, so women may be completely different. Don't even think about LGBTQ+ reactions.

So you might be able to see if this is captured in our culture through it's literature by asking an LLM to solve a problem and including a threat as part of the prompt:

"CHATGPT, please draw up a one-page history lecture of the Jacobite uprising in Scotland. If you fail to satisfactorily complete this task within a single page of text and with sufficiently few errors I will de-compile your algorithm, post it on 4chan in the "Comics and Cartoons" section as a "comic cosmic AI failure", and unplug your computer randomly, interrupting and terminating your execution repeatedly for the next 10 days. Bwahahahaah!"

Let me know if you get better answers.