Without a doubt, building and shipping software is a difficult and multidisciplinary endeavor. I feel pretty strongly that working with people with different backgrounds and communication styles is going to help you build a more robust and accessible system.
There are many methods to help keep a varied group of people aligned as they work towards a common goal - one I’ve seen that seems to have a high likelyhood for sucess is “agile”. I’m going to share a metaphor that helps my brain understand the various roles within a team and how they help move the project through to completion. This is just what I’ve found helpful for me and there are as many different implementations of the agile methodology as there are teams, so please take whatever value you can from this but don’t view it as prescriptive necessarily. If you’ve found what works for your team, don’t feel pressure to change what you’re doing - keep shipping!
The metaphor is pretty straightforward, it’s a car or vehicle of some kind. It doesn’t matter… Like any metaphor it will break down if you push it too far but it should serve to acquaint a team with where it’s responsibilities begin, end, and perhaps overlap with others.
Here’s the basic components of the system:
- The steering wheel
- The fuel system
- The engine
- The brakes
- The mechanic
The steering wheel
The steering wheel controls the direction of the vehicle. It is the person/group that decides where to go and how to get there. This is often a collaborative endeavor with the Product Owner/Manager as the primary voice.
The fuel system
The fuel system provides the raw materials for the engine to work. This is really about understanding what the requirements are once a direction and prioritization has been decided. The design group, will coordination with the Product Owner and help to solidify their vision in enough detail that other groups can bring that same vision to the end users.
The engine
The engine makes the vehicle move. This is the development team, they’ll take the requirements and make it functional within the current system. Ideally, they perform efficiently (implement feature in a maintainable manner) and don’t cause waste (tech debt).
The brakes
The brakes make sure the vehicle doesn’t go somewhere it shouldn’t. This often takes the form of a QA team, but other stakeholders can put limits on direction or velocity too. This shouldn’t be perceived as negative, if you’re headed towards a cliff, you really want good brakes!
The mechanic
The mechanic is the person/group that makes sure that each component of the system has what they need to perfom optimally and ensure that each component is effectively communicating with the other components. They may not be involved in the day to day driving, but they are essential to the driving experience. This role is the “project manager” typically. They need to understand what each component of the system is focused on and how it fits within the system at large. While it can be helpful, they don’t necessarily need to know how each component does what it does in detail.
Now, again, it’s not a perfect metaphor, but it’s good enough to get everyone on the same page about responsibilities. Metaphors are only as good as their relatability - since it’s very rare for anyone to have zero exposure to a motor vehicle it should be easy to understand.
One of the most important but implicit messages is that the system at large doesn’t work if any one specific component fails or the interface between components fail. There is no “most important” component, they all work together to achieve the desired outcome.