Forums

I work in an IT organization where I'm responsible for all of our customer interactions and I rely heavily on the development and operations teams to actually deliver a product. I have no authority over those teams and my team has to manage expectations and retain customers when something goes sideways. One thing that I frequently face, especially when working with the other teams to try to remediate an issue that affects our customers, is the response of "I don't don't have a timeline for that - this is the first time we've had to do this."

While I understand that the situation may be an unknown, that's not really something I can take to customers or tell my team to take to customers.  Attempts to work out a timeframe have resulted in escalation to senior leadership who back up not having a timeline.

Does anyone else deal with this? If so, how do you handle it?

jrb3's picture

The "first time" phrasing triggers an alarm bell for me, though -- first time to address a problem, a problem with this stack, this specific type of problem with this stack, what?

Another thought:  "timeline" might have different meanings for you and for the developers and operators.  Perhaps you want a brief sketch of current approach to solve, while they think you're asking for when the solution will be in place and active.

What I found helps is to emphasize that I'm looking for something to communicate onward.  "Hey, this is a lines-out issue for three specific customers.  They're expecting me to check in hourly until the dust settles.  Who's leading our technical response?  I want to make sure I'm staying out of everyone's hair, yet connecting us to anyone outside we need to resolve this, and keeping our customers happy while we fix this."  Then work with the response-lead to get rough schedules and insights and activities to pass along.

kashworth's picture

Most times that I hear technical team leads refer to "1st time" is do dig into what that means as it matters.  However, pulling the leads into a discussion about their approach/steps to get to the solution always bears fruit.  Why?  They always know how they intend to get to the end-in-mind, while my role is to solicit their input and help to frame the approach/steps over a timeline.

The timeline, IMO, is something that must query the tech leads with "when will you know enough" to give me an iteration 1 of the project timeline.  That drives responsibility, for me, to set client expectations that aligns with the software development process (approach/steps) and sets-up the check-points and ability to manage initial expectations.

No technical leader, doing anything for the first time - stack or operationally - can tell us "when" but the secret is to get them to tell you what they have in mind for the end...and the steps to get there.  That's the clear synergy between the client facing role and the technical role in this dynamic.