Hacker News Reader

Comment by jmathai | Hacker News Reader

In my experience on small teams that I've been on - a key motivator for people is shipping products and features. The sooner and more frequently you can do this the more positive reinforcement there is for the entire team - not to mention reduced risk of something never making it to the target users.

Teams that have figured out the optimal way to get product and features into the hands of users as quickly as possible are the happiest teams because it's evidence that they're working together efficiently to meet their shared goals.

View on HN

Releasing is great. Unused work is quite sad.

A big condition for motivation though is if people are not pressured to rush features.

Being in a rush does not work long term and not being happy with the quality of the work done is very demotivating and impairs the sense of meaning. Micromanagement too.

Personally, the two week sprints and daily stand-ups did this to me in my previous job, but I can see they could be a source of motivation for others. So, how work is organized and managed is really important too and depends on the people in the team.

What kind of micromanagement did you experience / E.g. do you have an example?

I'm in the position where I as tech lead don't fully know if I can trust my team (yet) to do the right decisions. One of the reason is that our product is quite new, and we haven't discussed developing principles yet. And some people tend to over engineer stuff all the time. But I also don't want to micromanage.

Having to report every day during the daily stand up felt like micromanagement to me. But that's just me. Many people do seem like to have this kind of daily routine so your mileage may vary obviously.

Having to fit tasks in two weeks periods was a problem too, with all these ceremonial meetings where we end up having to make things up and which actually take a lot of time. Being able to give feedback is good, but I don't like to be polled every two weeks on this in a far too long meeting, and waiting the end of the sprint if something is actually wrong is not ideal neither. We ended up merging shit code if the tasks actually needed more than two weeks and artificially splitting those tasks into smaller ones is a lot of overhead and can have deleterious effect on the code architecture. I think we were also not very good at planning a bit ahead so decisions needed to be taken and validated by the boss too often, which can feel like micromanagement too.

Trusting your team about taking the right decisions is probably not an issue, if you have meetings where you make the general "big picture" (design) decisions all together. It'll probably help you notice that your team can make the good decisions too. But if you do have the big picture, it's a good thing you participate in this. I think small decisions should be left to the developers though.

Not trusting they will do their job would be an issue.

Good luck :-)

> Having to report every day during the daily stand up felt like micromanagement to me. But that's just me. Many people do like having this kind of daily routine so mileage may vary obviously.

Same here. I used to be in a team with daily stand-ups, reporting to the manager what work I did the day before, and they killed my will to work, consequently causing me to work ~3 times slower, which presumably is the opposite of the intended effect.

The problem is that a lot of developers (especially junior ones) make shitty decisions and/or just work slowly without the accountability of having to say what they worked on (and having to explain why what they said they will “finish today” 4 times already isn’t yet finished for the 5th time).

They are not necessarily bad developers, just need the need the external motivator.

If you have 10+ years of experience and you repeatedly make shitty decisions or keep drastically underestimating your work instead of introducing accountability via daily standups you can simply be fired.

I have seen this happen to junior developers.

In hindsight I think it is much more effective to pair them up with a senior developer instead of waiting for a pattern to become apparent during the daily scrum.

Ideally yes, but it’s also not that easy to find senior developers and a lot of them don’t like having to hand-hold juniors.

The standups I've been in are about reporting to the rest of the team what you're doing.

This way, everyone has a clue what's going on, and can also chime in with advice and questions.

I'm not against stand-ups per se, just against daily stand-ups. Currently I'm in a team which does three a week. That's at least tolerable, but if it was up to me, I'd opt for once a week. Daily made me feel that I had no agency over my work, that everything to the tiniest detail needed to be negotiated with someone, most often the manager. Less agency means lower engagement in work. At least for me. I do know that there is plenty of other people who are different.

We must mean very different things by "standups".

My standup messages are mostly "I'm working on adding feature X, it's going well", or "I'm fixing bug Y, and I wonder how to handle Z".

Usually that's it. Sometimes there are questions or discussion about details. It serves to keep the team aware of what's going on.

