Your team is divided on integrating emerging tech. How do you choose the right path forward?

Choosing the right path forward entails understanding the values and attributes of each technology and their potentials for integration. When this has been asertained , it is very important to plan the whole process. Undertand the needs, objectives, and requirements to see the process to the end. This can be achieved by engaging relevant stakeholders who provide insights to what success looks life

There are 2 things the team may choose the path to be taken if seems both path equally have the same opportunity to deliver value and no side willing to withdrawn their approach: 1. Majority Vote from all the team members and agree to set aside differences afterwards 2. Take the spike method on both path and assess either path fail fast then continue with the other path seems to work well

Project's need to upgrade and integrate w.r.t.technology advancement should be thoroughly evaluated in terms of cost and delivery time saving. Any new updation in work handling is appreciated in the benefit of project progress, hence identifying project need is very crucial for selecting the technology Integration. It adds on to other requirements for implementation such as training needs for team members for new technology as well as expert persons in some cases. Opting for new techniques in early phases keeps the confidence levels low till the time users get handy with upgrades. Experts support for the training phase is crucial as well and works well when implemented on live projects.

Find out whether the emerging tech aligns with your needs at all. Not every new technology has application (although many times engineers love to dream up fancy scenarios !) Also see the broader picture of how it will enhance the product but also enhance the people who work to make it, sell it etc, the human element is more vital than the product!

Consult External Experts: Surely an external point of view can provide clarity. Consultants or industry experts can offer unbiased insights that can change the course of your project for good

There are organizational context to collect with sponsors as well to mitigate : - Cost / complexity of running the applicative landscape if too many different tech stacks are in use. (In our company the usage of a more exotic stack for a new product has becomes an issue when the product has stopped being actively developed and goes in standby/run mode. Indeed, we face now a lack of funds to maintain several stacks , while also making it also harder to reallocate applications between product teams) - Make product teams autonomous in their choice , increasing their motivation and efficiency for this specific job, at the cost of organizational/long term complexity. (Eg amazon CEO letting anyone choose their tech as long as API are exposed)

In general, new tech can be a challenge with the lack of expertise available (persons, documentation, AI..) and instability, so i would say the latest trend should be used when it is justified by game changing new features. In general we tend to go toward the actualized market standards, but not latest innovations. Depends on the risk you can take if your app goes down or you need to completely rewrite it (size of code)

Important to think about the TCO with the unpleasant thought that one day this product will have accomplished it's primary objectives and may have less investments, difficulties to maintain a dedicated team. At that time, it might be less expensive to have some tech that can easily integrate with the stacks of the other teams in the same domains, to ease up reorganization / applications transfers between teams, rationalization of costs.

Do piloto para produ??o, será importante considerar uma avalia??o de toda a supply chain para ter certeza se na escala real, ser?o conseguidos os prazos e custos necessários ao produto. Isso porque o piloto é realizado cercado de aten??o e as condi??es em que é produzido podem n?o condizer integralmente com uma condi??o de produ??o normal.

The helloworld or editor marketing "contoso demo" often works. So go beyond in my opinion in the specificities of your context + beware about timings and loads. Some exemples: - Event driven architecture : how much time from event to reception by subscribers. - Load test, does it support all our users while keeping perf good (<3s good, <10 usable, more forget about it according to google) - Complexity to make the solution evolve without expensive consultants with a generic tech profile and a small training - adoption of business to the front & the backoffice - Support for Oath2 authentification and access right check scenari (such as intricated group memberships.. ) ..

I like to take a very practical approach to any integration or upgrades. 1. You should assess whether the integration into your system will actually improve it for the end user or create unnecessary complications. 2. You should also very critically analyse any integration or upgrade against your existing user market and the intended use of your products. This harmony is one of the most important in any such project. 3. Another critical point would be to look at the integration from a long term perspective. Ask the questions: can I sustain this upgrade over a longer period of time? Will I need to make serious overhauls to accommodate this change? At the end of the day the reason for such upgrades is to make the product better for users.

I think the decision should not be completed only at team level as the impacts can be much wider for the organization. Product team should lead, with support of architects, business and have clear guidelines of organization sponsors regarding the objectives to prioritize (product delivery speed/ tco - organizational flexibility)