0

I work as a Lead dev in a tech startup whose product is a B2B SaaS application.

Late last year, in a moment of crisis for the company, my team was asked to build the central feature of the app in a very short time, and without any product spec - no user stories, nothing.

After it was done, I shared a basic product spec for the feature, thinking the product team would want to take it over... hmm.

The problems with this feature have become a central point of criticism of my team over the last 6 months, although despite two further efforts to spec the feature and to get the product team onboard, I was told recently that "since the tech team built it, the tech team owns it".

I have no access to users of this feature (so I have to guess how they want it to be ?), I have a huge workload elsewhere, and the product team is VERY inexperienced and includes the boss of the company.

My questions

  • is this a "normal" situation ?
  • if it's not normal (and supposing I can convince them of this...) what might a smooth transfer of responsibility from us to them look like ?
2
  • Barnaby's answer is the logical way to address the problem. But from what I understand from your post, your boss should be aware of the entire situation, right? How it was built, the initial spec, the criticism, your current workload, etc. Yet their aproach to solving the issue is to try to throw it back over the fence? Within their own company? Your boss should have been the first to propose collaboration, clarifying responsibilities, and finding the best way forward. Perhaps I don't have the full picture, but this looks like a red flag.
    – Bogdan
    Commented Jul 24 at 18:04
  • @Bogdan yes you have the full picture, unfortunately
    – EREFF
    Commented Jul 25 at 6:18

3 Answers 3

3

Sadly this is not an unusual situation. It is what I would describe as "silo thinking".

I would recommend that you favour collaboration over having a clear definition of responsibility. Look for a way for your team and the product team to work well together.

A good first step would be meet with the product team to reset the relationship. I would suggest focusing on:

  • What are the product team's concerns with the current situation?
  • What can be done to overcome these concerns?
  • What is the most productive way to manage the feature going forward?

The key will be to make this session collaborative and non-confrontational. While there is disagreement there are no winners. By finding a compromise that all sides agree to then you can at least start to make forward progress.

0

This is something we face a lot. For the smooth transition of the ownership of this document can be done while implementing updates to the feature.

When the product team requests updates to the feature, you can ask them to update the documentation according to their needs (with “track changes” for example) so that you can come up with the list of changes needed. This will help you to learn the new requirements and incrementally deliver the ownership of the document to the product team.

0

Based on your description, heres what we know:

  1. Engineering built critical feature approx 6 months ago. (in the absence of Product team)
  2. Engineering updated feature specs from basic to adv in two increments.
  3. Product team was onborded with the updated feature specs.
  4. Product team is new and inexperienced.

Assumptions:

  1. Product spec here mean the Feature Acceptance Criteria
  2. In all likeliness, the Acceptance Criteria will become User Acceptance Test (UAT) which usually be signed-off by Business / Product.
  3. Technical specs are internal to Engineering, Product may not need it.
  4. Since this feature was done as an emergency, your manager or skip would know about it and will have the context when you bring this matter for discussion.

Your questions:

  1. is this a "normal" situation ?
  2. if it's not normal (and supposing I can convince them of this...) what might a smooth transfer of responsibility from us to them look like ?

My POV:

  1. This is normal in fast paced env, however continuation of maintaining Aceptance criteria by eng might not be normal due to conflict of interest.
  2. As Tech Lead, smooth path would be to esclate to EM or TPM and let them handle / define RACI matrix.

RSCI Primer - https://www.cio.com/article/287088/project-management-how-to-design-a-successful-raci-project-plan.html#:~:text=The%20RACI%20matrix%20is%20a,Accountable%2C%20Consulted%2C%20and%20Informed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.