DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

Cover image for What are the big differences between working for a "tech company" and being a dev for a "non-tech company"
Ben Halpern
Ben Halpern

Posted on

What are the big differences between working for a "tech company" and being a dev for a "non-tech company"

Words in quotation marks because it's probably more of a spectrum than binary, but let's talk about the difference between tech/code first work and code work for other types of orgs.

Top comments (33)

Collapse
 
yechielk profile image
Yechiel Kalmenson

My first job was part of a team of 5 devs at a non-software company.

The biggest difference in my view was that software companies view their dvs as their biggest assets where non-software companies view them as an expense.

Because we were an expense, the company was always trying to cut corners. We never got time to pay down our mounting technical debt, most of which was added by engineers that the company outsourced to in SE Asia (another cost-cutting measure).

I was even told by my manager that the reason they hired me and another bootcamp grad was because two juniors were much cheaper than the senior developer they so desperately needed...

It's no wonder I "noped" out of there as soon as I had enough experience to get a job at an actual software company.

Collapse
 
itsjzt profile image
Saurabh Sharma • Edited on

Yeah it happens. What concerns me is: biggest tech companies today are just advertising firms.

Collapse
 
g_abud profile image
Gabriel Abud

Had a very similar experience as a developer in a non-tech company, those positions tend to be very underpaid in my experience.

Collapse
 
yaser profile image
Yaser Al-Najjar

Huge difference

Starting from in non-tech companies you will have managers who have no idea about tech... and, good luck with that!

Collapse
 
yusufkolawole profile image
Yusuf Kolawole

Reason I quit my job

Collapse
 
ben profile image
Ben Halpern

Any communication strategies for situations like this?

Collapse
 
srleyva profile image
Stephen Leyva (He/Him) • Edited on

Principle: Consider the audience.

Pragmatic programmer talks about this but essentially tell them how new developments affect bottom line, availability, security of service in ways they understand and care about. The board doesn’t care if if you’re running Kubernetes, Docker, microservices, monelith, Linux, Windows, etc. All that matters (or really should) is it works, is cost effective and allows you to viably get to market. In a non-tech company, your tech leadership should be able to communicate that back to management in a clear way. Though, the DevOps handbook hypothesis’s that every company will be a tech company in one way or another and business side will need to understand the technology side as they are too tightly coupled.

Collapse
 
arschles profile image
Aaron Schlesinger

I like to start by boiling it down as much as possible.

Managers all want to know when it's gonna be done & how much it will cost (even the highly technical ones!), so I like to start with those two messages in mind, and then expand as necessary from there. I usually don't expand at all from there, to be honest. It's nicer and easier for both parties to let them ask the questions after you present the facts.

Collapse
 
miketalbot profile image
Mike Talbot ⭐ • Edited on

I've been a founder of technology startups pretty much my entire life, it's in my blood. However, 2 years ago I accepted a job with an organisation that wanted to go on the journey to become technology led. It's a different beast.

In the non-tech sector:

  • The business isn't counting the cost of feature development and thinks it's paying for everything.

As a software company you are constantly reviewing what makes financial sense to be included. In non-tech our journey has been to identify that "great ideas" from "the people who make all of the money that pays you guys" need equal scrutiny. We all knew we were going on this journey and my colleagues are great, but it's been a nut to crack. Building stuff that matters is what's important to all of us, but old habits die hard. It's really a lot about the whole process of becoming "product" led - more than just the technology.

Software development should be a two way street and the only thing that matters is that we solve the business problem our clients (internal and external) have. The key thing is to understand the business requirement not the feature demands and make sure we are all on the same page.

If anyone is interested I made this video for our investor community (other companies significantly owned by our shareholders) which talks about the issues of going from non-tech project stuff to software company like products.

From that video I think this is one of my key points - just the attitude to failure...

When a non-tech project fails it's a disaster
projects

When a tech company fails it's a learning experience:
products

Collapse
 
jwp profile image
John Peters

The only-tech companies make money on the tech services they provide. This is an asset.

The non-tech. Companies make money on things not directly related to tech work. This makes tech workers a liability.

When budgets fail, liabilities are first to go.

These are two different worlds. Tech people are treated as either an asset or libality. Environments often follow this demarcation.

One of them can be prone to toxicity.

Tech companies are more of a true engineering culture.

Under the right conditions either can be excellent places to work.

I prefer tech companies.

Collapse
 
chingiz profile image
Chingiz Huseynzade • Edited on

Currently, I work for university. Our workload are based on working with cloud APIs mostly. And it sucks to be honest. Because most of the companies that give services for universities established to long ago and their documentation are the worst thing to read(not up to date docs). Most of the times even they don't understand what they have done(I know this by talking to them).

Collapse
 
ben profile image
Ben Halpern

Any specific examples to speak of?

Collapse
 
chingiz profile image
Chingiz Huseynzade

Around 3 weeks ago, our production key expired (it should not expiry based on their emails). Requesting new key took 2 weeks, but that key didn't work, because they had to add that key somewhere which they couldn't explain in order to that key work. That took 1 week. By the way we had no idea about that process.

Collapse
 
themattyg profile image
Matt Graham • Edited on

I've worked for both, and there are pros and cons to both.

Working for a tech company pushes you harder, to learn more and be better. I learned more in my job at a tech services/development company than I have anywhere else. The thing that sucked about that job was the hours (though my time at an ad agency was much worse) and the time away from my at-the-time new family.

