I think it depends on the maturity of the company. If we are talking about startups CTO - usually the CTO is also the first engineer of the company. So in that case, you have to code something. Now, if we are discussing about mature startups or companies with resources to hire other people to do the work; then I believe the organizational, people, and other skills will be more relevant.
Spot on. Moreover, technical cofounders that start as CTOs make terrible CTOs once the startup gets to 50, 100 people or larger.
The most successful stories I've seen are startups where the cofounder CTO moved to a technical role (chief architect, Devops or r&d) and hired a CTO. Or they hired a very strong VP of Eng and kept working in small startup mode.
Even if you have the title of CTO, you may actually be a founding engineer.
I remember talking to a mentor who was a manager of managers (VPE) at the same time I was the CTO of a small startup and our views and concerns were worlds apart.
Just a piece of anecdotal evidence, one of my bosses has since become a VP of engineering at Netflix without a development background. One advantage he always had was a fantastic group of engineers around him. He did a great job identifying the right leads, letting them drive technical decisions and it was his job to align those with the business objectives and then “manage” the team.
I could easily see him in CTO role in another large organization but may not do as well at a smaller startup where he’d have to provide more hands on technical leadership, perhaps without those strong senior engineers.
It can be enlightening to try something new, for example, Rusts borrow checker, containers etc.. But beyond that there's no need to actually code production.
Looking at the actual code and observing the process at that level of granularity can be helpful as well.
But given the amount of focus, attention, issues around specific compliance, reviews, I'm not sure if it's a good idea for the CTO to be coding when the company has >50 Engineers, they'll probably just be in other people's way.
So definitely 'hands on' experimentation, but I don't think it generally would be production coding.
That said - there are certain types of execs who really love that, and find extra time to do it, if they want to stay late Wednesday and Thursday nights, then that could work as well.
I’m not a CTO, but I am a senior leader that also in the past helped found a leadership development program focused on management (tech and non tech related).
As is always the case with this, one can code and one can also not code in a CTO position. Sometimes CTOs manage no one and are only focused on technology. Other times, they are the top of the management pyramid. Other times, they’re just one of a couple of engineers early in a startups lifecycle.
No matter the situation, the truth remains that it’s not which path you take, it’s how you manage the path you choose.
If you are a coding CTO with a lot of people, make sure you’re delegating the focus on the people components to another leader (hiring strategies, interviewing process, comp, reviews, high level program management, etc).
If you are a CTO that focuses on people, make sure to bring on some senior ICs that can help lead the technical direction of the company. They should still be coding and empathizing with the team, and helping to highlight long term tech trends for the team to progressively adopt to stay current.
Hire people that do the thing you don’t have time to do, and care deeply about doing that thing the org needs. Keep repeating that process all the way down the management chain, with a heavy focus on trust and delegation.
People and teams fail when folks hang on to responsibility long after they should have given it up, because they aren’t self aware enough to realize they don’t have the time or knowledge anymore to effectively do a task. Don’t be that person!
There's really very many types of "CTO" roles, some of which:
* The pure people and executive manager: This is a VP of Engineering by another name, usually in a company that hasn't split the role into two yet.
* The pure technical CTO: Often the most active contributor to the codebase. Has a strong VPE or Director of Eng for people management (or regrets not having them)
* The innovator: Works on special projects to find new strategic direction / prove out new technology. Often has a small team focused with them on that or engineers get to do rotations on that team
* The all-arounder: Usually in a smaller startup, the CTO does a bit of all these things until can fill in with other folks
If you want to aspire to be a CTO someday, heed the author's advice: "Apply technology to the business need." You can be the smartest and most technical person in the room, but if you don't know how to resourcefully apply tech to efficiently solve business problems then the executives are not going to look to you for that role. And as the author notes: "respond to changes in the environment." I've so often seen the smartest and most technical team members get stuck in a rigid way of doing things, but the folks who advance are the ones that adapt quickly to the present need.
I think of this way… if I can’t solve the business needs with technology maybe I’m not so smart… it’s much harder to apply something I know then it is to know of or how something may be
Or the business needs a non-technical solution. A good CTO helps a business to not invest time and money into a technical direction that doesn't make sense. It's more advantageous to end up late on a javascript framework that maintains significant activity and market share than it is to be one of the first to migrate on to the hottest new one that then fades into obscurity a year later.
I'm a senior manager, nowhere near CTO, and I don't code anymore. It's very important that I understand the technology, that I can learn things for myself by analyzing the codebase, and that I create a culture of strong engineering, but none of these things requires writing production code on a regular basis.
Depends on what you are working on. Coding gives you insights into things that you may / may not be able to achieve if you didn't code.
For example, we had to reverse engineer something that a vendor provided. The vendor simply provided a binary that was executed and provided some kind of output. Including the binary into our build was one solution but it was not ideal since it meant we had to install another dependency that was old and outdated (java 6). So the other solution was to replicate this in our own native language (Elixir).
When I throw that kind of work at my team, more often than not I'll get a "not possible" as an answer.
Me being me. I took matters into my own hands. I reversed engineered the binary and was able to re-construct the logic and re-wrote the thing myself in our programming language and incorporated it into our pipeline flawlessly.
Sometimes you just need to get your hands dirty.
Or sometimes you are tasked with something innovative and having the ability to code at least gives you a chance to explore things and come up with a first draft solution which you can hand over to your team to fully bake.
Coding is an essential skill and teaches you to think in ways you can't possibly think otherwise (at least for me).
If you don't code and claim you are good CTO. Well how would you know you haven't coded you cannot compare how you would do if you knew how to code. So the assessment is not a fair test.
Now someone who has coded 20 years of their life becoming a CTO but CHOOSES to abstain from coding to focus on other areas. That's someone I would be interested to learn from.
Without having written code, readcode, maintained code, thought about architecture you do not understand technology and can't be a tech leader. Only as a coder you can grok technology (I even organized "Coding for manager" workshops as CTO, business leaders thanked me for the insights they did get to better interact with technology or manage outsourcing projects).
Yes people are very important, yes software development is a people problem, yes you need to apply technology to business.
Should you write code on your job? No. From my experience - at least this was the case with me - under a certain percentage of time of coding you do not understand the system, implicit assumptions and are not very productive. I've brought down a multi-million user website as a tech leader because I thought I could still write production code :-)
Nevertheless I love love love coding and still write code every day in my spare time. Currently I write Rust code to understand the concept of the borrow checker as somethings other languages do not have (after 40+ years of coding).
Gladly all my CTO coachees have been coders, none of them write code in their day-to-day job.
One time I got the CTO fired because I exposed the fact that he literally didn't know how to use a computer. To be fair, he had other issues as well. But they hired some big exec from Yahoo and never asked him anything during the interview. He was there in name only.
The actual CTO was my boss and definitely a strong coder but was deathly afraid of Java annotations for some reason. It was too "black magic" for him as he preferred to define all his Spring stuff in pages of XML and log into the servers directly to edit code in production. He also had anger issues and once slammed his fist into a metal cabinet, verbally assaulted employees and flirted with all the interns (despite being married with a kid).
The view from the office in downtown SF was excellent and I think that you should write code to be a CTO. The job isn't just about managing people. It is about having product vision. You're not going to develop as good of products if you haven't done it before yourself. Sure, there might be a few super stars out there who can do all this anyway... but that's why they are stars...
I am a little confused why we are talking about CTO and not CIO (chief information officer). I thought the latter is the role responsible for information systems.
Although for years we have been told that CIO means "career is over" and was a dead role. Which I never fully understood.
To answer my own question, I suppose both roles (CIO and CTO) benefit from having coding experience, maybe CTO more than CIO assuming a CTO is supposed to be "closer to the technology engineering".
"Saying that you have to code to be a CTO is like saying that, in order to design a skyscraper, you have start as a cement mixer, then work your way up to girder riveting before finally hanging drywall and installing windows before they let you design the building."
This type of argument from analogy isn't very persuasive to me. Software developers aren't really like cement mixers and CTO's aren't really like architects. They are different jobs. Thus, while, "You don't do X in Y" may be true, it's not necessarily relevant to the discussion. And, it would probably help if the person leading a team of cement mixers was himself an expert cement mixer.
Slightly closer to compare the ops and infrastructure folks to the cement mixers (still a terrible analogy). Your devs are already designing software. Code is a blueprint. So yeah, if you want to design a skyscraper, you should understand building design.
Agree. Analogies of this sort are rarely helpful. I've never understood the motivation to draw analogies to problem domains we have little knowledge of to explain our own domain to each other.
This sounds like a huge self-rationalization to me. While there have been great leaders who don't know how to code, comparing it to a designer knowing how to mix cement is a terrible analogy. Coding is a fundamental skill in the 21st century, like writing or being able to do basic arithmetic. It's not like asking a designer to rivet girders, it's like expecting a designer to know geometry. Coding is simply a bunch of logical constructs expressed in a way that can be translated into machine code.
Imagine hiring a CTO that didn't know how to read and write. In the 21st century, where almost every aspect our lives is dependent on computers, having some knowledge of software engineering should be considered a basic skill.
Maybe a better example is a robotics company. Besides software engineers, you will have electrical engineers and mechanical engineers. You may also have systems engineers, controls engineers, reliability engineers, and application engineers. It is unrealistic to expect the CTO to have strong experience with every engineering discipline.
Though if it a pure software company, I can see wanting the CTO to have a strong background with software.
Electrical and mechanical engineers should also be competent with coding, even if it's just Arduino, Python, or (ugh) matlab. Whether that's to automate some SPICE simulation or data processing task, optimize some design parameters, or something similar, it's part of almost every modern engineer's education across disciplines. Electrical engineers in particular will also typically have experience with C or C++, for writing firmware.
I was a physicist. The only reason I started to code was that I needed to automate control of some scientific equipment and process data. So yes I assume many professions can benefit from at least basic coding skills.
When I came to Canada I soon have discovered that unless I am an Einstein I will never make decent money in science. So my side skill /tool suddenly turned into full-time money making "hobby".
so are doing surgery and lawyering also essential skills then? what about underwater welding? we should teach kids that skill too from early on, it’s super important everyone can do that too, since you expect everyone to know how to write software.
STEM degrees require people to write code because it helps sell people on the degrees. parents are hoping their kid will be the next zuckerberg. that does not mean that this is right, and that this is what society needs. another reason why this idea that everyone needs to code is promoted, is that companies need cheap labor. so the more code monkeys are churned out the cheaper it is to build software. so just forget about this idealistic idea. it’s not what you think it is.
Can you be a "VP of Sales" without ever doing any sales? Can you be a head chef without ever cooking?
Sure, you can be immensely impactful being a people leader and a conduit between business and tech without ever having written any code. But you can't call yourself CTO if you haven't written any software yourself without diluting the meaning of the title to homeopathic levels.
Agreed, experience in the field is a must. But do they need to keep coding, especially in the company? No, I think that's an anti-pattern. They should be busy with getting the business and the tech aligned, shaping culture, shaping hiring and coaching other tech leaders.
I'm a VPE at group level for a sizable conglomerate. From what I experience myself or through observation, I can say that "codeless CTO" is fine BUT if you can't code, you better don't be a jerk.
Good at coding = respect. Good attitude = respect. Not coding + jerk = no respect from team.
Also, it depends on the team. If you don't know about code, and your team is not mature enough, you're at disadvantage. You can't tell if a feature really takes 2 weeks to develop. You can't tell if the team are optimizing for local maxima at the expense of long term. You can't tell if the product is a pile of hacks on top of hacks.
I agree you don't need to be the best coder in the room, but you should be aware of critical technical decisions.
I was a CTO for a while and I specifically moved away from coding because I didn’t enjoy it at all anymore. I liked coming up with ideas (like a product manager but not having to document them) and then seeing them turn into a reality. I could base my ideas in technical reality though.
Agree to disagree. To lead in technology you need a strong BS meter. You need to know what is and isn’t possible, for yourself. You can’t just take the advice of who you think might be the smartest guy. Everyone is not always going to agree on a technology decision and the same person won’t be right every time. If you don’t have an ability to pierce into the weeds and discern the real truth you’re not bringing much value to the business at all. Any jack wagon can stand around imagining what “the future of technology looks like for our organization.”
Yeah. sure. Which vendors proposal do you pick based off analyzing their stacks and devops procedures? The one that smells nicest? The consultant that bought you a steak?
Your tech leads think you should use one architecture, your consultant insists it’s another. Who is right never-made-software-before-cto-jack-wagon?
You’re just going to pick the guy you like the most or that was the more persuasive communicator. Every time.
I guess if you’re a CTO that doesn’t have to make technology decisions and just… dreams big dreams and is a great people person? It can work?
As a CTO for a good decade now (mid sized and small companies), I agree. At my previous (big-ish) company I maneuvered myself into a position where, before I left, I largely had to make business decisions and build bridges based on what my engineers told me - that either creates an incidental consensus culture (which the company might not want), or the most persuasive engineer is the de facto CTO. Being able to make up your own mind (and detect BS - our industry is full of it) seems crucial to me for technical leadership.
Nobody says you need to be the best or come up with any solutions yourself, but I do believe it's important to know what's _actually_ going on. What I ended up with is to spend roughly 50% of my time with the code base and fellow developers. People management, hiring and all the other misc management topics are important too, but they can easily consume all of your work time and then some if you don't timebox them (forcing you to delegate), in my experience.
+1 a perfect illustration of Dunning-Kruger. I was going to say it’s a common pathology if MBAs but while he went to Wharton, he didn’t actually get one.
> Yeah. sure. Which vendors proposal do you pick based off analyzing their stacks and devops procedures? The one that smells nicest? The consultant that bought you a steak?
> Your tech leads think you should use one architecture, your consultant insists it’s another. Who is right never-made-software-before-cto-jack-wagon?
I think these types of decisions apply to many "leadership roles". Those arguing for different ways should be able to explain pros/cons or cost/benefit/risk for each solution. Ideally you would want all parties to be able to agree on your list of pros/cons or cost/benefit/risks. If you can't get agreement over a majority of the items, hiring a neutral party with technical experience might make sense to help with the decision if it's important enough.
I do think knowledge of your company's technology is important. In my experience, people without an interest or passion for it tend to make poor managers as they're harder to communicate & relate with.
In short, I do think that your people skills & management skills are more important than your tech skills. I do think your team should be making most of these decisions. An exception here would be very small development teams (teams < 10).
>I found myself working for a software startup in Harvard Square. As a… wait for it… … project manager.
>Yes, the guy who makes sure people are checking off their tasks! The most hated and useless person in an engineering organization, right? The very definition of OVERHEAD.
>Except I wasn’t. Instead, I was the person standing between the engineers and the business people, translating in both directions.
The "Developing Leadership" podcast [1] by Jason Werner (ex Github CTO) and Eiso Kant (founder Athenian) just did a three-part podcast series where this was also discussed. Can recommend.
Coding is not hard, I’d have 0 respect for a CTO that doesn’t know how to code. They don’t have to actively be coding, but if you don’t understand how to read code then you probably got your CTO job from nepotism or something.
Past experience is crucial and tech leaders/managers need to keep up with what's happening in the world. Do they still need to code professionally in the same company? Nope. Actually, clinging to coding as a source of a sense of accomplishment is one of the fallacies of (especially new) managers. There are far more important skills to hone... https://leadership.garden/the-5-common-mistakes-of-new-engin...
51 comments
[ 6.2 ms ] story [ 27.9 ms ] threadThe most successful stories I've seen are startups where the cofounder CTO moved to a technical role (chief architect, Devops or r&d) and hired a CTO. Or they hired a very strong VP of Eng and kept working in small startup mode.
Even if you have the title of CTO, you may actually be a founding engineer.
I remember talking to a mentor who was a manager of managers (VPE) at the same time I was the CTO of a small startup and our views and concerns were worlds apart.
I could easily see him in CTO role in another large organization but may not do as well at a smaller startup where he’d have to provide more hands on technical leadership, perhaps without those strong senior engineers.
in the beginning, code up the product, even if it's not the best, get something that works.
once the product is in a usable state enough to gain revenue, use the cash to get more engineering manpower.
now that there are a few folks, code in tandem with engineers while managing team, tapering down coding as team grows.
now my day to day is probably 20% coding, 60% product/project management + QA, 20% recruiting/hiring
Looking at the actual code and observing the process at that level of granularity can be helpful as well.
But given the amount of focus, attention, issues around specific compliance, reviews, I'm not sure if it's a good idea for the CTO to be coding when the company has >50 Engineers, they'll probably just be in other people's way.
So definitely 'hands on' experimentation, but I don't think it generally would be production coding.
That said - there are certain types of execs who really love that, and find extra time to do it, if they want to stay late Wednesday and Thursday nights, then that could work as well.
As is always the case with this, one can code and one can also not code in a CTO position. Sometimes CTOs manage no one and are only focused on technology. Other times, they are the top of the management pyramid. Other times, they’re just one of a couple of engineers early in a startups lifecycle.
No matter the situation, the truth remains that it’s not which path you take, it’s how you manage the path you choose.
If you are a coding CTO with a lot of people, make sure you’re delegating the focus on the people components to another leader (hiring strategies, interviewing process, comp, reviews, high level program management, etc).
If you are a CTO that focuses on people, make sure to bring on some senior ICs that can help lead the technical direction of the company. They should still be coding and empathizing with the team, and helping to highlight long term tech trends for the team to progressively adopt to stay current.
Hire people that do the thing you don’t have time to do, and care deeply about doing that thing the org needs. Keep repeating that process all the way down the management chain, with a heavy focus on trust and delegation.
People and teams fail when folks hang on to responsibility long after they should have given it up, because they aren’t self aware enough to realize they don’t have the time or knowledge anymore to effectively do a task. Don’t be that person!
* The pure people and executive manager: This is a VP of Engineering by another name, usually in a company that hasn't split the role into two yet.
* The pure technical CTO: Often the most active contributor to the codebase. Has a strong VPE or Director of Eng for people management (or regrets not having them)
* The innovator: Works on special projects to find new strategic direction / prove out new technology. Often has a small team focused with them on that or engineers get to do rotations on that team
* The all-arounder: Usually in a smaller startup, the CTO does a bit of all these things until can fill in with other folks
If you want to aspire to be a CTO someday, heed the author's advice: "Apply technology to the business need." You can be the smartest and most technical person in the room, but if you don't know how to resourcefully apply tech to efficiently solve business problems then the executives are not going to look to you for that role. And as the author notes: "respond to changes in the environment." I've so often seen the smartest and most technical team members get stuck in a rigid way of doing things, but the folks who advance are the ones that adapt quickly to the present need.
Why gate something based on anything other than ability to deliver?
For example, we had to reverse engineer something that a vendor provided. The vendor simply provided a binary that was executed and provided some kind of output. Including the binary into our build was one solution but it was not ideal since it meant we had to install another dependency that was old and outdated (java 6). So the other solution was to replicate this in our own native language (Elixir).
When I throw that kind of work at my team, more often than not I'll get a "not possible" as an answer.
Me being me. I took matters into my own hands. I reversed engineered the binary and was able to re-construct the logic and re-wrote the thing myself in our programming language and incorporated it into our pipeline flawlessly.
Sometimes you just need to get your hands dirty.
Or sometimes you are tasked with something innovative and having the ability to code at least gives you a chance to explore things and come up with a first draft solution which you can hand over to your team to fully bake.
Coding is an essential skill and teaches you to think in ways you can't possibly think otherwise (at least for me).
If you don't code and claim you are good CTO. Well how would you know you haven't coded you cannot compare how you would do if you knew how to code. So the assessment is not a fair test.
Now someone who has coded 20 years of their life becoming a CTO but CHOOSES to abstain from coding to focus on other areas. That's someone I would be interested to learn from.
Without having written code, readcode, maintained code, thought about architecture you do not understand technology and can't be a tech leader. Only as a coder you can grok technology (I even organized "Coding for manager" workshops as CTO, business leaders thanked me for the insights they did get to better interact with technology or manage outsourcing projects).
Yes people are very important, yes software development is a people problem, yes you need to apply technology to business.
Should you write code on your job? No. From my experience - at least this was the case with me - under a certain percentage of time of coding you do not understand the system, implicit assumptions and are not very productive. I've brought down a multi-million user website as a tech leader because I thought I could still write production code :-)
Nevertheless I love love love coding and still write code every day in my spare time. Currently I write Rust code to understand the concept of the borrow checker as somethings other languages do not have (after 40+ years of coding).
Gladly all my CTO coachees have been coders, none of them write code in their day-to-day job.
The actual CTO was my boss and definitely a strong coder but was deathly afraid of Java annotations for some reason. It was too "black magic" for him as he preferred to define all his Spring stuff in pages of XML and log into the servers directly to edit code in production. He also had anger issues and once slammed his fist into a metal cabinet, verbally assaulted employees and flirted with all the interns (despite being married with a kid).
The view from the office in downtown SF was excellent and I think that you should write code to be a CTO. The job isn't just about managing people. It is about having product vision. You're not going to develop as good of products if you haven't done it before yourself. Sure, there might be a few super stars out there who can do all this anyway... but that's why they are stars...
Keep it weird though.
Is that not ironic?
Although for years we have been told that CIO means "career is over" and was a dead role. Which I never fully understood.
This type of argument from analogy isn't very persuasive to me. Software developers aren't really like cement mixers and CTO's aren't really like architects. They are different jobs. Thus, while, "You don't do X in Y" may be true, it's not necessarily relevant to the discussion. And, it would probably help if the person leading a team of cement mixers was himself an expert cement mixer.
Imagine hiring a CTO that didn't know how to read and write. In the 21st century, where almost every aspect our lives is dependent on computers, having some knowledge of software engineering should be considered a basic skill.
Though if it a pure software company, I can see wanting the CTO to have a strong background with software.
When I came to Canada I soon have discovered that unless I am an Einstein I will never make decent money in science. So my side skill /tool suddenly turned into full-time money making "hobby".
It really is not.
The vast majority of people will never have need to 'code'a line of anything, even in the modern workforce.
More common, yes, ubiquitous, no.
If there are >25 Engineers, the CTO generally won't be coding in production unless they kind of have a very special passion for it.
I do believe however that the CTO should be technical, unlike some examples here. When the are not I feel it's political, for better or for worse.
Sure, you can be immensely impactful being a people leader and a conduit between business and tech without ever having written any code. But you can't call yourself CTO if you haven't written any software yourself without diluting the meaning of the title to homeopathic levels.
Good at coding = respect. Good attitude = respect. Not coding + jerk = no respect from team.
Also, it depends on the team. If you don't know about code, and your team is not mature enough, you're at disadvantage. You can't tell if a feature really takes 2 weeks to develop. You can't tell if the team are optimizing for local maxima at the expense of long term. You can't tell if the product is a pile of hacks on top of hacks.
I agree you don't need to be the best coder in the room, but you should be aware of critical technical decisions.
Agree to disagree. To lead in technology you need a strong BS meter. You need to know what is and isn’t possible, for yourself. You can’t just take the advice of who you think might be the smartest guy. Everyone is not always going to agree on a technology decision and the same person won’t be right every time. If you don’t have an ability to pierce into the weeds and discern the real truth you’re not bringing much value to the business at all. Any jack wagon can stand around imagining what “the future of technology looks like for our organization.”
Yeah. sure. Which vendors proposal do you pick based off analyzing their stacks and devops procedures? The one that smells nicest? The consultant that bought you a steak?
Your tech leads think you should use one architecture, your consultant insists it’s another. Who is right never-made-software-before-cto-jack-wagon?
You’re just going to pick the guy you like the most or that was the more persuasive communicator. Every time.
I guess if you’re a CTO that doesn’t have to make technology decisions and just… dreams big dreams and is a great people person? It can work?
I’ll pass on working for that guy though.
Nobody says you need to be the best or come up with any solutions yourself, but I do believe it's important to know what's _actually_ going on. What I ended up with is to spend roughly 50% of my time with the code base and fellow developers. People management, hiring and all the other misc management topics are important too, but they can easily consume all of your work time and then some if you don't timebox them (forcing you to delegate), in my experience.
> Your tech leads think you should use one architecture, your consultant insists it’s another. Who is right never-made-software-before-cto-jack-wagon?
I think these types of decisions apply to many "leadership roles". Those arguing for different ways should be able to explain pros/cons or cost/benefit/risk for each solution. Ideally you would want all parties to be able to agree on your list of pros/cons or cost/benefit/risks. If you can't get agreement over a majority of the items, hiring a neutral party with technical experience might make sense to help with the decision if it's important enough.
I do think knowledge of your company's technology is important. In my experience, people without an interest or passion for it tend to make poor managers as they're harder to communicate & relate with.
In short, I do think that your people skills & management skills are more important than your tech skills. I do think your team should be making most of these decisions. An exception here would be very small development teams (teams < 10).
>I found myself working for a software startup in Harvard Square. As a… wait for it… … project manager.
>Yes, the guy who makes sure people are checking off their tasks! The most hated and useless person in an engineering organization, right? The very definition of OVERHEAD.
>Except I wasn’t. Instead, I was the person standing between the engineers and the business people, translating in both directions.
Reminds me of a quote from a certain movie...
[1]: https://developingleadership.co
Can you lead a team of engineers if you're not an engineer? Yes. Should you? No.
Can you go out, form a cult, and commit mass suicide? Yes. Should you? No.
Conclusion: "Can you" and "should you" questions tend to be very different beasts.