The CTO Journey: Ryan Roemer of Formidable

When did you first fall in love with tech? And how did you get into tech as a career?

Oddly enough, I never really expected to get into technology and fell into it more accidentally than anything.

After spending a lot of time doing policy debate in high school, I pretty much always expected to become an attorney. I was well on my way to a Political Science degree in my sophomore year of undergrad, when I noticed many of my friends taking the introductory Computer Science series, and decided to take it as well. I took the series and liked it so much that I decided to get a minor in CS.

As fate would have it, I graduated in 1999, the height of the dotcom boom. I decided to try out being a software engineer for a year or so, while I applied to law school, in case I didn't like programming. As it turned out, I loved software development and figured I had found my fit! But then, 2000 rolled around with the dotcom bust, signalling bad times ahead. And, the timing of the bust coincided with my law school acceptances. So, I decided to jump to law school and try out technology law.

I became an IP attorney at a large law firm, working on a lot of different software matters. And while there are certain aspects of the law that I still find fascinating, I realized that I really wanted to be doing what my clients were doing — building amazing new software. After a bit of soul searching, I went back to school to get a grad degree in CS, and then made the full switch to software development.

Since then, I've worked in big (Microsoft's Azure Cloud Storage Group) and small (first engineering hire for a language-learning company) companies. And, even a patent data analytics startup! I've never really looked back. There certainly are challenges and lackluster elements of being a software engineer, but I get to help build things (in some fashion) every day.

The arch of finding my way to technology has had some benefits too. At Formidable, most of what I do as a CTO is the standard engineering stuff. But, as a co-founder, I have been on point for coordinating all legal matters / outside counsel for almost the entire ride. And, since Formidable has deep inroads in the open source community and most of our clients build applications leveraging open source, as an ex-IP attorney I'm often able to help our clients' legal teams navigate how to use or publish open source.

Transitioning to a Manager Role

Some people in our community are thinking about making the transition from a developer to a tech lead / engineering manager / CTO. But many are unsure if they should really make the switch to a more managerial role. Do you have any tips on how to answer the “is this right for me” question?

Folks looking at whether or not they should stay in an individual contributor capacity have several things to consider. The first one should be if your organization offers a full career path as an individual contributor — if not, you're really going to be balancing this decision not only substantively, but with a potential job switch as well.

Assuming you have the opportunity to pursue options like being a project tech lead, engineering manager or an organization lead, it comes down in large part to what types of challenges and projects excite you.

Does helping people progress in their career and find paths to shine excite you? Engineering manager might be a good fit. Does wrangling product owner visions and requirements, coordinating the engineering teams, and somehow making it all fit together into something that produces a real world application energize you? Then you might want to consider becoming a tech lead.

It really comes down to researching what the available non-IC positions entail day-to-day and figuring out if you want to trade off more traditional "coding" time to have a potentially larger effect than as just one person on an engineering team. There's no clear answer for any given person, or even at any given time — so it's important to keep an open mind and long view as to potential career focus switches as you go.

What do you consider the most challenging aspects of your role today?

Leading a consultancy, the most challenging aspect of my role is both following the technology trends and watching where things are headed next. We often encounter clients that have pre-existing technology constraints that our teams have to work within. And, other times, we are tasked with advising and guiding an entirely new technology stack for a project that will best fit the team for years to come.

Even within Formidable's history, we were originally a Backbone.js shop, and now most of the frontend and mobile applications we develop are React-based.

So, this means a constant evaluation and review of technologies on our projects — both in terms of purely technological match for the application and the specific capabilities of our clients to take over and own projects long term. We must consider the magic mix of technology, people, and time.

Some examples of decisions our tech leads make in our projects include: monorepo vs many repositories, functions-as-a-service vs containers, which CI/CD pipeline to choose, TypeScript vs. plain JavaScript. The answer to these (and other) debates is usually "it depends," and an answer at one point in time may differ later.

At Formidable, our project tech leads make these decisions and evaluations all the time (particularly at the beginning of a project). We have a technology steering group to monitor and evaluate what new technologies and trends we should keep on our radar. And we have a healthy environment of cross-project communication, discussion, and knowledge sharing.

Should a CTO Still Code?

Sometimes, there’s a debate about whether a CTO / Tech Lead should still actively develop code. What’s your take on this? Must or can a CTO still reserve some time to code?

It's a really tough issue as you get higher up in a technology organization. I think, fundamentally, a CTO / Tech Lead does not need to actively develop code, but it really helps if you can, and in its absence you need to keep pace with the technologies and directions.

A CTO must be broad and support the organization as a whole. That means that I'm available for architecture guidance for the types of applications and services that Formidable writes. I lead a technology team that forecasts what the future holds for our applications and what education areas the company broadly needs. For example, as we continued to find that our customers for React and GraphQL applications needed expert-level support for taking those apps to the cloud, we grew a bespoke cloud infrastructure practice that focuses intensely in that area.

