2

I work on the new marketing platform for my company and one of the features is notification (push/sms/email.) I decided to build notification as a separate product where any systems can use it. Currently, it supports email notification and we are working on push and sms.

Last week, I reviewed this with my manager and he said another team planned to build something similar. I checked with that team, they said they have checked some third party products and have not started anything yet.

From my experience, they say they will build this or that and tell others to wait for them. I personally think they want to own every product in the company and I do not like that. This has also caused a huge delay to our delivery.

How can I handle this situation? What can I do to prevent this problem from happening again in the future?

Update
We have our squad that set for delivering this marketing platform. The product team of our squad takes care of feature requirements and priority, notification is one of them. We do not have the notification system and need to build one for our product.

Update 2
Each product has a squad of product owners and engineers. Product owners decide what to build and create tickets, engineers choose how to build it. In this case, there are two different products with a few overlaps features. Notification is one of them.

Marketing platform has notification feature to notify promotions to customers. Another product in the company is order management platform which also has notification system.

Improve this question
6
  • 3
    "I decided to build notification as a separate product where any systems can use it." Did you unilaterally make this decision or did you boss ask you to do this?
    – sf02
    Oct 6, 2020 at 17:26
  • @sf02 I worked with product team and figured that we need a notification system. updated in the question
    – Code Project
    Oct 7, 2020 at 1:26
  • @JoeStrazzere Product owner decides what and when to build features, engineers choose how to build it. We wanted this feature and we did not have any systems that do it, so we build one. I am an engineering manager
    – Code Project
    Oct 7, 2020 at 1:28
  • 2
    What's missing in your question and comments is who decides to whom each task should be assigned. Go to that person and make your pitch. If you can prove everything you told us, it should be an easy decision.
    – Ramon Melo
    Oct 7, 2020 at 8:41
  • @RamonMelo i updated the question. each team decide what features to add to product. once the feature is ready, we can share it with another team. the problem right now is that another team says they planned to build it while it's already up and running on my side.
    – Code Project
    Oct 7, 2020 at 16:53

4 Answers 4

Reset to default
3

You need to pin your colleague to a date.

Estimate how soon you can deliver and then pad the estimate by an appropriate amount, maybe 20-40%. Set a meeting with your manager and colleague and state that you require the product to be delivered by this date. Ask if your colleague can deliver. If they say yes then great, you can document their commitment. If they can't promise to make the target then push hard to take on ownership of the project yourself.

Improve this answer
3
  • This is a great suggestion. I have tried it a few times and they never hold on to the date. The closest one they delivered relative to the promised date is 6 months delay. That approach does not seem to work with this situation.
    – Code Project
    Oct 7, 2020 at 1:33
  • 1
    @CodeProject - if it's happened before, you can ask for some milestones and weekly progress updates. If they fall behind the plan, you can go back to whoever makes the decisions and ask for a change of plan.
    – Robin Bennett
    Oct 7, 2020 at 8:52
  • 3
    If you have a department that consistently misses key deadlines by a huge margin but is still given priority for important projects then you have a much larger problem than the one originally stated.
    – P. Hopkinson
    Oct 7, 2020 at 12:14
1

I will try to partially answer your question, that is:

This has also caused a huge delay to our delivery.
How can I handle this situation? What can I do to prevent this problem from happening again in the future.

I think you should focus on trying to not get delayed, rather than focusing on what the other team should build or not. The key here is for everyone to realize that these two requirements look the same "a system that does notifications", but they are not. Your project needs a system that does notifications for your specific use case right now, while the other team is building a generalized system for notifications somewhere. Since you do not have the time to explore all possible use cases to build a generlized solution and the other team is not ready to provide a working solution right now, there is reason to keep both projects for now.

I have been in a similar situation before, except that my solution wasn't even build yet. After discussing it with the other team I told my managers: "They are not ready yet. We don't know exactly what they will we providing and when it is ready, and we don't want to risk being blocked by them, so we decided to go with our own solution for now, even though that means we have to do some of the work twice."

My managers care more about deadlines being met, than about potentially redundant code being written. In your case your code is already there, so you can make an even stronger argument.

I also made sure to appease them:
"I am excited about your solution, and really think when you are done, we should be looking to integrate it with our project. Since you don't have a timeline yet, and we need to deliver by December, I think we will go with our own solution for now. That way our teams can work indepedently from each other, but let's keep each other updated."

Acknowledging that there is room for two systems right now, and it can be merged in the undefined future avoids a pissing context. For the other team it also is a benefit to not have your team with a hard dependency and strict timeline breathing down their necks.

In my case I think in the end it took the other more than a year to finish their service, and we never migrated to their solution, at least as long as I was involved.

Improve this answer
0

From what i gather , your team need notifications as one of your product`s features

Until you told by management NOT to build notifications functionality in anticipation of the other team providing them, your team is required to provide them and can be on the hook for delays, stemmed from not having them.

With that being said, it is up to your manager and team to decide in what way YOUR feature will be built.

As i see it, you can build it as a general solution and utilize it in your project.

And after that your manager can present it up the chain of command as feature of your product that can be made generally available for other projects in the company.

In that case ownership of the solution stays in your team

Improve this answer
-1

Currently, it supports email notification and we are working on push and sms.

So you already have a working solution, they have nothing. Ask your manager to study the possibility to bring that team under your supervision. You already proved that you have good initiatives and you can deliver.

As a supporting material for the discussion, build a small "project plan" - showing the main required activities, desired modules in the software, and the number of people estimated to be necessary.

How can I stop another team from taking over my projects?

I learned it the hard way that choosing words is very important. In your case, you have to remember that all the projects are company's projects, not yours.

Improve this answer

You must log in to answer this question.

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