Engineering Empathy for the Non-Technical

As a non-technical founder one thing that I have always struggled to understand is how technology is actually built. Over the last few years I have wrestled with questions like “What will this cost to build?”, “How long will it take?”, “How many people will I need on the project?”, “What languages should this be built in?”, and so on. Time and time again I would come up with an idea, and then once I look to have it built have someone tell me that it will cost hundreds of thousands of dollars and take years to build. Simply put, without a technical co-founder, it would be difficult to build out my ideas, and this has always frustrated me.

Whenever I explained this problem to people, they told me to go learn to code. Now, while I have a profound respect for technology and desire to learn the answers to these questions for myself, I don’t want to learn how to code. Personally, I don’t think that my brain is wired for it, and while I would love the creative process, it’s not something that I would like to spend my time doing, because it isn’t aligned with my true nature as an individual and entrepreneur. I would rather learn processes for how technology is built, what it costs, and how to work with engineers, than I would to spend the next 2 years learning a handful of languages I will most likely be mediocre at.

When I started searching for a technical co-founder, it was a nightmare. I didn’t know how to evaluate someone’s skill set, I didn’t know if what they were telling me was reliable advice, and simply put, I didn’t even know how and where to find these people. When I would finally sit down with an engineer, I could explain my vision and map out what I wanted the website to look like, but every person I spoke with had a different way of building it, and they told me I would need $100,000 minimum to build what I wanted. The languages and frameworks they spoke about seemed like foreign languages and I couldn’t make an educated decision without speaking to 10 people afterwards. It was a very frustrating process to say the least.

Luckily, a few months later after I had stopped looking for a technical co-founder my close friend left his job and was searching for something new. He was previously the CTO and Co-Founder of a different startup, and was someone I always looked to for help when it came to technical advice. After a short conversation with him, he agreed to come on board and build our MVP. I couldn’t have been happier. Not only did I get to work with a close friend and someone I looked up to in business, but I got someone who understood my technical limitations and was open and willing to teach me what I needed to know…even if it meant his own sanity throughout that process.

While all seemed great and my pie in the sky fantasies were running wild, the first few months working together were a rocky start. He’s the type of programmer that likes to “build fast and break things”, and this was very frustrating to me. He would put his head down and build things as fast as humanly possible, and I would be left wondering what was being built, how long it would take, and when it was being released. The right things would be built, and they were built on time, but I felt utterly lost when it came to understanding what the hell he was actually doing on a day to day basis. To make matters worse, I was heading back to the US for a few months and we would have to work with each other remotely.

We set up a Trello board to handle our product management, but this was an utter failure as well. I would see terms like “staging” and “V 0.0.1” and wonder what the hell all of it meant. He tried to explain these things to me, but for some reason it just didn’t click. He would release something to staging, and I would wonder why it wasn’t live on the website. He would release something to the live website, but it would be full of bugs and errors. I hated this and would come back to him asking why everything was broken. He would explain to me that this is perfectly normal and is something called a “hotfix”, but the concept of releasing something you knew might be broken was unfamiliar and made me feel very uncomfortable. I wondered if this is really how software is built, but put my skepticism aside and put faith in him to do what he must.

Some context here is also necessary; most companies will put a simple signup landing page on their website while they build out their MVP. We didn’t do this. In retrospect it was probably not the brightest decision, but it wasn’t a conscious decision I ever made. We were getting entirely too many signups organically, and handling the business manually in the way that we used to simply didn’t work and was causing us to put our heads through a wall. We needed a system that could process all of the people we were receiving and put them through the pipeline, and we needed it fast. As a bootstrapped company with limited funds, if we didn’t we would be out of money and the business would be dead. I tried things like Streak and Pipedrive but they just weren’t what I was looking for.

So what did we do? We built and released things piece by piece, broken and buggy, and hoped for the best. We’re still building this way as I write this article.

Around the time of New Years I took a ten day break and went to do Vipassana Meditation (a 10 day vow of silence + meditation course). For the majority of those 10 days the website and my company were a distant memory as I focused on working on myself. Thoughts of these frustrations would come and go, but I quickly learned to let go of things and resigned myself to dealing with the struggles of building a technology company as a non-technical founder upon my return.

When I returned however, something interesting happened. Meditating in silence for 10 days had a strange way of clarifying things, and I simply took a look at what had been built and realized that we had a broken system. Were we releasing product and getting it to do what we wanted? Absolutely. (We had around 800 signups in the 10 days that I was gone, all from a release we made right before I left). But had we created a sustainable system that would allow us to keep releasing product and keep everyone on the same page? Absolutely not.

I brought this up to my friend and now our Head of Product and our other engineer. The other engineer recommended that we move away from Trello and move over to JIRA/Confluence. I took a look at JIRA and it was overwhelmingly confusing to me. Words like “user stories”, “issues”, “sprints” and more made absolutely no sense to me, but once again I put my skepticism aside because I knew that moving over to this system would be a great learning experience and it was what the company needed. We switched over to JIRA and it’s been history ever since.

