Rant about non technical people in the tech industry

Posted by Mindless_Tangerine32@reddit | ExperiencedDevs | View on Reddit | 89 comments

I'm a senior dev and work for a scale up. I've been in a tech lead role for a few months now, and I am finding it increasingly frustrated with the extreme lack of technical skills from tech adjacent roles, mainly product owners and designers. They self confess that they are "not technical" and using the terminal or opening dev tools "scares" them.

If you work in the tech industry, you need to be a technical person. I don't care what role you do.

A lot of product owners at my company don't have enough of a technical mindset. They find it too difficult to learn basic SQL queries, so I'm constantly pestered to find the information they need. I ran a SQL workshop, gave them access to Claude and they still can't wrap their heads around simple queries. A lot of them don't even try because they are so used to relying on the "technical people".

I also found out a designer and a product owner spent an entire week ideating something that is basically going to be impossible to build in the timeline we have, and it was a complete waste of time as an exercise because in their mind it was a simple button click and table. In my mind, it's a performance optimisation nightmare, but the thought didn't even occur to them. Even a junior dev would have been able to flag that this is a huge build.

I know they aren't hired for technical ability.. But it's expected that as a frontend leaning dev, that I know basic to intermediate design. As a senior dev, it's required for me to be able to handle stakeholders, find out what clients think they want vs they need. I don't need a non-technical man in the middle that just adds another layer where things can get lost.

It's astounding how many people work in the tech industry who even after years don't even have the basic knowledge of software engineering and proudly declare themselves as "non technical".

[-]

t-tekin@reddit

“I have been in a tech lead role for a few months now”

Do you have any mentors? Or someone working with you on your onboarding?

Senior engineer to tech lead transition is one of the hardest. It’s way more different than junior to senior transition, and it looks like you need help, a lot of it. It requires a lot of soft skills growth. And with every sentence you wrote I can see you are lacking them and it was probably too early for this responsibility change.

I’m writing with a lot of positive intent. Act on this before it’s too late.

[-]

Mindless_Tangerine32@reddit (OP)

It's hard, and a lot of people are brutal in these comments. I'm not acting like an asshole at work to these people. I'm very polite and supportive, I'm not scoffing at them or making them feel stupid. I also don't think the world revolves around engineering and everyone should learn the ins and outs of it. Not everyone needs to be technical, but people who work in the tech department should.

I want to try and empower non tech people to be able to solve their own problems sometimes, instead of constantly relying on me or my reports. If their job consistently requires them to analyse data via SQL, then they should learn SQL and stop asking me every time they need something. A few have told me it's too scary, and I just can't wrap my head around that response as being acceptable. Hence why I held a workshop, and taught them how to use Claude, and paired with them instead of just giving them the queries they need.

I was brought on to try and improve team performance because the team hadn't met their target 3 quarters in a row, and part of the reason is the constant hounding by POs for help with things that they should be able to learn and do on their own. There has been little expectation on them to learn new skills or become more technical.

I know I'm not a good tech lead yet, but I'm determined to learn. Maybe I'm just overwhelmed and grumpy, maybe I'm justified in my feelings. Probably somewhere in the middle.

[-]

t-tekin@reddit

So How do I think about all of the things you wrote;

The main expectation from POs is; They should be able to represent the customers' needs, either by researching the customers, or via taste making mechanisms. And they should be able to set good product direction and vision to their teams.

Do they need to know SQL to do this? Maybe, maybe not... Maybe someone builds them a dashboard, maybe they learn to do it themselves -> This is just "how" they do things. The performance of a team or an individual should be measured by the impact they deliver towards their goals, not "how folks do what".

Regardless, if the PO needs these dashboards should the team work on that? Or should PO work on that? Depends, it can go both ways? What are the goals of the team? And compared to that top goals;
* Is PO busy with other higher priority work?
* Is team busy with other higher priority work?
* What is the cost of building this with the engineers vs PO?
It is all a tradeoff, and team should discuss it, and commit to the result.

