Skip to content

Monograph's Design DNA: Q&A with Moe Amaya

Designer Fund
14 min read

Moe Amaya is the co-founder of Monograph, a data-driven platform that helps architects and design professionals manage their back office. Since wrapping up his studies in design computation at MIT, he’s continued to straddle the worlds of design and engineering—from working at Figma and launching a design and software consultancy to shipping an impressive collection of side projects.

Now at Monograph, Moe is putting all his learnings into practice in leading both engineering and creative direction at the 50-person company. He recently joined the Designer Fund Collective community for an AMA (Ask Me Anything), looking back on his path as a designer-founder and sharing a few of the early-stage hiring tactics that remain in use today, advice on bridging the trust gap between design and engineering teams, and the impact of his personal brand on building a startup.

Moe Amaya

On Founding a Startup

Q: Tell us about the story of your journey with your co-founders. What was the lightbulb moment that made you realize it was time to move from running an agency to starting Monograph?

I consider myself quite lucky in how I was able to meet my co-founders. Alex Dixon was my closest friend from architecture grad school and we started an eponymous agency together, Dixon and Moe. We did our first internship together in 2011 in Shanghai—living together in company housing, partying along the Bund, and designing some wild buildings. When we returned to school the following semester, we were both interested in expanding beyond architecture and built professors' websites, developed crypto projects (which clearly went nowhere), and started the MIT Arch Happy Hour.

We moved out to the Bay Area purely coincidentally, because Alex's long-time girlfriend landed a job in San Francisco (which is not a hotbed for architecture). We met our now CEO and co-founder Robert Yuen through a close friend from school, and after meeting up with him every single week for a year, we decided that we should just work together and formed an equal partnership in the business.

Monograph was never intended to be a venture-backed business. In fact, we were pretty adamantly anti-VC when we started out. Very early on, we sponsored the IndieHackers podcast and were happily running a healthy, profitable consulting business and building multiple SaaS products on the side.

The market completely shook us out of our comfort zone. After a year of bootstrapping, Monograph had gotten up to 30 customers. One Sunday morning (our primary support day), we received an effusive email from a customer thanking us for finally building a tool that catered to architects. He went on to describe how it felt like we were developing software right in his office, understanding all the nuances of what it takes to run an architecture firm. But his email concluded with over one hundred line item requests for problems we could still be solving! This was the lightbulb moment that led us to give up the cushy agency life and go all in on Monograph.

At that moment, I realized: this is why people take on venture funding. The scope of the problem was huge, and if we continued at that same pace, we'd be decades in and barely making a dent. We were lucky enough to raise in a few months and saw bittersweet and unexpectedly exponential growth during the pandemic that took us from 30 to 230 customers in a year.

Office
Monograph's founders, from left to right: Alex Dixon, Robert Yuen, Moe Amaya

Q: It’s been nearly three years since raising your seed round. What have been the biggest surprises for you in building Monograph? What advice would you give yourself if you could go back in time to 2019?

  • Learn business communication: By far the biggest lesson is that at a certain stage, businesses are forced to use new vocabulary and terminology that I was—at the time—both unfamiliar with and mildly uncomfortable presenting about at a board level. I had been consuming startup content for a couple of years so I understood the basic financial terminology, but the primary mechanism through which we communicate design, product, and engineering decisions now is spreadsheets and numbers.
  • Prepare for the drama of fundraising: Fundraising is already such an intense, time-constrained moment in a startup's life, but the stress compounds with competitive behaviors...it's wild. I've talked to founders who've seen some crazy things, and I personally don't know how I would handle it. My co-founder Robert takes the brunt of the stress and I along with my third co-founder serve as support.
  • Decisions aren't as permanent as they feel: One constraint I experienced as a designer is that I wanted every bar to be set pretty high. Looking back, many decisions weren’t as critical as I’d previously thought. Things like that one animation, that initial color scheme, or the component spec, were overly thought-through for the level of impact they actually made.

On Collaboration

Q: Any advice on getting alignment between design, engineering, and product teams?

