Ed Gonen, a Chief Technology Officer @ 28software: “I’m convinced that we are on the brink of the next scientific revolution by a magnitude similar to what we know happened in science and culture slightly more than 100 years ago.”

We met up and had a conversation with Ed Gonen, who’s the Chief Technology Officer at 28software. He’s been working in the high-tech field for many years and in this exclusive interview, Ed shares his insights into the future of software development. He elaborates on the challenges of architecture development and the complexities of hiring multi-disciplinary development teams.

— Your initial education includes Computer Science and Nuclear Physics. You did work as a rocket engineer in the 1980s! This is incredible! How did your journey take you to the role of a CTO? I mean, transitioning from a nuclear scientist to a software engineer and eventually becoming a Chief Technology Officer. That’s the path!

Ed Gonen: Yes, it’s been quite a long path. My career as a scientist began in the middle of the 80s. Being an MSc graduate of the Nuclear Physics department with experience in computers I have found myself in a position of researcher engineer at my alma mater. I was surprised to find out that my laboratory dealt with the modeling and development of new components in the production of solid rocket propellants. As you may guess, the solid rocket propellant’s main goal is to burn and burn very fast. Hence, in order to study the process you need something significantly faster than the traditional equipment, i. e. a computer.

In the late 80s, I decided to leave the Soviet Union and move to the Holy Land, where I continued as a software engineer which in a few years brought me to my first CTO position. So here is the line from a nuclear physicist, via rocket scientist, into software developer and later CTO.

— And how did the software development market differ in the earlier stages of your career?

Ed Gonen: I was very lucky to be with the companies that shaped the market. In general, the two last decades of the 20th century were extremely exciting. Almost everything I had a chance to work on could be labeled “the world’s first”. To name a few — network switches, routers, remote access software, distributed networks, Internet security, Web collaboration, new protocols, languages, operating systems, and much more. We closely cooperated with such companies as Microsoft, Cisco, IBM, Sun Microsystems, and many more. Some of them ceased to exist.

— As a CTO with extensive experience, you’ve had the opportunity to work in various countries, each with its unique mentalities, geographies, and a range of companies, from startups to large corporations. Considering your wealth of experience, what observations can you share about the evolution of the software development industry over the years?

Ed Gonen: It is a very interesting question. When looking at the evolution of the software development industry I can see several threads:

a: Software development has become so much easier than in the past. The huge amount of open-source software, libraries, components, programming languages, and frameworks has made the life of a software developer a joy.

Imagine what a challenge it was to a software developer in the 80s or even early 90s to write a real-time image recognition application in assembly language. Or Apollo’s software development. And we did that. And it worked! Without Git, visual debuggers, IDE. And even in the first C, Pascal compilers, the data structures should have been developed by the programmers themselves. Can you imagine that? Lists, queues, threads, GUI elements, semaphores, trees. Not to mention classes and objects – everything had to be done manually. As far as I remember my first experience with built-in classes was with C++ in the early 90s. What a joy and relief that was.

b: The modern software developers market is filled with a lot of new self-taught individuals who lack the culture of industrial software development. Just don’t get me wrong. I’m not labeling this as bad or good. It is just what it is. Nevertheless, I think the right education in computer science is a must for a software engineer and it has, sadly, been overlooked. Such classical books as D. E. Knuth’s The Art of Computer Programming or E.W. Dijkstra’s Co-operating Sequential Processes today may be more important than in the past. But who reads them nowadays?

— Why do you think it’s important to read the works of D. E. Knuth and E. W. Dijkstra?

Ed Gonen: In the past, people professionally employed in software development possessed some kind of academic degree like Applied Mathematics, Physics, or Computer Science. Such a degree involved a formal education in the said area. Nowadays, a person can become a software developer self-taught. I have no doubts about the talents of such a person but formal knowledge is a mandatory basis for all fields, and Software Development is not an exception. The formal knowledge is based on well-known and widely accepted authorities. The cover of the third edition of Volume 1 features a quote from Bill Gates: “If you think you’re a really good programmer… read (Knuth’s) Art of Computer Programming… You should definitely send me a résumé if you can read the whole thing.” The New York Times referred to it as “the profession’s defining treatise”.

— How do you envision the future of the software development industry?

Ed Gonen: I guess, a few years ago it was easy to answer — new programming languages, faster computers, more storage, smaller form factors, etc. Today it is even easier — AI and Quantum computers. AI will and already has changed the face of this industry. A huge amount of non-creative work will be handled by AI. And this is great. I’ve been using LLM (large language model) for a while now and can testify that with every month it becomes more and more useful. Many positions in software development will cease to exist. But this will not happen tomorrow. Maybe a day after.

