Lost in Translation: Why Business Doesn’t Understand Tech (and Vice Versa).
Working in tech companies is my passion. It’s a fast-paced environment where you never stop learning and where you deal with exciting people from all over the globe. But sometimes, it can be a challenge and even frustrating. The CEO wants to deliver, convince his investors, win customers, have a great culture and, of course, be faster than the competition. The tech staff wants one thing above all: a great product.
In theory, they both want the same thing. But it’s still something different. So what are the reasons why business and tech get along so badly? Why do we need a tech lead who does one thing above all: translate? Stephan Bachofen, a seasoned CTO and tech adviser, and I decided to partner up on this one and answer some of the most crucial questions both sides have.
Stephan: You worked as CEO in different tech companies. Did you ever experience a challenge communicating with engineers?
Boris: Admittedly, I have quite regularly experienced a communication gap in the companies I founded or worked at as a CEO. However, I somehow managed to teach myself to communicate with engineers and — more importantly — to respect their opinion. Especially when it comes to timings and all the things I don’t know about. Don’t get me wrong. I love to work in a tech environment, and I love to work with engineers, data magicians, QA, and a CTO. BUT: Such a collaboration works based on trust only, and as a CEO, you’re trained to reduce uncertainties to a minimum. How can this work best, Stephan?
By listening and respecting our opinion. Allowing for experiment and failure makes it a safe place to work.
Stephan: By listening and respecting our opinion. Allowing for experiment and failure makes it a safe place to work. It means you learn early when problems arise. If we have agreed and aligned clear, prioritized, and measurable goals (OKRs!), we have retros you attend, you look at our frequent deliveries, and also try to accommodate our best practices…trust and relatively timely delivery of agreed features should be the result of that.
Boris: I’ve always experienced accurate timing as the most significant issue. You need to know when you release something since your marketing team is waiting or you’re running out of funds. Why is it so hard to estimate a project?
In short: A software project is always unique. You implement something nobody has ever done before.
Stephan: It’s not only hard. It’s close to impossible to estimate. We keep asking for it, we keep doing it, and we keep failing. I like to point out two sources I’m aware of that explain it more elaborately and more eloquently than I can:
1) the book “Facts and Fallacies of Software Engineering” by Robert L. Glass and
2) the presentation “The Psychology of Estimating” by Joseph Pelrine.
If Joseph wrote a blog about this to spread the knowledge even further, it would benefit all of us. In short: A software project is always unique. You implement something nobody has ever done before. Experts bring their own bias from the past, but not the exact same experience as this new challenge specifically requires. The situation is different, the requirements are different, the team is different, and the technology stack is not exactly the same anymore. Then there is a psychological dynamic based on pressure and wishful thinking.
I guess that doesn’t help you with your marketing people sitting-on-the-fence-and-waiting-for-us-engineers-to-deliver-problem?
Boris: Nope!
Stephan: I thought so. But I’m glad you’re still listening. There are other ways to bring predictability into delivery — instead of estimating — and to ultimately help you with your planning. Focus on the value creation process and the team. Protect the team from distractions, and ensure plenty of flow moments. Have strong QA. Align the whole team on the priority. KISS — keep it simple and stupid. Make sure emotional safety is provided. Foster a learning organization. Don’t optimize for per developer cost. Paying a factor 10 better developer double the average is excellent value for you.
Boris: Stephan, have you ever heard something like: “Why does it always take so long? It’s just an app, right?” or “Why do we need so many engineers? It’s still just an app.” What’s your reaction?
Stephan: Oh yes, many times. Someone not familiar with tech looks at the tip of the iceberg and doesn’t see how much ice is needed below to make it float like this. An app has quickly reached a complexity of hundreds of functions and still growing quickly while the resulting complexity might even grow exponentially. Every little function has to be translated from a wish into crystal clear, minutely detailed instructions for a very rigid working machine. And not only the happy path needs to be thought of. Also, a plethora of ways that things could go wrong has to be thought of too. Later, when the app is released, it is used in ways nobody imagined, new needs arise, and bugs need fixing while adding new features. In addition to that, the whole infrastructure the app depends on keeps moving and changing at an ever-increasing speed and requires adaptation.
Boris: This is great. I have more quotes for you: “We have so many engineers — why do they still produce bugs?” or “WTF? Why do we need a QA team? Can’t you guys write proper code?”
Stephan: The reasons that you’re not happy with the quality could be manifold. But first about the QAs: QAs are trained to find bugs. But not only that. A QA will write you a test plan. This brings rigor into testing. Then, every feature has likely a handful of tests. Not only to make sure it works but that it also fails gracefully when something unexpected, often not specified, happens. QAs are also savvy in using tools to automate these tests. Automated tests allow you to release often without a hefty cost tag attached. This addresses regressions. It’s unfortunately not so rare that a code change affects other, not obviously related functionality at another place in the code. A QA also verifies that the requirement was implemented as intended. An additional pair of eyes to check it’s done as intended is best practice. We apply this in other areas as well. Signature in two, audit, proofread an article before publishing, etc. If you still have too many bugs: Were the timelines realistic? Are the specifications good? Can the developers work uninterrupted? Do you have too much technical depth in critical components?
Boris: What would be your best advice when hiring engineers?
Stephan: To attract them in the first place? Have demonstratively excellent and suitable work conditions, including office, equipment, and great work culture. A-players want to keep learning, involve themselves, and have a purpose. For screening: Look for attitude and transferable skills. Work with them to solve a concrete problem.
Boris: What’s the secret sauce of a successful tech company?
Good leadership! Perhaps, there is even less tolerance for bad or mediocre leadership to achieve excellent, sustainable, and cost-efficient results than in other companies and sectors — a good team with no egos.
Stephan: Good leadership! Perhaps, there is even less tolerance for bad or mediocre leadership to achieve excellent, sustainable, and cost-efficient results than in other companies and sectors — a good team with no egos. Allow the tech team to meet you on eye level, also in regards to designing the organization. Make sure you have the critical technical knowledge in-house. Keep the product simple. Have a clear priority.
Alright Boris, here is one for you. Why does the sales department sell our prototype? It’s not production-ready. It was an experiment; we hacked it together to prove it’s doable and get feedback from marketing, sales, investors, and users. Now I keep getting bug reports to fix.
Boris: Oh yes. Sounds familiar. There is a blurry line between prototype and production-ready, right? What we internally consider as a prototype or MVP might be a valuable and final product for a customer. AND DID YOU REALLY SAY “IT’S JUST A PROTOTYPE”??? I’m just kidding. However, reporting bugs is not wrong, and it’s more about how it’s being done. Suppose you’re aware that minor bugs don’t matter at this stage, then put them somewhere in the backlog. I agree that it is a pain in the neck when the marketing department or an investor insists on fixing what bothers them personally immediately. At this early, experimental stage, it’s all about learning how to improve the product to fit the customer’s needs.
Stephan: When I read what marketing writes about the product I built, I hardly recognize it anymore. I have to admit, sometimes I don’t even understand the value proposition anymore, and I’ve read every single requirement and had to understand it. The essence is lost somewhere. Why is that? How can we avoid that from happening?
I’ve seen many companies where the different departments and individuals have different views on the value a product delivers. When you hear them explain, you think they are talking about different products.
Boris: Excellent question! Honestly, I think the value proposition topic is a challenge. I’m using experimental approaches to test the value proposition. That means the version that creates the most demand wins, and that can lead to a different result than expected depending on the customer’s perception. But I think the issue lies more in not understanding a value proposition and trying to be overly creative. I’ve seen many companies where the different departments and individuals have different views on the value a product delivers. When you hear them explain, you think they are talking about different products. It’s crucial to train the team and align on what the product is about.
Stephan: Do you think it would make sense if the first salesperson in a tech startup needs to spend a bit more time with us, the tech team? Perhaps even adapt to our rigorous processes instead of maximizing their time on the road selling it? A less traditional salesperson first? Would you allow that?
Boris: Well, I think a tech product company should be built around the core, which is the tech and product team. A salesperson is a direct link to the customer, and the information must flow back and forth. So to answer your question: YES! The team needs a common ground. BUT: It can go too far. Salespeople are a bit different, but for marketing creatives for example it’s not always helpful to mind every single thing that happens in development. After all, users in most cases will also be aware of very little technical background and communications should mostly excite them about benefits.
Stephan: One question I ask myself often is, how early should a tech company onboard a product manager? What do you think of getting the product manager almost simultaneously or shortly after the CTO (once the prototype is done) and later the rest like marketing, sales, etc.?
Boris: In theory, yes. But there are usually limits. I assume you talk about a startup, right? In that case, you need to choose wisely whom to hire first. I like the strategic approach, defining the goals first and then the necessary internal competencies. That means if you want to reach a certain goal in a certain amount of time you need to build certain competencies to get there. In the case of a tech company, the essential competency would be understanding customers’ needs and implementing them. Whose role is this? Actually…sorry, Stephan, but I would even hire a product manager before the CTO — or have a technical co-founder.
Stephan: OK. While we are here: Do we need a CFO at this point already? They’re expensive, and I could use that money to build things.
Boris: No, I don’t think you need a CFO initially. This is usually a later hire when the company gets more mature. I like to work with CFOs, though, since I’m bad with numbers. It’s not that I can’t calculate, but as a CEO, you need to be optimistic and constantly sell the idea, service, or product to everybody. Motivate the team, and so forth. A CFO plays the opposite role in terms of numbers, and you usually meet somewhere in the middle. But this would be a whole other conversation…
