When I formed my last startup with two non-tech founders here in Barcelona I pitched myself as a “developer who can translate complex tech concepts into English”. At the time (6 years ago) I was pretty proud of this ability to serve as what we would probably call a “technical translator”.

I was probably like this because my father was an electronic engineer and when I was young tried to teach me. He wasn’t good at it and I’d get lost when he’d try to talk to me about components, fault-finding on circuit boards or even the basics of what voltage, current, resistance, capacitance, impedance meant. I just assumed I was stupid but it’s really not uncommon to run into bright people who are very poor at communicating what it is they see in their mind.

This left me with great empathy for non-technical people trying to participate in the decision making around a technical project. I always anthropomorphised technology, used metaphors and simple analogies that were maybe bordering on condescending but always effectively communicated how something was working. I do believe that if you’re a founder in a company you have the right to weigh in on where the product + the tech goes. The trap you can fall into when being the teacher is to become a provider of solutions for all ideas without actually pushing back. If you’re purely a technical translator you’re removing your experiences, opinions and gut feelings about how to tackle different problems and becoming an oracle between non-technical people and tech!

I think as a technical cofounder there’s 3 skill levels to effectively communicating:

Level 1: Communicating “difficulty”

The founder we elected CEO had a sort of pushy sales type profile. In the early days he would saunter over, phone in hand and ask me “how hard would it be to do X?”

This question was the bane of my existence.

The reason is the answer is always the same. Adding a text label, button, changing UI or adding a field to a DB/serving in via API/displaying it on a web or mobile app is not hard. But you might find yourself being goaded into delivering something that’s super low impact (“if it’s so easy, you can bang it out this sprint right? 😜”) I’ll spare you the product management rants on value vs complexity but it’s important to communicate early and often that it’s not about whether the feature is “hard” to implement or not, it’s whether it deserves to be in there and how much it contributes to the future complexity of the thing you’re implementing. If you imagine your small, bootstrapped product as a cramped apartment — how much complexity do you add to your cleaning schedule by adding another plant in the corner or another unit of shelves. Early days each feature needs to fight for its existence — push back and get a firm justification for the feature. Also, catalogue the existing features and the amount of time it takes to test them on each release. What feature would you remove to add this feature? That’s the killer question as it really puts it all in perspective.

Side note: try to hire a PM or cofounder with an experienced product person. ☺️

So if we want to add a feature, piece of functionality or some type of complexity to the product — does that affect our ability to iterate in the future at the same pace? Does it make our existing setup more error-prone? Can something go wrong? Next level

Level 2: Communicating risk

So going back to my original point about being a translator. I was rarely proactively suggesting product features or steering the ship technically, I was usually reacting: responding to ideas, feature requests and data admin type issues in my last startup in the early days. This isn’t a bad thing in and of itself, but it’s a defensive game instead of an offensive game. If you’re sitting in this position in the cofounding team you’re providing almost 0 creative value to the product. It’s good to be aggressive about defending the simplicity of your technical setup in the early days so you can keep iterating quickly, discarding what doesn’t work and doubling down on what does.

I was probably too empathetic and too agreeable in that startup I referenced. They would suggest a feature they were enticed by (usually with no data — we were novice founders btw learning on the job) and I would act as the facilitator for my cofounders; giving them a scenario A, B and C for how to implement the idea. This kind of “nice guy” problem solver attitude meant zero negotiating on the degree of complexity that we would introduce to the system (e.g. how much technical debt we’d incur to get to market quickly with the feature).

What I’ve learned after years of this is that it’s simply not enough to be a technical translator. You need to paint a picture of the future. You need to project how you see the feature/idea/concept/whatever impacting the product. How much does it slow things down (through testing on each release for example? How much does it cost to maintain? How easily can we remove it if it’s not successful? What’s the likelihood it could break in production? What’s the big picture — do we even use this thing in 2 years?

You need to become a “tech savvy-communicator”. Part of that is learning how to sell, otherwise you’ll get run over by a pushy salesperson who’s non-technical. Why? They don’t really care about complexity, responsibility, testing, etc — they just want the thing in the product and want to see if it has any impact. Which is fair enough by the way, as a cofounder you probably feel the same. That’s the tough bit about bootstrapping as a technical person — you’re constantly doing stuff that’s absolutely silly to try to get more traction/improve the product but your setup can get extremely messy. You need to communicate this somehow to your founders also.

Level 3: Communicating vision

In the same way that a good founder sells a vision of a product you need to sell a vision of a way of working both internally and with end users. Low friction, low risk and predictable changes. Doing less but doing it well. Anything that threatens this way of working is introducing risk. It’s not about winning the debate of adding a feature or not, it’s about evangelising for a smooth/professional way of working.