The trade off with this somewhat mandatory broad function of a CTO/Tech Lead is that I've personally had to make deliberate choices as to what I can actually dive into. And, it's a bit different as the CTO of a consultancy, where we need to support lots of technologies across all our client stacks vs. the CTO of a product company, where you are setting the technology vision and mandate for a singular endeavor.

For me, the best value I've found is focusing on the boring, non-application-specific things that block many engineers in our client projects. This sometimes means wrangling with webpack on the frontend (where I actively develop tools like inspectpack and the webpack-stats-plugin). Other times, it's handling packaging for serverless applications (where I've written tools like serverless-jetpack and trace-pkg). Neither of these are the core "application development" that Formidable does, but they are both areas that require deep expertise for outsized gains and can crush a project if not done correctly.

On the other hand, of course, not every developer wants to transition into a management role! For those that want to keep developing software: is there any piece of advice you find yourself giving often to the developers on your team?

For folks who want to be an individual contributor for the long haul, I think it's important to look at, and continually reexamine, what challenges you want to tackle and how you can continue to grow and enjoy software development.

For some folks that might mean going deep into an area of expertise. For others, that might be trying to push the envelope and explore new and promising technologies, and get behind projects with a greater risk + reward profile technologically.

Non-technical Skills Required

Producing code is only one part of the craft of software development. What non-technical skills should a software engineer develop?

Hands down, writing. Most of our communication as engineers is written. Our project plans, code documentation, and even the code itself is ultimately a written expression that is often written just a few times, but will be read and consumed by several orders of magnitude more folks and times thereafter.

It is worth taking the time to become a better writer straight up — blog posts and articles can truly enhance your career and provide enormous value to the community. Well-written code and documentation is often the difference between a project or application that languishes fast one or two years in vs. something that endures and is re-invested into over time.

It’s not a secret that developing software is a team sport. What traits, skills, and habits should an engineering team focus on to become a world class team - and not just a bunch of talented individuals?

Looking beyond pure engineering talent, the most critical skills I see are (1) people skills and (2) being able to focus on and solve problems efficiently.

On the people-side of things, software is built by people — often lots of them, with different roles and motivations, and not always perfectly coordinated. The most impactful engineers I've seen are those that can help coordinate the various people involved in a project and get applications shipped with the right balance of inputs and tradeoffs.

The other critical skill I see is engineers being able to tackle discreet problems (especially large ones) in a manner that gets the job done correctly and with the proper amount of effort. It's often really hard for engineers (me included!) to not go off the deep end on some problems to try and exhaustively solve everything around a problem. The most talented engineers I know spend a lot of time critically examining tasks and problems before planning a succinct solution, and then only turning to actually code something up thereafter.

Exciting New Technologies

Today’s tech world is brimming with new technologies. Is there any technology or recent development that you’re particularly excited about? Why?

At a consultancy, we get to work with a lot of different organizations and experiment with a great number of different technologies in the aggregate. For the most part we work in the frontend + backend + mobile JavaScript application and cloud infrastructure spaces, where there continues to be a steady flow of new technologies and innovation.

The thing I'm most excited about in our area for the near future is the Rust programming language. Rust is a modern compiled language with a wonderful memory management model. As someone who learned to program in C/C+, I love the opportunity to have the speed of a C program without the risk and hassle of completely manual memory management.

Rust is exciting in several areas for what we do at Formidable. It's a great backend server language (and already is growing in popularity for GraphQL servers). It compiles to WebAssembly that can be used in the browser or on cloud platforms (like Cloudflare Workers). And, it's becoming a strong contender for building JavaScript application tooling (e.g., the Rome JavaScript build toolkit is being rewritten in Rust).

About Ryan Roemer

Ryan Roemer is the CTO and co-founder of Formidable. He architects full-stack web applications, backend services and APIs, and highly available cloud infrastructures. Ryan leads development groups from small startups all the way up to Fortune 500 engineering teams. He advises clients on issues ranging from technology evaluation and engineering organizational structures to successfully leveraging open source software.

Prior to Formidable, Ryan's work has explored most levels of the modern application stack, including backend services enhancements for Microsoft Azure's Cloud Computing/Storage platform, wrangling large-scale data mining at IP Street, and directing development from scratch on a new language learning product at Curiosity Media.

Outside of engineering, Ryan enjoys trail running, cycling, triathlons, and Type II Fun in general. He is a registered patent attorney (inactive), and although he keeps a close eye on open source legal issues, it has been a long time since he has put on his lawyer hat. Ryan holds degrees from Stanford, UCLA, and UC San Diego.

Formidable is experiencing an exciting and sizable growth spurt, adding employees in multiple locations including North America, UK, and many European locations. Their remote-first approach lends itself to a flexible and balanced work culture. Formidable is seeking candidates to join them in engineering, product management, and business development. Applications are strongly encouraged at boards.greenhouse.io/formidable

Looking for a Git client? Download our 30-day free trial and take it for a spin!

PS: Did you know? Tower Pro is now free for students as well as teachers and educational institutions!