Ask HN: How to start afresh in a new domain after years of expertise in another?
Hi Guys,
I have over 12 years of expertise in a particular domain. Now I recently switched to another company in a new domain (based on some overlapping technical skills and good recommendations from my past colleagues) as the jobs were far to come by in my old area of expertise. But, I'm finding it really hard to adjust in the new one.
The biggest challenges I'm facing are :
1. Looking at my years of experience my colleagues expect an expert level of performance. But being new to the domain, I've not been able to meet their expectations.
2. I've tried looking for non-tech roles PM, TL etc., hoping to leverage my management/leadership skills, but my senior management aren't buying it.
3. I feel isolated in meetings where everyone around me are talking the technology and I just take notes or stay silent mostly.
4. When I see guys half my experience are miles ahead of me in terms of the tech skills in the new area, I wonder if I even have a chance catching up ?
Any suggestions / advice is welcome and highly appreciated. Thanks in advance !
90 comments
[ 2.8 ms ] story [ 58.5 ms ] threadAll I can tell you is to fake it til you make it. It doesn't take that long before your lack of experience in the particular subject at hand ceases to be the limiting factor.
Just a thought!
(Which is exactly what I'd love to do.)
I've only been in the industry for about 5 years, but I've swapped company almost every year. When you're a junior, you rarely have the luxury to re-use the technical knowledge from one company when you jump to the next one. You'll carry with you the general development learnings, but specifics about platforms and domains are kind of thrown into the brain garage where they'll stay until you make an effort to dig them out.
Now, you're not a junior. You have 12 years of expertise. These are worth a lot. Even if your specifics might not be as relevant you still have the general learnings. Of course you're not the best guy around when it comes to an area you're new to. Why are you setting these expectations on yourself?
> When I see guys half my experience are miles ahead of me in terms of the tech skills in the new area, I wonder if I even have a chance catching up ?
When it comes to your insecurities about this, just take a deep breath. You'll catch up dude. Everything's a process. Patience and persistence is all that's required.
However I realised they had accepted me because I was an expert in telco, not health. Similarly, I suspect you were hired because of technical skills and not because of your lack of experience in their domain.
As such, I learned the skill of saying "Can you just explain xyz, please?" in a direct and confident way. Context matters, of course. I wouldn't interrupt a meeting. But there's a time and a place.
Hope that gives you something to think about.
- experience with infrastructure, so you don't need to have underlying things explained to you
- experience with team projects, so you don't get mired in irrelevant sidequests and trivia
- experience exercising judgment, so you can survey alternate approaches and pick the one most likely to succeed
- experience learning, so you can come up to speed quickly
- wide experience, so you can apply lessons from your history in the new context
Take the notes, then go back and research them. Figure out what a minimal project in the new domain looks like, and do one quietly. Familiarize yourself with the tools that the new company uses.
Read research papers, technical journals, and all the in-company documentation you can get your hands on. Attend new engineer training sessions.
Figure out what the schedule is for your group(s) and dig in.
If that doesen't help, look for a job elsewhere.
1. Ask a lot of questions at the start. People know you've switched domains and will tolerate dumb questions for a while.
2. Don't ask the same dumb question twice.
3. Read a lot to get into the new head space. Set up google alerts for your company and its competitors. Join forums dedicated to your new tech and domain.
4. Offer learnings from your old domain, humbly. "At my last gig, we approached this <method>. May not apply." This shows everybody you have things to offer but you are just getting your sea legs.
5. LEAVE THE OLD JOB. All of the above things you did for your old gig. Stop doing them, you don't have time anymore.
1.) Really, really, really ask those dumb questions in the first week. Everyone will tolerate it and even expect it
2.) Learn the basics of your new domain / industry top-down asap. Meaning: understand for what your company gets paid for, understand the basic process how it gets delivered, understand the strengths / weaknesses of your company. Know who the key customers are and what they really want. It’s often the new guys who are empowered to challenge those high-level topics while everyone else takes it for granted (and often have the wrong idea in mind)
3.) Always ask a question / say something during the first five minutes of a meeting. It just gets harder and harder afterwards. But as soon as you asked you’re in the game
4.) Bring in experience from the past but try to take the extra mile of translating it as much as possible to the new situation (“at my last gig we did... I understand that here we have... however I see further potential in...)
5.) Ask a colleague to give you a dedicated intro session. Not just a random “I show you some stuff on my PC” but a real one. Typically a nice way for the colleague to reflect on their learning as well and/or prepare a public talk :-)
6.) Be aware that almost no one really knows. They are all bluffing, they are all biased. There are exceptions but they are super rare. Even someone 2-4 years in a specific job will get his stuff done but still struggle with some concepts. On Management Level it gets worse as those guys tend to not have the time to digg into it
Had the best intro in my previous job where the first 2 weeks were dedicated to learning and meeting people. Overwhelming, but good chance to really crack on with it.
- Were there any times you got a job in a new domain without any experiences (e.g. didn't worked on as a hobby project, didn't do extensive learning the new domain by yourself)?
- Any ideas why those employers chose you for the job? (e.g. purely because of your past experience from the old domain? Any specific qualities they saw in you?)
- How much effort (time?) you would normally spend to learn a new domain before applying for a job? Or if time is difficult, what criteria you use to determine that "Yeah, I'm ready to find a job in this domain"?
Right now I'd like to go from embedded to data science, machine learning. I think I have some useful skills. But I obviously can't show much in terms of SQL knowledge. I've used python pandas for a few internal tools. I have a solid background in statistics from uni, but I feel like after some years in industry, people don't care about your uni background anymore.
Three other option is going back to firmware, which I did in my previous job, but I don't want to write more firmware drivers. It's just not exciting.
Additionally I'd also like to do more creative work, I find data science sounds very exciting and I could probably bring a lot of software skills to the team
But convincing the industry to go another path is probably harder than switching fields.
If you are working deep embedded/legacy products or purely on the hardware side, you may need to grab an ML course/certificate to signal your interest, or just network really hard. Having embedded engineering skills can't hurt though.
Before that I hadn't done much more than develop and self-publish several Flash games, sometimes collaborating with an artist.
They chose me probably because they were tiny, could tell I was passionate about games, and they expected I would do more game design than I ended up doing (my title was Lead Game Designer... I did some of that, but I was mostly a producer).
And since I thought it was mainly a design role, I didn't hardly anything to prepare. Once I got there, it was like someone volunteered me for the Ice Bucket challenge and didn't tell me before dumping the water on me. Had a lot of fun, though.
Only reason why I'm not doing it now was because I felt like my coding skills were atrophying the whole time I worked there and that thought made me feel pretty uncomfortable. I'd probably be more successful now though if I stuck with it, though.
I normally ramp up on the company and space for at least 6-8 hours before the interviews start. I take the approach of a customer and try to figure out whether I would buy their product or not. I tend to ask questions about competitive threats and possible pivots that show you grok the market. Sometimes I discover competitors they have never heard of, this sometimes kills the job :-P
If you have the technical chops, you need to show you'll use them productively as soon as you hit the ground.
I'm also both a manager and a developer and can easily plug into multiple roles. I'm happy to roll up my sleeves and program while building the team.
The secret? Stop worrying about not being an expert in the area. Be friendly with coworkers and immerse yourself in the new field. You will pick it up, even if the verbage doesn't make sense at first.
While doing this, exercise regularly, since this promotes neural plasticity, which is needed to learn new things.
With half of these jumps I'd be worried about Impostor syndrome.
With all of these? About Dunning-Krueger.
Also, if you ask a question and it gets shot down, you learn something from that too. You have to figure where the edge is before people start complaining.
I don't agree. You should obviously not attempt to make it appear you know something you don't, but asking questions is a great way to show that you are thinking and trying to connect your previous experience to the current context.
You'd likely expect that it's normal for her to take time to gain a bunch of context about the area. I promise you your coworkers feel the same way about you now.
Take the time to ramp up. No one is expecting gigantic impact from a senior person in their first three months.
Good luck.
Anyways, common for consultants. I think searching for consultant-material would be what you're after.
This might mean to radically change what you do.
The vibe I get from your post is that the situation you are in is the result of a "career move". Driven by rational thinking about salary and future safety.
If your goal is to live a happy, meaningful life, I am sceptical that this approach can work. But I am very open to discuss this.
Personally, being raised very anti authoritarian, I naturally always did what I loved doing or what I was curious about. I'm not super rich and I don't jump around in joy all day. But I have a pretty nice lifestyle that I enjoy.
Would love to hear other perspectives on this.
I would think they are within the realm of our control.
We regret to inform you that starting tomorrow, our organization, our parent company, our subsidiary company, and our affiliate partners will no longer be able to provide you services.
Unfortunately, all of our employees read your post and they agree with you and they have all quit to follow their bliss and have left en mass for Chiang Mai until they can "figure out what that means."
Candidly, we expect a large increase in the number of people working as life coaches.
As a result, we will no longer be able to provide the following services:
- Retail employees to help you - Any sort of clerical work - Coal mining and other energy gathering work that requires outdoor and or physical work - Water plants and filtration systems - Less glamours medical care - All the law jobs you don't know about but which keep our world running as well as it does - And any and all sundry job that aren't cool enough to be in an TV commercial
By this letter, we formally requests you stop spouting your bullshit.
Further, we encourage you to consider the implicit flip-side of your argument that, to paraphrase, one can only be happy or have a meaningful life if one does what they love. The incredibly insulting inference being that people who don't do exactly what they love can't possibly be happy or have a meaningful life.
Good luck with your parakeet farm or whatever it is you do.
Cordially,
The Good People at JustTryingToMakeRent Co.
Thank you very much for your open letter! And thank you for making the world such a wonderful place where coal is mined and plants are watered and everything works so flawlessly.
Is it really impossible to love those jobs? I often have the feeling that at least some of you are in a great mood when I meet you at your workplaces. For example when I visit my dentist. The whole team is always in a great mood, making jokes with each other, being friendly, enjoying the workday.
If there are jobs that simply cannot be loved - I think we should enhance or automate those. Let's start the debate. What job is nothing but shit?
I don't run a parakeet farm. I object to the "use" of animals. One of the things I love to do is write software though. Right now I am sitting in a nice internet cafe. At a window that overlooks a river. Sipping coffee, enhancing an application. And right now I love it. Chances are good that some of you are users of the application.
Yours, TekMol
I would love your help on a dilemma - how do you get past the practical hurdles of recruiters and "X years work experience reqd" & background & credentials?
Like I have an interest in ML and a very solid understanding & passion for math. I have picked up a bunch on my own and I'm sure i can pick up the rest - its mostly just linear algebra / statistics. But working data scientists tend to be grad students/PhDs and have some credentials to prove they are "academic" (because the rest of us could not possibly be "academic".. LOL). How do I get past that?
Companies have been hunting me down and trying to convince me to work for them for years now. Every company craves people who build great stuff and are passionate about what they do.
Shift your focus from what you get to what you give. And everything will fall in place over time.
2. Not talking in meetings is generally something that other people notice to the extent that you should be talking but are not. Without knowing the details of your particular situation (eg, maybe within your company's culture it actually IS a big deal that you don't talk in meetings), I would say that if doing your job requires you to be active in meetings in which you are currently quiet, fix that. If this is a case of you feeling insecure because you feel like others are fitting in better / earning more brownie points / etc, I would posit that this is something that you notice a lot more than others do, and advise you to keep your focus on being good at your job rather than comparing yourself to others.
3. If you want management responsibility, I would suggest the following: a) ensure you are seen as a "set of safe hands" who knows how things work (tech and company processes) and can be entrusted to get stuff done and b) ensure that your manager and peers see you as a competent communicator. Once you are confident that a) and b) are both true, initiate a conversation with your manager about what type of leadership responsibilities you'd like to assume. If both a) and b) are not true, you shouldn't be angling for management roles.
Good luck!
Some specific thoughts:
2. Going the management route might work if you have domain knowledge but lack experience with the tech stack. If it's the other way around this will be a much harder sell in my opinion. Either way, don't be looking for a promotion unless you've been there at least a year, or there's a pressing business need that putting you in the job would neatly solve. They hired you to do a job, they're probably not going to react well to you immediately trying to get a different one.
3. I wouldn't sweat this one. Real time collaboration is going to be the hardest given a knowledge gap, but the real work of design and coding can be done very effectively while conducting research to fill in knowledge gaps when you need to. Your company and colleagues probably care more that you produce high quality code fast than whether or not you shine in meetings.
4. I think it's reasonable to expect you'll be pretty behind on tech skills for the first 3-6 months. If that's the case, I wouldn't sweat it, you'll probably catch up. If it's been a year and you're still behind you might be in trouble, it's time to find a new approach to learning what you need to learn. Domain knowledge on the other hand is a much slower slog. It may take 5 years to get to expert, and I don't think there are any real shortcuts.
Explicitly ask for this permission -- and take advantage of it. If done well, yes, people will drop their opinion of you for a week or two. Then once you "get your feet wet" you'll start making a sythesis between what you already know and the new domain. It will start making sense to your coworkers.
Don't soft-pedal it. Don't try to know everything. In fact, admit to being a complete noob. Starting at zero you can humbly begin to kick ass and get noticed. Walking in the door as Superman? Not so much. If you do that, there's nowhere to go but down.
The crazy thing I've noticed is that people inside domains view technology as the most important part of a job. So instead of learning SexPumpkin 4.0, they'll look for somebody who's already an expert, because that's what we need!
As it turns out, there are a ton of super smart people in the world, but there are only a tiny few people that know both tech and the domain well enough to solve problems well. If you're too busy, lazy, or incompetent to pick up the new tech, then fresh meat isn't going to help. The real skill is to already know a bunch of things people want and be able to transition domains quickly.
You can gain that kind of thing by doing charity work, alongside personal projects.
One of the unexpected benefits of being the new guy and asking dumb questions is that in many cases, you end up solving complex problems that have stymied the org for years -- mainly because they've been so deep in the work they haven't been able to look at it from the outsid.
The worst thing you can do as a technical expert is to ignore this advice. Ask questions. A lot of them.
I brought it up in the next weekly meeting, asked for a resource (book, session by colleague, video anything) from the team already working on it. They recommended a book and I explained that I need to work through the book while correlating the app with the book and working on bugs/features, all the same time while explicitly stating that I need some time/guidance to be up and running.
That was taken very positively and in a few weeks, I was productive as per/more than the expectations, while following the steps outlined.
Don't worry, be pro-active, ask, make a plan with the team and follow it. The more you do nothing about it, the worse it might get. Best.
It seems to me that there is no other way to go other than full immersion and feeling really dumb for quite some time. The thing is though that you really need to depend on an unshakable faith that you will eventually come through the other side. You need to be firmly convinced of this. If not, convince yourself. It really helps to have done these career pivots before (which I have) and that may be the best thing about being an older developer. I know that there is nothing that I cannot come to grips with given time and effort.
Some hints:
Never pretend you understand something unless you do. Always admit "I don't know that" rather than fake it. This rule can be bent for small stuff that you are going to look up when you get back from your meeting.
Take notes (which you seem to be doing already). This is what you will google when you get back to your desk! ;D
Have a really understanding tech lead. Of course, I realize that this is just luck and a crap shoot, but working with great teachers and humane people is always best.
Have faith in the fact that the problems in your new domain are largely (probably) problems of computation that are generally applicable in ALL programming domains. Look for patterns that you are familiar with, like: what are we actually doing here? Reading some data files, transforming the result and storing them somewhere else? Oh! It's ETL! I know this. Ignore the weird jargon and get to the heart of the matter.
Give yourself time to feel like a dunce. You aren't, it's just gonna take time.
- Knowledge of the domain
- Ability and willingness to explain things clearly and succinctly
When questions come up, ask that one person, in private. Some of your questions will be:
- I think I need to learn X, Y and Z. Which should I learn first?
- How do I learn X?
For example, I was a finance guy who switched to tech. Was the worst student in my programming bootcamp. Got a job and found a niche in testing. It met the company's needs and my skillset at the time. 3 years later I'm still not as skilled as other geniuses miles ahead of me but I'm doing great, work is great and my salary is top of market for a lead engineer.
I'd recommend you form deeper relationships with the peers so they are helping you learn. Let them know you value their experience and they will be more likely to help. Constantly remind them, in a passive way, that you are learning. It sounds like they are competing with you, and you want them to be helping you. This will happen much better if you drive it. If you have to, get management involved, but that has it's own down sides and risks.
While I don't have as much experience as OP in my current domain (Which happens to be the mortgage industry ~2 years) I still have the same feelings.
Whenever I would want to get a new job elsewhere I _hope_ that all of my knowledge isn't too domain specific to the point where it doesn't help me later on.
Any extra tips would be appreciated.
Ask questions until you think you understand, then have someone confirm your understanding. Those with experience in the domain will be able to recognize the right questions being asked.
In my experience, most seniors in a company are willing to help you get up to speed if they see that you're actually trying to understand the domain as opposed to just learning enough to get by.
Even though it seems like everyone else has a good understanding of things, this is usually not the case. Often people have bits and pieces of domain knowledge, but not a thorough understanding. These are not the ones who can really help you.
Find someone who has a good understanding that you seem to get along with. Be proactive and ask them if you could pick their brain over a long off-site lunch and then ask a lot of questions.