Fragments of Ricocheting Thoughts

TLDR: Don’t suffer in silence.

You know how we feel pain? Evolution selects for pain because it steers organisms away from certain kinds of harmful situations. When you try to lift something, and pain starts up in your back, it’s your body (and eons of evolution) telling you “maybe find a different way to do this before you hurt yourself.” Pain is the catalyst for change. Pain is useful!

Organizations don’t technically feel pain, but people in them certainly do. Whether it be endless overtime, dysfunctional meetings, ugly exchanges, missed deadlines or what-have-you, team members bears these pains. Prolonged exposure burn people out.

Unlike, say a finger that reflexively informs the nervous system of pain, people in an organization can choose to absorb the pain, or to let it propagate/fester. I want to convince you to not absorb the pain, at least not as a matter of course.

Why? Because if the organization doesn’t feel pain, it will not learn, and it will not protect itself. When you simply absorb the pain, you get in the way of potential change. To put it differently, you are blocking the flow of information necessary to make proper organizational decisions. Don’t be a painkiller, be a catalyst for change instead.

So should we just be squeaky wheels all the time? Isn’t there a time for fighting through the pain? Here’s my framework for evaluating when is the pain worth it.

Is it passing pain, or chronic pain?

Is it a calculated pain, or a random and/or unpredictable pain?

Time for a 2x2:

A passing, calculated pain is like the floor burn you get when you’re diving for a ball. E.g. a well planned spurt of overtime. It hurts, but its a short duration, and hopefully there’s clear pay off. This kind of pain is probably fine to absorb.

A passing but “random” pain is like a sort of flare-up in your back. An example here might be an unexpected bout of fire fighting. You might consider absorbing this kind of pain and “be a team player about it.” More often than not though, it points to overlooked problems in the organization. (E.g. why don’t we have better QA? Or preventive measures?)

The line between passing and chronic random pain is pretty blurry. As these kinds of flare-ups become more regular, it is more and more likely that a real problem needs to be diagnosed and addressed. Absorbing this kind of pain is like gorging painkillers to deal with regular flare-ups in your back. The pain points to some chronic misbehavior (e.g. you’re sitting too much, and your posture is terrible.) One day it will fuck you up. Don’t absorb/tolerate this kind of pain.

Chronic, calculated pain? Well, that’s just an abusive organization. Get out of there.

In an organization with people of mostly good intent, if you truly experience a chronic pain, it is usually because it cannot be properly fixed at your level. (Otherwise, as the recipient of the pain empowered to fix it, you would have fixed it already.) Passing the pain up the organizational hierarchy gives the org a chance to address it at the right level. It may not fix things, but hopefully focuses attention.

So. Don’t suffer in silence. Share the pain, it’s the adaptive thing to do for both you and the organization.

Corollary – Organizational Pain and the King Lear Problem

...or why you should celebrate the people bringing bad news.

This idea has a frustrating twist when looked at from the managerial point of view. I think of this as the King Lear problem, i.e. do you have a cultural habits/mechanisms setup to get reports of pain/dysfunction from your org quickly and accurately? The more powerful you are (i.e. the more you can shape the fate/reward of those who report to you) the more your reports are incentivized to “shape” the information they share with you.

In benign cases, they are doing the right thing to conserve your bandwidth, filtering for you only what you need to know.

In pathological cases (as alluded to in part one) they are hurting themselves and the org by absorbing brokenness in the org without telling you.

In malicious cases, they are actively misleading you for their own gain.

Without some mechanism of keeping your ears close to the ground and/or cultivating alternative information channels, a senior leader can lose touch with reality on the ground without realizing it. Note that the King Lear effect is the default case! It will happen to you if you do not actively work to break out of the bubble. 

I have no good comprehensive answer for this. However, at the very least it calls for not shooting the messenger, and for institutionalizing blameless post-mortem processes. If as a senior leader you get mad at and/or begrudge the bearers of bad news, soon you lose access these flows of information. If you punish cries for help and displays of pain, the org will learn to suffer in silence until it collapses.

