What other levers do you pull when the response to updates from engineers is consistently, “it’s going fine”? What other ways do you frame the question to get more detail?
7 Likes
What kind of detail are you looking for and what format are you using (i.e. video call vs. email vs. slack msg?)
7 Likes
Here’s a few things to try:
- Are we Green, Yellow or Red for ABC milestone?
- Does this task need to be broken down into something more granular?
- When would you need input from me or someone else?
- Is our initial scoping for this still accurate?
- Do you foresee any blockers or issues?
- Will we be able to demo something by end of the sprint?
- Does this work overlap with other work being done by the team? Or work done by other teams?
If there’s more context, happy to offer more ideas
6 Likes
Thank you @MarcoSilva, That was very descriptive.
I’m looking for more visibility so I can be helpful (unblocking, managing expectations) and understand when we’ll wrap so we can plan better.
Currently using slack msgs… would ya’ll recommend a more sync format for this type of thing?
6 Likes
You could try:
- Bringing this up in a team meeting (retro could be a good place if lack of visibility has caused issues or seems like it will cause issues)
- Chat with the engineering manager and tech lead (and possibly other cross-functional leads). Make sure there are clear expectations on this for the whole team. Make sure everyone knows what good visibility looks like and that they’re responsible for updating others and asking for help is a good thing. It’s good that you’re probing for updates but that can’t be the first line of communication
- Doing a synchronous chat with 1-2 individuals for work that you’re especially involved in. This can double as relationship building
- Give examples of things you want to be notified of or types of visibility that would be helpful to you and maybe quick example of why it is useful. E.g. Please let me know when we are a few days away from X because that is when I know I need to start notifying beta users and they need a few days to a week’s worth of notice\
6 Likes
I haven’t found sync vs async / Slack to be a huge determining factor in getting the proper visibility if the right culture and expectation is in place
6 Likes
Great questions from Marco - agree with those!
I find that until I know how each engineer works/communicates, having 1:1s is helpful to build relationships and understand how they like to have those conversations. Some engineers on my team will just include estimates in technical docs, while others have to be asked. In general, I have regular 1:1s with all the engs I work with (small group right now so I can manage it).
In our planning meetings as we’re breaking down a big project, I ask questions like what parts of this are going to be challenging or time-consuming? What milestones can we expect to hit in this sprint? Talking through that in a group discussion then makes it much easier to follow up later async i.e. “are we on track for milestone X”
It’s also useful to explain what the detail will help you accomplish - whether it’s customer comms, beta testing, updating support docs, working with marketing on product marketing/website updates, etc.
5 Likes
Super actionable, thank you thank you both! These examples are so helpful. I feel like part of the issue here is I don’t know enough yet about what I’m actually looking for… just know I need more than “fine”.
This gives me great ideas to be more clear + direct w the ask!
4 Likes
Adopt a curiosity mindset, especially if you’re not technical in background. Find a way to get past the “they won’t understand” piece. But also, trust? It’s their job to give you an ETA. If they say it’s going fine, and it ends up not being fine, you can tackle this in a retrospective and see where you can help.
3 Likes
Do you set a target (e.g. release date, xxx/second processing capacity) for each your project with engineering? Are they able to meet those target most of the time?
If the answer is yes then maybe you don’t need to worry too much. Use more personal approach to make them more friendly or open.
If they can’t meet the target, then that’s where you can start digging and asking “why” and “what’s the action to fix this”
2 Likes
Majority of points have been covered. I am a Product Engineer, straddling on both sides, so sharing my 2 cents.
- Building trust is the foremost step otherwise any action you take can be challenge.
- Evaluate which of the targets are high-commitment vs which are low-commitment. You would want to spend your energy on the high-commitment ones.
- Engineers should be the ones coming up with target date, milestones and key capabilities.
- Keep repeating the question
What is the biggest risk do you see in launching this on target dateand support in de-risking them - This doesn’t have to be a fixed template with everyone, as you build high confidence with few engineers you could be spending less effort with them while helping the ones where you are not able to be confident (do reflect on this)
Hope this helps
1 Like
I like to create a culture around demoing work. This provides me more visibility into in-progress work without it feeling like accountability. There are many benefits to demoing besides visibility:
- it helps everyone present and talk about their work.
- allows people to show off what they built, which is fun and also good for cross team learning.
- it creates more of a co-building dynamic where i am in the trenches with the devs, rather than being the manager who only asks when something will ship
- provides opportunities to ask clarifying questions and highlight discrepancies earlier in the process
- there’s a lot of context i can pick up from a video that would be lost in a written or verbal status update
Demos should not be polished, they are a quick loom that they post in slack or on their dev ticket. Can also do these live as a team, but I prefer async.