Ask HN: Why do so many CXOs hate talking to tech teams?
Yesterday, I was talking to a product manager friend who used to be a country head for revenue at a B2B company. He went off on a rant about how annoying and dispiriting it was to talk to tech people.
According to him, this sentiment that tech people are unpleasant to deal with is quite pervasive at executive levels across multiple industry verticals.
As a tech person myself, I knew many of us were opinionated and brash but this was eye opening.
Does my friend's opinion align with your experience as well? What goes wrong when talking to tech people? How can this be improved? As someone who has been in both tech IC (individual contributor) and higher management levels, this is often a relatively simple result of impedance mismatch (excluding bad faith individuals for now): ICs and lower level managers are all about inputs and outputs, blocking and tackling, getting shit done. At the higher management levels it is all about setting direction, setting the "tone", "getting the culture right". There is just so little concerns that intersect between these groups, that communication becomes a challenge. I think there's a level of bullshit in both views. Many orgs are absoloutly mismanaged. - At the lower levels you're getting shit done. Maybe. And if you are that's good, but if the shit isn't revenue generative, supporting revenue, or saving costs, then your job might actually be a bullshit job. - At the higher levels, you hopefully know where your revenue is coming from, and your job is to maintain that whilst growing more. But if you have no operational ability, you're at the mercy of the first group, and might not actually have any real impact in the direction of the company. The mismatch and lack of empathy causes the discourse. The devs typically have limited incentive to chase revenue, the leaders have limited desire to get their hands dirty. Successful startups / growth companies are less likely to look like this, though funding can distort the relationship. Even mid managers have expressed similar concerns to me about finding it difficult to work with tech. E.g., a product manager has complained to me that they wanted a feature built which would have had a direct revenue impact but were stuck because the tech team wanted to "triage" which she didn't understand. Sounds to me that we need a "tech-to-normal" language translator. Triage isn't a word that came out of tech, though. It's a term from the medical field, specifically for trauma care, and effectively means prioritisation under pressure. A product manager really should know and understand this, because it's not like it's impenetrable tech jargon. They should also be the ones making those prioritisation calls, albeit with a solid understanding of the real trade offs. In a situation like this there can be multiple reasons for the mismatch, none of which have anything to do with needing a language translator. For instance, is the product manager trying to force through that feature without moving out the team's other work to match? If so, then they will obviously get the 'triage' demand and be forced to make a priority call. I've seen that too often in my career, where from the PM/PO side a feature or improvement is 'obvious' but because they won't take on the political battle of moving out a team's other feature work that's less valuable they either force the team to work beyond their capacity or, if they have more backbone, to refuse outright. Or is the team intransigent and inflexible, and trying to protect low value but more technically interesting work? Then that, too, is a problem and needs to be solved through incentive changes and other measures, because it's just as unhealthy. > A product manager really should know and understand this, because it's not like it's impenetrable tech jargon. It's not tech jargon but it's a medical term, that has to do with people possibly dying or wounded soldiers that can't be handled, and now we're using it in tech? Ignoring the ridiculous overexaggerating that is, this is exactly the kind of jargon that techies will get mad at managers for using. Just say what you want. "We have other priorities, how does this fit with those, and what item will have lower priority now?" Except that the semantic shift of triage to also meaning any under pressure prioritisation of too-scarce resources, including in a project sense, is decades-old and predates its usage in tech. This is a case of tech adopting business jargon, not the other way around. Even if the product manager wasn't familiar with the term itself, they'd surely be familiar with the idea of prioritising incoming tasks by importance and value and moving out work with lower scores. A simple question should've allowed them to link the word and the concept in their heads. This is unlike true tech jargon, where both the word itself and the underlying concept might be completely unfamiliar to anyone outside of tech and difficult to understand. You shouldn't have to explain prioritisation to a product manager. Aren't PMs supposed to have an elevated communication skillset compared to ICs? I don't think it's too much to ask for a manager to know what the word "triage" means in a planning context, or to look it up. Particularly a product manager; understanding that stakeholders have multiple different priorities and navigating that situation is the essence of their job. Perhaps we're misinterpreting and the team was just stonewalling. That happens sometimes with certain teams, sometimes it's because they're chronically understaffed. However, that's obviously no representative of the "tech" (i.e. software) role as a whole. Triage is usually a non-tech word (QA/Customer Support normally). We need a human-to-human language translator, and it exists, it is called a question. One of the main role of product manager is supposed to do this translation. Two different worlds. When I speak to a non-tech folks I try to re-adjust myself in a way so that I don't make them feel intimidated. Engineers tend to ask many questions, try to find illogical sequences in what is being discussed, raise doubts, propose alternatives etc. etc. We're trained to act in that way and I find that this is what is most irritating to non-tech people. Non-tech people don't know nor they _need_ to know how to communicate in that way. That's not how they get their stuff done, they are focused and equiped with totally different skills. Also, my experience tells me that we suffer more than other people in having a good social intelligence. I'm probably lacking social intelligence, but it sounds to me that you're saying "non-tech folks" are full of shit and don't like to be told so. Perhaps one could interpret my words like that but that's not my personal stance. I have a lot of friends which are not in the tech. I think that we're simply having different ways of reaching to conclusions. And often it's very challenging for me to understand the angle where they're coming from but I'm pretty sure that's what they think too. But nonetheless I believe there's an actual value in trying not to dismiss the opinions solely on the fact that I haven't found the argument, for example, convincing enough. I think it's really important to keep your mind open. I also find similar patterns in conversations with folks with engineering degrees but who aren't in the R&D positions. Both of these two groups do perfectly well on their positions. That is somewhat interesting and which is why I occasionally start questioning our industry practices. At times they feel a bit unhealthy. Further to this point...
Questions have a cost.
In other fields, they are used more judiciously and more is inferred, so conversions don't resemble the tiresome socratic method that often. I believe many CXOs are insecure about not knowing what’s going on and not being able to judge what’s being said. It’s easier for most to have an opinion on product, marketing, hiring… not so much on the technical areas. On the other hand, tech people have a tendency to spend disproportionate effort worrying about programming languages, frameworks, monads, etc… compared to understanding the business - and I somehow understand that, because when job hopping it’s more useful to have experience in certain tech than in certain domains, most SWEs positions are “fungible”. Because there's usually a huge gap in people skills. Most high level management is about meeting others and creating teams and motivating people to work together. High level tech teams are about focusing on one thing and excluding the world around them. And in my experience, quite a lot of skilled programmers aren't comfortable being around too many strangers. When programmers are concentrated on work, some people persons will misinterpret that as shunning them. Also, so many tech people treat management as a waste of money, that I'd say the disdain for each other is mutual. My view from the ground as a client support monkey is that people who ply on tech spend their days having arguments with inanimate or intangible objects, and/or mediating other peoples' irrational arguments with inanimate or intangible objects. Management's job is to ply on people. Rational arguments with rational actors...most of the time. I’ve talked to multiple C-level execs in my career. There are many different leadership and communication styles but at that level you need to be succinct, direct, and know at least something about the business challenges they have. A lot of technical employees want to jump right into technical problem solving - and sometimes that’s fine given context and audience or if you already have a relationship with the audience - but in my experience you need to understand their world and how what what you bring to the table is relating to the business and their direct care abouts. How do we resolve this tension between tech jumping straight into solutioning and an executive concerned about business challenges? If a C-level executive keeps having to listen to tech people offer solution after solution, does this mean a translation layer is missing between them? Depends on the tech people, speaking as current product management. Some were wonderful, interested in customers and business, and added a lot to my knowledge (and I hope theirs too). Some were horrible, seeming only to care about their language/tool cult de jour and to hell with the resultant product/business. Were you able to find a way to work with the “horrible” ones? What were some issues with the worst tech counterparts? The worst were actively disruptive even directly lobbying customers though that verged on termination/legal action. Much of it could be construed as coming from an internal sense of virtue but so utterly unworldly that it was destructive. Ultimately I could work with these people once they were made to understand some sense of consequences. From my experience, big part of that comes from worrying about completely different things. To illustrate – my personal background is in sales/marketing (branching into tech), so that naturally (1) gives me a relatively wide view into our startup, and (2) forced me to develop people skills. And despite that, I still often found myself on calls where both our CEO and I were frustrated and felt we're talking past each other. In my case what worked was just getting more exposure to the executive side of things. After we had a few discussions about the wider ramifications of my ideas (e.g. Does our dev team has enough spare capacity to work on this extra thing I want? Is it going to impact our trial conversion down the line? etc. etc.), we started having much more productive meetings, because I was able to think about these concerns in advance. Eventually, many of our meetings turned from "should we do X?" to "I think we should do X because of A. B is a concern, but I think benefits outweigh the cost." Obviously I'm super lucky, because our founders invested a crazy amount of effort into training. For someone without that bigger picture, I think a useful starting point might be asking "how is that going to impact the entire business?" – both to yourself when you're preparing for a meeting, and to the actual CXO, if only to show them you're not just considering your own walled garden. CXOs are bullshitters. They deal exclusively in bullshit. Tech guys are stuck cleaning up the bullshit those CXOs spew. Do you want to talk to your janitor? Sure he knows how a toilet works but fuck that. I don't think that MBTI is the be-all, end-all explanation of all human interaction, but I think it's a good lens to partially think about the world through. You're going to find a significant overrepresentation of INTPs in the tech field. (citation: https://news.ycombinator.com/item?id=946249) And this type basically perceives and interacts with the world in a very different way than people who tend to gravitate to management positions: (it can be anybody, but I think ESTJs have more of a tendency to seek out management roles) You basically have 2 different ways of looking at the world forced to interact. It can be uncomfortable for everybody. It's a function of how both accumulate influence/respect/trust/power. The paths taken are (generally) very different. So what each thinks is possible or not is based on different paths travelled. For certain types of problems the paths will diverge. Some people handle this well and some people don't. I'm finding your comment very abstract. Can you share an example of this in action? Executives ascend the power/respect ladder by persuading, selling, influencing, meeting, communicating, negotiating with people, and winning over others. Now you have this tech person who has achieved similar power/status by not being good at any of those things. Tech people gain power/respect by studying, doing, building, understanding technology. People tend to like/respect people with qualities they want or respect. Reminds me of the Oppenheimer and Groves situation in which both sides must gain mutual respect for each other to be successful. https://www.atomicarchive.com/history/manhattan-project/p4s2... All of the comments here about engineering being too focused on frameworks/languages/etc can be absolutely true, but I could say similar things about any functional area in every business because each area is driven by their specific incentive structure. For example, <Functional Area> is difficult to talk to because: -Sales - All they are focused on is driving sales and numbers against the multipliers and metrics the head of sales has set for the time period they believe they will be around. They have no sense for the long term. -Marketing - Only focused on the top of the funnel and give little thought to whether those customers will ever convert or be retained without proper guardrails in place. -Finance/Legal - Only focused on risk minimization, not necessarily on the cost of the risk minimization. All that said, regarding Engineering, there is a feedback loop that I've seen that can make these conversations more difficult than need be. Non-Tech Perspective - Tech people are difficult to work with because they are more likely to say "no" to new ideas. Tech Perspective - Tech people are hesitant to say yes to ideas that are not fully fleshed out because as soon as they say yes to a component of an idea, they will be held accountable for the implementation of the entire idea at the originally discussed timeline. I've seen this "bait and switch" happen enough times that I now specifically begin the conversation with "Let's discuss how long this specific version of the idea might take" or "What are your thoughts on this component in terms of difficulty" with the addendum that "If the scope on this new idea changes, I won't hold you accountable for your original estimate, we're just brainstorming". You can also start the conversation with "I'd just like to brainstorm and understand your perspective on new ideas, we are not talking about prioritization or implementation." The challenge is you actually have to mean it, and not backtrack, which is all about building trust. I also believe this loop happens unintentionally without malice, but it is done implicitly in a way that can rub engineering the wrong way. > Non-Tech Perspective - Tech people are difficult to work with because they are more likely to say "no" to new ideas. This is really important. Many tech people (to non-tech) come across as finding ways things WON'T work as opposed to providing solutions. I see this happen all the time. Good tech people mature and realize this and that eventually leads to leadership roles. Maybe because the CXO is interrupting the tech people and don’t understand how important concentration is to puzzle solving, so the CXO feels that tech people are unnecessarily hostile. Programming is a low-status endeavour. Not for all programmers, but for most. It comes with relatively good salary for that status and the perk of solving geeky problems for a living. I can only talk about my experience. I've been a dev but mostly done support and implication roles. I'm usually the the guy who uses the n-word with execs: "No". Execs hate that word. It ruins thier day. Sales, legal, compliance, product (and HR and finance) all say yes to whatever an exec says. They might think it's a bad idea but they can just do it anyway. Only tech people will give a hard no and say, up front, that X is not just dumb but not possible. Sometimes this is worsened as, by concentrating on technical skills, we can lack interpersonal skills. I never start by saying "No". I start by trying to understand if we can achieve the same result another way, or steering the conversation away, or saying I will look into it and never getting back to them. This is much better. But occasionally I get cornered and have to say that word. I follow it with some carefully dumbed down but still unwelcome explaination. Tech people usually make another mistake here: they think that an explaination is helpful, but it isn't. People want their widget. Explaining why they cannot have it just add insult to injury. Because if my "nonconfrontational" style, I am much more popular than my (more able, smarter, harder working) tech colleagues. I am seen as more of a team player maddeningly. This is covered in How to Win Friends and Influence People. No one thanks you for telling them an inconvenient truth. Except in tech where other people actually will thank you for educating them and saving them time. Sadly that does not translate the the real world (including the C-suite). Disclaimer: you may get lucky and find one or two managers who do appreciate getting a straight answer fast. Value them. A few examples: * An exec wanted a VWAP Algo in crypto. He'd sold it to a client who was very impressed we'd managed to make one. But to run a VWAP you need reliable volume profiles and volume profiles on crypto (last I checked) are not at all reliable. I managed to steer the client into accepting a Percentage of Volume Algo. It's not the same bit it's similar. * A client needed Transaction Cost Analysis which we did not do. I managed to turn that into them specing out TCA for us to build with a 6 month lead time. I was very pleased with that achievement. No one else was happy about that though. Product were pissed because it broke their roadmap (no mercy for them, they said yes when the exec "checked" it was already done). The exec would not understand why we couldn't "just do it". And I became the bad guy. * I lost the support of the CTO because I came back from a client with 32 smart, sensible, necessary improvements to our algos and he thought it was not my place to bring. I had the client rename and send the same list and it was forwarded company wide as great input and much appreciated and rushed to engineering for immediate execution. Yes, I am a little bitter sometimes :) but it's better to play the game and win... > Tech people usually make another mistake here: they think that an explaination is helpful, but it isn't. People want their widget. Explaining why they cannot have it just add insult to injury. Absolutely maddening that the world is run by people who have the same mentalities and behaviors of five-year-olds. I try and have compassion on people. Mr/Ms Faceless Executive doesn't really know what I do, they don't know how any of this actually works. It might as well be magic to them. Every time they deal with me, they get apparently randomly "Yes"s and "No"s and "Maybe But"s. Are those truly random? Am I slacking off (intentionally or not) by upping the number of Nos? Am I secretly giving more Yes's to a different exec that I like more? They have no idea. And they have made commitments, to clients, internal or external, to get X done by the end of the quarter etc. So their only option really is to dig their heels in and try and insist and punish me for all and any "No" they get. If it fails then at least they know that "No" was real. If it succeeds then great. And even if they suspect I am right, they're not rewarded for letting their client down but helping the business as a whole, quite the opposite in fact. They do have skills, and they are ultimately people trying to get by in a world of uncertainty. They're just not technical. And they're forced to play a game where the worst behavior often wins so it's not necessarily their fault as people when they act badly. At least those thoughts keep me sane. I am lucky to have a very good team around me. We all support each other. And the others are much more technically able and detail oriented than I am. So I try to shield them by turning aside the worst of the execs and their craziest demands and try and run interference etc. > Sales, legal, compliance, product (and HR and finance) all say yes to whatever an exec says This isn't true at all. Legal and compliance are literally paid to say no to stuff (which does of course make the job of saying no easier). HR and Finance too, to a large extent. Sales are paid to say yes, but will still try as hard as possible to block anything that will hurt their performance figures/targets Though all of them tend to be better at converting their department's own technical details into the appropriate amount of intelligible detail, and making "no" sound more like "Great idea, but we can't" or "Maybe later" and less like "You should really understand our platform before you start having ideas" Where I have worked (mostly smaller companies but some tier 1s), it's very routine for an exec to over rule legal or compliance. As long as they're happy to sign off that's that. And that's the problem with technical issues: you can waive the risk of a regulator fining you, you cannot waive 1+1 not equalling 3. I think there is knowledge to be had in the confusion itself, given this was asked on HN. Read a HN comment section, versus a Reddit comment or YouTube comment section, and take some notes on the difference in communicative styles. The latter are what people on average like to be around: it's got political stuff and the like, sure, but most comments that rise to the top are jokes and generally uplifting comments. A HN comment section is more like a series of bitter black-white 0-100 swings on who is right or not about something. Relatively, it's scathing and stammering. Sometimes it feels like the author had their fists clenched and was stomping their feet on the ground as they wrote it. "Normal" people just really don't like that way of communicating. It's not pleasant, and they don't want to be around it. But that's how tech people tend to be, relatively speaking, especially at senior levels. Much like the computers they work with: empathy only if you're 100% right, otherwise a surly rebuke. Also it's a fairly open secret that this profession has a lot of people "on the spectrum", which is jarring for others who are not used to interacting with such people. The solution lies in putting in solid work so develop understanding of each other. And it only takes reading a few books. The two groups are necessarily different. Many manager types would go nuts dealing with the daily inanity of machines breaking in new and creative ways. Many engineer types would hate having to deal with directly with customers, investors, marketers, sales reps and all that "people stuff". They need each other and "othering" each other doesn't achieve anything in the long run. The managers need to do more to understand the daily experience of the engineer and what they value or dislike and why, and engineers need to zoom out and try to understand or at least mimic the perspective and social needs of managers. Everybody's busy and no one wants to do this, but they just have to. They can at least start with recognizing each other's experiences. A manager saying "we need to pay down technical debt so we can speed up future development", or "we won't add more devs to the project because it will slow it down" will go a long way towards respect. That's "empathy" to an engineer. Likewise, an engineer will do well to say things like "this task will improve lifetime customer value" or "reduce churn" or even hold your nose and say "synergise" if you have to, and hold your tongue on the technical matters. And above all else: ask questions! Actually try to understand their needs, so you can find new ways to meet in the middle. That's empathy for a manager. Hard to say without concrete examples. The grifter ones hate talking to tech people. An aspect that no one here has mentioned but absolutely is a major reason: Tech teams are littered with chronically online SJWs. When something as innocuous as an email about Domain Driven Design [0] can quickly go off the rails and be derided as misogynistic, it's tough to communicate. Executives are not used to dealing with groups that have such thin skin. You constantly have to walk on eggshells around tech teams, and even then something/anything may still trigger them. I had a (fantastic) VP of Eng that of about 100 engineers. He quipped about how being a parent prepared him for leading an org and several people got their feelings hurt thinking he called everyone childish. It became a thing he had to publicly apologize for. Ffs.