Is it possible that my experience as a freelancer is irrelevant in the real workplace?

Question

First, a bit about my background: I'm developer/designer who started freelancing right out of college. For better and for worse, I'm entirely self-taught, and always made it to clients what my strengths and weakness are. I was always proud of my work, and my clients and users were always happy, as well. I worked with startups for about three years before deciding to apply for a full-time job to get experience working on larger projects.

By the time I started looking for a full-time job, I had planned, designed, and built several fully functional web applications for small startups or just side projects. I considered myself to be great a UI/UX design, decent at JS, and never oversold myself. I got a great position on a small team looking to revamp their aging application to something more modern. Great coworkers, room to learn new skills and improve my programming, etc. Perfect fit.

However, once we got into the development, I realized (later than I should have) that my approach to UI design and layout is very different from my boss's, and it's beginning to make me wonder if I wasted three years learning the wrong techniques. The best way that I can describe it is this: If you were to build a web app like Slack, or Trello, or Atom (a text editor build with HTML), you would approach your layout very differently than if you were building Stack Exchange, or Github, or even Facebook. I've been building applications the "Slack/Trello" way for four years, and all of my go-to approaches for design don't apply at this company, and are shot down because they are seen as wrong. I'll spare you all the details and jargon, but if anyone is familiar with the topic, I can get more specific.

For the most part, I am looking at this as an opportunity to learn new techniques, and get comfortable working in ways I'm not used to. However, I still feel bad that I sold myself as someone who could take a feature/product from conception to production, and that hasn't turned out to be the case. It's not that I can't (I did it professionally for 3 years), it's that my suggestions are shot down as being wrong or just irrelevant. I feel as though my relevant skills put me back at entry level, or worse: "ux ninja" level.

Is this something I should bring up to my superiors, or should I just keep my head down and do my best to change my approach to fit theirs?

Answer 1

When they hired you they probably checked some examples of your previous projects. You are not supposed to be an advocate of a few specific technologies. You are suppose to be an expert that can bring its own background to the table and contribute to the innovation of your companies projects. Tech-culture diversity is enriching.

From this point of view do not argue in favor of a specific technique (let's say layout) just because its your familiar ground. You are in UX so you know the deal: "First know your User. And than Design for it." Use metrics, usability examples, compare with the competition, etc. You did not oversold yourself, you are just another point of view to the global expertise of your team. Sometimes your solution is the best, other times it won't be. Most of the times the solution is a composite of all insights and eventually reaches a "mature" state.

My advice is: do not focus on your differences (you did not become a worst designer overnight, neither were you fooling yourself about your expertise), focus on the final objectives. You have a target user so design for it.

Answer 2

No experience is irrelevant. However it seems that your approach is a bad fit for the company and team.

Learn the ropes, learn their methodology and move forwards. Your insights approaching problems from a different angle will come in handy and earn you respect later.

As an engineer I have to hit the ground running with widely different networks built in different ways quite often even though at their core they all do the same thing. The most important factor is learning and working with what is there before making any changes.

Answer 3

Learn.

All new positions will have you learning something, but what you learned in the past doesn't disappear or become irrelevant. I know quite a few languages now, and they all work together in my head to make me more flexible. I don't use COBOL any more (who does?!), but some of the things I learned from my COBOL coding days have stuck. Ditto C++/C#, even though I work in VB.NET now.

When it comes to a new way of doing things, trust me, you will have something new every time you swap jobs. From processes and procedures to duties to code standards. The company knows it takes some time to adjust (well, hopefully) and will take that into consideration. If you fall behind by continuing to present your way and fail to take in their way you might have problems. You can turn this on its head by simply doing it their way...but turn your expertise into an asset. "I see we're doing this, and I did it that way, but in my experience I've seen that another way might be more efficient." Most bosses will listen to anything that makes a process better, even if they don't take it on, as long as you have done it their way BEFORE you make your suggestion.

"Hey, boss, I got that project done. While I was working on it, I found this other way we COULD be doing it that's more efficient and takes less maintenance."

Do it their way, tell them your way, let them make a decision as to what fits more in their strategy.

Answer 4

I'd say it's actually a bonus for the whole team. Groupthink only ever leads to complacency and you can guarantee at least some of your users will not think in the same way that the designers do. The more people you can involve in the design and development who have a different thought process or a different perspective, the more likely it is the end result will be successful.

Joining a new team you will always find that they do things differently to how you are used to, but it's a two way street - an opportunity for you to learn how they do things and an opportunity for the team to learn from your experience of the "outside" too.

Answer 5

Flexibility, learning and compromise are certainly important. But in software development I find self-taught freelancers/consultants have quite a different approach than more "streamlined" straight-up development teams*. Freelancers also know that to get paid (ie. make a company money) they should deliver what's needed as accurately as possible since unused/rejected designs/code is unpaid designs/code.

Freelancers and consultants focus on business needs and customer satisfaction besides development. Development teams focus on speed (especially nowadays), delivery and methodologies. The best companies should of course have a right balance between the two.

A rational approach would be:

• Am I helping or disrupting teamwork?
• What are the industry's best practices (beware of unjustified bandwagons though)?
• How do current practices fit and benefit the company's business needs?
• Are current practices beneficial to customers (will it increase sales)?
• What are the tolerance levels of change within and without the organisation?

TL;DR: There is no right or wrong. Discuss and negotiate where you can. Learn and adapt if possible. But you shouldn't discount your passion, skills nor abilities. You may be destined for bigger and better things anyway, one can tell that from your question phrasing.

*If I may, I want to elaborate on this point. On the customer side, it's no point for someone to promise the customer the world and have no reasonable understanding of how to achieve that. Neither should they fail to grasp business needs and requirements. Conversely, development teams should not smash out code and use trendy technologies just for the sake of it. Yes, development teams should have freedom and flexibility to enjoy methodologies they like but they should be aligned (an overused word, no doubt) with customer satisfaction and external and internal business needs. Who knows, maybe down the line you're the person to bridge this "gap", if it exists ;)