TL;DR: Building a design culture in an engineering centric organizations requires designers to first seek to understand, then to be understood.

1. Good design requires non-designers.

Designers can put together mocks and prototypes, sketches and wireframes. That doesn’t really count as shipping – not without engineers writing code, product managers writing specs, marketers writing press releases, sale folks showing demos, support team educating customers. A well designed product is delivered by a whole team, through a collaboratively built pipeline. If folks along the pipeline doesn’t understand the value of design, some part of the customer experience will fall through the cracks.

2. Learn your counterpart’s Language and Motivations

Engineers want clean and maintainable codebases. Sales folks want a easy to explain and attractive product. Marketers want a coherent and relatable product story. Support teams want well documented error states and messages. Everyone wants to serve customers, and all of them measures their success in their own lens. Design isn’t necessarily top of mind, until and unless you can frame how design helps your teammates succeed in a way that they can see and understand.

Getting your teammate to see the impact of design is therefore itself a design problem.

3. Give non-designers a framework for thinking about design

… or at least a framework for interacting with you. Start with the basics of empathy, e.g. 

• people have short attention spans (therefore products must earn their attention)
• people have pre-existing mental models for understanding their problems (therefore frame ideas in customers’ existing mental models where possible)

And the basics of the design process, e.g.

• It is iterative and intuitive (so trust the process and keep at it)
  
• practice beats theory (so prototype it and show it to customers, then listen)

Help the team understand that design is not colored pencils and magic, but a deliberate practice of making products fit how customers understand/solve their problem.

4. Build a network of design-minded non-designers

Give your framework to everyone who would listen. Not everyone will, but with just a few people on each team with this mindset, it will become a lot easier to deliver good design. You won’t have to run around advocating for design yourself, you will have nurtured advocates.

Keep that network going. Check in with your new, distribute (across functions) design team. Your sales designer will pass along customer feedback. Your marketing designer will come up with new product framings. Your support designer will find and patch (!!) edge cases you never thought of. Your engineering designer will tell you about new possibilities that the new stack is about to unlock.

5. Start with conversations

All of that sounds like a lot, but it doesn’t need to be. It just needs to start with conversations. My go-to opener is, “How are things in Marketing/Eng/Sales/whatever-land?” then followed up with attentive, inquisitive listening. People love to be heard, and people love to help. Both of those things happen more often when conversations are happening, and when people feel that a relationship has been established.

End Notes: Tactics for Building Design Culture

• Jump in on other teams’ needs at hackathons. Every hack I’ve done at Sift were for one team or another. It helps build credibility, and shows that you actually care about your counterparts’ success. It’s also a great way to demonstrate the value of design applied to their problems.
  
• Run regular, open-to-all design critiques. An open design critique is one of the best way to demonstrate you value feedback. In the beginning it is necessary to establish ground rules about what kind of feedback is sought, and how feedback should be structured. It also requires more preparation to frame presentations for non-designers. Once that practice is established however, it models a pattern that spreads outside of just these critiques.