Coders from Mars Non-Coders from Venus
Men Are from Mars, Women Are from Venus is a book written by John Gray. The book states that most common relationship problems between men and women are a result of fundamental psychological differences between the sexes.The book tells a story that men and women are from distinct planets. Each is acclimated to its own planet's society and customs, but not to those of the other. However, we sometimes seek each other. This is an abstract analogy that developers and designers, coders and non-coders want to join forces and build the same solution but there are issues - in my mind it is communication issues that are in the way. That is the need that a few big tech products are here to solve.
We are struggling with the same issues almost all tech-teams, product and development, face. Communication. It seems like there are tools for every type of communication, that there is a methodology for every issue and that there are so many products out there where in fact every product, looking at Jira, Confluence, Monday, ClickUp and more try to solve the communication problem. Realizing this, I would like to share some of the thoughts that we had in early 2022 looking at the tech industry and specifically at product development and companies that build and maintain products.
This is the text as is was written back in march 2022:
“Drimz investigates the way teams communicate, work and their work processes. The basic technical team of companies in 2022 consisted mainly of a Team Leader with an engineering background, at most. The team size will vary between three and seven other members. Many companies will have members in quality assurance as well as data analysts.
The diagram above shows the members in an extended squad. The colors are the personas types. Developers and Data oriented people are native to code. QA is stepping into the code and is more oriented towards coding. PMs and designers are not. This is because we have even more communication issues between these types.
It is becoming increasingly difficult to manage a matrix-based team. PMs and TLs, as well as other members, need to influence the tasks due to the matrix-like nature of the teams. In addition, this team is facing the problem of "naming", conventions between any of the relationships, such as product, design, marketing, and technology.
With Drimz, this team experiences fewer sync-related issues because it is based on code. Every engineer, designer, and project manager uses the same naming convention and names for many elements and UI components. Drimz provides a few tools for enforcing design systems. Design-Tokens can also be managed by the designer. The tokens can be distributed and implemented correctly in all the components that the organization owns with a simple method.
In place of writing long specs, the team-lead and product changed the way they work using Drimz. A link is provided to the composition and each component. The specs are more "User stories" and business-oriented, explaining flows and usage rather than UI/UX. The PM and engineers are discussing the business's vision more frequently.
Drimz empowers the designers in the teams to share "code". Substantial parts of the "coding" are shifted to the designers.
It is nice, but what else is new? Product managers, CPMs, or design team leads can introduce metrics over the designer's tasks, evaluating "Design Velocity". We no longer have to track "code completion" or "inspections to production", but can track the adoption, impact, and impact of design tools. As a result, feature expectations can be very detailed, and the product roadmap can be developed. Feature and bug release timing can also be tracked by "project managers" on the tech team.”
Let me explain what we meant back then. We would like that at some level all members of a squad or a team, will speak the same language. We think that this language is code. The way communication bridges the gap between people is by developing a good tool or a process that looks at all the “same parts of Mars and Venus people” and with this similarity we work to communicate. In production, there is code on the servers and in the cloud, we should offer code solutions, designers are used to certain tools we shall provide. Product manager and QA would like to be included in the mix, and will try to make the product fit these guys as well. However, for now, we focus on making the team communicate over code. While in the future to allow every member in the squad be a participant sharing code that will hit production at some point.
Companies that have great products and millions of users are like that because they solve a need but the execution in these places are phenomenal. I think that it is because the people in these companies have great communication skills and communications processes and tools. Communication and culture that emphasizes a “can-do” attitude, willing to grow and evolve, encourages openness and doesn't allow ego in the decision making. We are looking at the “Yes and…” movement in the workplace.
“This is my design, that is actually code, you can use it”,
“Cool, adding logic and fixing some of the implementation. Thanks!”
The fact that we allow designer design and the output can be seen both as images, and components but also as code, allows - at least as we see it - as an effective communication process.