Getting metrics from customers might be indeed a top priority thing. And team can work on that, there is really no problem with any of this in my mind.
In big tech companies there are teams dedicated to SQL dashboards, and PMs just use them. In small startups, the work might be done by PMs or devs. It is just a team discussion and prioritization.

So something as small as a team discussion & prioritization problem became a big frustration and Reddit post for you. I think you need to reflect on why that is happening.

I have a feeling; PM and team doesn't talk with each other in a meaningful way. And team doesn't prioritize together. PM thinks dashboard work is top priority, and goes to devs directly, maybe doesn't understand how much of disruption these causes. Team doesn't understand how important these dashboards are for the team's direction.

So what should you focus on?
* I think your argument should be more about "Our team is overly prioritizing PM dashboard needs over our other goals and hey are disrupting our work. To fix this I'm trying to change the culture so PMs take on that work." - 1st statement is the team's problem, 2nd statement is your solution.

First start with the problem statement -> Do people agree with it?

And once you have that settled, 2nd statement is the next discussion. And there are many solutions come to my mind. Including the one you mentioned. Discuss it with your team basically.

[-]

herrick86@reddit

Have you thought about building these reports into your product instead of giving people access to the DB? If they’re vital for your product team to operate that’s what I’d be pushing for. Even if they do get the hang of SQL, non-data people can easily misinterpret data especially if things are not named intuitively at the DB level. I wouldn’t want any users of a system to have direct DB access ideally.

[-]

Mindless_Tangerine32@reddit (OP)

We are still in the exploratory stage where generating reports is too rigid a solution right now.

There's non-technical solutions out there but they cost money, and I'm trying to get buy in for that. But I was hoping people would be able to write some basic select queries that the majority of the requests people could solve themselves.

Again, small scale up. I have to learn many different things, I expect others to do the same.

I don't like they have access like this already. First thing I did was remove their write access, so at least there's that.

[-]

DanFromShipping@reddit

Human beings specialize. The solution to the annoyance of being asked to write SQL queries isn't to make everyone proficient in basic SQL, it's to build a dashboard that non technical people can use. And the solution to getting the time and budget to build that is 50% social finesse, 50% data from you to demonstrate the time you spend on these requests and the productivity lost to make the company more money.

I also think it's definitely healthy to have a place to gripe candidly about these people - everyone needs that. As long as you aren't letting it bleed through in your professional interactions with them.

[-]

Mindless_Tangerine32@reddit (OP)

That's the long term solution is to build a dashboard. It's one of the top things on my list but will take time. I was hoping an hour long session of SQL would take 80% of these requests off my plate while I get buy in.

The majority of SQL queries we are talking about are literally "select count(*) from x where y". Maybe a join at the most. Nothing more complicated than that.

[-]

Mindless_Tangerine32@reddit (OP)

Also, I know SQL may not be included in everyone's understanding of product owner responsibilities, but we've pivoted to drilling down user demographics more to understand our users better and target specific groups.

We work for a small scale up, it's expected to wear many hats.

[-]

InternationalHair725@reddit

I don't care if they're non technical. That is fine.

What pisses me off is that they are managing my time, managing my technical projects without any contribution beyond nagging me to work faster.

I resent the meetings they set up which are supposed to facilitate engineers unblocking eachother and communicating but only ever end up amounting to a "justify your existence" roll call.

I literally do not have anything against "free loaders" in corporate America, but this is not free loading as they are actively working to make my job worse. A free loader would be far more preferable and presumably wouldn't be getting prompted based on my work either.

No, I'm not bitter :)

[-]

Mindless-Fail-5248@reddit

what kind of tasks do you think should be expected from non-dev roles?

[-]

InternationalHair725@reddit

Anything that doesn't take time away from me doing what they want me to be doing in the first place

[-]

