If I had a PM come by my office twice a day to "check-in" I think I'd quit.
Same. I'd be pissed. I mean, if they have time to come by everyone's desk a couple times a day, WTAF are they doing and why are they getting paid for it?
The art of interrupting software engineers
11–20 of 255 posts
Re: The art of interrupting software engineers
#12I 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 discussing design options and asking for modifications was common.
But when I was pairing with another engineer we did whatever was on the top of the backlog according to our best judgement and with attention to quality. If it needed refactoring, we refactored. If we felt that would be better to wait, it would wait.
The most important discussion, I found, was about chores -- work that engineers view as paying dividends in future velocity. Our view is that engineering is the ultimate owner of chores and can schedule them according to its considered discretion. The system works because of trust. I trust that product managers and product designers will be diligent in identifying user values and priorities. They can trust us to do what needs to be done to make the software to a sustainable high quality.
I remember once I was rotated in as anchor for a product that had begun to struggle a bit. In particular we had a particular giant tech debt: we had fallen behind on React versions. Worse, there were three parts of the codebase using React, in three different ways. With my peers I decided that we were going to fix it. "I think it will take one pair week", I remember saying.
It took five weeks. But nobody ever said: stop, you work for me, my way or the highway. We talked about the reasons. This tech debt would only grow as time passed. There was no good time to repay it, so sooner was better than later.
We were trusted to do the right thing, so we did the right thing.
Re: The art of interrupting software engineers
#13I'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 are passable via slack or something similar. Otherwise all data on this can be easily done via a Kanban board.
Re: The art of interrupting software engineers
#14[deleted]
Re: The art of interrupting software engineers
#15Software engineers aren't special. Literally any job that requires a modicum of concentration, whether it's writing marketing copy or doing complex financial forecasts, means that interruptions are costly.
Re: The art of interrupting software engineers
#16If 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.
I was skeptical too, before I joined Pivotal Labs, but I love it. It's worth noting that it's a skill, or rather a collection of skills, that are much easier to learn from an experienced pair.
At the moment I have been on a solo allocation for about 6 months. It has let me go down a lot of rabbit holes, which can be educational. But I miss pairing pretty badly on days when I am working on straight regular development.
Re: The art of interrupting software engineers
#17I'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…
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
Re: The art of interrupting software engineers
#18I only read the first paragraph and couldn’t read anymore. I’m unsure why he cannot Know when a story will be delivered. A story should fit into a sprint and so he should reasonablely expect that it’s delivered at the end of that sprint. If it’s not going to be delivered then this information should be relayed back to the pm.
Going and pestering the team is only going to slow down development process and increase the likelihood of the team not delivering for the sprint.
Re: The art of interrupting software engineers
#19If 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.
I thought I would hate pair programming, but it turned out to be, BY FAR, the best thing that ever happened to me professionally.
That said, it really isn't for everybody. But you may want to give it a chance.
Re: The art of interrupting software engineers
#20> 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.
This is monumentally bad advice.
> I try to find a time when a pair does not seem to be heavily focused. Some of the cues might be they are having a casual non-work related conversation or are just returning from a break
So surveill and/or eavesdrop and/or ambush. Nice.
> Hadrien Raffalli is a Product Lead at Pivotal.
Here's me thinking it's probably a more junior PM doing this. Nope, it's a Product Lead.
PMs/TPMs can be great, if they are good. I've worked with some that made my life easier. I've worked with others who really didn't.
Based on this article alone, Pivotal's PMs would make me quit.