This was the best decision we ever made as a company. Not only did we get organized and finally have everyone on the same page, I was finally beginning to understand how software was built. He walked me through what it meant to create a “user story”, how to document “issues”, what a “sprint” is, and how long these take (on average). He explained to me the difference between development, staging, and production branches, and how all of them intertwined with each other. He explained the difference between a feature we didn’t think through and a hotfix. He helped me to understand that we were in Alpha, and most of the websites I use on a daily basis are in Gamma and that’s why they are mostly error free (at least to the untrained eye).

I was finally beginning to understand how frustrating it must be for an engineer to work with a non-technical team who is sending 100000 requests a day to fix every small problem they notice on the website. I was finally beginning to understand how software is actually built, and how frustrating it must be for someone to say to you “can we put this on the website today?”. This was the beginning of learning what I now refer to as “engineering empathy”.

In the beginning of working with him, I would flood him with messages asking for this and that to be fixed. I would propose outlandish ideas and ask when we would be able to implement them, and wonder why he would just shake his head at me. I would list hotfix after hotfix and then complain that they weren’t finished. I would get aggressive when something was broken and he tried to explain to me the difficulty in fixing it. In retrospect I look back on this and realize how hard it must have been for him to deal with this, and I’m truly grateful he’s still around and helping me learn.

Since then I have learned to calm down (on most days :P) . When I have an idea we want to implement on the website, I understand that once a sprint is set there is no chance it will be included in the current sprint. When I notice a problem on the website, instead of sending him a message I create an issue in JIRA and then we discuss it at the right time and place. When writing up a product requirement, I take into consideration how long something will take to be built, and write the requirement based on the basic necessity, rather than how I want it to look ( ex) Implementing check boxes into a profile instead of a sliding scale, because sliding scales are harder to build and will take 2x the engineering cycles + design, whereas a checkbox is easy to build, easy to fix, and requires little to no design).

I still struggle with this, but it’s been an incredible learning experience for understanding how to work with engineering teams and make their lives as easy as possible. For example, we are currently building out notifications on the website, which seemed like a relatively easy task. However when you eventually create 30 categories of notifications, things can get confusing quickly. At first I made a list of all the notifications I would like to see, but then was quickly corrected as this would be difficult for an engineer to understand. I then went back through to create a table that outlined dashboard vs. email notifications, what copywrite would needed to be in place for each, what design would be needed for all of them, and then prioritized just in case we couldn’t fit all of this into the current sprint. In retrospect this should have been taken care of before the current sprint, but hey we’re still learning!

While I have always known that there is a fundamental disconnect between technical and non-technical team members, I can now appreciate why I need to make an engineers life easier. At first there’s a mindset of, “I’m hiring this person to make my life easier”, but I’ve come to realize that it’s the exact opposite. There are 100’s of ways to build the exact same product requirement, and the more vague I am in my approach, the more is open for misinterpretation, which leads to lost engineering cycles and un-needed hotfixes. Now, my goal is to make the engineer’s requirements as specific and easy as possible to understand, so that they don’t have to be frustrated by my lack of understanding.

Going through this exercise has helped me a lot to not only be a better manager, but really understand how difficult it is to build great software. I used to look at a website and simply say to myself, “I want mine to look like that!”, not appreciating how many engineering cycles and how much product development it took to get the website to function like that. I used to go on a website and take for granted why that website is so well thought out. I used to think that everything on the internet was easy to build, and if I wanted something built similarly to something that already exists, I should be able to. I thought, “if it’s not an algorithm or machine learning it’s easy!”, and I now realize that I couldn’t have been more wrong.

I now understand (or am starting to understand), what it is like to be an engineer. Building software isn’t easy, and working with people like me who want to throw a million ideas and fixes at you every day only makes your life that much harder. Building a great product takes a lot of time, a lot of errors, and a tremendous amount of patience, and if you’re looking for a quick fix or a cheap website you’re in for a rude awakening.

I believe that every non-technical founder, or aspiring entrepreneur who has never built a product, should adopt this mindset of making the engineer’s life easier. If you are not empathetic to their needs and their style of communication, you will only be wasting your own money and time, all the while causing yourself frustration. It is important to think from the perspective of the developer, because if you don’t you’re going to be the one who loses out, and you won’t be able to build strong engineering teams.

Last but not least, this mindset of empathy is not only for engineers, I believe it’s applicable to every profession. Think about working with designers and asking them to design a logo. Think about working with a videographer and asking them to change the music once the video is entirely finished. When we work with someone from a profession that we have no understanding of, it’s easy to throw requests at them without understanding how difficult their job really is. By adopting a mindset of empathy, we first learn what it is like to be in their shoes, and then cater our requirements to their needs as a creator. Empathy comes first, business comes second.

In short, building software is hard, and it’s that much harder when the person on the other takes for granted how difficult the other person’s job is. If you want to work well with engineers, realize that no matter how small the task seems like it is, it’s probably more difficult than you realize. Take an approach of understanding their needs, make their lives as easy as possible, and try to put yourselves in their shoes. Do everything you can to learn more about development, and understand what a day in their life is really like. I have learned this the hard way and caused my engineers far too many headaches due to my own lack of understanding. I urge you to not do the same, and approach development with the perspective of Engineering Empathy

And developers, it wouldn’t hurt to clue us in from time to time to help bridge the gap a bit more