¿Cómo establece confianza y credibilidad con su equipo de ingeniería?

I've seen that sharing this overarching strategic context for the arc of a large problem we need to solve is very useful to Engineers who are trying to both solve for what is at hand and anticipate where this solution design will iterate next. On a lighter note, it also implicitly moves the Engineering team onto equal footing with everyone else who knows where we're going over the next few months. When the strategy or vision are shared and discussed, the Engineering Team is not being asked to "just build this." But rather, "let's all solve this bigger thing together."

I prioritise open communication, ensuring my team knows not just the 'what' and the 'how,' but the 'why' behind our projects. It's pivotal to involve them in the strategic process, offering clarity on our objectives and how their contributions fit into the bigger picture. This fosters a sense of ownership and alignment, key drivers of innovation and productivity!

Establishing trust and credibility with engineering: 1. Communicate transparently and honestly. 2. Respect their expertise and listen actively. 3. Support their growth and development. 4. Follow through on commitments consistently. 5. Collaborate closely and value their input. Building a positive relationship fosters a strong and productive team dynamic. P.S. What's your top strategy for earning trust in your engineering team?

Building trust with your engineering team: 1. Communicate openly and authentically. 2. Respect their expertise and autonomy. 3. Support their professional growth. 4. Acknowledge and learn from mistakes. 5. Foster a collaborative and inclusive environment. Trust grows through consistent actions and mutual respect. P.S. What's your approach to earning trust in your team?

Building trust with your engineering team is vital. Communicate openly, listen to their ideas, and provide support. Acknowledge their expertise and involve them in decision-making. Deliver on commitments and prioritize their growth. Trust is earned through consistent actions and genuine care for their well-being. How do you foster trust within your team?

In my software product team, we first work on Discovery (understanding the user and their problem) then Delivery (building the solution). Organizations that respect their engineers include them at the beginning of the Discovery phase, not just in the Delivery phase. Including Engineering teams as early as possible (along with Design, Analytics, and QA) makes the end solution better and creates buy-in amongst the whole team before embarking on the product development process. We use a kick-off meeting and related documentation template to bring all the relevant people to the table right at the beginning. This early inclusion and documentation is a key part of respecting and valuing the range of possible contributions from your Engineers.

As someone with deep roots in TPM, I've learned that the cornerstone of a thriving engineering team is respect. Acknowledging and valuing your engineers' expertise isn't just about trust—it's about effective leadership. Practice active listening in meetings, be transparent about decisions, and encourage ownership with clear, achievable goals. This not only accelerates innovation but also builds a culture where respect and credibility are mutual!

In adding value to an engineering team, I think a PM showing curiosity and learning from the engineers is highly respected. On top of this, pursuing various learning paths can help you gain a high-level understanding of their domain, enabling you to communicate more effectively and make informed decisions.

Our software product development teams are made up almost entirely of people working remotely. Thus, I would emphasize the importance of clear written documentation. In our agile product development process, we keep documentation light. We use a mix of relatively brief contextualizing and summary documents as well as progressive documentation in User Stories. Regarding clear communication, the most important part is in concise and unambiguous Acceptance Criteria collected in only one place (ideally in the User Story "ticket"). Specifically, we use Gherkin Syntax for our user stories to make test writing easy and to make intended actions and effects clear.

5 ideals I stick by: 1. Listen to understand versus listening to respond 2. Get to professionally know each member, their styles, concerns, and importantly, their visions, by getting on their calendars 1-on-1 3. Communicate the good, the bad, and the ugly early. No surprises 4. Encourage programmatic updates on boards (Azure DevOps, Jira, Asana, ... ) by makign stand-ups something to look forward to (coffee and doughnuts ... wow) and provide assistance ... always 5. Have fun by providing a balance between work and fun stuff people do (e.g., Cricket is a nice conversation across cricket fans)

In my software product team we often talk a lot about healthy boundaries in the ownership of the "Why", the "What", and the "How". These are good "Why" and "What" questions for Product to lead on answering: Why is this problem important to prioritize solving? Why is this valuable to our company? What is the problem we need to solve? What are our hypotheses to test? The "How" though, that's where it is vital that Engineering teams have their autonomous space for creative problem solving. How will we architect this solution? How does this interact with other parts of our software estate? These (and many more) are all good "How" questions for Engineers to lead on answering.

Listen to the engineering team. Take the time to understand their concerns. Defend the engineering team when appropriate. Don’t tell them that they don’t understand when the schedule desires don’t match up to reality (in most cases, they do understand and they are busting their humps to try and get as close as possible to the business desire.) You can ask for the difficult but don’t ask for the impossible. Share your concerns and the issues of the business unit — but make it a conversation. Don’t betray things said to you in confidence. Try to help them and in return, include them when you need their help. When you have a product management problem, ask them for ideas. Be willing to make tradeoffs — give something to get something.

Communicate early and remind goals Every project/feature has a goal that needs to be communicated early so that we are very clear with Engineers about the problem we are intending to solve for end users. Any feedback must be provided on fly rather than conveying at the end of Sprint or deadline.