[captnObvious]

Apologies in advance, I needed to vent:

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.

[fhd2]

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.

[mattferderer]

> 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).

[fmajid]

+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.