Why would any talented engineer work with this guy?
The art of interrupting software engineers
31–40 of 255 posts
Re: The art of interrupting software engineers
#32I work for Pivotal. Product managers vary in how they work with a team, so this approach is new to me. As an anchor (approximately a tech lead) I made it my business to work closely with PMs on the product: giving feedback on how the technical direction was shaping up, asking for stories to be updated or broken apart, giving options for technical seams and so on. Frequently we embed product designers as well, so disc…
> In particular we had a particular giant tech debt: we had fallen behind on React versions. Worse, I don't want to read any further. Surely it doesn't get worse than that! /s
It's a dependency for our main visual library, PivotalUI, which is meant to give a uniform brand across all our products. When you get a flagship site falling behind the products that customers have installed, it looks dumb.
But more to the point: it slowed development. I could deal with a bit of visual glitchiness, but my job as an engineer is to create software to solve problems. Piling hacks on top of hacks doesn't do that and it's shitty to the next engineer who joins the team.
Re: The art of interrupting software engineers
#33I've found the best way to avoid interrupting engineers is to have a daily sync (a.k.a stand up meeting). My team meets for 30 minutes each morning to give an update, have Q&A, and discuss priorities and issues. We're a small team (3 developers) but it works perfectly because folks either had their inquiry answered earlier in the day or can execute good judgement to try to figure it out and if not ask about it tomorr…
A daily sync is way too often on teams that know what they're doing. It feels like busy work and is a waste in throughput and stress. Once a week, with committed items with a true definition of done is all that is needed. Anything in-between should be facilitated by the team members to unblock each other. Anything else is just stakeholder over management and or inexperienced teams. edit: at the most, I think async ar…
> Anything else is just stakeholder over management and or inexperienced teams.
At Pivotal we see the PM as part of the balanced team. The PM, just like designers and engineers, will have the daily standup, weekly retros and planning meeting together. The goal of the standup is to share what of interest happened yesterday, if help or opinions are needed and discuss pairs for the day. Sometimes discussions start about topics mentioned in the article where it's crucial to have the PM there.
Standup should usually be around five minutes. That's the reason it's not a sit-down meeting.
Re: The art of interrupting software engineers
#34If I had a PM come by my office twice a day to "check-in" I think I'd quit.
Pivotal also has thing where everyone is expected to pair program all the time. I think I would despise the environment but it’s clearly not for everyone, myself included.
OK, all the time is a bit extreme but pair programming is actually a lot of fun and a great way to pass on knowledge when done right.
Re: The art of interrupting software engineers
#35Earlier quoted context omitted.
A daily sync is way too often on teams that know what they're doing. It feels like busy work and is a waste in throughput and stress. Once a week, with committed items with a true definition of done is all that is needed. Anything in-between should be facilitated by the team members to unblock each other. Anything else is just stakeholder over management and or inexperienced teams. edit: at the most, I think async ar…
I like daily syncs if they are done quickly (<15m), and if people are working on different-enough things that they don't really know what their teammates are working on. Because that way you can unblock each other and actually use agile the way it was meant to be done in the face of underestimated tasks or changing requirements
In my experience anything more than 10 minutes is a smell. It typically means you've got stories that are too big, have unaired problems, that you dive into implementation instead of just syncing briefly, or the team has too many people.
Re: The art of interrupting software engineers
#36Judging by all the negative responses do most people see themselves as some sort of vigilante programmer in their company?
I'm not a PM but I sympathize with how difficult it is to discern where a project is up to when it comes to software, especially when you can't come up with short enough milestones...
Re: The art of interrupting software engineers
#37Is it really common for software engineers to work under these conditions? As an electrical Engineers I have plenty of deadlines and do plenty of work with PMs, but none of this daily standup and thankfully Jira was recently dropped as it was considered more trouble than it is worth (management just wanted to know the big things going on and not all things). Of course it's better than plenty of other jobs, but the constant treatment of employees like they're on an assembly line sounds rough. I know software development is tough and respect those that do it. I have critical time sensitive tasks and I'm expected to have them completed on time. My manager might check in once a month on a year long 1/4 million dollar project among all the other work I do. I know that's peanuts compared to a large software project, but still.
Re: The art of interrupting software engineers
#38I'm a PM and this does not resonate with me. If you're getting status twice a day... I think something is very wrong.
The brutal truth of software development is that the quality of your output is going to vary with the quality of the engineers you work with. Good engineers don't need daily standups to build great products, and bad engineers aren't going to be helped by doing twice-daily checkins.
Re: The art of interrupting software engineers
#39Judging by all the negative responses do most people see themselves as some sort of vigilante programmer in their company? I'm not a PM but I sympathize with how difficult it is to discern where a project is up to when it comes to software, especially when you can't come up with short enough milestones...
I think lots of people have just had genuinely shitty experiences where they were slowed down in their work by interruptions or made to feel that they were not trusted as professionals.
They see this and it fits a pattern and so they are fairly skeptical.
Re: The art of interrupting software engineers
#40Thank you for reminding me how much I dislike working with PMs I especially can't imagine working with this one. Imagine constantly having to revise estimates and getting micromanaged by someone who isn't your manager. The "role responsibilities" conversation would happen very quickly I find it especially ridiculous that this person is interrupting people two times a day for fresh updates on top of a daily standup .…
Until recently, I shared your sentiment about product managers, but recent experience has refined my point of view.
IMO a good product manager does not focus on trying to understand _why_ things are hard, but rather _what_ things are hard.
With this understanding they can either 1) work to change scope/requirements so that the bigggest user pain points are solved ASAP or 2) accept that more time than anticipated is required to solve user problems.
Implicit in all of this is the trust that when engineers say something is hard, it is actually hard.
When I see the author talking about paranoia, trust is the first thing that comes to mind.
To be fair, I don’t think that trust is easy. But I also don’t think that effective product management is possible without it