Building Trust and Credibility Questions

In the first 90 days, I would focus on rebuilding trust by proving that engineer input changes decisions. Trust is belief that your time and expertise matter, so I would design the rhythm around that.

Days 1 to 30

• Meet engineers 1:1 and ask what felt performative, slow, or already decided.
• Sit in planning and retrospectives as a listener first.
• Identify one or two decisions the team can truly influence.

Days 31 to 60

• Change the agenda so meetings start with open questions, not status.
• Share pre-reads early so engineers can react before the meeting.
• Close the loop by showing, "You raised X, so we changed Y."

Days 61 to 90

• Keep only the rituals that produce decisions or unblock work.
• Retire meetings that are just theater.
• Ask the team to rate each meeting on usefulness.

Concrete example
If planning used to be a 60 minute meeting where decisions were already made, I would split it into a 20 minute pre-review and a 30 minute decision session. Engineers would see their input shape scope before commitments are locked.

The signal that trust is improving is not attendance alone. It is when engineers start raising trade-offs earlier and disagreeing in the room instead of after the meeting.

I would treat documentation as a decision tool, not an archive. The goal is to reduce repeated questions and speed up judgment, so I would keep only the artifacts engineers actually use: a one-page decision log, a short RFC, and lightweight operating notes.

How I would set it up

• Define what each doc is for. For example, an RFC answers, "What are we deciding and why?"
• Put an owner and expiry date on every recurring doc so it is reviewed or deleted.
• Use templates with required sections only: context, options, decision, risks, and next check-in.
• Keep operating rhythms tight: weekly planning, a short dependency review, and a monthly retro on process itself.

Concrete example
If a feature has three options, I would ask the team to write a 1 page RFC with the trade-offs in plain language. In the meeting, we spend 10 minutes on the open question, make the decision, and record it in the log. That way the next engineer can see why we chose option B without reopening the whole debate.

The key is to measure whether the process saves time. If a meeting or template does not improve clarity, reduce rework, or unblock decisions, I would simplify or remove it.

I would diagnose this as a system problem first, not a people problem. A dependency is when one team cannot finish work until another team delivers something. Missing it early usually means the dependency is invisible, not malicious.

My approach

• Review the last few slips and ask where the dependency first showed up.
• Map the work stream, including who owns each handoff and when it was first known.
• Check whether engineers have a safe place to raise risks early.
• Look for patterns like unclear ownership, overloaded partners, or planning done too far in advance.

Change the collaboration model
I would introduce a simple dependency register, reviewed weekly, with three fields: dependency, owner, and due date. I would also add a cross-team checkpoint before commitments are finalized.

Avoid blame
In the team conversation, I would say, "Our process did not surface this early enough." That frames the issue as shared. If the other group is late, I would focus on the handoff design, not the people.

Example
If feature A needs an API from another group in week 3, I would raise that in week 1, not week 3. That gives everyone time to adjust scope or sequence work instead of discovering the gap at the end.

I would facilitate the discussion by making the decision criteria explicit before people debate solutions. A trade-off is a choice where improving one goal, like performance, may hurt another, like maintainability or scope.

My role in the room

• Restate the decision we need and the deadline for it.
• Ask the technical owner to summarize the options and their risks.
• Separate facts from preferences.
• Push the group toward criteria: user impact, long-term cost, and delivery timing.

If the room is stuck
I would ask, "Which risk is hardest to recover from later?" That usually surfaces the real priority. If there is no clear answer, I would propose a small follow-up experiment or time-boxed spike.

Example
If option A is faster to ship but harder to maintain, and option B is cleaner but slips the launch by 2 weeks, I would not decide for the engineers. I would ask them to recommend the least risky path, then confirm the business trade-off with the group.

The respect part is important: I make the conversation structured, but I do not override technical judgment. My job is to help the team leave with either a decision, an owner, or a clear next step.

Situation: I joined a team that was skeptical of cross-functional partners because they had experienced a lot of noisy requests and little follow-through.

Task: I needed to earn credibility quickly without pretending I was technical owner of the work.

Action:

• In my first weeks, I listened more than I spoke and asked engineers what wasted their time.
• I came prepared to meetings with context, not opinions.
• When I made a promise, I followed through the same day or explained the delay early.
• I made sure decisions were written down so no one had to re-litigate them.

Result: The team started engaging more because they saw I was reducing friction rather than adding it. A good sign was that engineers began bringing me risks earlier and asking for help before issues became urgent.

What told me trust was building was not praise. It was behavior change: they attended meetings more consistently, challenged ideas directly, and used me as a partner instead of seeing me as another layer of process.