If your team is argumentative it can drag out and be a drain. That's when it is up to the manager to break it off and move any needed discussions somewhere else. If your manager is the argumentative one... you have a bit of a problem.

This is also what I mean by stand-up.

These stand-ups get in the way. I'm bored when I need to listen to what people have to say, or worse, what they are making up. I'm stressed by what I need to say or make up. They take time. They often happen at a time where my productivity would be the best / when I'm in the middle of something, or else I need to rush to get on time. Or to watch for the time when we are close and interrupt everything I'm doing. This, every single day. It's fine for meaningful meetings solving real problems, but stand-ups are not this kind of meeting for me.

I very much prefer not having a daily synchronization point, and instead give status to relevant people when needed, or give my status when asked for (which is not too often, we can see what tasks is left for me in the bug tracker). If I'm blocked or if I have a question, I'll ask. If colleagues have a question, they'll ask. We have flexible hours, not at exactly the same timezone, some people are already full of important meetings. Not having a standup to babysit, to schedule, to watch for and to be stressed about is one less problem to handle.

I'm thrilled to be able to start my work day when I'm ready and not having to interrupt for this daily thing that does not seem to bring much value in the end. I'm happy to be able to have an unproductive day and make up for it the next day without nobody noticing it and without me lying about it, because in the end, it's none of nobody's business and it doesn't matter. And the day is just a bad unit of time for development tasks most of the time.

When I had to attend daily stand-ups, indeed standing-up (wtf!), I just had the impression we were (treated like) a bunch of children not able to be autonomous for a few days.

But then, it seems everybody in my current team is wired for working efficiently without this kind of things, so it works for us. We are also good at knowing what people are on to by the reading the stuff they are discussing on the chat, and the big picture, fast, weekly status update we have anyway. I don't need the details brought by the stand up, unless I do but then I will get them via efficient communication anyway.

Totally agree. And so does my team. We solve this by running daily Slack-ups, i.e. just tell what you're doing on Slack, which is much, much faster.

We only use daily standups when there are new people on the team.

This is not just you.

That's a very valid and shared perception of DSMs and even Scrum in general.

For some types of projects, and for some people, it just does not work.

And when it is nonetheless forced onto them (because for some others it works, or because company policy/management dictates it) it is actually failing and working against its own principle: agility.

> Having to report every day during the daily stand up felt like micromanagement to me.

Agreed, and some teams go even further than that. I have to update statuses multiple times a day. If I don't, I get nagged about the status of this or that (as though I can do more than one thing at a time). I wish I could just say "I am doing A because I am waiting on B just like I was yesterday" and have it stick.

I almost want to make that painfully hackneyed “did we work together?” Joke because this was my last job. It was status update overload.

Standups daily, then we’d have weekly all hands that I had to prepare status updates for, then a weekly 1:1 with my boss that needed status updates, and then each week my team would have to type out what we accomplished at the end of the week so the Director could send it to the execs for the weekly reviews.

The result? I am giving the same status updates to the same people upwards of four to five times in a single week. There were moments when I legitimately wanted to ask my boss in a very flippant way about his note taking abilities but that wouldn’t have done much but get me in the management dog house probably.

It was a source of annoyance with every other dev I talked to about it.

Can you prove that their "overengineering" makes things worse? And not just in the short term, but also for maintainability down the road, accounting for their developer experience and job satisfaction, etc? Otherwise maybe it's just a healthy level of engineering, knowing the details that person knows.

The management advice I was given is that if you don't first trust people, they will never get a chance to show you that they are deserving of said trust. And showing that is allowed to take some time.

Another thing I try to keep in mind is that I might not always trust each individual in their decisions, but I always trust a team decision over my own. So when in doubt, involve more people on the team.

Of course you can't prove that these four extra layers of abstraction will never be useful, but they aren't right now. That's why people with over 10 years in the industry are valuable - they have the intuition to see this coming.

The dev took twice as long to build the feature as they needed to, and updates to the code also take twice as long. I have seen this over and over, and GP is correct - there are some engineers who need to be coached out of overengineering.