I'll admit I'm still actively learning this, but I'll share what's worked thus far at companies of different sizes:

  • Monograph (startup): Be deliberate and thoughtful about developing a strategy, then repeat, repeat, repeat until everyone is aligned on the strategy. We live by the idea that it's not prioritization until it's painful, and saying no—while hard—is a critical alignment mechanism.
  • Figma (medium org): We had a great response to feedback windows where everyone could be involved. The Head of Design and Creative Director were always deeply involved in projects, but we also brought in the CMO, VP of Sales, Customer Success, and Design Advocates to all contribute feedback within a two-week period. We'd remind folks when they had one week left and then one day left to submit feedback. Everyone had an opportunity to contribute.
  • LendingTree (public company): For a larger company, an alignment tactic that worked well across a 300-person EPD org was the use of fully coded prototypes. We iterated for months and tested with customers before getting buy-in from the leadership team and eventually EPD. Because we weren't building production apps, we focused a ton of energy on aspiration animations, transitions, and new UI techniques that inspired the EPD org.

Q:You led a 25-person engineering org, which is a feat in and of itself, but even more so with you being a designer. How did you gain the trust of engineers and bridge the gap between design and engineering?

  • Lead with empathy: I had to immerse myself deeply into engineering, and let go of my "designer" label in many ways. While I learned to hack on frontend through side projects, I had to learn to build a basic app using our technology stack, Rails and React. This learning translated to being able to directly ship production code along with the team for the first couple of years of starting Monograph.

    I also started following more engineers on Twitter, listening to engineering podcasts, and getting mentorship from VPs and CTOs in companies a few stages ahead of us. Finally, I helped develop and stayed involved in our engineering process: diagramming, building workflows, and code reviews—things a person with a design skill set can often do better than an engineering one.

  • Hire product-minded engineers: Because I was in charge of sourcing, vetting, and making offers to the engineers, I over-indexed on folks who naturally gravitated toward product. Our earliest frontend hire and now Head of Engineering, Dan Knisley, started his career as a PM and UX designer, so he's continued to use the same hiring philosophy.
  • Emphasize systems: I was an early fan of design systems and worked with our teams to think through our early primitives for both frontend components and backend services. Because of the nature of shipping quickly in an early stage startup, we were able to bridge the trust gap by working together on early collaborative projects where design and engineering played equally pivotal roles. To this day, I do think that not separating the thinking between design and engineering is what makes Monograph so successful as a product in our market.
To this day, I think that not separating the thinking between design and engineering is what makes Monograph so successful as a product in our market. Moe Amaya

Q: How do you reduce the time it takes to go from idea to implementation when working with engineers, especially when you have limited design capacity?

Reverse the direction of information. How does the engineer you’re working with prefer to receive information? Another way to say this is: how does the person you're working with prefer to learn?

Each engineer has their own learning style, so detailed specs might not be the best form of communication for every person. Instead, they might prefer asynchronous Loom videos to walk through the spec, 15-minute daily syncs, prototypes in Figma, written specs with stories, or examples of apps you could point them to. Personally, I appreciate specific examples and struggle to learn when I’m given theoretical approaches or documentation.

Q: What are your tips on managing a remote team in different time zones?

It’s a work in progress, but we subscribe to a fairly asynchronous culture at Monograph. We have a four-day workweek (with Wednesdays off), so synchronous meetings happen on Mondays and Thursdays. On Tuesdays and Fridays, we discuss our progress on specific projects through asynchronous catch-ups in Slack. This format works especially well for time zone differences, as folks in Korea and Spain collaborate async and sync with the rest of the team at planned intervals.

On Hiring and Scaling Teams

Q: What was your approach to scaling the design practice at Monograph? Any key learnings about hiring and building your team?