A friend at work came to me and asked about how I thought about leadership. I had been running the Design Technology team at Noodle for a while, and had worked hard at the “care and feeding” of my team. I boiled it down into two things – leadership is creating an environment with clarity, and psychological safety.

Clarity – does the team know A. why we’re here (the mission) B. what we’re doing (the blueprint) and C. how we’ll do it (the prioritized task list)

Psychological safety – does the team feel safe and supported? does the team feel empowered to attempt complex things and learn from the process? does the team feel understood by their leader?

There’s a thousand different ways to make this concrete. I tend to think of these as stances/postures that I take in my day-to-day interactions with my team. To clarify my thinking, I’m going walk through few scenarios.

In a Project Kick-off

In a One-on-one

Design Critiques or Code Reviews

In On-boarding

In a Project Kick-off

The project kick-off is crucial moment, when anxiety and uncertain are high. There’s a temptation to jump right in and clarify the what and the how. I try to resist by recap-ing the why of a project to start. The why might include:

why this project advances the mission of the company/product

why we (or the leadership) chose this particular priority

why we didn’t choose some alternatives

Part of the focus on clarity is to remove friction that comes with doubt around the direction of a project. My goal is to get alignment, or at the very least “disagree and commit.” Momentum on a team gets built by having folks push in the same direction. Starting with why is at the core of that.

A second part of the focus on clarity is to figure out where the uncertainty is hiding. Large parts of the design/engineering process is discovery and synthesis. Reducing uncertainty is everyone’s job, and it starts with knowing where we stand, i.e. what are the known unknowns. (... and acknowledging there are unknown unknowns.)

It is not enough that the leader knows this. Part of the leader’s role is to help everyone on the team gain this perspective. Clarity feeds into psychological safety by making sure everyone is on the same page, and preparing the team to take on uncertainty with confidence. It is much easier to feel safe and prepared for challenges if you know (and everyone else knows) where the risks and tough tasks are.

In a One-on-one

I start every 1:1 with three questions:

Is anyone bothering you?

How are you feeling about your work?

What did you feel like you learned this week?

The first question, repeated week after week, can feel perfunctory. I insist on it, however, because I believe it sets a tone. I want the team to have a psychologically safe environment. I will not tolerate harassment or even the appearance of harassment. By creating a clear, proactive channel for raising issues, I hope to nip potential issues in the bud. While I have not uncovered any harassment issues, the question has surfaced issues in communication style between teammates which has been valuable to fix early.

The other questions are about a mix of psychological safety and clarity, depending on what’s top of mind for the person that week. The goal for such an ambiguous question is to leave room for the team member to steer the conversation. Where possible in these conversations I prioritize reinforcing the why’s (i.e. the big picture) of the projects the team is working on. The reason is that in our day-to-day there’s already sufficient time spent on the tactical how’s. The 1:1 serves as a forum away from the day-to-day where mission re-alignments happen, unhindered from the tactical weeds.

One note on “what did you feel like you learned this week?” – the way I tend to steer this question is to encouraging trying new things, and reflection on things tried. This goes back to the psychological safety theme – the question sets the tone that I care more about trying/learning than accomplishments/project status.

Design Critiques or Code Reviews

Design Critiques and Code Reviews can be psychologically fraught, especially for folks who are not used to them. Clarity in this context is difficult because work exists in the tension between:

time constraints

best practice

project priorities, and...

personal development 

Balancing between these requires judgement and context-sensitivity. In discussion of design/code I do my best to explain not just what I think, but how I arrived at my suggestions. The aspiration here to demonstrate my thought process, in the hopes of eventually delegating decision-making responsibilities to the team more.

The catch here is that the leader must be as transparent as they can about the context required to make good judgements. Did priorities just change? Tell the team. Do you want to use a particular challenge as a learning opportunity for someone? Tell them. Assigning a complex piece of work to a junior team member makes a lot more sense to the rest of the team if they know that A) the time constraints are loose and B) it is deliberately set up to help them grow.

Sub-bullet: Managing the Culture around Feedback

