One of the best things about working at a startup is that you don’t work within any set boundaries. So even as a non-technical team member, I’ve found myself learning how to talk to developers. Much of what I do involves collaborating with the other team members as our projects move start to finish. When we have a new feature release, I work on the copy to make sure it sound clear to our target audience. It goes into staging, we all QA, and then it gets released to Production. Easy, right?
Wrong. Learning to think like and communicate with our tech team has been a necessary challenge. As I’ve been carefully warned, how you phrase a problem is very important because you wouldn’t want your developers trying to come up with every possible scenario for what is only a small request. It’s important the purpose and desired outcomes down the road when building a feature. That way, your team can do what they do best and build the proper framework.
Step One: Learning to Communicate
At the startup I work at, we follow an iterative process for development like many other lean startups. For us, it’s important to release things quickly, even if isn’t perfect, so we can get feedback and use that to improve our process. One way we do this is through what we call MUEI’s (minimal user experience improvements). For us team members that work in a client-facing role, we interact with the platform daily, so it’s our job to take feedback from customers and translate them into these MUEI’s. We then submit these as cards on Trello, a web-based project management application, for our developers to sort and complete.
Very frequently we receive feature requests from our customers. At the beginning, I had a habit of just explaining what the customer wanted, e.g. expand breakout session information in the iframe.
After taking a look at the MUEI’s we had been submitting, our lead developer told us, “give me problems” and that it was his job to come up with solution. This was the exact opposite of what I had been doing. We ended up having a short meeting to discuss the best way to present things to developers, going over how to describe what the user is trying to accomplish and clarify steps that need to be taken.
This forced me to start to think in a way that wasn’t intuitive to me. I started to realized the importance articulating the problem, e.g. the breakout sessions are hidden so potential attendees might know they are there, because there are different ways to tackle it.
Step Two: Learning to Code
Why is it important?
Learning how to talk to developers is like learning another language, and it’s pretty cool when you start to feel comfortable communicating in a different way. Not to mention, it increases your marketable value as a non-tech professional. (If you need more convincing, check out the Wall Street Journal’s “Sorry, College Grads, I Probably Won’t Hire You”).
Especially when you work at a small company, it’s important to show that you know your stuff. When we talk to potential partners, knowing our technical specs and API capabilities helps us gain credibility right off the bat. Then we can go talk to our developers and flesh out the details.
Even though I’ve started to figure out how our developers’ minds works, I’m still learning. I hope that as the company grows, I’ll be able to increase my tech skills until I’m one day able to work independently on our e-mail and blog designs. Till then, I’ll be working on asking the right questions.