How Non-Techies Can Learn to Talk Tech (So as to Not Crush their Colleagues’ Spirits)

Building a Culture of Healthy Questioning – Kevin Mackey, Co-founder and COO, Coterie

This blog highlight’s two non-technical founders’ experiences learning from mistakes when communicating with technical colleagues. 

It took about four months at my first startup to realize the language I was speaking to our technical co-founder wasn’t landing. 

“I’ll have it done over the weekend”, was something I repeatedly heard and, after several consecutive weeks of our builds not being completed according to schedule, I couldn’t hear it anymore.

Our scope creep and inability to hit deadlines created a tense environment – and I had a large part in it without realizing it. 

What I came to understand months later (and even years later as I still recall my mistakes) is my inability to communicate directly, in tech language, what my expectations were of the product caused added builds, incomplete (and probably unnecessary) features, and a lot of bug testing for half-completed integrations. 

I know my partner was frustrated with me, as I was with him, but we didn’t have the maturity to self-correct quickly enough to prevent those problems from escalating into other areas of the business. 

You see, when developing complex tech products, the business surrounds it, informs it, and shapes it – but doesn’t build it. 

Technology products are challenging enough to build on their own, but when compounded with human error – particularly ineffective communication between “the business side” and “the tech side” – an onslaught of invisible distraction can cloud a team and sabotage a project, or even the whole company depending on how severe the problems compound and cascade through the organization.

In my experience, the simplest solution to miscommunications between techies and non-technies (as we’ll generally refer to both parties moving forward) is creating a culture of “healthy questioning”. 

To understand why healthy questioning is a simple solution to technical miscommunications, which we I have observed is a starting point to many major problems at a startup organization, we must first agree that both groups perform their job with fundamentally different ways of thinking.

Business leaders tend to think without boundary about the problem being solved – what can we do and what will make money? That way of thinking is what makes their contributions to the world’s problems so fresh and valuable. But those thoughts and visions are being executed by others who think about how we can do it. If business leaders don’t understand the “how”, one of a couple things tends to happen:

  • Business leaders ask for the impossible – “we can’t actually do that”
  • Business leaders assign competing interests – “well if we do that, we can’t do this”
  • Tech leaders don’t educate business leaders on the how – “well I didn’t know that”

More often than not, because no one likes conflict, the parties walk away with inaccurate understandings of what will happen next, who is doing what, and how long it will take. As the organization grows, that misinformation spreads to the tentacles, which tend to be sales teams who sell, but don’t deal with, the product on a day to day basis.

In the end, disorganized promises can have product teams scrambling to complete work, rather than passionately pursuing the best possible product, which is what they want in the first place. 

In an environment of healthy questioning, however, each party must be aware and vulnerable enough to come closer to the other to “bridge” the communication gap. If you start with an expectation that the opposite side of the business knows more about that particular function than you, then you’re always going to be learning more. In that environment, asking “why” is a great thing because you want to learn about why the other party spent their time and intellect doing something a particular way.

Over time, those pathways of learning will seep into day-to-day work. I’ve seen it! When anticipating someone else’s questions, you’re actually teaching yourself to go deeper and smarter in your own craft. That versatility, which shows itself as business or technical acumen, makes every employee more mentally diverse. 

Embracing mental diversity and having confidence in the capability of your teammates moves products forward fast and is the hallmark of an environment of healthy questioning. Anything that doesn’t foster such an environment is just friction. And in the startup world, friction causes missed quarters, pressing, and, typically, chaos. 

I think we can all agree that’s no way to make the best product, so let’s get out in front of it and contribute to working cultures that focus on what the other person doesn’t know so the whole company’s vision of how is the same. 

 

How the “Tap Dance” Looks in Real Life – Christi Brown, Founder and CEO, iReportSource

Start-up founders need to be problem solvers with humility, experience, passion and the skillset needed to get the MVP across the finish line.  Learn fast and iterate. Sounds great, right?  The hardest part, in the beginning, is that everything is based on a hypothesis and prospects who may or may not see your vision.

