| A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Thanks for your interest in The Question! Sign up to participate in future questions here. This file is the raw data from Episode 37, deep dive hosted on November 7, 2024 with Ben Callahan and Caroline Horn. There are 60 answers. The question this week was: ----- We’ve all met them, those mythical contributors who seem to straddle the artistic and the analytical. The folks who understand the technical intricacies (or roadblocks) to incoming requests, who can sometimes skip weeks of conversation and hone in on the critical part of your next design system feature. We’re talking about designer/developer hybrids. Some call them unicorns while others simply call them good at their jobs. These folks can wield great power, especially on design system teams where everything we do tends to expose and challenge the unhealthy practices in the larger organization. But perhaps there’s a dark side to this as well—the skill and power of being able to operate in both worlds can leave you working in isolation and sometimes create tension with other teams. This week we’re going to look at the benefits and challenges of having these hybrid folks involved in a design system program. I’m joined by co host Caroline Horn, who just so happens to be one of those hybrids. 😏 For the sake of this week’s conversation, let’s define a hybrid as someone who: • Has strong UI design, UX design, and front-end development skills • Is fluent in the tools and frameworks used by these roles in your company • Actively contributes in all of these areas • Has the social skills to smoothly navigate conversations with these roles With this as context, here is The Question for the week: Do you have any hybrids on your current design system team? What are the pros and cons you’ve experienced in working alongside hybrids? Should design system teams have clearly defined positions for hybrids? Why or why not? | |||||||||||||||||||||||||
2 | Question 1: Do you have any hybrids on your current design system team? | Question 2: What are the pros and cons you’ve experienced in working alongside hybrids? | Question 3: Should design system teams have clearly defined positions for hybrids? | Question 4: Why or why not? | ||||||||||||||||||||||
3 | Yes | I'm a hybrid. I also worked with a designer on a design system who had strong frontend skills. He was so easy to talk to when discussing new features/components because he knew what was and wasn't possible programmatically. Hybrids bridge the gap between design and dev. I can't think of any cons right now. | I'm not sure. These days, there are Design Engineers. Sometimes these roles are well-payed, but if they're not, it's almost like expecting one person to do the job of two people. | |||||||||||||||||||||||
4 | Yes | The pros are that they can solve the problems faster by bringing together both disciplines of design and development and they can spot solutions quickly. The problem though is that they are usually either placed as a designer or a developer and therefore have to fit only one of the two responsibilities roles | To be honest I haven’t thought about this too much, I’m looking forward for the discussion in the group | |||||||||||||||||||||||
5 | Yes | Pros: the speed at which problems can be solved, communication between "design" and "development" is better, a deeper level of understanding in general Cons: none | It shouldn't be a requirement but if I was a manager, I would try and make sure to have at least one hybrid profile in the team, always | Because hybridness is not easy to define, there can be various degrees of it. Designers turned into developers and viceversa. Curious, multidisciplinary people, generalists. And it would also be limiting. | ||||||||||||||||||||||
6 | n/a | n/a | n/a | n/a | ||||||||||||||||||||||
7 | No | I am a designer and I do not have design technologies on my team or in my company BUT I work very closely with my engineering partners on the design system team. I actively have to participate in architecture reviews in engineering to ensure that we are meeting some kind of alignment. Pros: a wealth of knowledge and a translator of sorts between how something is made, really helps refine how it should look and behave and visa versa. No real point is designing something that’s going to be spaghetti code without a very strong design reason. My goal is make the api and designs only as complicated as they NEED to be. Cons: translation barrier. As someone who can speak a “little engineering” I personally can see how it’s challenging to “translate” between devs and design and again, visa versa. | Yes | I think a definition is worth the effort. I would be fearful that a design technologist lives in-between orgs and that could be challenging for long term career path. | ||||||||||||||||||||||
8 | Yes | I'm a developer/designer (less of a developer nowadays) and I have hired several developers/designers. Pros: - Less discussion about the value of things like animation, transitions, and overall fit-n-finish - Better quality deliverables than with so-called "full-stack" engineers. - Quicker response to customer issues in the UI - Cost-effective for smaller teams Cons: - Will modify designs to be easier to develop (could also be a pro) - Increased context shifts between their "hats" - Difficult to hire the right people | It depends | It depends on the project, the design system, and the organization. Some organizations can fit a hybrid role, others will not. In many orgs the hybrid will be more of a developer than a designer. | ||||||||||||||||||||||
9 | No | working alongside people who have skills is always an advantage imo | I'm still a bit new to DS to accurately answer this Q | (please see above) | ||||||||||||||||||||||
10 | Yes | I am a hybrid, and we're the oft misunderstood role at organizations. While the industry agrees we're the essential role on any design systems team, existing silos at organizations often exclude our participation. The pros include being able to work on either design or engineering teams. The cons working on design teams include managers who don't understand what you do. The cons working on engineering teams include engineering looking at you like you don't understand what an engineer should. | Yes | To quote the great Nathan Curtis: "Design systems are a home for hybrids". (here's the full quote) "Design systems tend to be home for hybrids that bridge design and development. Depending on the culture, it can be a very risky place for them. Often, if a designer who’s frontend capable, but isn’t the world’s leading expert on Typescript, suddenly they’re rejected by the development staff you’re trying to merge into the program because they don’t know all the ins and outs of Typescript. They could totally run circles from a design token/tooling perspective around all those Typescript developers, but they’re not allowed in the repo. Be careful of that, but also work to set expectations of inclusivity and how team members can evolve." | ||||||||||||||||||||||
11 | Yes | Team members in dedicated design or development roles often overlook recommendations from hybrid roles, viewing them as generalists rather than specialists. | Yes | As the industry progresses, product designers increasingly fall into either purely design-focused roles or roles that blend design and development. Those with expertise in both areas often contribute more effectively to design system initiatives. I believe we'll see a rise in "Design Technologist" roles in the near future. | ||||||||||||||||||||||
12 | Yes | Not being 100% allocated, and to some people, it might be challenging to jump around from one project to another. However, the benefit of having the context of some projects is helpful to understand how certain components will behave or even better recommend which ones to use! | Yes | Cost allocation; time and task management; professional expectations and evaluations (you can't expect the work of one person allocated 50% to be the same as 100%, etc). | ||||||||||||||||||||||
13 | Yes | You'll have to ask my team! ;-) Also, I'm the only one (though training others to take more programming responsibilities). | No | Yes and no? A hybrid (or Design Technologist) is an essential role within a Design System team. They are able to create custom solutions and communicate to both design and engineering. Ideally they are constantly defining and redefining their roles as needs arise. | ||||||||||||||||||||||
14 | Yes | Pros: - Generally more aware of accessibility needs, requirements, and goals - Understanding of the technical aspects and constraints they're design for - Experience a good degree of job satisfaction when able to work on a problem from multiple angles - More empathy and collaboration with different roles Cons: - Tougher time building up a specific skillset - Harder to separate what you want to work on vs. what you need to work on - Can get pulled in different directions to fill gaps that may stray from primary responsibilities At GitLab, we use GitLab to build GitLab, so I would say most product designers have some ability to make changes in the code. Managers, copywriters, and other disciplines do too. We also have teams that don't have a designer so there are developers who are able to do design work. Every designer who has worked on the design system team has been a hybrid, quite often with deep development skills. | Clearly defined responsibilities and skills, but as part of a role, not something unique. | Systems thinking naturally covers a spectrum of skills and I think it's more important to understand where individuals fall on that spectrum and where they're wanting to grow. I don't believe the terms "hybrid" or "unicorn" are helpful. In my own experience, it made it tougher to know where to fit or how to describe my skillset or career path. In one role, I had initially been hired by the internal design agency, but helped fill in as a frontend dev, and eventually was part of the experience design team doing all of it plus research, maintaining an email system, and supporting eComm. It was fun for sure, but always interesting come review time when discussing career path and growth. | ||||||||||||||||||||||
15 | I have people who _could_ do that, but are directed at a specific practice. | I haven't met many who were "unleashed" that way, but the value is the same as what people who say "designers should code" actually mean. The biggest pro is the ability to ask better questions when working on design/code. | Yes | As a firm believer that design system teams should be a mix of design and engineering, a person who bridges both areas well can be more versatile in what they work on. It's a DS generalist, essentially. | ||||||||||||||||||||||
16 | Yes | Pros: adoption, implementation, and standardization across product spaces. Internal cross-functional solutioning before implementation (huge asset to avoid problems during implementation) | If a specific system requirement needs to be filled to deliver value, the best solution is often a derived role/position. BUT, often the highest value lies in understanding the problem and solution space BETWEEN the categories usually associated with roles and positions, so if they are defined, understanding across roles is often the biggest value driver. Working across roles also helps keep the interest of some the best DS Designers and Engineers. | Dito to the the response in the "Should design system teams have clearly defined positions for hybrids?" | ||||||||||||||||||||||
17 | Yes | I work in a hybrid role. I think hybrid experience allows for better understanding and integration across teams. It also asks people to take ownership of issues that arise during the design and development process. For example, developers feel more empowered to make suggestions which positively improve the final product. I think we get into a rut of thinking that design and development are two very different mindsets and skills. I think they have more overlap than most people think - the more that we encourage collaboration across that boundary with hybrid roles the better. The one big disadvantage of being in a hybrid role is the need for increased context switching and feeling spread thin. Tech is a forever evolving and growing industry, which can be hard to stay current and up-to-date with. When your trying to do this across both design and development it can be tiring and feel like a lot of pressure to stay relevant and good at both. | Yes | I don't think it is always necessary but having people in these roles allows those people to take ownership of both sides, rather than just occasionally reaching across only to be meet with hostility on the other side. I think having hybrid roles in a team can also give permission for others in the team to learn and grow more hybrid way - which improves everyone's career development and skills. However, there aren't many hybrid skilled people in the market, so having good communicators in both the development and design team is more important, and a more realistic way to achieve the same pros. | ||||||||||||||||||||||
18 | No | Pros > When hybrids are working on the design side of a project they have a strong understanding of DOM and how elements should flow across multiple breakpoints. In my experience, they are also able to more thoroughly annotate designs using technical language that developers are able to quickly and accurately interpret thus reducing ambiguity. And there is a stronger understanding of how to scale designs for MVP. Cons > When searching for creative solutions the hybrid must be able to flip the switch from dev mode to design mode and not allow what they know as a developer to hinder their exploration of all the possibilities available to them. | Yes | Because these are the jobs that I want to apply to! 😁 | ||||||||||||||||||||||
19 | Yes | Being a hybrid myself, it's a pleasure working with developers who understand UX prerogatives and designers who understand dev constraints. As long as the hybrid folks understand that their role is their key responsibility and their additional knowledge is a bonus but not an entitlement, it is perfect. -Arko | No | It's not possible, hybrids are of weird overlaps, when you have one, you use them to the best of their capacity but very often we'll have the positions filled by people who have the best capacity to fill that specific position, on top of that they'll have capabilities which overlap other functions, those capabilities are a bonus and should be cultivated and used, but the next person on a similar role might have a completely different overlap and you won't be changing the JD every time. -Arko | ||||||||||||||||||||||
20 | No | Pros are that they help translate constraints/benefits into terms that each discipline best understands, and can make each the goals of each more approachable. And being more neutral between dev/design helps them prioritize the system over specific teams. A con is that by doing this, product teams sometimes begin to defer to the DS team to help them communicate hand offs. | Yes | Many design systems often naturally draw those who are hybrid, and it would make sense to formalize the role. | ||||||||||||||||||||||
21 | No | Pros: - Hybrids bring insights and understanding of technical constraints & execution early into the design phase, which can guide design direction. From the development side, their UX and UI skills positively influence the execution of designs & animations. - Hybrids can also be really wonderful communicators and educators that help to bridge the gap between design and dev, which is incredibly valuable. Cons: - I’ve seen hybrids have their career trajectory taken out of their control because of how some companies value engineering vs design work, and end up spending all their time developing instead of designing because they were seen as an “extra free developer”, and I’ve seen this lead to discontent when these hybrid folks were hired as a designer and end up spending 90% of their time developing instead of designing. - Another con I’ve observed is these hybrid folks being stretched far too thin across different tasks and ultimately end up making poor UX and UI choices in favor of needing to design/develop the easiest or quickest solution to try and keep their sanity. | Yes | I think having clearly defined positions can help protect peoples’ time (allows them to set boundaries and align with their manager on how their time gets allocated) and help provide clear expectations of the role (so that people can determine if the role aligns with where they want their career to go). | ||||||||||||||||||||||
22 | No | N/A | Yes | I go back to the use of RACI and career ladders. These are great for whatever position you have on a team and clearly defines expectations, deliverables, and responsibilities s there is no confusion or teetering of work between folks. | ||||||||||||||||||||||
23 | Yes | s a hybrid designer/developer, I can handle projects end-to-end, which is particularly valuable for tasks like design tokens where I understand the complete workflow from defining variables to implementing them in code. However, this self-sufficiency has a downside: since our DS team owns the token system and I'm working across both disciplines, there's no dedicated developer available to perform code reviews or validate that my technical implementation follows engineering best practices and standards - something that would typically happen in a traditional development workflow. | No | Work in a DS varies throughout the sprint and it's useful to have people that can jump into different work where they are needed. | ||||||||||||||||||||||
24 | I was laid off this summer, but I've always been the hybrid on the team. | I've always been a lone unicorn, but I'm interested to hear the responses to this question. | I think it depends on the organization and if they value folks with a hybrid skill set. | If the company doesn't value the hybrid skill set, it can create a toxic environment for hybrid folks and reinforce impostor syndrome. If the company does value the hybrid skill set, it can be a rewarding and fulfilling experience. | ||||||||||||||||||||||
25 | Yes | As a hybrid myself (or maybe more accurately someone who was a hybrid), I find hybrids to be incessant know it alls who have an opinion on everything (I joke, lol). Hybrids are fantastic drivers of change speaking the common language that brings cross functional teams into a common understanding of the work that needs to be done including risks, dependencies, usability and technical feasibility. These folks are phenomenal | Yes | Every job role should have clearly defined positions so that the employee knows what they are responsible for and what they are not responsible for doing. If that employee chooses to go above and beyond their job description, that’s fantastic. I see job descriptions more as protection for the employee from their employer so that they don’t get put onto so much work that they can’t focus. | ||||||||||||||||||||||
26 | Yes | it me! Having this role promotes quality. I get looped in to TONS of convos, often early, because I can provide more context on feasibility of building something; I often do early design feedback, early eng feedback. Designers don't work in their medium (code), so IMO it is critical to have someone helping review "how would we build this?". It's great that designers can consider experience "separate" from constraints, _and_ we have to bring those constraints in at some point, because how the browser/code works is a constraint that can't be avoided. cons: - I get looped in to TONS of convos and that can be EXHAUSTING, it feels like I'm involved in literally everything we build. - depending on the team/individual, this can turn into a gatekeeper type role. It doesn't have to!, but it can. | yes, or that should be the only type of hire for a DS team | Spicy take: I believe ALL design systems folks should fall into this bucket a little bit. The point of a design system is "helping bridge the design-eng gap" and that, I think, _requires_ the understanding of both design and eng. Having a DS team made up of silo'd designers and engineers (or worse, only one or the other), means you are missing half the perspective. | ||||||||||||||||||||||
27 | Yes | Pros: Great at bridging communication gaps for the people on the team who lean more towards design or coding. Great at being flexible about what they work on and can do whatever task the team needs at that moment. Cons: Because they're always reacting to what the team needs it can be difficult for them to define and work towards a clear career trajectory. I think their hybrid nature can sometimes make it hard to stand out either on the design team or on the FE team. | No | Having clearly defined roles can make it difficult for the hybrid to truly bridge the communication gap that their role needs to fill. But it might work if the role can be written in a way that is flexible and can speak to their own unique skills. | ||||||||||||||||||||||
28 | Not technically a hybrid, but a designer w/ a background in development. | Pros: - Can provide a developer's prospective in design - Great for design QA when comparing code/designs - Can do on-the-fly fixes and updates on code that devs may not have the capacity for - The team can work on designer-focused developer projects such as plugin tooling. Cons: - Sometimes limiting in terms of pushing the bounds of "what is possible" when comparing designs with technical feasibility when there are gaps in dev knowledge. | Yes | Yes, because that way there is a structured learning path and expectation for the hybrids. It's hard to judge growth when the managers may not know what entirely to expect from a hybrid as managers are usually versed in either design or dev, but rarely both. | ||||||||||||||||||||||
29 | No | At my job, the design and development roles are kept separate. We don’t have anyone who does both, and people can be a little territorial of their job roles. I am a designer who is decent at front end, and I have wanted to work in a hybrid role, but haven’t found any opportunities, either at my job or elsewhere. It seems like there would be a lot of advantages to having roles like this, but I haven’t experienced this. | Yes | I haven’t experienced this, but it sounds beneficial. There is a lot of design/development overlap when working on design systems. | ||||||||||||||||||||||
30 | Yes | Hybrids are great, and are typically perfect for design systems teams. The issue is that at a lot of companies, design systems teams already fall outside of the established product development or platform functions. They may sit under one of these departments/domains, but there can often be an asterisk in the reporting structure, how the team is resourced, or even the roles involved. When you then have someone who spans two established functions (design/eng) it can be tricky to fit the individual back into the org and provide them a clear career path. | Yes | Yes, if you can get enough headcount to balance out the tradeoffs across the team. They're very powerful, but nesting a specialist who is then a generalist in that specialty can lead to it's own challenges. Ex: Which function do they report to? Do they have a clear career path? Does their hybrid nature mean they're asked to do more on their own vs building collaboration skills? etc | ||||||||||||||||||||||
31 | Yes | Pros - they know ALL THE STUFF 🤩 Cons - they know ALL THE STUFF 😳 | If you can; and if not, making space for a dev to lean design and vice-versa | If it fits in your org, YES. If you are trying to remain lean, I think allowing your talent to shine however they are suited makes the most sense. | ||||||||||||||||||||||
32 | Yes | Great at working with engineers to achieve desired design outcomes while respecting the original intent, or helping less technical designers understand tradeoffs during their design process. Prototyping in code and technical knowledge also helps when working with engineers to achieve specific style and behavior implementations. | Yes | Designers' and engineers' performance is evaluated by a specific set of criteria that may not fit hybrid roles. In my experience at least, designers are incentivized ~away~ from specializing in more technical skillsets, and in a waterfall-style development process, this can lead to a rift between designers and engineers in terms of collaboration and communication. Hybrids fill that gap and can reduce headache for both sides. | ||||||||||||||||||||||
33 | Yes | Having a hybrid who can bridge the gap between the design and dev languages help teams ensure they are on the same page from the beginning, aligned at handoff, and better maintain the communication leading up to validation. | Two teams never fit the same mold | Each team is unique. While it may work for one team, it may not for another. I've worked on teams where the dev team is very hostile to the idea of a designer entering their space -- someone who straddles that line only decreases their credibility. Other teams I've worked with embrace a hybrid who can push lines of code to provide varying degrees of proof-of-concept to production ready components. | ||||||||||||||||||||||
34 | Yes | It’s entirely a positive thing. Knowing more and doing more is good! I also think it’s natural for curious, passionate people to learn adjacent crafts. | No | Everyone’s skillset is different, and I don’t think it’s essential we cover every permutation with its own job title. Having said that, I’m not opposed to anyone having a title that celebrates being a hybrid. | ||||||||||||||||||||||
35 | No | They often have to straddle competing objectives (both in the tasks/work they're assigned AND within immature orgs who don't have the systems in place to support and nurture their careers). | Yes | Clarity over brevity, ALWAYS. Throwing someone into the deep end without a relatively clear (lets say 60%) description of what they should/should not be focusing on is irresponsible. I'd say I'm more lenient to small orgs/startups having that lack of clarity (given their natural state of scale) but large orgs have no excuse. | ||||||||||||||||||||||
36 | Yes | I am the hybrid on our team. I also lead our design system team. I'm essentially a "Tech Lead Manager" (a UX Engineering manager that still writes and reviews code due to our small team size) that can assist our sole designer when he needs some support. That might be reviewing the designs of design system adopters and providing feedback. That might be building out the Figma component for a new UI pattern. That might be consulting with a contributing designer on a pattern we are considering adopting into the design system. The pros are primarily around being able to fluently "speak the language" with both developers and designers, and around being able to lighten the load for each of those roles on the design system team when needed. | No | Both designers and devs could always use some assistance. | ||||||||||||||||||||||
37 | Yes | A pro is that the silos won't be as tall. The only person who is a hybrid is the person who has the most familar with the front-end team. The con is that the front-end team mainly reaches out to the the hybrid (who is on the design team) which leaves out the other designers on the team. | No | Not in our situation. Our Hybrid is on the design team and is someone that the other designers can go to for questions and help bridge that gap. | ||||||||||||||||||||||
38 | No | Unicorns tend to be very opinionated... more often than not in a bad way that has an adverse effect on team dynamics. And... are they *really* as technically proficient at design or development as those who specialise in one or the other? | No | There's a place for real specialists, who focus on becoming experts in a small subset of all the possible skills/disciplines needed in this space. Those experts can (and should) have a reasonable understanding of other skills, but that's not the same as being a unicorn. | ||||||||||||||||||||||
39 | Designers will often claim to have some level of coding capability, and some engineers have done design related tasks earlier in their careers, (e.g at uni) or otherwise still have strong and valid opinions about design. We don't have anyone who meets all the criteria of the Bullet points above, but there is still experiential crossover. | Dunning-Kruger effect is a possibility. I don't have enough experience to comment. | Yes | Yes, they should - if there's room at the table/budget. But this is not required. There are some tasks where having someone equally competent at both sides of the task would just speed things up. But there's also a danger of losing the opportunity for checkpoints and discussions. | ||||||||||||||||||||||
40 | Yes | Pro - they have a good holistic understanding and view of design systems Con - they can sometimes jump to the solution before delving into the problem | No | Hybrids exist on my team but they have one title and report to that org (engineer to engineering manager, ux designer to ux director, etc.). I think it's good to have clear roles but you can still have hybrid skills/understanding/experience. | ||||||||||||||||||||||
41 | No | I love working with designers who know how things are actually built in code and can design anticipating that. In my experience working with design technologists has lead to some great problem solving collaboration with the devs that are building components. | No | We have difficulty enough staffing and keeping individual roles for designers and developers, the idea of bringing on a technologist in my org I think would be seen as an opportunity to cut budget lines—that person would do the job of 2+ people and probably not get compensated much more. At a small/org/team/start up i could imagine it could be beneficial, to move fast in a space where everyone wears multiple hats. In a larger inhouse org its more complicated and bureaucratic (for better or worse). | ||||||||||||||||||||||
42 | No | Some of the pros of working with people who at least have hybrid knowledge is that they understand the potential hurdles before coming face to face with them so it's easier to have conversations to address potential roadblocks before the project gets started. | Yes | I think it's important to have some fundamental understanding of how UI/UX translate to code to begin with and having some knowledge in both area is crucial to bridge the gap between designers and engineers. | ||||||||||||||||||||||
43 | Yes | Pros: Understanding that ultimately, what matters is the implementation. Figma files and designs are only artifacts, and hybrids are able to more quickly and reliably prototype in code than Figma. Also emphasizing the importance of documentation not just in design, but in the coded library. Someone who is equipped to answer design and eng questions on components, and can make code changes on the fly. Cons: When working as a solo designer-engineer, less need to document process since they are the one coming up with designs and implementing them. Totally fine until team scales and processes/knowledge need to be shared and agreed upon. Design and eng partners making a habit to rely on this person to answer questions (taking up their time), rather than learning or referencing documentation. | Yes | Most product orgs value engineers (with higher pay) more than designers. Accurate job title also implicitly communicates to designers/engineers how to collaborate with this person (what types of questions to ask). | ||||||||||||||||||||||
44 | they dont sit on DS but theyre on the design team more broadly | Pros: diversity in thought it is brought from this role in both design and dev convos, helps bridge the gap of understanding and delivery, always love enabling more people to do and learn more things! Cons: rarely is this role defined well in my experience. i feel like its usually design trying to have more influence so teams hire someone with an eng bg that isnt really brought into the eng org fold. this makes it hard for them to influence in the desired way and make sure the work is impactful, and could cause issues with the engineering teams | Yes | https://medium.com/capitalonedesign/responsibility-without-territory-65501c807f80 "At the root of most team drama is fear.." clearly defining the role and scope allows people to know when theyre stepping outside and know how to respond in kind by connecting with other teams or influencing across. imo, the reason to not have this position is only if you cant clearly define it. if you can define what the ask of the position is, what they are responsible for, and thats agreed on between design and eng teams, then why not bring on someone with a unique skillset to help drive team innovation and growth | ||||||||||||||||||||||
45 | Yes | Shit gets done. Designers don't need to beg for change. Can set an expectation on a design team that everyone needs to be hugely technical. That's not the case. I don't expect an Illustrator to be super strong at UX...etc. But there are folks that are. They are still "hybrids". | I'm not sure titles matter too much. It's more important to write up job expectations as clear as possible. "Nice to have" is typically bullshit. Generally I'm OK with people calling themselves whatever they want. Some "Design Engineers" like to be called Designers. Some Engineers like to be called engineers. Typically adding "Engineer" to a job title equates to a pay increase, which is the best reason to add it to your title. | The best teams I've had were composed of generalists. Any of the members could have called themselves whatever they wanted. They didn't have walls, and instead had a focus of expertise. For example, can they write copy? That's just as essential. | ||||||||||||||||||||||
46 | No | N/A | Yes | Clearly defining roles allows for employees to have scope in their work. Easier to delegate tasks and ensure work is done. | ||||||||||||||||||||||
47 | Yes | pro - open and flexible because they have a good broad undertanding of the different aspects and perspectives regarding creating using and managing design systems con - some tendencies to be more practical than open depending on their role in the company (eg more dev focused) | Yes | More brainpower and especially more perspectives | ||||||||||||||||||||||
48 | We have a close to hybrid individual or two (dont have front end development skills but tick the other boxes) | Pros: can rely on them to do the job 90% well with very little handholding Cons: there are not enough of them and they get overwhelmed with support requests themselves. We have a 150+ design team with only 3 or so close-to-hybrids | Yes | I think people with deep but broad skills are few and far between and should be elevated for their knowledge so they can spot and impact the places where process falls down or has gaps. | ||||||||||||||||||||||
49 | I am the hybrid. | From my experience, working alongside hybrids (like me!) comes with a mix of benefits and challenges. One of the biggest advantages is the ability to act as a translator between design and development teams. When disagreements arise, I can bridge the gap by explaining the reasoning and constraints from both perspectives, which helps align everyone toward a shared goal. I also naturally encourage collaboration between teams, spotting opportunities to bring them together in ways that might otherwise be overlooked. Being a hybrid allows me to think beyond the typical “designer” or “developer” roles, promoting innovative, user-focused solutions that integrate the best of both worlds. However, there are challenges too. Staying proficient in both design and development is tough—it’s hard to find enough time to dive deeply into trends and tools for both disciplines, which can leave me feeling stretched thin. Another common struggle is identity; I often feel like I’m too design-focused to be seen as a true developer, yet too developer-minded to be considered a pure designer. This gray area can make it tricky to fit neatly into teams or roles. Additionally, my mindset frequently leans toward prioritizing consistency in design and ease for technology. While this balance is valuable, it can sometimes make it harder to push boundaries or explore experimental ideas when innovation is needed most. | No | Design system teams benefit from hybrids, but defining a clear position for them is challenging. The role is often too broad, and in my experience, it leads to everyone assuming, "You can do that, right?" This versatility, while valuable, can quickly become overwhelming without clear boundaries. | ||||||||||||||||||||||
50 | No | Haven't had the privilege as of yet, but I would assume the pro is probably for small focused teams. | Yes | I imagine like most places, designers are stretched thin compared to devs, so while someone might be capable of doing both they would need more allocation towards design | ||||||||||||||||||||||
51 | Yes | Being able to take prototypes to the next level by creating dummy apps where we can concept test. They’ve been particularly useful for stakeholder engagement, but mainly in testing / research especially for accessibility testing. | Yes | They serve a different purpose I feel to validate thinking. They can demonstrate the art of the possible before engineering teams blindly refuse to make something happen, they bridge the gap so for me should be defined separately. | ||||||||||||||||||||||
52 | Yes | Pros: things get built as they are designed Cons: they tend to be better developers than designers | It doesn’t really matter | There are too many variables in team and compensation setups. So it really depends on the company | ||||||||||||||||||||||
53 | No | PRO - removes some impediments when the same person can serve as a universal SME and contributor for the design system | No | Not having clearly defined positions allows for greater flexibility | ||||||||||||||||||||||
54 | Yes | Pros: hybrids remove project bottlenecks. Cons: lack of career mentorship/career ladders for hybrids and muddy reporting structure make it difficult to thrive and advance. | Yes | Clearly defined positions and true support from leadership allow hybrids to shine — and make your team/product more successful. | ||||||||||||||||||||||
55 | Yes | Pros: more paritu across code and design, stellar prototyping, deeper insights and empathy for what impact design decisions on development, and vice versa Cons: sometimes isolated work is harder to bring more folks into | Yes | Career growth - this role doesnt fit neatly into otber tracks. Capa ity accuracy. | ||||||||||||||||||||||
56 | Yes | Pros: Can transition between dev and design teams to help smooth the handoff process. Gives valuable feedback in the design phase on technical requirement. Can work with designers to take ideas straight to code. Cons: They are usually more of a generalist and not specialized in one area. Tend to work in isolation. | Yes | Yes, ideally these positions should be well defined, but the versatility of the role makes it difficult to do so. Newer roles like design technologies seem to try and define the scope of these position better. | ||||||||||||||||||||||
57 | Yes | Pros: speed to prototype Cons: lack of clarity on where they should report to / sit within an organisation | No | Trying to put people in boxes can sometimes prevent innovation | ||||||||||||||||||||||
58 | Yes | Translation - manage tension and avoid unanswered frustrations that stem from not knowing what the other side does, avoid absolutes e.g. can't do this now with this info/ approach is not the same as can't do this ever | Yes | Translation is a full time job - if it was explicitly defined our hybrids can do their jobs with official scope instead of feeling like translation is extra work. | ||||||||||||||||||||||
59 | Yes | I am a hybrid. It allows us to avoid long running handoff and churn but it can often be a jack of all trades master of none situation. | It depends! | I think it depends on context, structure, process etc. it could work really well for some teams. Not well for others. | ||||||||||||||||||||||
60 | Yes | Pro's - They can speak the development langauge and also ascertain from the get go the technical requirements for the design before its handed to devs. They also understand the iteration methodology and MVP more better than most. Con's - They might overwhelm designers who don't have that development knowledge | No | Because it limits their abilities to succeed in the role | ||||||||||||||||||||||
61 | Yes | As a hybrid, I enjoy the ability to more easily bridge the two sides and appear faster than my counter parts as there is less overhead for myself. At the same time it does create misperceptions of the team as a whole and expectations of how everyone should be working. I also find myself context switching far more frequently than others with playing multiple roles which can make it harder to balance and prioritize efforts while still being able to find and get into a flow state | Yes | I feel it provides a level of clarity around performance and the reality of expectations for the varies people on a given team | ||||||||||||||||||||||
62 | No | None yet | Hybrids can rapidly prototype interactive concepts and validate their feasibility early in the design process, reducing the risk of misunderstandings and rework. When designers and engineers have limited understanding of each other’s domains, it can lead to inefficiencies and a final product that underutilizes the strengths of both roles. Engineers are often brought into the process too late, which limits their ability to propose more innovative or technically efficient solutions. By integrating more hybrids, that feedback loop can be shortened/removed, making it easier to develop high-quality, feasible designs from the outset. | |||||||||||||||||||||||
63 | ||||||||||||||||||||||||||
64 | ||||||||||||||||||||||||||
65 | ||||||||||||||||||||||||||
66 | ||||||||||||||||||||||||||
67 | ||||||||||||||||||||||||||
68 | ||||||||||||||||||||||||||
69 | ||||||||||||||||||||||||||
70 | ||||||||||||||||||||||||||
71 | ||||||||||||||||||||||||||
72 | ||||||||||||||||||||||||||
73 | ||||||||||||||||||||||||||
74 | ||||||||||||||||||||||||||
75 | ||||||||||||||||||||||||||
76 | ||||||||||||||||||||||||||
77 | ||||||||||||||||||||||||||
78 | ||||||||||||||||||||||||||
79 | ||||||||||||||||||||||||||
80 | ||||||||||||||||||||||||||
81 | ||||||||||||||||||||||||||
82 | ||||||||||||||||||||||||||
83 | ||||||||||||||||||||||||||
84 | ||||||||||||||||||||||||||
85 | ||||||||||||||||||||||||||
86 | ||||||||||||||||||||||||||
87 | ||||||||||||||||||||||||||
88 | ||||||||||||||||||||||||||
89 | ||||||||||||||||||||||||||
90 | ||||||||||||||||||||||||||
91 | ||||||||||||||||||||||||||
92 | ||||||||||||||||||||||||||
93 | ||||||||||||||||||||||||||
94 | ||||||||||||||||||||||||||
95 | ||||||||||||||||||||||||||
96 | ||||||||||||||||||||||||||
97 | ||||||||||||||||||||||||||
98 | ||||||||||||||||||||||||||
99 | ||||||||||||||||||||||||||
100 | ||||||||||||||||||||||||||