Dry_Author8849@reddit

I guess it depends how clear the roles are defined?

Usually a product owner cares about product features and have a strong knowledge on the business where the product will be used.

So, from PO POV, expects you to provide estimates for features implementation. The tech part of it is your problem. Either you can solve it, or not, and give your time estimate. There is a gray area where both can work togehter to find solutions for impossible problems. May be the feature can be changed, maybe there is a simpler technical way to implement it if some changes are made.

PO is there to isolate you from endless meetings with stake holders.

You, as tech lead are expected to solve problems in the technical way you see fit. PO shouldn't try to influence technical decisions, like which stack to use or which programming language.

Now, you wanting them to learn SQL will make sense for the PO of a relational database engine. There are technical products that require PO to have in depth technical knowledge, like OS, IDEs, programming tools, etc.

As you haven't said which type of product are you working on, most of us will assume you are working on LOB applications, where PO business knowledge is more important than the tech used to build it.

So, take a step back and see if what you want makes sense. It seems it doesn't.

Cheers!

[-]

ExperiencedDevs-ModTeam@reddit

Rule 9: No Low Effort Posts, Excessive Venting, or Bragging.

Using this subreddit to crowd source answers to something that isn't really contributing to the spirit of this subreddit is forbidden at moderator's discretion. This includes posts that are mostly focused around venting or bragging; both of these types of posts are difficult to moderate and don't contribute much to the subreddit.

[-]

No-Economics-8239@reddit

I have some bad news. The further up the ladder you climb, the less technical people become. Which means part of our job becomes translating technical information into business information. Certainly there is a point to be made about our audience making an effort to learn our language the same way we need to learn theirs. But we use communication to make ourselves understood. And we don't often get to choose our audience.

[-]

MonochromeDinosaur@reddit

Yeah the best advice I’ve ever been given is to not explain details and give them the point up front and let them ask questions so they stay in their depth.

[-]

dfltr@reddit

I had to do media training once, and the guy hit me with:

“I asked you the time and you’re giving me a brief history of watchmaking.”

[-]

NotGoodSoftwareMaker@reddit

Does the computer Unga or does it Bunga?

Up shake head for agree, side shake for disagree!

[-]

Mindless_Tangerine32@reddit (OP)

I don't mind talking to clients or people that don't work in the tech industry. I don't like having to talk through them with a non technical product owner that doesn't ask the right questions, and I have to go to the stakeholder myself to find out the answers. It creates more work for me than it saves.

If the product owner made an effort to learn my language that way that I had to learn theirs, it would be mutually beneficial. That's the point of the post. But I see little expectation for product owners or designers to learn engineering, but a lot of expectations on me to learn their domain.

[-]

TRBigStick@reddit

Imagine being a plumber and being mad that people don’t know enough about pipes and toilets to ask you the right questions. It simply doesn’t make sense.

The non-technical people at your company were hired to do a non-technical job. It is your job as the technical person to understand the business well enough to work with them.

[-]

MoreRespectForQA@reddit

OP isnt complaining about customers. He's complaining about people who are dictating work for him to do without understanding it.

It'd be more like being a plumber and getting call outs from somebody who speaks to customers, feeds their complaint into chatgpt and asks it to produce a work order for the plumber to use.

[-]

TRBigStick@reddit

I think you’re right. I was mostly reacting to this comment:

If you work in the tech industry, you need to be a technical person. I don't care what role you do.

Such a broad statement confused me, but it sounds like OP’s (valid) frustration is with a specific product owner dictating work to engineers. That absolutely shouldn’t happen.

[-]

Mindless_Tangerine32@reddit (OP)

This is it plus unwillingness to learn new skills they think are too "scary". I'm just not very eloquent today, brain is fried.

[-]

TRBigStick@reddit

Have you spoken with your manager about this product owner? They sound like a liability.

[-]

Mindless_Tangerine32@reddit (OP)