My point is not that overengineering doesn't exist. My point is that if Alice says Bob is overengineering and Bob says Alice is underengineering, you don't have any evidence either way. You need to loop more people in and let both Alice and Bob air their concerns.

I think you need a way to have deadlines, without that you can easily fall into over engineering or completing other unrelated tasks.

I think for junior developers that might be true. Does the name connect? :)

no I'm not junior

I've worked with (and been a) staff engineers who have fallen into the same trap. Over engineering is something that we need to constantly be cognizant of because it's often dependant on scope.

E.g. are microservices over engineering? If you have 1 user now, and only expect 100 total users over the next 2 years, probably. If you're running AWS, definitely not. Everything in between becomes a grey area that requires thoughtful architecture to decide on the right approach, and even very experienced people will make the wrong calls

Well, sure. I wasn't saying it never happens to non-junior engineers.

Respectfully, that seems to be what your parent comment says :).

> I think for junior developers that might be true.

That strongly implies, if not outright says, "this only inflicts junior engineers".

I meant "if this can be generalized onto anyone at all, then at most junior developers". Was probably not the best way to express that, haha.

Sure! I currently work at a place where there are deadlines and no sprints. It works very well for me, and for the company too apparently. There are customers who expect their stuff to be shipped and the product has a month by month roadmap.

Now, over-engineering is a risk but I think I'm lazy enough to avoid it most of the time. I probably have the opposite issue sometimes.

We do get things done without running for a deadline most of the time though, so it works okay without deadlines for the some non negligible part.

We'd be dead if we didn't release. There isn't any investor's money to compensate.

The problem is that deadlines are often too tight because the person responsible is usually not the one who suffers the most. If this is the case, the result is low code quality and bad feelings because the developers are either overworked or feel guilty. Instead, it is best to create a priority list of tasks and review it regularly.

I agree deadlines are a necessary evil to ensure we hold ourselves accountable to both customers and internal non-eng stakeholders who need to know when things will ship in order to make plans around them and collaborate with us effectively.

One approach to develop a healthy culture around deadlines I've been thinking about lately:

Plan the deadline around the minimal lovable product, while spec'ing out the minimal shippable product, and ensure there's enough of a delta between the two so we can have a large degree of freedom w.r.t. scope.

Without this freedom to vary scope, _when_ (not if) our estimates invariably fail, our only options would be to extend the deadline (defeating the purpose of setting deadlines in the first place if we resort to this often enough), or to burn ourselves out with overtime work in an attempt to meet those deadlines (obviously results in an unhealthy/unsustainable environment, and not even guaranteed to succeed).

I believe this also depends on who you ask

For me deadlines are simply "someone wants this and this delivered @" I work on it a couple of days and then I tell that someone if it's reasonable and if it's not reasonable, what they are gonna get instead.

Most of the times deadlines are way off the mark and it also happens that they take 1/3 of the planned time, in that case instead of over engineering, I simply rest or study something new.

Over engineering is a curse only if one can't stop doing it and needs an external stimuli to mark the feature as "done".

Otherwise I believe most programmers know when their work is finished and can be shipped.

What early Agile knew and Scrum has obliterated is that basic advice you got from your high school or college teachers who pointed out if something is important you can't leave it until the last moment.

The counterargument about deadlines is always some sad sack story about shipping for the holidays or having tax software done in time for the start of the tax season. Those stories are all true, but they have fuck all to do with deadlines.

Continuous Delivery means that if you need something by Friday, the conversation is about the relative risk/reward of shipping the build we're going to do on Tuesday, or the one we did last Tuesday, or one from three weeks ago. Not whether the important features will be done by CoB on Friday. Because the critical bits of the important features were finished over a month ago and now we're just making everything pretty.

What happens is that "the work expands to fill the time" is not just a law that applies to developers, it also applies to management in spades. "Sure, we need this feature, but why don't you hold off on doing that while we do this other thing that feels important but only because I told someone it would happen and I'm too much of a coward to tell anyone that I was wrong about something, and I outrank you so you and your social life are going to pay for my mistakes, not me and mine."