We've been incredibly efficient with design at Monograph, which is counterintuitive given that we have two designer co-founders. We've only ever had one full-time product and one full-time brand designer on staff, even as we've grown to 50 employees. That's likely the result of a few compounding early bets on design including:

  • Giving full ownership to designers: We asked ourselves: If I worked at Monograph as a designer, what does my ideal role look like?

    • Our first designer Martin Rariga focused very heavily on design systems and worked with our frontend engineering team to get it into production.
    • Our current lead designer Lisa Zangerl, uses our design system to detail out features and has not had to modify much of our system to ship products to our customers. She works across our two feature engineering teams along with the PMs.
  • Hiring product-minded engineers: Our Head of Engineering, Dan Knisley, was a former PM and UX designer, so we really emphasize having engineers work out problems directly in Figma. This lessens the production strain on design and allows our designers to focus on the highest-impact problems.
  • Inserting contractors at key moments: Since we operated as freelance contractors for five years before starting Monograph, we often hire folks for short-to-medium term projects to supplement our team. We have a very talented UI engineer who worked alongside Lisa in Figma, Storybook, and our production app, to upgrade all the components across our app.
  • Critique as a company tool: Nearly 30% of our company has a background in design or architecture, so we're all quite familiar with design crits as a tool for feedback. We've used them to iterate across initiatives on all teams—from product to marketing to sales—and they help embed design as a cultural value within the whole company. We’ve also used “pin-ups” where team members can present a proposed solution to a business problem. We've found this format to be more inclusive and facilitate participation from the go-to-market side of the company since they’re more about idea generation and less about product thinking.

Q: Any advice on structuring EPD teams? Do you hire generalists, specialists, or somewhere in between?

We’ve focused on generalists across the EPD org, including on the design side. Our lead designer spends a majority (upwards of 80%) of her time on customer research and systems thinking. We do feature design work in a day or two based on all of the upfront research and/or using our design system.

We hire product-minded engineers and require them to complete a paid take-home assignment that assesses product thinking along with code execution. We also bring in contract specialist designers and UI engineers for visual, design systems, and frontend work, depending on the need.

On the Business Impact of Design

Q: What did you learn from monetizing your side projects? How have you seen design being used to drive business impact at Monograph?

It's been a while since I reflected on what I wrote back in 2019 about my year-long experiment of designing and launching several monetized sites. The biggest learning is that design investments require patience. I wrote that article reflecting on work I had done a few months prior and tried to assess business value from the lens of an immediate ROI. That was too shortsighted.

Over the past few years, I've divested from those projects to build financial stability (read: being a startup founder is challenging financially), but after a few years of separation, I realize the compounding value that design provides. The sale was significant for my family, but the subsequent patient capital growth buyers saw 5x growth in two years since the sale.

How do we take that learning going forward? Compounding—and specifically design compounding—is counter-intuitive. It's hard to compete with a "revenue today" model, but ultimately an efficient business wins out in the long run. Making your product more enjoyable to use generally doesn't provide the business lift that, say improving your funnel conversion, does, but product improvements actually compound over time.

I suppose the big takeaway for Monograph has been to double down on the product areas that are successful. We have a pretty solid invoicing product but we know investing another $1M+ will continue to make us the best-in-class invoicing tool and drive love for that part of the product. Product love isn't talked about often, but it drives some of the lowest CAC in the industry.

On Personal Brand

Q: How did you go about establishing your personal brand as a designer? Did that help to elevate you as a designer and lead you into the path of becoming a co-founder?

Admittedly, my personal brand is a bit unintentional. When I started working on side projects, I found it pretty natural to share them on Twitter and Dribbble, which helped grow a following. Indirectly, my personal brand did help quite a bit in our path to building a startup, including…

  • Getting the role at Figma, in part, due to my growing Twitter audience
  • Dylan investing in us and also vouching for us to our lead investor Index Ventures
  • Getting our first few VC meetings from a tweet
  • Landing our first few hires via Twitter

I've been more hesitant to tweet now that we've grown as a company, but I do have my unintentional brand-building to thank for quite a bit!

Big thanks to Moe Amaya for sharing his insights! Keep up with him via LinkedIn, Twitter, and his website. Plus, check out some of his side projects including Meta Tags, How Many Plants, and Dash Dash.

Applications are open for Designer Fund Partnership, the best investment and design support offer for early stage startups. If you or someone you know is a founder who values design, apply for investment and design support by October 31.