Product owner is head of product, which influences all the other product owners.

So it's a cultural problem. Need to approach it more delicately.

[-]

papaya_war@reddit

I see it differently, the engineering adjacent roles at an engineering company should definitely have some baseline technical knowledge.

It’s more like being a plumber and getting mad that the people designing the building keep putting bathrooms in impossible locations. Sure you don’t expect them to know a lot about plumbing, but the should know enough that they’re not asking you to do the impossible

[-]

Mindless_Tangerine32@reddit (OP)

much better analogy than what I gave, thank you

[-]

Mindless_Tangerine32@reddit (OP)

So I call a plumbing company asking them to do a big plumbing job, but can only communicate through to the plumbers via someone who has never been a plumber and doesn't even know what a spanner is.

Wouldn't it be better to talk someone who has plumbing skills instead?

[-]

Early_Rooster7579@reddit

Thats typically how it works. Most plumbing companies will have a secretary answering phones or doing dispatch

[-]

TRBigStick@reddit

That’s not the analogy that I gave.

All I’m saying is that it is unrealistic to expect everyone at a company to be a software engineer. At some point you will interact with someone who has never opened a terminal. When that happens, you should still be able to solve problems for the business.

[-]

No-Economics-8239@reddit

Try being autistic. They don't think like you do. They don't see what you see. The world looks different to them. They don't understand why you can't speak their language. They see their perspective as the normal one. Their speech and acronyms and cute little office speak rhetoric is the way it is supposed to be.

They are wrong. But they can't see it. Maybe once we're in charge we can force them to see things our way and speak our language. But, from what I've seen, putting us in charge just turns us into them.

[-]

OfficialBadger@reddit

Try being autistic and an engineer

[-]

Mindless_Tangerine32@reddit (OP)

Isn't that most of us?

[-]

lolCLEMPSON@reddit

This is not always true.

I worked at company where a founding CEO was extremely technical, had a PhD, did the work to actually make the first products, and spent a good amount of time understanding things. A senior VP in my team was extremely technical and would nail your ass if you were bullshitting him. It's entirely possible. But our customers were also very technical.

I've been places where the top people were not super technical, but they relied on trusted technical people that had communication skills to tell them what they needed to know to make good decisions.

The problem lies most when you have non-technical people who try to compensate or dismiss technical experts because it doesn't tell them what they want to hear. That happens a lot, and in the age of AI it's absolutely dreadful when it happens because they get validated by an "expert" that is just telling them nonsense.

[-]

james-ransom@reddit

"The further up the ladder you climb, the less technical people become."

Lol. Noob vp here.

[-]

ActuallyFullOfShit@reddit

Why are you blaming people in non-technical roles for being non-technical?

I think the real problem is your lack of willingness or skill to work with people of different backgrounds. You should focus on that.

[-]

ritchie70@reddit

I'm not OP, but I'm blaming people in roles that should be somewhat technical when they're non-technical. I'm surrounded by it, and it's probably a daily problem.

[-]

ActuallyFullOfShit@reddit

That sounds like a real but distinct situation from OP

[-]

muuchthrows@reddit

I don’t believe that’s what OP is arguing against. It’s more the equivalent of being hired to work indoors but not knowing how to open a door.

[-]

drakgremlin@reddit

Hot take: When you are designing for a project you are a technical person.

[-]

PodiVennai@reddit

I would suggest to give the task to any interns or junior devs to create an UI based system that will enable the POs and non technical managers to view the data instead of giving them SQL queries ( this was primarily my task as a trainee 10 years ago where I was building UIs for product and it was a great learning experience for me too )

And also we had a project manager who would help to bridge the gap between non technical and technical teams that would allow us to focus on the coding and design aspects as well .. but now with most orgs saying they want lean teams with no PMs or juniors I believe this is the tradeoff and additional tasks that senior devs have to take on

[-]

okayifimust@reddit