In general, I’m convinced that we are on the brink of the next scientific revolution by a magnitude similar to what we know happened in science and culture slightly more than 100 years ago. Then it happened again in the 50-60s.

I strongly believe that all those world perturbations we witness today are a prelude to that. It is impossible to predict what huge breakthroughs we will see soon. But it will be grandiose.

— I guess many startup entrepreneurs come to you for advice on the technical side of their businesses. What is the first step in developing the tech product? What do you do initially?

Ed Gonen: It might sound boring but the first step is the SWOT analysis (simply – analyze your strengths, weaknesses, opportunities, and threats). Then monetization — how you are going to make money. And then comes the time to build a development plan — architecture, team, milestones, prototypes, etc.

— What happens next after the architecture is developed? Team evaluation?

Ed Gonen: I would not jump over architecture development. Make sure that architecture is developed by someone who knows how to do that. You wouldn’t consider architecting a building yourself, would you? I know that I wouldn’t.

When developing your system architecture try to be modest and not develop everything from scratch with the idea that it will hold many years. Modern architecture goes very well along with existing infrastructure (Clouds, ready systems, etc.). There is no need to invent the wheel. The chances are that what you are trying to achieve already exists and at a reasonable price.

— Sounds very reasonable. What happens next?

Ed Gonen: That was the “what” question. Now about “who” and “how”. Here we come to the team selection. There are several options. Each one has its own benefits and deficiencies.

Let’s start with the fact that it is a challenge to hire a multi-disciplinary development team capable of bringing to life your product. It involves risks and costs a lot of time and effort which is directly translated into money. Also, another very important fact should be taken into consideration — having assembled a heap of great engineers and product managers does not mean you have the team. It takes years to build the right synergy and convert that heap into a dream team that is significantly more than just a sum of people.

Our aim is to significantly reduce if not completely eliminate, those obstacles along the way. I’m a big proponent of our model — you tell us what you want to do and we provide you with technological superiority. You can focus on what is really important — your business.

— What is a typical workflow you offer for both emerging and established companies?

Ed Gonen:

1. You prepare and share with us your business intentions and goals

2. We get back to you with a proposal that includes:

• Recommendations about system and software architecture.
• Engineering structure (appropriate engineering talents, groups, teams, management, quality assurance, design). This structure is highly scalable as we can make it grow along with your needs. And in case of a need it can shrink (this may happen in business) while preserving your core assets.
• Product management structure and the way it interacts with Engineering in the most Agile way.
• Initial work plan with milestones.

3. Upon fine-tuning the proposal and general acceptance, we negotiate the cost model. Even prior to the final agreement, we start:

• The onboarding process. The onboarding process usually means identifying a core team out of our existing engineers and adding more layers of talent around them from the huge pool of available resources.
• Work with your (or ours, if you prefer) business/product managers on the roadmap and training (when needed) using the best practices of interaction between business and engineering.

4. Once the agreement is greenlighted, we start immediately.

— To delve further into what you mentioned about workflow, could you elaborate on your engineering structure?

Ed Gonen: We believe to be the right engineering structure.

— By the right you mean…?

Ed Gonen: It is a hierarchical, transparent, scalable, and very efficient scheme proven by many years of experience. It is based on:

• Position – especially ‘who holds authority over whom” in the structure.
• Unity of command – each member of the hierarchy has one and only one superior, precluding the possibility of contradictory orders.
• Strict accountability – those who issue orders are responsible for the consequences, not those who carry them out.
• Strict escalation rules – complaints go up the hierarchy to those with the power to deal with them, not down to those who do not have that power.
• Detailed rules for decision-making – what criteria apply and when standardized processes.

Rules and standards, are usually enforced as early as recruiting and screening of candidates. This does not guarantee that your business succeeds (after all, it is a matter of your business idea, market, and not in a small part, luck) but makes sure the chances are dramatically higher.

— You’ve been an Agile consultant at large global companies like Marvell and Nokia-Siemens Networks. You’ve also developed and successfully implemented Agile methodology at Playtika, the globally recognized gaming company. You’ve implemented advanced software development methods for numerous, geographically separated locations across the globe. What’s the best thing about Agile in your opinion? And how can Agile be effectively implemented?

Ed Gonen: First of all, let’s remember that Agile (it has many flavors such as Scrum, XP, BDD, etc.) is not something that was suddenly invented. Many companies, organizations, and individuals had practiced those principles long before the world gave them their current names. Here is a list of benefits Agile brings when correctly implemented:

