View the original post
What are designers doing, and why are they getting no-where?
This might be worldwide truth that the collaboration bit between engineering and design isn’t a straightforward business. Often product managers become the glue between both the teams and pass messages between them. Although team leads are keen to organize workshops between design and engineering, practical workshop actualization is challenging. When all efforts fail, companies try to break down teams into squads and force different disciplines to sit next to each other in “pods” and talk more while sharing the same desk. Unfortunately, none of these team-building tricks work. They can end up creating more silos and less empathy.
Luckily the real magic happens when individual contributors (ICs) start putting more thought into their actions. Here are the four steps you can take to resolve engineering and design team differences and drive empathy for both ends.
Understand Mental Models
The black hole between design and engineering is usually because both teams are ignorant about the differences between each other’s mental models. This leads to a struggle to communicate with each other. It is not easy to break free of one’s mental model and adopt someone else’s mental model. Engineers try to fit creative design methodologies into their logical mental models. And that’s where things start to break apart. The only way the two mental models can fit into each other is by slowly instilling the Lego blocks of design in the engineering team and vice versa. Only when the foundation Lego layer is strong can both the team start building more nuanced concepts on top. The Foundation layer promotes more learning. And learning promotes more involvement and collaboration.
Work with the people you have. Scaling to a bigger, more functional team will only happen when teams work together harmoniously.
To enable a smooth flow of knowledge between engineering and design mental models, you have to,
- Create systems that support both domains. Create design systems that include style guides, a component library and support each component with some front-end/back-end logic. Like for example, when creating customer animation, support your animations with bezier curves and timing markups.
- Create processes that involve a bit of both engineering and design. Every team will need a champion designer and developer to lead other team members. Building mental models take time. But they can only be built bit by bit.
- Interchange and collaborate using different tools. Learn a bit of HTML, CSS, JS, and ‘try’ coding some of the components you designed. This will cultivate empathy towards developers.
Success Metric: Overtime, you will see both teams speaking a common language. The language will be a mix of concepts from both domains.
Problems Spec Sheet
If you are riddled with collaboration-related problems frequently, then it is time you start journaling some of the common reasons why you are in a spot where you shouldn’t be. Journal these,
- How can you make your team members valued by appreciating their contributions?
- How many times has there been story points spillover? Is it happening frequently? Why is it happening?
- How much is the tech debt? How long will it take to get the debt prioritized on the roadmap?
- Can the code and design be made more reusable?
- Pain points — Where are the teams struggling?
- Identify the process and people-related bottlenecks.
- Identify the silent signs of struggle.
- Does every meeting have an agenda? How many ad-hoc meetings does the team get pulled into? How can only contributing members be a part of meetings?
- How can you promote ownership, accountability of code and design?
- What is the process of code reviews? How frequently is it done? Is there a HiPPO effect during code review?
- Is my team Agile from the outside and Waterfall from the inside?
- How soon do design and engineering collaborate? Do designers feel comfortable letting engineers roam around design files in the WIP stage? Is there any design QA happening before every release?
- Are the designs getting built on vague requirements? Are the design decisions supported by data or user insights?
- What is the current level of UX maturity, and how can you improve it?
What NOT to do
- Don’t work late nights to cover for the increase in scope. People will expect it is your job to spoon-feed everything and keep scoping tidy.
- Don’t work weekends creating and deleting redundant tickets. You will only make a facade of a perfect sprint on JIRA, and extra work will keep falling to you every time there is an issue.
- Don’t document your working methods because no one in their right mind will read them. Every time I dropped a document bomb onto my teams, it led to me feeling proud of myself and only one-two people giving it a read.
- Don’t speak loud and assume everyone will hear you. Repeating the same message, again and again, will create deafness for your ideas.
Don’t do work in a silo that fixes broken communication lines in your teams. They will continue to be in the dark if you let them be. Become vocal about the problems, discuss possible solutions and enable teams to help you fix broken items.
Don’t burn the midnight oil for the wrong reasons.
Building a collaborative and tight-knit culture takes time. Taking a more in-depth look at your team's inner dynamics will uncover patterns that we might have ignored before. To untangle these patterns, we don’t have to twist hard and solve them in a straight-jacketed way. Instead, try to treat unique problems with unique solutions. Flexibility, collaboration, and frequent knowledge transfer will follow.
Give me a shout!
Thank you for reading this far! 😁 Let me know if you have any questions or comments on my design — or — If you’d like to have a chat about anything design-related, I’d love to hear from you!
Before you go…
Designers are still doing a terrible job working with the developers was originally published in Prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.