If you work in the tech industry, you need to be a technical person. I don't care what role you do.

What you hear is the sound of the world not caring about your opinion.

A lot of product owners at my company don't have enough of a technical mindset. They find it too difficult to learn basic SQL queries, so I'm constantly pestered to find the information they need. I ran a SQL workshop, gave them access to Claude and they still can't wrap their heads around simple queries. A lot of them don't even try because they are so used to relying on the "technical people".

Yes, usually, this is not part of their job description, and very much part of yours.

I also found out a designer and a product owner spent an entire week ideating something that is basically going to be impossible to build in the timeline we have, and it was a complete waste of time as an exercise because in their mind it was a simple button click and table. In my mind, it's a performance optimisation nightmare, but the thought didn't even occur to them. Even a junior dev would have been able to flag that this is a huge build.

Yes, that can happen. There's a balance between finishing an idea or bugging you about input early on. Sometimes people miss the mark. The solution here is not for them to learn about tech but to involve you sooner.

I know they aren't hired for technical ability..

Then what is the point of the thread?

But it's expected that as a frontend leaning dev, that I know basic to intermediate design. As a senior dev, it's required for me to be able to handle stakeholders, find out what clients think they want vs they need. I don't need a non-technical man in the middle that just adds another layer where things can get lost.

Do you say that, or is that part of your actual job description? Where I am, they mostly keep us Devs away from customers. Dealing with them is literally the job of a bunch of non-technical people.

It's astounding how many people work in the tech industry who even after years don't even have the basic knowledge of software engineering and proudly declare themselves as "non technical".

Still not their job. Still very much you're.

[-]

pl487@reddit

Let's say you're a high school teacher. Cleaning up messes is the janitor's job. It's beneath you. He can put a broom in your classroom, but you're not going to use it. And if he starts teaching you how to sweep, he just doesn't get it. It's beneath you.

You have to understand the disgust people feel toward us and what we do. They hide it well, but it's always there.

[-]

cosmopoof@reddit

It's the other way around: if you can't talk to a non technical person, it's your fault, not the other person's fault.

The real world doesn't buy code, they buy solutions for problems - and if you can't see that technology is only one small portion of that, that's ignorance.

[-]

Mindless_Tangerine32@reddit (OP)

Why isn't it also on the non technical person to be able to talk to me? Why is it always on engineering to learn? Why not both?

[-]

RagnarDan82@reddit

Let me frame it a different way.

Would you feel ok if your neurologist didn’t make an effort to translate terms and situations to you in a way you as a layman can understand and act on?

You don’t want to, or can’t learn all of the terms and their context, what’s meaningful and what’s not. Especially not while managing every other aspect of your life. Expecting you to be a citizen neuroscientist isn’t reasonable.

They’re not just paying us to know what to do, they’re paying us to know how to translate that information into business relevant context so they can make decisions and weight in on development.

Especially as you work with people higher up the chain, they are dealing with hundreds, potentially thousands of individual experts in different areas, trying to get the relevant slice of information from each, to piece together a picture of the whole.

If they had to be even intermediate levels of proficient in each of those areas, that would take over from their primary job.

The more niche your expertise, the more the burden of explaining it to laymen rests on you.

[-]

Mindless_Tangerine32@reddit (OP)

Ok so if I went to see a neurologist, but I couldn't talk to them directly, only through someone who wasn't a neurologist and doesn't have any experience or understanding of neurology.

How would that meeting go?

[-]

iamgrzegorz@reddit

Because non-technical is the default state. It takes effort and a lot of time to learn technical skills. Does your finance team require you to learn their language? Do sales people expect you to know their jargon? When you talk to lawyers, do they scoff at you for not knowing all the terms that are obvious to them? No, it’s always like this, experts need to be able to explain concepts to and work with non-experts.

[-]

Zeikos@reddit

I agree with you to some degree, but I'd expect a designer and a PM to get some input from a dev when ideating something.