If design critiques or code reviews are public, extra care must be taken to make sure the language and the stances people take in their communication is constructive and sensitive. To create a psychologically safe environment, every team member must take care to clearly articulate their feedback without assigning blame. Why? See: “Blameless Post-mortem and a Just Culture” and I quote:

Having a “blameless” Post-Mortem process means that engineers whose actions have contributed to an accident can give a detailed account of:

what actions they took at what time,

what effects they observed,

expectations they had,

assumptions they had made,

and their understanding of timeline of events as they occurred.

…and that they can give this detailed account without fear of punishment or retribution.

Why shouldn’t they be punished or reprimanded? Because an engineer who thinks they’re going to be reprimanded are disincentivized to give the details necessary to get an understanding of the mechanism, pathology, and operation of the failure. This lack of understanding of how the accident occurred all but guarantees that it will repeat. If not with the original engineer, another one in the future.

This applies to design as well. Maintaining this culture is not just the responsibility of the leader, but also individual members of the team as well. My (potentially controversial) stance is that the responsibility of managing perception belongs to the speaker/writer/giver-of-feedback. The main pathway here is to be deliberate in highlighting good/bad instances of intra-team communication i.e. praise/nudge people towards styles of feedback that are constructive.

In On-boarding

I wrote a letter that I send to every new member of the team. In it, I cover three topics:

What is the opportunity ahead for this company?

How does the Design Technology fit into the larger organization?

How should we work together?

Here’s an excerpt:

In order for us to deliver on that goal, we must first work well with each other. There’s a saying in management science that goes, “Culture eats strategy for breakfast.” The idea is that a team’s culture (norms, habits, etc.) determines how they execute – a stated strategy without a corresponding culture is futile. With that said, there’s a couple habits I try to cultivate on our team:

1. Learning is the most important thing we can do long term: code will rot, designs will grow stale – but if we continuously learn, we will continue to create value for ourselves and our customers. 2. We try things, sometimes it even works: the only way to break new ground is to try new things. The price we pay for trying new things is that sometimes it doesn’t work. We are fortunate that we work in software – code can always be changed. Thus, my general stance on trying new things is, yes, let’s do it. 3. Take your time: Learning things take time. Trying new things take time. Getting rested and rejuvenated takes time. So please take your time as you approach your work. Generally I want your best work, not your quickest work. Don’t worry too much about speed – if you’re moving too slowly I’ll let you know.

This part of the letter is entirely about setting up a psychologically safe environment. I’ve omitted the parts of the letter about the goals and the strategy for the company – in it, I try to make clear what it is we are trying to accomplish.

The first couple weeks are all about this kind of “laying the foundation” work. The themes of this letter is reinforced through conversations and meetings they go to, emails they receive, and conversations in chat, etc.

Wrapping Up

Here are the 10 behaviors of Google's best managers, along with some practical tips on how to develop these behaviors. (You can find more detailed advice on developing your management skills in my new book, EQ Applied: The Real-World Guide to Emotional Intelligence.)

1. Is a good coach

A good coach avoids the trap of solving every problem for their team as soon as it arises.

Rather they use these problems as teaching moments. They guide and share insights at the right time, letting their team gain valuable experience along the way.

2. Empowers team and does not micromanage

Everybody hates a micromanager. In contrast, a good team lead gives their people enough freedom--to explore new ideas, to experiment, and to develop (and adapt) their own working style.

In addition, great managers make sure their people have the tools and flexibility they need to do their jobs.

3. Creates an inclusive team environment, showing concern for success and well-being

Great managers make it a priority to build trust in their teams.

As Google puts it:

In a team with high psychological safety, teammates feel safe to take risks around their team members. They feel confident that no one on the team will embarrass or punish anyone else for admitting a mistake, asking a question, or offering a new idea.

(More on how to build this type of environment here.)

4. Is productive and results-oriented

The best managers make those around them better.

They realize what their teams are capable of, and they use emotional intelligence to motivate their people and help them realize their potential.

5. Is a good communicator--listens and shares information

Great managers are great listeners--this enables understanding. They also share what they can, realizing transparency is beneficial for the team as a whole.

They share sincere and specific praise, early and often. But they also don't hold back from giving necessary (negative) feedback--making sure to frame it in a way that is constructive and easy to learn from.

6. Supports career development and discusses performance

Great managers are invested in their people. They provide career path options, realizing not everyone wants to follow the same road.

They also don't hold their people back for personal gain. Rather, they support team members and help them to reach their goals.

7. Has a clear vision/strategy for the team

Great managers know where they're going, but they make sure the whole team knows, too--rather than keeping them in the dark.

They are also careful to communicate "scope," realistic expectations as to what specific actions are needed to execute a strategy, and each team member's role in delivering.

8. Has key technical skills to help advise the team

Great bosses understand a job well and are skilled at the work they oversee.

If an effective manager is brought into a new department, they take time in the beginning to familiarize themselves with their people's everyday work and challenges. This earns them the respect of their team.

9. Collaborates across [the company]

Some managers create silos, running their teams with an "us versus them" mentality, competing against other teams within the company.

Great managers have the ability to see the big picture, and work for the good of a company as a whole.

10. Is a strong decision maker

Great managers take the lead. They make the tough decisions, and make sure everyone understands the reasons behind those decisions.

Then, they commit to following through.

TL;DR: It’s hard to learn from circumstances. It might be easier to learn from people. I’m joining a company with two experienced founders, because I want to see how they work.

So I just switched jobs again. The pre-mortem didn’t capture this– that is to say, I failed to foresee how much I would hate the 1h20m commute down to Mountain View, and how little energy it would leave me to work side projects.

I also failed to foresee how difficult it is to “learn-on-the-job.” At H2O I built from the ground up a team of seven – designers, UI engineers, and even had the legendary statistician Leland Wilkinsen on my team. I was supposed to lead building a killer visualization product. I couldn’t do it, I didn’t know how to organize the team and protect them from noise and distraction. I didn’t know how to keep them focused. Hell I didn’t know how to stay focused myself in the storm of competing priorities.

What I realized was that, I was hired on the strength of a side project, where I only had to manage myself. I had one other person to collaborate with, but I didn’t have to deal with prioritizing and saying no to a team, or a boss. When I decided I had to leave, one of the things I knew I wanted out of my next gig is a role model in organization and management. I want to see how a well run team looks like.

This week I started at Noodle.ai, which calls itself an Enterprise AI company. The founders are experienced consulting folks, having been partners at Deloitte and Infosys. The place is run like a consulting shop, and my role as a principal designer will, at least initially, be focused on delivering data visualizations and dashboards as the front-end to our data scientists’ work. It’s individual contributor work that I am well equipped to do.

What I am really looking forward to though is seeing how these people work. One week in I am already keenly aware of how different the culture is, particularly the focus on documentation and communication. Stephanie said this is exactly how consultants are trained to work. Before any piece of work begins, they check:

are we internally aligned on this?

are we aligned with the client on this?

when can this be delivered?

who is responsible for the success this piece?

The focus on converging and getting to specifics is ... refreshing.

Last two times I started a new gig, I wrote pre-mortems. I don’t know that I will write one for Noodle. I wrote those as if I were about to invest in those companies, and clearly I was investing time. In retrospect I think it set the wrong tone for how I approached my role. Thinking as an investor focused me on the valuation and the upside. This time, I think want to focus on what I want to get out of the experience.

...and there’s really only one thing I want to learn. Steve Pratt and Raj Joshi, the founders, have worked together for more than a decade, and built two very successful consulting practices together. They clearly have a great rapport, and it seems that they are able to extend it to the teams they build. They speak with confidence and humility, and are comfortable with uncertainty. The team they’ve built reflects that as well.

What we are selling is not the software product — the set of all the features, in their specific implementation — because there are just not many buyers for this software product. (People buy “software” to address a need they already know they have or perform some specific task they need to perform, whether that is tracking sales contacts or editing video.)

However, if we are selling “a reduction in the cost of communication” or “zero effort knowledge management” or “making better decisions, faster” or “all your team communication, instantly searchable, available wherever you go” or “75% less email” or some other valuable result of adopting Slack, we will find many more buyers.

That’s why what we’re selling is organizational transformation. The software just happens to be the part we’re able to build & ship (and the means for us to get our cut).

Sell the benefit. Sell the job-to-be-done. Sell the change-you-want-to-see.

I love coming back to this post because it helps reorient how I think about product design. People don’t care about what the features are. People care about how their lives will change.

At H2O – this should mean “smooth, operationalized data science”, “get models to production faster.” It should mean reducing the barrier between “I wonder if ...” to “hey, come look at this graph” to “the model is serving live traffic” to “here’s how the model performed last week.” 

With H2O, I should feel excited that I can jump into the data, be empowered to get something out quickly, and have more conversations about the data (and less conversations about the infrastructure.)

TL;DR: Why I am joining H2O. This is long and rambling, and mostly written for myself so I can review it in a year or two.

Today I start a new role at H2O, a machine learning applications company with a open source platform for data analysis. Three years ago I wrote a blogpost about why I chose to work at Sift Science. This blogpost is similar: this is my hypothesis for why H2O is an interesting opportunity. I thought about it from the following lens:

Company Mission

Team

Learning Opportunity

Unique Contribution

I will focus mostly on my rationale, but I will also add a few pre-mortem notes.

Company Mission

As I understand it, H2O is a “tools” company. They focus on making really great machine learning software, which data scientists and engineers can use in applications they are building. The way I explained the difference between H2O and Sift Science was this: if Sift Science created cars (i.e. a full featured product designed to solve a specific problem for customers.) then H2O makes engines.

There are many companies with this business model – make tools available for free, charge for services and consulting. What makes H2O interesting? To me it is the company’s thesis about the future of data science and data analysis.

Today, in order to do large scale machine learning and data analysis, you must first understand statistics and modeling. On top of that, you must also understand distributed systems engineering. Why? When a data set is sufficiently large, it is infeasible to perform all the computation on a single computer. It’s simply too slow. The solution is to split up the task and have multiple machine perform the task at the same time i.e. distributed systems. This is why good machine learning engineers are so hard to find. A suitable candidate needs to understand both distributed computing and machine learning to do their job well.

What if that’s not necessary? Machine learning and data analysis does not intrinsically require understanding distributed systems. If we can remove the distributed systems engineering requirement, then large scale data analysis will become accessible to a lot more people. There are an order of magnitude more data scientists and statisticians out there than there are machine learning engineers. These are the people who will be enabled by H2O’s software to run analysis they had never been able to before.

Frankly, I can’t wait to see what creativity this will unleash.

Pre-mortem: I can see a few ways things might go wrong,

Abstracting away distributed systems proves impossible, or the abstractions will prove too leaky. In this case, H2O’s software will still be valuable, but will not be paradigm-changing. The status quo of big data analysis requiring engineering+statistics “unicorns” remain.

Abstracting away distributed systems proves too easy, and competitors are able to quickly replicate this ability. In this case, H2O will need a different competitive advantage.

The value of data analysis pipelines resides not in better algorithms, but in better feature extraction, and therefore competing to be the best ML package is futile. Frankly, this is the one that actually worries me most. ML packages can compete on speed and accuracy, but both of those traits have diminishing returns. As I witnessed at Sift Science, real world prediction gains comes just as often from improvement in feature extraction as from algorithm improvements.

Team

My first connection with H2O came through Erin Ledell. This was after R2D3 came out, so naturally talked a bunch about how to communicate machine learning insights to a broader audience. Through our conversation Erin’s passion for good open source software clearly shone through. She really wanted good tools to be accessible by as many people as possible. As I met more folks from the engineering team, it’s evident that this passion is shared by many at the company. The theme underlying every interview question was, “How can we make this software better? How can you help us make this better?”

In addition to a passionate and sharp R&D org, I was also intrigued by my conversations with Kanishk. He is the VP of Customer Applications, and we had an interesting and wide-ranging chat about how H2O’s software might get used. The most interesting insight from Kanishk was how algorithm speed opens up new frontiers. I was reminded of the maxim about how the abundance of a resource leads to more imaginative uses of it, and my mind danced with ideas about using machine learning for art.

It was clear that H2O has put together a really impressive team.

Pre-mortem:

I may get silo-ed as a data-visualization designer in a engineer centric organization. While I am glad that H2O reached out specifically because I demonstrated that I can communicate machine learning concepts with R2D3, that doesn’t mean the whole organization understands the value of product design. I guess I was worried about this when I joined Sift too, but that worked out fine.

I will have difficulty nurturing design culture there, since the culture of H2O is largely already set. I joined Sift Science when it was eleven people. It was much easier to have a personal relationship with everyone who was there, simply because I was there while the organization grew. I made it a point to explain the role of design to everyone when they started. My influence will be much more diluted at H2O, which already has 50 members.

Everyone at H2O seemed super focused. One of the things I really enjoyed about Sift Science’s culture was its emphasis on work life balance. I didn’t really probe the culture at H2O as much as I should have. Other than a really smart and focused team, I am not sure what I am getting into culture-wise.

Learning Opportunity

I have an draft of a blogpost called “What comes after the Triple Threat Designer” where I contemplated what kind of skills I should develop next. My personal career thesis was to be fluent in design, technology, plus product strategy, and to create a unique blend of capabilities from those disciplines. At Sift Science I was able to prove out that this blend was in fact effective, especially in these two situations:

Making design decision while taking all three perspectives into account.

Vetting and refining ideas from various parts of the company into feasible projects.

Translating ideas across functional boundaries effectively.

At H2O, I want to add data science to this mix. Thanks to working at Sift, I have developed a particular affinity for data products. I learned a lot about the in’s and out’s of machine learning, and saw how machine learning systems gets deployed in real world applications. At the end of the day though, I was designing for fraud managers and analysts. In reviewing my various hackathon projects at Sift, I found that half of my projects were tools I built for Sift’s ML team. These were often the hackathon projects I enjoyed the most. At H2O, designing tools for data scientists will be one of my primary roles. Given the range of customers that H2O has, I have the opportunity to see a broad range of data science teams and processes. My goal is to use this opportunity to develop a unique perspective for designing data products, and become a world class data product designer.

Pre-mortem:

If I mess up this opportunity, it will because I get too caught up into building “cool” things, and do not spend enough time actually talking to customer and clients. I know I have the tendency to obsessively polish a project, which worked well for R2D3, but will serve me poorly if it takes away from learning from actual users.

Unique Contribution

There a lot of product designers out there. Many of them have front-end engineering chops to bring their designs to life. The pool starts to narrow if you want the product designer to have a data-visualization focus. Of these, very few are also familiar with machine learning and data science. H2O is looking for exactly this, and I am fortunate that my skill set and interests are such a great fit. H2O aims to be the go-to platform for open source machine learning. It has already developed a great set of tools algorithms, and a track record for solving real business problems with them. To broaden adoption, it needs to improve the usability of this tools, and help people understand their results through data visualizations. These are things I have done before, so I am confident that I have the right set skills to push H2O’s product to the next level.

Pre-mortem:

This data+design+product synergy may be overstated if the needs of the company turns out to be more simple. e.g. if lots of individual data visualizations needs to be produced independently of each other, and customers don’t find it important that they are cohesive.

This synergy is not scalable. This I already know is true. As companies get bigger, roles ought to become more specialized. As H2O brings in more specialists, folks with hybrid skill sets either move into management, or find their opportunities diminish. A company at H2O’s size should be starting to hire more specialists. I am not sure how this will play out.

The Point of a Pre-Mortem

Folks often complain to me about the morbidity of ‘pre-mortems’ – but to me that’s exactly the point. I am really excited about H2O, but I want to make sure I remind myself that failure is always a possibility. I don’t think I am a pessimist. I know most of these ‘pre-mortems’ likely will not come true, but it is important to articulate it before hand, so it can be a point of reference for review later.

As I was writing this post, I went and reviewed my pre-mortems for joining Sift Science. Essentially all of them were unfounded worries. I had a very happy two and a half years at Sift. The only one that was remotely accurate was the one about “wanting more variety.” It took 28 months before I even starting thinking, “oh maybe there are other interesting problems out there. I should go out and look.”

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.