I've worked mostly in non-tech companies. @ben as you said, it is a spectrum. I've worked as the sole dev in a large corporation, but also as part of small-to-medium sized tech teams inside of non-tech firms. I've also worked as a sole dev in a department of a large telecommunications company with many tech teams outside the department I've worked in. I find the non-tech companies (with a few exceptions) to have a better work-life balance.

When you're by yourself, and the people around you aren't so techy, they're amazed at the stuff you can do; or extremely frustrated when something that seems simple takes so long. When you're in a team, you can get the best of both worlds... you push each other to learn and be better devs.

Being a freelancer in the time of COVID, though, has been truly rough. Stuck in my basement, losing my sense of time/schedule, SO... MANY... ZOOM... MEETINGS.

Collapse
 
briankephart profile image
Brian Kephart • Edited on

I work at a non-tech company, and I find that there is a lot of discussion in tech about titles, hierarchy, and team processes that are not part of my world at all. The formalities don't exist for me.

Collapse
 
krtobias profile image
Tobias Krause

A typical problem with non-technical companies is that their managers see IT only as a necessary but annoying cost factor.
They try to save costs by hiring people who can do a lot at once, instead of hiring several people who are really experts in a field.
Furthermore, managers often do not understand tech. They make promises without being able to estimate the necessary effort.

Testing the project? Just unnecessary costs.

If you talk to them about it, they often feel attacked (people are afraid of what they do not understand). Therefore, everyone should have learned basic knowledge imho (which is not hard nowadays).

But it is relatively easy to avoid these companies, because you can usually recognize them by the job advertisement.

Collapse
 
_hs_ profile image
HS

Worst thing for me right now, in non-tech, is the feeling of all your work and effort being underestimated. They think everything is a push of a button, few keystrokes away. Yesterday some were shocked when they realised how much work just 1 simple piece requires. They behave like a startup while having enterprise requirements.
Also you get to be "smartest guy in the room" too much time - in terms of your job/career. So there's no space to learn from others you just work.
This finnaly boils down to the fact that I think I'm degrading professionally.

On the other hand it's much more satisfying to see the purpose of the software and be directly involved with solving real world issues by thinking not by tasks in Jira or patterns. You feel more useful, at least that's my case

Collapse
 
tdwright profile image
Tom Wright

Having worked at both, I think the biggest difference is the problems that tech solves. At a "tech company", tech is often the product and there will likely be a shared vision of what this should look like. In a "non-tech company", developers may have more of a role to play in helping the company identify what business problems tech can help with, and then delivering on that.

Collapse
 
justsharkie profile image
/*Sharkie*/

I've worked in exclusively non-tech companies so far, and it's been a challenge while also being super rewarding bringing them into the modern tech space!

I also wrote a fun article about it: dev.to/justsharkie/just-a-big-tech...

Collapse
 
mcgurkadam profile image
Adam McGurk

I’m the lead developer for one of the largest solar companies in the nation.

For over a year I was the only dev in the entire company (now I manage a total of five other junior devs). It gets a little isolating sometimes when there is nobody else I can turn to who knows what my job is

Collapse
 
flyingjolly profile image
FlyingJolly • Edited on

At a tech company the c-level people say: "we're an IT company". At a non-tech company the c-level people say: "we have an IT department" (or they just outsource IT). The difference between the two is how much influence the dev/IT managers have over leadership. That being said, tech companies don't always fully comprehend the state of the art in information technology; e.g. "Dev Ops" may be considered a team instead of a company culture, similar to the concept illustrated in the DevOps literature.

Collapse
 
rrampage profile image
Raunak Ramakrishnan • Edited on

Biggest difference is tech in "non-tech" companies are seen as a cost center and thus the organization tries to always reduce cost. This results in decisions like off-shoring or out-sourcing which if not handled correctly cause loss of knowledge and capability in the organization. It has a big impact on the employee morale and work culture.

In tech companies, the developers have more freedom and responsibilities without worrying about short-term impact on company's bottom-line.

Collapse
 
matt profile image
Matt seymour • Edited on

Opinionated response ahead. Disclaimer, not all companies and made or run equally, there are good and bad non-tech companies and good and bad tech companies. These are just some ramblings, and should be read with a pinch of salt.

From my experiences managers in non-tech companies tend (not always) to be promoted because they have been at the company for a long time and the company need to make them feel like they need to be promoted. They are usually (not always) promoted because they have knowledge of the company and sound like they know what they are talking about from a technical point of view.
Those who are technical enough to sound like they know what they are doing are the most dangerous type of people (to me). You will end up being dragged into situations where they will say things without truly understanding ramifications (there is a good chance blame will be passed around, (in some ways its not their fault they are in a position they think they understand).
As a dev you will will probably be taking on more work where the spec might be "fuzzy", the spec will be something like: Make A do Y. The work will tend to be constrained to cost rather than accuracy. There will be technical debt.

In tech companies you tend to have two types of people on the tech side. Those who are "tech people people", and those who are "tech people". Those who are the "tech people people" will start going up the management career ladder, team lead, dev manager. The "tech people" will tend to follow the technical career path, senior dev, architect, principal engineer.
As a dev in these organizations early on you should be given a talk or your manager should be aware of your preference, would you rather go down the technical manager route or the technical dev route.
In technical companies the work tends to be about doing things right, minimizing technical debt where possible.

19 Valuable Github Repositories for Beginners

>> Check out this classic DEV post <<