Not knowing is fine, but I at least expect them to know that they don't know.

[-]

Mindless_Tangerine32@reddit (OP)

They don't know, and they don't think to ask.

[-]

Mindless_Tangerine32@reddit (OP)

I'm not talking about those people. I wouldn't expect someone in finance etc to know tech jargon because they aren't in the tech team.

I'm talking about people who work in the tech team, who work with engineers regularly.

And to be clear, I'm not asking PO's/ designers to be experts in swe. I'm asking them to put a bit of effort into learning my language too.

[-]

dorox1@reddit

Because:

A: Learning a little bit of technical stuff is far harder for most people than learning a little bit of non-technical stuff. Learning the level of technical knowledge needed to understand what a junior dev understands about SQL optimization is a multi-year process, not something you pick up in a quick workshop.

B: We get paid top 10% salaries to do it. A lot of supporting positions don't.

C: The technical details are rarely the core business issue. Every once in a while the exact technical aspects of a SQL query may be important at the business problem level, and in those cases is it the job of non-technical people to trust your expertise. In a healthy work environment you can (politely) say so. Most of the time the "technical" issue translates to a non-technical outcome of some sort which can be explained easily.

In your posted example it sounds like the core issue is that they make decisions without consulting you. The issue isn't that they're non-technical. The issue is they had someone who *is* technical and didn't talk to them!

There is no world where your non-technical coworkers are going to understand "feature XYZ is going to run into troubles with performance optimization", but there could be a world where they think "XYZ sounds great, but we should run it by Mindless_Tangerine before spending a week on it".

Becoming someone who is willing to speak their non-technical language will actually help with this, because people pathologically avoid interacting with coworkers who are going to throw terms and arguments they don't understand at them (often in an annoyed tone). I've seen it before where very skilled devs are underutilized because they're unpleasant or difficult to communicate with, If they know that coming to you could yield an answer like the following, they will usually be happy to consult you:

"I know XYZ sounds simple, and it seems like a great feature, but there are some real implementation challenges that aren't obvious from the outside. I can go into detail if you like, but the important thing is it would take a lot of time to build if we want it to run fast enough for customers' needs."

[-]

cosmopoof@reddit

Because in communication theory, the language to be used to communicate effectively, should be one that is common.

So either you are able to explain things in normal language to be able to include others, or you are not - but expecting non technical people to be able to understand technical language good enough is arrogant and unreasonable.

You sound a lot like you think you're special and entitled.

You're not.

[-]

Mindless_Tangerine32@reddit (OP)

I can communicate with common ground. Because I put the effort into learning how to communicate with non technical people.

They haven't put in any effort into learning to communicate with engineers. It's one sided and unfair.

[-]

cosmopoof@reddit

Unfair? You get paid a ton for doing something that's not exactly hard. Get your perspective right.

[-]

matthkamis@reddit

I agree, but to be fair other departments use internal buzzwords as well

[-]

NerdEnPose@reddit

In my experience we are paid very well for it to always be on us. I have no problem with that, it’s the unwritten job description.

[-]

Canadianingermany@reddit

Because it is always the job of the specialist to bridge the gap back to the core need.

[-]

sndrtj@reddit

I think your expectations are wrong. Product owners are not technical people. While it certainly helps if they have some technical knowledge, it is not their role. As a tech lead, it is your job to deal with non-technical stakeholders, and translate into technical terms.

[-]

zicher@reddit

Translating what you do to non-technical language is an absolutely essential skill that you must have to succeed.

[-]

Then_Alternative7143@reddit

sounds like there's a big communication gap between roles

[-]

gokkai@reddit

why do you need to learn basic sql when claude can do it better than 95% of devs?

[-]

gokkai@reddit

[-]

Individual-Shame6481@reddit

"Higher up people should care about the work of lower people"

Huh, no. That's not how a healthy company works.