Streamline of interaction between the business and engineering. For most companies, this is a very painful point. In the majority of cases, engineering tends to affect business by imposing many constraints. This is a healthy process when it is kept under control. Engineering must do that. The problem arises when engineering imposes irrelevant constraints on business processes. Engineering must be an enabler and always remember that its purpose is to serve the business. Engineering does not exist (or at least cannot afford to exist) just for the sake of itself. This, initially fragile, business-engineering relationship should be established as soon as possible and enforced.

Predictability. Business hates uncertainty. The time of long huge projects in software development has passed but we still observe many cases of atavism. If you are interested in learning more about that, I can refer you to an excellent book by Fred Brooks The Mythical Man-Month published fifty years ago but still important today. The best way to achieve predictability is to split the project into small, controllable, verifiable, demonstrable steps. After each step’s completion, you assess where you are and how much is still to go. If you do that often enough, you can predict when you get to your goal as you know how much is ahead of you and your average speed of progress. Then you may update your initial estimations. Please note: this is not a remedy for a project to be completed on time with the initial scope and budget. It is a way to know where you are during the process and take the necessary steps.

Transparency. If business hates something more than uncertainty it is opacity. Opacity in engineering leads to suspicions, lack of trust, and mutual blame. Agile defines very clear two-way communication between business and engineering. Each party knows what the other does.

Development performance leap due to competitiveness. As all above, this is a huge issue to discuss and it, along with the others, deserves a separate interview.

I would finish this answer with the following statement. In contrast to many others, I strongly believe that Agile is first and foremost for business and product development. Thus, the success or failure of Agile in a company is entirely dependent on the management position. The shift should come from business management rather than from engineering. Otherwise, the chances of Agile success are quite low. I mean one can claim — we are Agile, but this is not what Agile is about.

— With all your experience, you’ve probably got some tricks up your sleeve for building tech teams and hiring new members with technical expertise. Do you think it makes a big difference if you’re building the team in-house or working with a remote team, like with the outstaffing or outsourcing model?

Ed Gonen: Yes. In the past two decades, my focus has primarily been on managing development projects distributed across the globe.
I’ve participated in development projects spanning across numerous countries (USA, Israel, France, Germany, Ukraine, Romania, Poland, Belarus, India, China, Argentina, and probably some more) and have a vast experience with that way of working that has become more and more common today.

There is definitely a difference between building an in-house team versus an outstaffed model. If I were to answer this question 20-25 years ago, I would definitely advocate the usage of your own dedicated team. Mostly because of the rarity of such a situation and the lack of infrastructure to support remote work. It is worth mentioning that an in-house team has its own benefits like sharing the same culture, mentality, time zone, and language.

Today all those benefits are outweighed by the benefits distributed development provides. It is important to mention that there is no inherent contradiction between the usage of an in-house team in combination with outstaffing. Actually, such a model may be very efficient. For instance, you may consider keeping your core assets within the in-house team while deploying contract-based development principles. If you are frantically concerned about your intellectual property, this is a perfect solution. You may also benefit from the “follow the sun” development approach.

On the other hand, distributed development has become today the mainstream. Just imagine the amount of engineers working together in the Open Source community. This is the best proof there is.

Working with the outstaffed teams among the other benefits opens you to an endless ocean of talents across the globe at a competitive price. But this ocean is also deep and dangerous. You might be tempted to build your team alone. Well, it is an option but a very risky and costly one. Just consider the overhead of effort and energy you need to invest, not to mention stability and confidence that your team will be there tomorrow. Therefore, in reality, there is no alternative to companies that provide you with the whole envelope. Essentially, you get peace of mind and can focus on your business rather than anything else.

— In your opinion, what defines a Chief Technology Officer with the necessary skills? What are the key competencies that a CTO should possess?

Ed Gonen: I would say it is a combination of experience and an everlasting thirst for knowledge – that is what defines a CTO. I would say that the key competencies that a CTO should possess are leadership, responsibility, and creativity. Not necessarily in that order.

— What advice would you give to a CTO who is just starting out in their established career? What hard and soft skills should they develop?

Ed Gonen: Well, if you are already in the CTO position you probably don’t need my advice, do you? I would only emphasize that among the CTO competencies I’ve mentioned earlier, the responsibility, i.e. ability to take a decision and be responsible for it — is probably the one you should cherish the most. I guess, you are all right with the remaining two, otherwise, you wouldn’t get such a position. If I were to add one more thing, it would be flexibility of opinion. The last thing you want to be is a stubborn engineer who is not ready to change her/his opinion without any reason. Being open to other points of view and ready to change is one of the virtues I have grown to appreciate over the years. And if you are a technological leader, it is of paramount importance.