You're facing clashes over tools between developers and engineers. How do you bridge the gap?

Before any decision regarding which tool to put on a shortlist is made, every stakeholder - both from the development team as well as engineering departnent - should have their say. Not only to make them feel they have been taken on board but for obviuos reasons such as the fact that it is them, not the management or the purchasing, who understand the best all desired functions, questions regarding stability and robustness etc. One of possible ways to get to the finel shortlist is a mind map plus SWAT analyses.

Software Engineers, Development Operations, and Infrastructure will always want best practice systems that provide flexibility, ease of use, robustness, high performance, and a litany of other factors. But at the end of the day none of these people should be making this decision only providing the best information so that the business can make an informed decision. The fact is modern software development is a balancing act at most if not all companies. If the business decides the pace of feature implementation is the most critical and potential risk is outweighed in their strategy then that is what the technology team should prioritize. Learning business needs and how to properly assess risk are critical for an IT organization.

Engineers and developers have different perspectives over the tools needed to complete a task. However they are united by the same goals. The key to that is communication and ability to achieve balance between performance and reliability.

The dialogue should ideally not only relate to the colleagues of the particular company, but also include cosultation with other 'mates' with deeper/longer experience with that particular tool which is being considered. Similarly to a situation when a private client is researching product reviews in order to either foster his/her preference and, above all, prevent making wrong decition; these pieces in information can be also helpful in the process of purchasing new engineering tool for a company. Take into consideration experience and other helpful information from those who come from comparably large/small company positioned in an analogical field of business, naturally.

My major concern about a number of these questions is that they assume that engineers and software developers are two independent silos. That structure just doesn't fit a modern IT organization. A modern organization has full-stack broad t base teams that cover both infrastructure and development. Teams will always have subject matter experts but in the end they can all work on the system end to end. Certain centers for excellence exist for each skill generally under the office of the CTO. For example, a CoE for Development Operations that provides resources and training to teams for implementing best practices in CI/CD and IAC. The question is flawed or atleast dated.

Regular meeting between engineers and developers will ensure that the project is on the right track. It will facilitate consistency and help the team meet deadlines.

Your shortlist with alternative options for the engineering tool should actually not be too short. There is a general understanding that human mind can comprehend maximum four items of the same/comparable kind, not more. This would be my reccomendation regarding the short list size, but obviously it largely depends on many technical and business related factors. Once knowing the alternatives, figure out criteria which can be measured (numerized) to create an unbiased assesment chart/table. For example, as the answer/rating of the the already created SWAT analyses, especially the strengths and weaknesses part.

In large organizations a CoE group will implement and assess tools for use. Team propose tools for consideration and an approved list is provided by the CoE. Smaller organization use a single developer to build a POC of each candidate and then present the results to the rest of the team. This tends to be a senior developer. It is critical that these sorts of decisions are made ahead of development and are well informed as choosing the wrong technology can make or break a company. Some companies especially SaaS companies are valued purely on the quality of their software. Business consideration like staffing, dependency, and cost are just as important as performance, scalability, and longevity when considering a tool.

Every engineering and developer tool has its own benefits and weaknesses. However everyone needs to work together as a team and decide where to use a particular language or environment. This should be based on careful weighing out of solutions and abilities to compromise.

If you know that the purchasing process is not unique but sooner or later you are going to face a similar situation again, it really pays off the create guidlines for the process. You sould therefore, right from the beginning, protocoll or your important steps plus note potential pitfalls and mistakes/omittments you made or were lucky to avoid so that next time you have your cook book ready to make the purchasing process more efficient and faster.

Creating guidelines is crucial for every project. There should be clear objectives and requirements. The tools selection is dependent on all factors pertaining to the project and its a unanimous team decision.

I beliefe the two groups - engineers and developers - should never be treated and should never feel as two divided entities, two worlds which do not communicate with each other since they have not sufficient empathy for the other party's needs/troubles. Joint sessions, trainings and vivid exchange of experience - e.g. in form of a know-how plattform which is available and accessible for everyone from both teams - is ideall, in my opinion. It is only important to guarantee that those joint sessions do not turn into regular compulsory workshops where 90 % of the attendees are absent-minded and passive, waiting only for the lunch break.

Training implementation sessions for new tools are great for professional development. It can help bridge the gap between engineers and developers. This will lead to acceptance of new technologies and ease stress and uncertainty.