Most tech companies accept that their Chief Sales Officer should still be good at sales and have closed deals recently. Same for Operations, Finance, and Risk officers‍—‌they should actively practice their craft.

But dare suggest the CTO should still write code? Controversial.

Here's why I think the conventional wisdom that CTOs should stop coding is wrong, and how engineering should actually be run.

What is Engineering?

Engineering is the practice of using natural science, mathematics, and the engineering design process[1] to solve problems within technology, increase efficiency and productivity, and improve systems. 

The word engineering is derived from the Latin ingenium. Engineers typically follow a code of ethics that favours honesty and integrity while being dedicated to public safety and welfare. Engineering tasks also involve finding optimal solutions based on constraints, with testing and simulations being used before production.

In my opinion, engineering requires building (not buying) technology to solve problems. Buying and using existing technology is, in my opinion, more properly called IT.

Why does any company need an Engineering department

Most companies, including Griffin, exist to solve customer problems in ways that create competitive advantage. For tech companies, that advantage comes from building technology that serves customers better, cheaper, or faster than what currently exists in market. If incumbents could buy existing technology to match your advantage, they would. Your engineering team exists to build what can't be bought.

At Griffin specifically, we're building banking infrastructure that moves as fast as fintechs need without compromising on compliance. That requires the kind of technology that’s built with a lot of context and nuance‍—‌it can’t just be gotten off-the-shelf.

Why not just use consultants?

For the same Theory of the Firm reasons that we don’t outsource sales, marketing, product, operations or risk: you need people who deeply understand your thesis, your customers, and your domain.

In banking, domain knowledge matters enormously. The people building the solution must understand not just what customers want, but why they'll pay for it, what regulations govern it, and how it fits into complex financial systems.

Contractors wouldn't have that context. You'd either get disconnected work or spend massive transaction costs keeping rotating contractors educated.

Also, someone still needs technical knowledge to evaluate whether contractors deliver good output in reasonable time for reasonable cost. Just like companies hire in-house general counsel to manage external lawyers, you need technical leaders to manage technical work. Civil engineers do the same for large-scale projects.

Taste is another factor. To build the best product, someone needs to know what best-in-class looks like for all the technology choices: API design, login flows, page load times, webhooks, etc. Non-technical users can be proficient at this, but it’s easier for engineers because it’s closer to their skillset.

## My job as CTO As CTO, I’m responsible for making sure we are delivering good solutions, in a good amount of time, for a good amount of money. To do that, I ensure that we are hiring good people, using good tools, and following good processes.

“Founder/CTO” is a slightly different job title than “employee CTO”. As founder, I stick my nose in a lot of other stuff including product strategy, marketing, pricing strategy, and customer experience, but let’s focus on pure engineering management for now.

The Engineering Manager's job

The same as the CTO, but scoped down to the team level. Day-to-day, EMs are responsible for keeping the team on track and working with Product to make sure the product design documents are good. EMs are also responsible for keeping the team’s code quality high by determining when a new feature’s quality bar is met and directing time allocation between new features and tech debt.

The big strategic levers EMs have are hiring and retention. It’s critical that good talent is hired, retained, and promoted while under-performers are managed out.

Why does this require getting your hands dirty?

How are you going to make sure the team is delivering good work, in a good amount of time for a good amount of money if you can’t observe their output with your own eyes?

The mainstream answer here is “I’ll just poll the team ICs and see what they say”. Bluntly, a person who does that is not in charge and is not responsible for their team’s output. At this point, the team is voting on who gets hired, promoted and fired, not the manager. It is good and encouraged to seek input from the other ICs on your team, but they can’t replace your judgement.

If the ICs are 100% responsible for voting and handling promotions and firings, what value does the EM bring? Polling is also a problem because if your team composition changes, your answers on who should get promoted and fired change. Maybe your ICs are biased against an unpopular IC. Maybe the traits they value are not the same as the traits you value. A leader should have an opinion on what ‘good’ looks like. As an EM, this is also a problem for you if your team is underperforming. If the team is underperforming and you don’t know how to fix it, you’re still getting held responsible, even though it wasn’t “your” decision on who to hire, promote or retain.

High-performing engineers can vary a lot on a number of productive traits: quantity of code produced, quality of code produced, quality of code reviews, quality of design docs, quality of bug reports, time spent in incidents, time spent helping customers, etc. Many of these are not easy for non-technical people to observe directly, but all are useful. Even more pernicious, some traits are easy for a non-engineer to observe. A non-technical manager who biases toward promoting ICs who are spending time on legible work but producing poor code will drive down the quality of the team.

Second, even though all are useful, certain teams need more of some skills than others. Some teams just need to ship a lot of medium-quality code quickly. Some teams need high-quality code and can’t afford production incidents. Some teams interact with customer engineers more directly. Some engineers are better at product work, and some are better at infrastructure or tooling. Knowing which traits your ICs excel at and what your team needs is important for building a high quality team.

What we expect from Engineering Managers

We expect EMs to have had successful careers as IC engineers. Today, every EM we have has been an IC engineer at Griffin. We expect that trend to continue, and we are biased towards converting Griffin ICs to EMs rather than hiring outside EMs. If we hire outside EMs, they need to pass the IC hiring bar, and work successfully as an IC for for part of their probation. This is more painful to hire, but results in better EMs because they understand how we like to work.

We expect EMs to remain technical. This means dedicating 10-20 hours per week writing code, debugging and participating in code review. EMs are not expected to write code that is on the critical path to shipping any feature with a due date. Their available time is too unpredictable, and in some weeks this won’t work out.

The reasoning here is that it forces EMs to experience IC life and pain day to day, and more directly observe who is having a positive impact, and who is not pulling their weight. It forces EMs to go through our processes (testing, code review, CI, deploy), and notice if any of them are too slow or cumbersome. ICs will respect EMs for remaining technical and for understanding how their job works.

The trade-offs

Smaller span of control: This puts a cap on the number of reports an EM can manage. The typical rule of thumb is that an EM can manage 8-10 direct reports. If EMs must remain technical, this probably puts a cap at around 5. In my opinion, that’s worthwhile if it improves team quality.

More management layers: The second, messier problem is that at scale, it probably increases the layers of engineering management. If EMs manage 8 ICs and the CTO has 8 reports, that’s 64 engineers before we need another layer. At 5x5, that’s 25 before adding a layer.

We don’t have a perfect answer for this problem yet. For directors (managers of EMs) and above, it probably means more reports with less 1:1 time. But we expect directors to remain technical, for all of the same reasons.

Is this right for every company?

If your competitive advantage isn't technical, you might make different choices. But for companies where engineering quality directly determines success, I think technical management is the way to go.

---

We're hiring

We're looking for engineers interested in working where technical excellence matters and management stays close to the code.

If you have Clojure experience (or functional programming experience and willingness to learn), and you want to build regulated banking infrastructure without cutting corners, we'd love to hear from you.

View open roles at Griffin