# Mike Meyer > building design systems at Brex • formerly: Twitter, Smyte Location: Brooklyn, New York, United States Profile: https://flows.cv/mikemeyer My work centers around building tools and infrastructure to enable both designers and developers get to the results phase faster. Nothing makes me happier than a team with clear processes and a clear vision for what needs to be done. I'm a firm believer in mastering the tech I use day to day and transferring that knowledge on to those around me. ## Work Experience ### Senior Software Engineer, Design Systems @ Brex Jan 2023 – Present | Manhattan, New York, United States ### Senior Software Engineer, Design Systems @ Twitter Jan 2021 – Jan 2022 | Brooklyn, New York, United States The remainder of my time at Twitter was spent working on Feather, the design system for ads tools and internal tools. My primary focus was developer efficiency—both the efficiency of developers on the team and the efficiency of our internal customers. Highlights: - I overhauled our component build system and managed to get build times from 6 minutes (!!!) down to about 20 seconds. - I introduced a number of autofixing lint rules that helped contributors avoid common mistakes and antipatterns, thus removing the need to discuss these things in code review. - I built a Flowtype to TypeScript conversion process that allowed us to migrate a massive Flow codebase over to TypeScript module by module, and with no negative impact on our customers. - I introduced the team to a light agile process, replacing our home baked task tracking setup with something more focused on team accountability and accurate project estimation. ### Software Engineer, Twitter.com web team @ Twitter Jan 2020 – Jan 2021 Highlights: - I helped bring multi-destination carousels to the web, thus providing advertisers with a new enticing ad format and growing ad spend. - I fixed a number of accessibility issues in the Twitter preroll video player and introduced a new way of displaying the video content attached to the preroll ad. Backstory: Due to headcount limitations on a team I intended to join, I was temporarily loaned to the Twitter Web team to help them build new ad formats. Those months ended up being an invaluable deep dive into react-native-web and accessibility on the web. It was quite surreal working on a web app that served millions of customers. Once I had helped get a few ad formats projects out the door, the headcount I was consuming was moved over to my intended team and I joined them fulltime. ### Software Engineer, Health Tools @ Twitter Jan 2018 – Jan 2020 | San Francisco, California, United States Highlights: - Elevated teammates' output through pairing and mentoring. - Prototyped a TypeScript-based stack for the future of Health Tools. The project that spawned from this prototype is still in use today at Twitter and it powers a number of critical Health tools. - Botmaker 2 rescued from development hell and shipped. Botmaker is the front-line tool for fighting spam and abuse at Twitter. The old codebase was Ruby on Rails and jQuery and it was a ticking time bomb. The Botmaker 2 project commenced a year before I arrived but had been stuck in an incomplete state for some time. In a period of about a month and a half, I rebuilt the entire frontend using Feather, our internal design system, as the basis for the design. ### Lead Designer → Lead Frontend Engineer @ Smyte (Acquired by Twitter) Jan 2015 – Jan 2018 | San Francisco, CA Highlights: - I learned React on the job and developed a deep knowledge of webpack and React internals. - I singlehandedly designed and built the entire Smyte user interface and worked closely with customers to deliver the features they needed in the UI. I joined Smyte in 2015 as their first hire. I was brought on to design the fledgling web UI for the product. In the early days, Pete Hunt, our CEO, would implement my designs. As CEO duties started to consume more of Pete’s time, I started to take on more and more frontend work. Within a few months, my design workflow shifted to a code-first approach and I started digging into frontend tooling so I could iterate more quickly. In the years that followed, I collaborated closely with both our customers and our analysts to build out the features they needed in the UI. I learned the ins and outs of the entire frontend pipeline and developed a deep knowledge of webpack and React. ### UI Engineer @ Venmo Jan 2014 – Jan 2014 | San Francisco, CA I was brought on as a contractor to help with the intricacies of building out a design team. I worked with the lead designer in SF and the web team in NYC. My contract at Venmo was fairly open-ended. Initially I prototyped mobile concepts and got the team set up on a prototyping workflow with Framer. I unified mobile app assets into one source of truth per platform and built out an asset export pipeline/workflow for creating pixel-perfect app assets at any resolution. Towards the end of my project I worked with the web team to envision the future of Venmo on the web. ### UI Engineer @ Dropbox Jan 2013 – Jan 2013 | San Francisco Bay Area The end of 2013 was a pivotal point for design at Dropbox. At the start of my contract, the team was comprised of fewer than 10 designers, and by the end of my contract that number had more than doubled. Morgan Knutson, the lead designer at Dropbox at the time, realised that as the design team grew, the design language of Dropbox would start to change and grow as well, but there was no framework to provide structure for that growth. Enter DIGs, or Dropbox Interface Guidelines. Designers at Dropbox were full steam ahead on their own projects (Dropbox for Business!), so Morgan brought in some outside help: me! The contract was pretty open-ended but Morgan and I broke up the work into a few pieces: 1. catalog the design surface area of Dropbox 2. determine a shared workflow for designers to use 3. build tools to support that workflow The Dropbox design team had just acquired a plotter printer that came with giant rolls of sticker paper. I went through every workflow in every Dropbox app and organised the flows into something that we could print out with the plotter printer. We stuck the giant sticker right in front of the design wing. An interesting side effect: teams that were working on these flows would come to the design wing to discuss updates to the flows, and they’d use the giant sticker as reference. Determining a shared workflow was quite a challenge. Designers tend to do things their own special way, which makes standardising around a workflow rather difficult. Some designers used Photoshop and some used Sketch, which made things even more challenging. In the end I settled on a Photoshop-based workflow (unsurprisingly) built around Dropbox. Design documents already lived in Dropbox, so I could use source files to derive shared assets. Adobe had just released Adobe Generator which allowed people to build photoshop plugins with javascript while having full access to the power of Photoshop via a nifty API. A screenshot of the tool I built is attached. ## Contact & Social - LinkedIn: https://linkedin.com/in/2mike2meyer --- Source: https://flows.cv/mikemeyer JSON Resume: https://flows.cv/mikemeyer/resume.json Last updated: 2026-03-22