That's literally why a CEO hires you. To remove that burden from himself so he can make business.

You are asking to demolish the very core fundamental of every single business out there.

This shows Software Engineers can truly be laser-sight blinded. Please open your mind.

[-]

heelek@reddit

You missed the point and you are speaking about opening other people's minds. OP complains about the people that are not higher than them, OP complains about people he works with daily and together they collaborate to create a technical product. I'll give you an example from my past: we somehow got a non-technical PO on a team whose product was strictly technical (think API gateway, database engine, that sort of things). How can you own a product which you don't understand nor do you even care to try to understand? It shows lack of respect to the engineers on your team, Im fully in agreement with OP

[-]

xaervagon@reddit

Tbh, I'm happy for my non-technical people to remain non-technical. I've had too many situations where some script kiddie things he deserves a seat at the design table because whoever managed to get an automation framework to do a simple task for them. Then you have the ex-programmers up the chain who haven't touched a line in years, but also thing their opinions on how long things should take are gold standard. Then you have non-technical people who are trying, don't have the ability, and do real damage because the company doesn't understand what internal controls are.

Honestly, it's less hassle for me to work on communicating with non-technical people than non-technical people trying to learn how to speak to me. Communicating with non-technical people and being able to navigate discussions where they have unrealistic or impractical expectations is an important skill. Staying plugged in with the non-technical people on relevant tasks is also important because you have to steer them before they sell management a whole load of hopes and dreams and you get blamed for not delivering.

[-]

supercoach@reddit

If people are coming to you for information then that's because you're either not making it available in a format that's digestible or they're being lazy. You've mentioned that people won't run SQL queries for themselves so that suggests it's the former and I'm sorry to break it to you, but expecting anyone who isn't a developer to do developer things is just being abrasive for the sake of it.

For most people, all you need to do when they ask for information is give them a way to get what they're looking for in an excel spreadsheet or CSV. Non-technical people will happily stumble their way through excel and stay out of your hair.

If you want to lighten your load, you need to empower the people you engage with and stop treating them as adversaries. Provide them with access in a non-technical manner and watch them thrive.

The fun thing about providing people with the tools to help themselves is you can direct queries for bespoke reports to the report tool or portal or API or whatever it is your company has decided will be the pathway for information. You set the contract and you can then set the expectation that your role is ensuring that the application works and that the information is accessible and information can be retrieved via the agreed pathway. It's all about empowering the people you work with to be self-sufficient.

[-]

Vinegarinmyeye@reddit

My favourite are the ones who laugh about it and go "Oh well I'm just a bit useless with all this computer stuff... Teehee".

Cool, so you don't know how to use the tools you need to do your job?

Imagine I started working on a construction site and dug into a gas main... "oh I'm just a bit useless with this jackhammer stuff... Teeheehee"...

I could kinda charitably understand it decades ago when I started working in this field... But in the year 2026 I don't see much excuse to not know how to operate a fecking computer.

[-]

Mindless_Tangerine32@reddit (OP)

Yes. This is what I mean.

[-]

sarhoshamiral@reddit

Lets talk about your idea example. As the dev team, your job is to find technical solutions to business problems.

It is entirely possible that customers actually care about a feature even if it means it is not very fast initially. So when product teams made that idea pitch, did you just shut it down saying it is not possible or did you give them options saying it is but with certain caveats.

Yes, anyone outside the dev team usually doesnt care about tech part of it and they dont have to most of the time.

[-]

Mindless_Tangerine32@reddit (OP)

Ofc I gave them options, but it would have been good when they came up with the idea to be like "oh, this touches x,y,z, let's bring a dev on to ask if this is possible" instead of spending a week acting like it wasn't a big deal and spending time making the design. They should have validated their idea first with engineering instead of wasting time.

[-]

Connect-Shock-1578@reddit

