Hacker News Reader

Comment by jkaunisv1 | Hacker News Reader

I see a lot of comments here about having a daily standup. As somebody who has been the weakest developer in a team of stars, standups can be really intimidating and not a place I'd like to own up to the fact that I'm stalled on something.

A daily meeting/checkin is super valuable but don't expect your junior devs to pipe up with what's actually important. You may have to check in with them one-on-one, in private, to hear what's actually on their minds. And ask specific questions, not just "how's it going?"

View on HN

If you are stalled on something, AKA blocked in agile terms., then its the job of the scrum master to have people unblock you. Stand ups and agile are put in place to help people. Its sounds like the people in comment thread have had poor scrum masters/managers. I'm an engineer and scrum master and love the process of helping and being helped. Thats the whole point, not accountability.

I think a lot of companies heard about "that agile thing" and implemented stand-ups because that's the stand-out thing they can emulate from whatever blog article they read. Or they don't even associate it with agile.

I don't think any of the places I've worked that did stand-ups were trying to do agile, it's just an attempt by the manager to know what's up without devoting much time to it. I haven't seen it work well in that context.

I find the opposite. I'm fairly new at a company, and worry about not looking bad. Sometimes, things stall. The next morning, I can explain where I got stuck, and get someone who the group trusts involved. If it's a hard problem, and the best programmer gets bogged down as well, I look okay. If they solve it in 10 seconds, I'm unblocked. Either way it's way more comfy than sitting on it for a week wondering when I'll get in trouble.

Totally. I think it depends on the group - especially group size. The intimidating standup I was describing was I think around 15 developers, mostly working on separate issues. It worked for them because the majority were very self-starting, skilled devs.

And I was speaking more to the general idea that OP shouldn't expect everything to bubble up to them automatically, because different people work and behave differently. Learning about that is an important aspect of being a manager.

>sitting on it for a week wondering when I'll get in trouble.

Mandatory participation in a meeting isn't going to stop that. You take the proactive approach and ask for help, but you're asking in the meeting. Why wait? Fire off an email to the last person to look at the code? Send a chat message to the person who wrote that segment of the spec. Flag down your favorite senior developer on their way back from the restroom.

The question or problem can always wait until the daily meeting to be resolved, but it can't be answered until you ask.

Great psychological insight here. The intimidation factor can make you deeply want to step up your game, but it can also lead to some odd behavior that results in less transparency. Manager beware.

I think in general managers (well, everybody, really) need to be aware that people have different inclinations to share. Some people are the type to speak up and possibly dominate the conversation in a meeting, others are silent until prompted. Some people need to be probed multiple times to get their true thoughts.

This might be a reflection of either your working environment or your attitude. A lot of times companies will try to implement agile methods but if team members have the wrong attitudes about it and it can create a very unhealthy work environment.

If your team members make you feel like you aren't doing enough on your own, then intimidation makes sense. If you feel that you have to be able to get everything done right & quick on your own, then intimidation makes sense. If you feel you are working together as a team to help create a quality product/service, then standups should be a welcome break in the day to let everyone know how your progress is and ask questions. For me, it is sometimes "okay, I'll keep trudging through this problem until the standup, then I'll mention my problem and maybe Jane will have some insight on ways to help me improve".

How does "intimidation" make sense? What does that word mean, as used in your comment?

In the context of the post I replied to, feeling like the weakest developer - intimidation may make sense if you're afraid to share your progress (or lack of progress) because your team members are judging your development abilities, or if you just don't have confidence in your development abilities. If the attitudes of the team members is laden with competition and judgment versus cohesion and improvement, standups can be hell. But that's a team/attitude problem, not a standup problem. Standups shouldn't feel intimidating.

I'm not saying it was a consciously intimidating atmosphere, or that I felt judged. You're right, standups shouldn't feel intimidating. But depending on how they're structured, they can be. The standups I've taken part in felt more like a time to update management on what you're working on, not a time to get help.

They usually had far too many people involved. I think that's a standup problem, not an attitude problem. It's hard to speak up amidst 10-20 people (much less when they're all brilliant developers) when the whole room just wants to get down to work. It just doesn't feel like the place for issue-specific discussion.

Ah, I'm sorry - I'm a big Scrum proponent and I forgot that standups aren't always just a small team. What you described sounds pretty painful and more like a progress report that may not benefit the team much. I think I'd also feel intimidated in that situation and would probably seek out help separate from the standups. Any way you could plant the seed to break these standups into smaller groups based on the areas of the project you're working on? I think it could help!

No worries :) The situation I described was five years ago, and I think they've done what you described. They're a crazy successful company, so regardless they're doing something right. These days I'm on a small team, and in the intervening years I've gotten a lot better at managing myself and managing "up".

That experience should teach you to speak up and ask for help privately before the standup time.

Well, I was eventually fired from that job because I wasn't consciously aware of that effect at the time, and was basically unmanaged so neither side acted to correct the issue until it was too late. I learned a lot from that experience after the fact.

But in a situation where one person is the experienced team leader and the other is a junior developer, possibly fresh out of college, I think the onus is on the team leader to ask if they need help rather than expecting everyone to speak up on their own. Maybe the junior doesn't realize they need help. Maybe they're too busy with trying to progress on the code, possibly affected by personal problems, to think about their process.

A lot of the improvements that have made a difference for me as a developer and an employee in general have been learning how to work and manage both myself and the people around me, not learning more about a language or framework. I think that's a big part of a manager's job.

Reply on news.ycombinator.com