Sometime in the mid-90s, I volunteered to work on a knowledge library and intranet for my then-employer. Truth be told, I probably volunteered because I was a little bored in my role and I was looking for something else to do. I didn’t know the language I would need in the digital space and I didn’t have the skill sets that were commonplace among my new colleagues in IT. If I’m honest, I still don’t. I’ve been a stranger in a strange land, helping translate the challenges and goals of a non-technical enterprise into terms that will be brilliantly resolved and executed by the engineers, UX architects, and designers that I work with.
I know I’m not the only one. I often find myself in conversations with folks who have backgrounds in communications, marketing, or project management but are pivoting to play contributing or leadership roles on technical projects. There’s a slight sigh of relief when we realize that we share the same lane. We can take the conversation through business objectives, cultural impact, or timelines, and how we’re going to need to bring in some additional perspectives if we really want to get into the details.
I can’t teach you to code. I don’t know which tech stack is going to be best for your product. I’m not the one to turn to if you have questions about React Native. I work with people who can do all that and more (call me, and we can discuss!) I can, however, provide some advice about how to communicate effectively with your team—even if HTML and CSS are not your native languages.
Here are three things to think about if you’re the non-techie in a room full of techies.
1. Be clear about what you know and what you don’t know.
If you’re working on a technical project with a non-technical background, it might feel like you should hold those cards a little close to the vest. You might give the smile-and-nod during parts of the conversation that you don’t completely understand. Sometimes that’s fine! There will be technical details that go over your head and those may be details that you don’t actually need to grasp. But you’re on the project for a reason, so make it clear to the people you’re working with exactly where your technical expertise stops. That will help your colleagues ensure that they’re including you at the right times and allowing you to add value wherever you can.
2. Don’t be afraid to ask questions.
You may never need to know the difference between a token and a component. Yet when it comes to the impact of technical choices on a finished product, you absolutely do need to know. So pipe up and ask for all the pros and cons that will impact the finished experience. Think of it this way: We’re all in situations from time to time where we see either the forest or the trees. It’s only natural to develop more of a focus on the areas that you know very well. If they’re seeing the forest and you’re seeing the trees, speaking up is what you’re there for. If you’re working with a team of developers, it can be immensely helpful to bring them an outside perspective. Your end result will be better for it, but only if you’re willing to let your voice be heard as a part of the process.
3. Don’t devalue your own expertise.
I’ve been a non-technical person working with technical teams since some time before the turn of the century (yikes). When I was first getting started, there were plenty of moments when I felt that I was just an observer—that I didn’t have a way to meaningfully contribute to the effort. Since then, I’ve observed that the best teams include folks from all different backgrounds, each bringing a unique perspective that contributes to a cohesive whole. So if you’re the lone designer or UX strategist (or even biz dev person) on a more technical team, don’t forget that you have a unique opportunity to contribute. You may not be mainstream on the product, but you’re not less than because of that. It actually makes your skills and feedback even more important. Jump right in, because you’re needed and valued.
At Sparkbox, we put all of this into action—it’s not just talk. We have all-team demos every two weeks where the whole team gathers for stand-up-style presentations on what different folks are working on. It’s great to see every member of the team step up: UX strategists, designers, developers, and also HR or communications folks. We’re a development studio, but we’re not made up exclusively of developers, and I really do believe we’re all better for listening to each other. I hope you’ll find the same experience with your team!