The faster you can get to users, the faster you can get to customer feedback, to build a product that adds value and drives adaption.

Everyone wants that to happen as fast as possible which ratchets up the stakes and expectations of everyone involved. 

In the beginning, I’ve seen how non-tech founders get excited about feedback from prospects who request features that we truly have no idea if it’s necessary or not.  This is when scope creep sets in. 

The conversation usually goes something like this.  

Me: “how difficult would it be to build ‘X’”

CTO: “It depends”

Me: “Just the MVP, how hard do you think it would be?”

CTO: “Well probably a week, I guess”

The CTO wanted to please me as a non-tech founder but I gave him nothing to determine what we actually needed, nor did I fully understand what the customer wanted.  I didn’t know how to ask the right questions. I was just excited that someone was willing to pay for my product.

If this sounds familiar then you know from there, one of two things happen in this circumstance.  A week goes by and they aren’t finished with the feature that the prospect suggested.  I start asking questions about why it’s not done.  The team says, well there were a lot of things we had to think through and we didn’t expect ‘x’ to happen.

Or they complete the feature and I say, “Oh that’s not what I wanted at all”.

This is where the egos come in. The tap dancing begins.  As the salesperson for the company, I go back and tell the prospect I’d have the feature ready in a week.  Believing the customer will be a paying customer when the feature is ready. I get frustrated because they told me a week and it’s nothing like I expected.  I feel like the time and money was wasted.  So, I decide, I’ll start having morning scrum meetings to “control” the process in the future and make sure we don’t miss deadlines or at the very least, I’ll know ahead of time we’re going to miss it.   The tech team is offended that I didn’t like what they built and feel as if I seemingly have no respect for their craft. They start to feel micromanaged and frustrated.  In addition, my “feature” just derailed the MVP build by at least a week.

As I’ve scaled and thrown money out the window, I’ve learned so much about my part in the chaos. In a well-funded startup or company, a trained product manager would communicate user research the content and functional scope typically to the UX/UI & Designer who would have put wireframes together and then the CTO would put the architecture together for the build, and finally handed it off to the DevOps engineers to build it.  The DevOps team wouldn’t have to think through anything, the plan would be handed to them.

I’ve spent hundreds of thousands of dollars to get my product launched.  I’ve worked with three different development teams of two or three developers: back-end, front-end, and one time a junior dev too.  I have a lot of respect for those small, agile teams who get the product launched in a relatively painless manner.  After all, we’re asking a team of 2 to do the work of 7-10 people in less than three months.

This is why investors like to have a tech founder on the team.  The assumption is that the tech founder will know the ins and outs of building tech and many of the above mistakes will be avoided.  At the very least, they assume the tech founder will have enough passion to avoid burnout and figure it out. Understanding this dynamic, business leaders have two options - hire or outsource the right people needed to have a well-rounded team AND up your game when it comes to being the product manager and respect the communication gap. 

After learning from my own mistakes, here’s a process I’ve seen work well:  

  • Find customer who love what you’re building right now.  Be transparent with them and know when to say ‘no’ to save time, money and burn-out.
  • Take feedback from prospects with a grain of salt.  The best feedback comes from users who are actually using the product.  Get the MVP out as soon as you possibly can!
  • Have a well-developed (agile) strategy for how features are vetted, mapped, and built.
  • Be humble.  Communicate and talk about your short comings.  Recognize that this is a journey, not a sprint.  If it were easy, everyone would do it. 
  • Phase 1 of SaaS start-up is to learn your customer acquisition rate.  All features should be about removing roadblocks to acquiring customers. Keep it simple.
  • Phase 2 is about building features that add value and reduce churn to understand your CLTV
  • Phase 3 is about creating a community of users who love your product and tell everyone about it. 

How about you? What have you seen work to improve communication between techies and non-techies and what impact did that have on your business?