It sounds like a process problem, not a people or technical skill problem. If your requirement engineers/product engineers/software architect/whichever name you give to someone who knows tech but can also talk business is not involved in the solution design stage automatically, that is a process problem.

I greatly appreciate our project manager. She has no interest in learning SQL whatsoever, but she knows where her limits are and gets us involved. If understanding the tech details is important to communicate an issue, she asks for explanations until she understands enough to talk to the business stakeholders. And then she takes care of all the organisational and political stuff and lets us focus on our work. Amazing person. I can never do her job.

[-]

coder155ml@reddit

It’s called job security

[-]

Mindless_Tangerine32@reddit (OP)

fair enough, maybe why we get paid more than them. Not really thought about it like that before.

[-]

mxldevs@reddit

What does "tech industry" mean to you?

Are you in the business of providing solutions to a technical audience, where it would be useful for everyone involved to actually understand what they are making and selling?

Or are you building products for a non-technical audience, where it's useful to be able to relate to the average person who has no idea what a database table is?

[-]

Mindless_Tangerine32@reddit (OP)

It's a very technical product with a mostly technical audience.

[-]

pineapplecodepen@reddit

I'll start using the terminal the day I don't have to argue with people like you, who think the terminal is peak UX, to implement an actual usable design into products.

[-]

bcb0rn@reddit

This is a shitty take. It’s actually part of your job to explain technical concepts to people that are not technical.

Do you think that accountant is raging as they process your payroll because you can’t balance a ledger?

Are you a good tech lead?

[-]

Mindless_Tangerine32@reddit (OP)

Probably not yet tbh, I've got a lot to learn. But I'm constantly badgered by people who could solve their own problems with a tiny bit more investment on learning some basics software engineering.

[-]

darthsata@reddit

You are worried about SQL? I had a staff PM at a FAANG to whom I sent a text file report several weeks in a row to. She never said anything, but it turned out she never managed to read it because of Unix line endings. I hadn't even thought about this as a major hinderence. I sent my manager a bottle of his favorite drink after the fallout from that incident.

[-]

Zealousideal_Meet482@reddit

Expecting PMs or designers to think like engineers misses the point of why those roles exist. They're supposed to bring product intuition, user context, and prioritization, not system design expertise.

Yes, they should understand constraints better, but it’s also on engineering, especially at senior/lead level, to surface those constraints early and clearly. Translating complexity isn’t extra work, it’s a core part of the job.

If a week was spent on something infeasible, that’s less about non technical people and more about missing feedback loops.

[-]

0xffff-reddit@reddit

Don't give them Claude! They may start implementing things and leave you with a pile of slop to maintain.

[-]

DuffyBravo@reddit

Learning soft skills and the ability to manage up is probably the two greatest skills you can learn as an engineer. This is coming from someone who wrote code for 20 years and then 10+ more years in technical leadership.

[-]

ritchie70@reddit

I'm in the US IT department of a major corporation. Way too many of my coworkers will proudly say that they "aren't technical." Damnit, if you're in IT, you need to be at least somewhat technical.

These aren't directors or senior managers with large teams - these are people who are individual contributors or barely not individual contributors. You need to at least know enough to know when the vendors or other teams are probably lying to you.

My favorite director (who is now a Sr. Director) was writing C code in 1992 - but one of my favorite managers was so good at parroting technical terms back, in correct context, that it took me almost six months to realize that's what she was doing.

The worst people to work for are people who don't like tech, are proud that they don't like tech, and have no interest in learning anything about THE WORK THAT THEY'RE DOING.

[-]

_Paladin_@reddit

Yeah this sounds like you might be in the wrong. It's up to the engineer to translate the tech into human-consumable language and not expect others to "get it" the same way.

The only extension to this that I'd wonder about is trust. As the professional developer, they'll have to trust you to make the right technical calls.

Let them ideate all they want, foster trust, and work on communication. The only place you'll get by expecting everyone dip into your role is the loss of a role.

[-]