Men are from Mars, Women are from Venus.
You’ve no doubt heard of this best-selling book that first hit newsstands back in 1992. Since then, it not only went on to sell millions of copies worldwide, it also became a punchline whenever someone wanted to explain away differences between two groups of people.
For example, CEOs are from Mars, technical leaders are from Venus.
I’ve been the technical leader for Modularis since 1999, and in that time, one of the most common and contentious issues I’ve dealt with is helping CEOs and technical leaders understand how the other approaches risk when it comes to undertaking new software R&D efforts.
The former (and I’m generalizing here) tends to think the latter never takes risk into consideration as they’re plotting out a new giant undertaking. This is hugely offensive to us technical leaders, because the truth is, we most certainly are considering risk. We’re just doing it from a technical perspective.
Because we’re from Venus — and we think differently.
What effective technical leaders need to prevent poor communication
Where the breakdown in communication stems from (again, I’m generalizing here) is that effective technical leaders really need two things:
- A good deal of expertise (someone who’s been through a few rodeos in their time)
- Clear direction from the CEO or business leader about their needs
Expertise is critical in these situations because only an experienced technical leader can construct complex solutions that adequately weigh both the financial and business risks. They’ve been down these roads before and know what questions to ask.
So what are those questions? I’m glad you asked!
In the spirit of building bridges between two giant entities (remember, one is from Mars and the other is from Venus), here are several scenarios the business leaders may pose to the technology team that require deeper conversation and clear expectations as it relates to upgrading technology. Thoughtful deliberation is key to ensuring shortsighted decisions are not made by either party.
Scenario #1
CEO says:
We’ve promised the board we’d deliver this project on time!
Technical leader thinks:
If the project has a FIRM deadline, then we should use technology our team is well versed in, so they can build quickly and efficiently. Also, we have to carefully limit and control scope so we aren’t forced to take shortcuts and compromise quality, stability, or scalability. After all, everyone knows (right?) that you either pay now or pay later. Meaning we either do it right in the first place and pay the cost in time and money to do so, or pay a lot more later when (not if!) the sh** hits the fan. Things can break when hastily deployed to customers, and then we’re scrambling to fix, band-aid, or work around the shortcuts we took to hit the damn deadline—shortcuts we knew we shouldn’t be taking in the first place. What we dread more than anything is the prospect of having to rebuild the solution, and our own (or our company’s) reputation.
Scenario #2
CEO says:
We’re moving to the cloud! It will be cheaper.
Technical leader thinks:
If we’re moving to the cloud, are there specific technology upgrades we need to make first in order to even run our software on the cloud platform? If so, there will need to be budget and timeline adjustments in place to deal with any dependencies that may exist in order to move to the cloud.
Also, how does my CEO think this will be cheaper? It may not be as cost effective as promised if we have inefficient processes or data access patterns to account for. Remember, when dealing with the cloud, you pay per transaction…that may not work in our favor.
And lastly, does my team even have the skill set to build software in the cloud? If they don’t understand how to build in the cloud environment, software development could take much longer and require more time in QA due to the learning curve.
Scenario #3
CEO says:
We need to shore up security on our app!
Technical leader thinks:
Security is one of the main selling points for modernizing our software or ripping out old tech to replace with new. In upgraded technology, security is meant to be better because the developers have learned about breaches and fixed them in the new version. But, do those security upgrades outweigh the cost of upgrading our entire system? The cost benefit may not be in the best interest of our company and there may be other ways to address security concerns (such as WAFs) that don’t require refactoring large amounts of code. Another critical consideration is how much of the existing code will not be supported in the new version? This could cost us more time and money in rebuilding existing features, because while the security is better, the code for features is not supported.
Scenario #4
CEO says:
Our app is performing poorly – we need to fix that!
Technical leader thinks:
Improved performance is almost always promised by platform providers and technology developers. I’ve been to conferences where they promise faster loading and fewer system down situations. All their marketing says, “If you upgrade, you’ll see better performance!” But, sadly, that isn’t always the case. In order to truly answer this question, we need to take a deep dive into the architecture and evaluate which areas of the app will be improved and which others will perform worse (yes, this actually happens quite often) because of things like increased database calls. This isn’t so cut and dry and the grass is not always greener on the other side.
Scenario #5
CEO says:
We have too many bugs in our software; our clients are complaining that nothing works!
Technical leader thinks:
I tried to tell you — we can’t just rush things to market without paying the piper! I’d rather make sure that we build the quality in rather than test it in, especially if that testing is done by our customers. That said, you know that there will always be bugs — we can’t aim for perfection because there’s no such thing. What we need to do is to put in place a sustainable develop-deploy-refine process, improve the accuracy of our estimates, and build a culture of ownership in our engineering team. Finally, will you please stop giving customers hard dates without talking to me first!
Obviously, this isn’t an exhaustive list of scenarios — these are merely the most common I’ve encountered over the last few years. But as the investor or leader of your software company, it’s important to provide your technical leader with the proper needs and constraints so you can achieve more together.
But, it’s also important to understand how your technical leader is approaching these challenges. There is an extensive decision tree growing in his or her brain to help you win. Unlocking those thoughts and bringing them into the open will give you more information to make better decisions for success.
After all, we are from Venus.
Get our Technology Decision Worksheet
(Free Download – No Email Required!)
