Some context: I started working at a startup with 8 employees as a mid level developer about 3 months ago. One of the responsibilities I was tasked with is facilitating communication with our product support/QA team and our engineering team. I really enjoy this type of task as an occasional alternative to engineering responsibilities, but I am finding it more challenging than expected.

The end goal is to create repositories of information and to establish regular communication channels between the two teams.

I set up a biweekly meeting with the customer service liaison and we've gotten a few actionable items from those meetings so far. But I'm definitely struggling to find a format for this meeting. I tried it with an open ended and casual tone, but it feels too meandering and vague, so I would like to develop a regular format.

How can I structure this meeting to facilitate our goals? How can I use our existing toolset(Atlassian suite) to improve communication? How can I avoid wasting the customer service rep's time and maximize value from this meeting?

  • You’re an 8-person startup which means your “dev team” and “support team” are, what, 2 people each? I’d be thinking a lot more frequent and less involved than a bi-weekly meeting.
    – Kaz
    Dec 19, 2020 at 18:52
  • 6
    At 8 people you should not have team liaisons, just talk to one another. Why not do just that?
    – Aida Paul
    Dec 19, 2020 at 20:18
  • An every other week meeting should include 1. What new clients are Sales bringing in (new directions), 2. What problems does customer service have, 3. What is the status of any new tools that are being developed for customer service? 10-15 minutes max unless they have unaddressed issues.
    – David R
    Dec 20, 2020 at 16:11
  • Is everyone working remotely? If not, is everyone working in the same room? Dec 23, 2020 at 2:04
  • No, everyone is remote. Dec 27, 2020 at 14:34

2 Answers 2


Identify needs and meet those needs.

Your customers obviously have aspects of their work that can be improved upon. You, as a business analyst (as that's how I interpret your role in this situation) should be gathering requirements from your customers as to how they can improve their productivity and revenue-earning ability and map those into technical requirements for the engineering team.

If your customers don't know what they want, then ask them what takes up most of their time and what holds up revenue, then work on those.


Do you even need to be doing this? Functionally it just seems to me that your organisation want to do like big organisation from the start and carry on.

But you must understand that such process are there for reasons. As a very small teams with possibly a few clients you shouldn't bother too much with those things and take advantage of your flexibility. Have a ticketing system where the clients can post and your team can see those. No need for a middleman to consult one or two clients and report back to a handful of devs.

Though I agree that being too close to those clients may create some entitlement this create goodwill and may be necessary to grow.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .