Deaf.

Not too greedy at all, and you certainly don't have to decide! But, I've found that the more variables there are, the more difficult the decision becomes for me. Without a hierarchy of priorities, what should I do if a mind-numbing project comes along that pays for my whole year? It's not fulfilling, but I can make a great living. Is that worth it? Or what if my dream project comes along, but I have to do it for free? Is that worth it?

All I mean to say is that clear priorities have aided me tremendously in decision-making.

Thanks for the great opportunity, Matthew and Designer News!

Brand guidelines belong within a design system.

I'm actually changing my tune on this. As my buddy Joshua Blankenship points out, "brand guidelines equate to 'how our brand represents itself everywhere' not just in the context of software." I agree with that. And, as I think about the design system work we've done at SuperFriendly, brand is usually managed by a separate design than the design system team and tends to have more organizational importance since it governs more than just software. That seems appropriate to me.

So, perhaps a clarification: the pieces of brand guidelines that apply to a design system should be found within or adjacent to a design system. Combined with software principles, that combination can be considered the design system guidelines.

Josh! I'll talk to you any day.

It mentorship part of your weekly routine?

Currently, it's not. I stopped my apprenticeship program at the beginning of this year because I felt like I don't have much more to give there, or at least I'm not sure what it would be right now.

But, I saw a tweet just yesterday that said, "Mentorship is not a role or responsibility, but rather an act that anyone can fulfill for you." While I've given up a mentor role, I'm actively looking for ways that I can practice acts of mentorship. Perhaps this AMA is one!

Jason! Great to hear from you!

Of the in-house teams you've worked with so far, I'd love to hear which design systems were the most challenging or interesting and why.

Oh man, that's like asking me which one of my kids is my favorite. The answer is that they're equivalently challenging and interesting (both design system teams and my kids).

Next time we eat burgers together, I'll tell you the real answer to which team—and kid—is my favorite ;)

Also, as a fellow parent of 2 young daughters, are your kids talking about trick-or-treating, costumes, and favorite candies yet?

Just this morning, my wife asked them if we should decorate generally for fall or specifically for Halloween. The answer was equivocally the latter. It's in the air!

Congrats on getting ready to take the leap, Rodrigo!

Any tips or things I should be aware of?

Lots! But I'll stick to one for now: before you do it, decide why you're doing it. Is it to make more money? Is it to spend more time on your hobbies and interests? Is it to do more fulfilling work? If you don't know, it'll make freelancing difficult. But if you can decide in advance, it'll make the decision-making part much easier.

If you're trying to make more money, don't be picky about gigs and take as much as you can and/or the ones that pay the most (as long as they're not crossing any moral, ethical, and legal lines, of course). You'll make a fortune.

If you're trying to do more fulfilling work, don't say yes to projects that aren't what you want to do. If fulfilling work is the most important thing to you, doing projects that your heart's not in will be more painful than, say, getting a bank loan or borrowing money from friends/family to pay the bills.

It's ok if your decision changes year-to-year, or month-to-month, or heck, day-to-day. But you decide. Don't let it be decided for you. You're in control of your own destiny.

Go get 'em, Rodrigo!

Yes, I read a lot! Here's a mix of my current and all-time favorites, both tech-related and non-tech-related, in no particular order:

• Leaders Eat Last, by Simon Sinek
• We Are Legion, by Dennis E. Taylor
• The House of X and Powers of X series, by Jonathan Hickman
• Shoe Dog, by Phil Knight
• The Culture Code, by Daniel Coyle
• Profit First, by Michael Michalowicz
• How to Talk So Kids Will Listen & Listen So Kids Will Talk, by Adele Faber and Elaine Mazlish
• The Count of Monte Cristo, by Alexandre Dumas

Looking forward to hanging out in NY, Michael!

I've inhaled all the writing about how to run successful remote projects from in-house teams (Doist, InVision, Buffer, etc), but I've come across far less with agencies. How is it different, if at all?

If the teams are parallel, I haven't seen a lot of difference between distributed in-house teams and distributed agency teams. However, I do see a lot more agency teams that are primarily co-located with one or two remote team members. My friend Mandy Brown wrote a wonderful article called Making Remote Teams Work, and one of my favorite lessons from there is to act "remote by default." If you have one or two remote team members, the whole team should act like they're working remotely, even if they're co-located. Otherwise, it's easy for the remote team members to be accidentally left out.

I imagine the Hollywood Model adds another layer of complexity, as well.

I haven't felt much difference here, but I'm sure some of that is confirmation bias, because it's what I do! The Hollywood Model—another way of saying that it's a team assembled ad-hoc for a particular project, the same way Hollywood makes a film—is really just a tax status. It means people have independent affiliations and choose to collaborate temporarily. If you have an invested team—whether or not they're full-time employees—that's the key ingredient for success.

Back when you did project work at SuperFriendly, how did you get involved with most of these projects? What were the outputs that you were personally responsible for? Did you still mainly spend your time hands-off, focusing on strategy and directing the team?

I tried many different configurations for myself over the years. I've done projects where I… - Designed and coded the whole thing - Designed comps and had engineers on the team - Directed other designers and engineers - Acted as principal or account person while someone else directed other designers and engineers

One thing I've learned is that, like movies, every project needs a director and a producer. When I first started SuperFriendly, I was the de facto director on every project. As I've been hiring more directors on projects that aren't me, the work has gotten much better.

What are the most valuable tools or processes for running projects and developing products that you've found works for SuperFriendly?

I'm a big fan of this George Patton quote: "Don't tell people how to do things, tell them what to do and let them surprise you with their results." I don't dictate any tools or processes to teams, but there are a few concepts and principles I try to communicate:

• Follow your instinct. If you hire good people, they have good instincts. Let them do what they'd do anyway. Otherwise, why hire them?
• Take risks. We have smart clients. They already know how to do the safe, easy stuff. Our job is to help them do what they can't do otherwise.
• Learn something, and teach something. When I was directing projects, I tried to make it my job to create a safe place for people to try something new. I want every team member to do that for each other.

I've only started to articulate these, but there are 4 working SuperFriendly principles:

1. Work together.
2. Play together.
3. Eat together.
4. Win together.

That's a tough scenario, Dexter! I'm taking your questions as two separate problems to solve:

1. How can you properly maintain a design system with just designers and no engineers?
2. How can you properly maintain a design system with a distributed team of engineers?

Regarding part 1, I'm a firm believer that design systems are software, so a design system team that consists of just designers with no engineers is missing a crucial part. My first suggestion would be to see if you could have at least engineer dedicated to the design system to round out the team.

But! I know it's often a reality that it's difficult or implausible. So, what do you do if all you have is designers?

One thing you could do is increase the designers' fluency with code. I'm not saying you need to become engineers. But, a little bit of knowledge in a few areas goes a long way with a design system. The areas I typically suggest to teams are:

1. CSS, specifically colors and font-sizes
2. The Web Inspector
3. JSON

If you're interested in why, I did a talk called "Should designers…?" that goes into more detail.

Regarding part 2, different time zones complicate communicating but spreading it apart. To fix that, you need tools and processes that can bring it together again. With different time zones, real-time communication is more difficult, so people resort to asynchronous methods like documentation and write-ups. Unfortunately, this is also where things fall through the cracks.

One method I've found to be really useful is sending videos back and forth. If you can't talk to each other in real-time, simulate it by having your video "talk" to the other person's video. I've been really surprised as to how many of the nuances of video make it feel like talking to the other person. Of course, it's not a replacement for an actual conversation, but it's a good runner-up.