141–150 of 255 posts
Especially this (joke?) is hilarious:
"I followed my mentor’s advice and started to check-in at least every half day with each pair of engineers I was working with."
But I suspect he is not at all trying to be funny and, I'd say, it is utterly terrible advice from some PM fitting right into what seems to me a work environment turned buzzword hell.
One thing that I've learned over the years is that product management is often effectively a junior management position and actually should not be a management role at all.
That puts things in perspective in terms of their authority. I've ended up coaching PMs on my team more than once in terms of helping them understand what the product was (often non trivial for new PMs joining an existing team), what kinds of things are easy technically and what kinds of things are not. Even just understanding that there is low hanging fruit to pick (i.e. opportunities for them to look good) is non trivial, etc. All the good ones I've worked with were quick on their feet in learning who to talk to and who to take advice from. A good project manager does not need to be a domain expert to be effective. They just need to learn to ask the right questions.
Ultimately, knowledge-sharing between all the stakeholders in a project (including the customer) is key. PMs acting as bottlenecks can actually be a problem when they are inexperienced. I've more than once had situations where a PM asked me "can you estimate building X please because customer Foo needs this ASAP" where we ended up having a discussion about why building X was actually important, what customer Foo was asking for vs. what they actually needed and us both deciding that actually building something else is a much better way of helping customer Foo. Asking the why questions is always important for both engineers and PMs.
That's why it's important for them to be free to do that and why the proper job title is Product Owner, not Product Manager. In the organizational hierarchy this sits at the same level as the tech leads he's working with in the same team. As soon as you have engineers reporting to PMs, it's a problem and if they have no-one reporting to them, they are not managers.
Earlier quoted context omitted.
As someone who has never worked with XP, does XP really encourage proactively _pushing_ business context and customer POV all the time?
I depends on who you talk to. IMHO, the most important thing is that every single story has to have "business value". In other words, it has to have something where if you put it up on a board and said, "My team did this today", anybody in the management structure would say, "That's wonderful news". I also feel that you should try to have stories that average between a day and two days in length -- so it's pretty dar…
Doesn't this reflect some much deeper problem with the product planning or management? If you literally can't plan even a week in advance that suggests there simply is no plan, and even the most scatterbrained business environment doesn't change that fast.
I'd say customers being able to stick to a coherent story about what they want for more than a week would be a key need in any successful IT project.
Earlier quoted context omitted.
I mean this is from a company that forces pair programming down everyone’s throat (so that you don’t space out on hn as one of stated reasons) so what did you expect? =)
I don't know how you get the idea that it's forced. We're known for it, it's part of the interviewing process for Labs and most of R&D. Folks who don't want to pair generally don't apply. Of those who apply, some try it during the interview process and decide it's not for them. That is a good thing. Besides which, solo work is common too. Most of the field org works solo, Spring folks mostly work solo, I love pairing…
We totally did force pairing on client developers, though.
Earlier quoted context omitted.
Your team needs excellent JIRA hygiene for that to actually work. I’ve been on and managed teams where it’s expected and demanded and others where it was an afterthought.
Our JIRA board is being gamed for management. Our sprint burndown chart always looked terrible because management changed things around mid-sprint by adding issues or swapping them around. So we have a fake JIRA board that has a perfect linear downwards progression because we keep changing the story points. For actually tracking the progression of the sprint we have a secret Slack channel that management can't see. T…
There seems to be a lot of misunderstanding about this article. First, you have to understand the context. This person is talking about an Extreme Programming team. Speaking as someone who wrote a book about XP, here are some things that are true about by-the-book XP teams: 1) All production programming is done in pairs, all the time. 2) Everybody sits in a shared team room at dedicated "pairing stations." 3) The atm…
He goes through a lot of psychology and science of how people work better when they're not distracted. It seems that all of the "Extreme Programming" guidelines go quite the opposite of what the science, per Cal Newport, suggests.
He also points out that collaboration is perfectly acceptable during deep and focused work, but this doesn't sound like how it should be at all.
You know what I don't get about status updates? We're all using tools like Jira, Trello, Pivotal Tracker, GitHub issues, etc., where you can see what everyone's working on and the status of each of those tasks. Why do we need frequent status updates like standups and PMs looking over our shoulders if you can just go to the project board and look for yourself? If I'm going to be asked about the status of what I'm doin…
I'm a big believer in "using the tools engineering is already using" but you need to also have a culture of including status updates in bugs. Developers typically are used to putting developery stuff in bugs, not statusy stuff. Crash logs, stack traces, commentary on possible root causes, diffs, etc. you can always find in the bug history. But updates? Not so much. Even a little "UPDATE: Root cause found, fix in prog…
Earlier quoted context omitted.
I'm extrovert as hell and I like pair programming...but not having "what are we going to do" written down, combined with a constant hum of conversation in the background sounds awful.
Depends how hard the problem is you are working on? I could totally imagine solving easy to medium problems in that environment. For hard problems I’d probably leave the room and think alone till I have something worthy of discussion
I don't know how many product people you have, but if everyone followed your suggestion at some companies, then the developers would spend all day chit-chatting with product managers and nothing would ever get done. Even with only 1 product manager, I can't imagine that spending ~40% of the day on status updates is worthwhile. (Literally have had meetings where the answer was "status is the same as it was an hour ago because we've been in this meeting giving repetitive status updates the whole time.")
What you need to do is get to know the developers themselves - how they work, how they communicate, what their domain knowledge is, etc. Then you'll know when you need to message them. And hopefully they'll know when to message you, but you'll also learn which ones might not under which circumstances.
Some will spend a lot of time planning, achieving nothing, but then produce something well-planned. Others take a quick stab, learn from it, iterate, and refine. And there are other styles.
Some try to understand things better before talking about them, others want to talk first. Some have enough domain knowledge that they can 'be the user', while others see the user as the one who keeps screwing things up and making things difficult.
All will occasionally get stuck in that cycle of "ok, it's _almost_ done" without realizing what they don't know until they take the next step. Interrupting to ask in that case isn't going to change anything. It's just something that is always going to happen and is (or should be) factored into the long-term planning averages.
The best PMs know their developers and know when to ping and I'm happy to talk to them when they do, even if (especially if) I'm not doing well. They don't pester me several times a day, so I don't need to spam filter them.
If you're really having anxiety attacks and paranoia several times a day when you're not monitoring your developers' every move, you should consider a therapist and possibly a more easygoing laid-back job. Software is stressful, but it shouldn't be that stressful, and inflicting stress on your coworkers isn't a great solution.