I hate having to ship features when I just want to work on improving reliability, doing upgrades, improving DX and clearing all the crap out of the way that's preventing us from otherwise shipping.

In this context, a completed upgrade or cleanup would count as "shipping".

The article's author seems to primarily emphasize serializing processes so that incremental progress is readily evident to everyone and the organization can reap early wins from the first-shipped results.

All that stuff is important, and I enjoy it more than most.

But I also keep in mind that the only point of it is to enable shipping more features faster and better.

For sure. For me it's about ratio's though. It never makes sense to me when I encounter situations where 100% of capacity is dedicated to features, features, features when sustained velocity is in the toilet when it feels like we're standing in an entire orchard of low-hanging fruit of productivity gains to be had. I usually find that after about a year or so in a company it starts to click for people that if they just let me be more self-directed then stuff starts to improve for everyone at a faster rate and it's win-win. I know there are other devs like me, but I feel like it's not widely recognized that we exist and should be enabled to just do our thing. I don't know if you can relate, but maybe you can?

Shipping an 80% solution is ok... it leaves a bad taste, but its "ok".

The problem becomes more-so when the next 80% solution is shipped on top of the previous 80% solution. And that just gets demoralizing after a time when one looks at the stack of 80% solutions on top of 80% solutions that needs to get fixed up (but "we don't have time to do that").

One thing I tell our developers (and POs) is that we can only tolerate 80% solutions so long as they also produce 120% solutions (or give us additional time/scope for them) at approximately the same rate.

I don't think it has to be even, but there is certainly a ratio.

Sometimes you have to let developers overengineer something or work on something a little too much so they don't go insane and take you with them. Or quit and go somewhere else.

Few things affect consistent delivery as much as bad employee retention and burnout.

Had the exact-same experience in a previous role: pressured to rush to release to meet a(n arbitrary) sprint deadline and then - the deadline not met - the work left unreleased. Super frustrating and almost caused me to quit at the time.

What motivates me is having a clear large goal (like say, adding a new core functionality to an app), and then break it down into small tasks that can easily be done in regular days of work.

You end up with an ever increasing list of "completed" tasks until you eventually reach a shipping point and you can have a celebration party or whatever.

The hard part is then managing deadlines and expectations from then on with whoever wants the product, where good managers can make progress feel very present and visible, which in turns makes speed feel predictable and everyone can plan with realistic expectations.

Not only shipping, but ideally shipping and receiving feedback about it. Feedback shows people care. It's not really motivator to ship something that people don't care about, or worse, don't use at all. It's shipping useful stuff that motivates people.

Yep. And if nobody actually cares about the feature like everyone thought they would, great we didn't waste time. If they hate it (usually through feature flags of product trials), and work needs to be done, simply flip the flag back off.

It's a great way to do small-medium features.

No it's not. Everyone who loves feature flags has never done serious work. The amount of extra work / redundant code that has to be done to accommodate different DB schemas / DTOs in addition to the "lol feature flag" on the front end is absurd.

If your feature flags are behind such complexity you have a bigger problem than feature flags.

Note "serious work". If you are hiding a banner, an extra button that calls a service method used elsewhere, some text, etc - feature flag away.

Real world problems tend to be, at the very least, "add some new fields to the form" - at which point you are messing with DB schemas OR following bad practices like making fields that should have no business being nullable accept nulls because "who knows if the feature flag is on". This quickly destroys normalization and data consistency.

Right... which is why I said It's a great way to do small-medium features.

If you want to do rolling/canary deployments without downtime, or gradual rollouts to subsets of users, or a/b testing, you will have multiple versions running in parallel against the same database. Plenty of "serious work" happens that way.

Same problem. Someone I used to work with wrote an article about it and you run into the same problem with A/B tests / canary deployments / etc - need to account for different DB schemas:

https://medium.com/swlh/worthwhile-modern-deployment-strateg...

This is the thing people miss with Agile processes. Agile without shipping is merely wasted churn. Nothing is more demotivating than wasted churn. Agile requires progress. How can everyone learn and re-evaluate if you always stay in same spot but just keeping turning in circles?

Reply on news.ycombinator.com