Technology companies are challenged to be adaptive and agile. But, is a traditional technology organization structure, with the CTO role at the helm, the best way to achieve these goals? I had the opportunity to talk with René Pfitzner, one of the founders of the startup Experify.io discuss his thoughts on this question.
Are you going to be in Zurich, Switzerland on Thursday, October 17, 2019? Join us for a fascinating TechDebate on this very topic. Click here to register for TechDebate – free to attend.
What are your thoughts on the CTO’s role and technology team structure in general?
RENÉ: The technology landscape has changed a great deal and it moves at a very rapid pace. From my experience, the CTO’s position very often seems to be a legacy role established when the technology landscape was very different.
When technology required enormous investments, and you were making decisions that would impact your organization for years to come, it was essential to have a considered and formal approach. But the entire technology landscape has radically changed, and we can move much faster without daunting investment and long-term consequences. For these reasons, there can be a lot of tension between today’s agile approaches and the measured, long-term decision making of years past.
Register today for TechDebates Zurich
If you have a classically trained CTO working with agile, adaptive, faster, product-centered professionals, there can be a lot of clashing.
The next generation of technology leaders is not afraid to change their complete infrastructure or technology stack if something better comes along. Additionally, these leaders understand that technology changes are much easier than they used to be. For example, I’ve seen people change production systems from their on-premise hosting to a public cloud solution – like Google or Azure—within a few weeks. This kind of dramatic change was unthinkable not so long ago. With modern technology, you are super flexible. These two different velocities in the industry are at odds with one another, but in the end, the faster approach will win in most cases.
The other thing that is changing is the structure of technology teams. Traditionally technology development teams were segregated by function. One team would research and develop, the product team would determine which features are needed, then a development team would take it from there.
Many startups, as well as larger companies, are adopting a different model that is much more self-contained. A team might consist of five to ten people who oversee a product from beginning to end, including research, product design, development, quality control, and product maintenance.
It is particularly interesting and valuable to me that these teams are charged with running and maintaining the product once it is in the market. I believe this structure helps the team to be much faster, as well as responsible for building quality into the product from the very beginning.
Moving back to the CTO question, I think the CTO’s role might not be the right role anymore. For many companies, I believe a chief product officer (CPO) will take over many of the traditional CTO responsibilities, but move faster with an intense end product focus. I would say that this is especially true of companies using technology, as opposed to companies that are in the business of building technologies.
As a company founder, what are the most challenging issues you are facing?
RENÉ: As I said, we are a startup. Our next hire will most likely be a technical person. However, we will not be looking for someone with deep technical depth in one area. Instead, someone who knows many other technology professionals because of a lack of ability to secure the skills you need for a given project is the bottleneck. We will need this new hire to connect us to the developers we need, and many of them, at least for now, will work on a freelance basis.
What do you think of the concept of building an adaptive organization?
RENÉ: I think one of the things helping us to be much more adaptive is the way we are developing software. In general, modern technology companies have moved away from building huge chunks of monolithic software. Now, we increasingly build microservices. The beauty of microservices is that you don’t end up with large amounts of tech debt as you do working within monolithic approaches.
Microservices allow you to put the pieces together as you need to and change the technology approach on one of the pieces without impacting the entire product. Microservices are also very helpful from a talent acquisition standpoint. There is often more than one way to accomplish a goal, so you can hire people without being extremely beholden to one approach or programming language. In my view, this is an important way of being adaptive and agile.
Microservices allow you to avoid having to have a crystal ball trying to predict what you will need. You can react very quickly once the need arises. Clearly, microservices are not for every use case, but many can benefit from this approach.
Are there issues with microservices being incompatible with one another?
RENÉ: If you’re doing it right, you are designing the infrastructure in a way that allows all services to communicate with one another using, for example, a well-defined and standardized RESTful API. So, it doesn’t matter which language you write the actual service in. If the microservices are developed with a common standard, the pieces will be able to talk with one another.
Sphere Software (https://sphereinc.com), is the sponsor and organizer of Techdebates.org and also finds great value in these follow-up discussions with industry experts. Sphere is a technology consulting and solutions company. Everything we do is designed to accelerate your business, remove technical constraints and eliminate staffing bottlenecks.
