Ask HN: How to start afresh in a new domain after years of expertise in another?

I've switched domains all the time (CAD/CAM -> Medical Imaging -> Genomics -> Web Development -> Internet Security -> VR -> Fintech), things I've found helpful:

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.

My answer to this is: Do what you love.

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.

Given the audience on HN, you could probably be a bit more specific about the old/new domain and get more relevant advice.

Just a thought!

Depending on your colleagues it might be totally fine to sit mostly silently for whatever time period you need until you start feeling you actually want to say something. The colleagues probably know your background, so they know there are large gaps in what you know about your current industry. Staying silent is at least better than desperately trying to speak of something you don't know about, IMO.

I've found that subscribing to SafariBooks for a few months and reading through material relevant to my new domain to be useful. That said, where you're really going to shine are areas in your new domain that overlap with your previous domain.

Some of your problems seem more like "new company" problems than "fresh domain" problems.

I have done a few major switches over the course of my career.

  Java/R&D -> MUMPS+VB/Medical -> Java/Legal -> C#/Military

The biggest problem was seeing that the common element over those multiple domains is that nobody really knows what they're doing, and everyone is just faking it so hard that it somehow just works anyway. So if you have any genuine competence in anything, you just copy everything that makes even an iota of sense from that into whatever else you're doing, and that makes you an instant genius.

You might have a different experience if you are in a hot spot where everyone around you seems to be smarter than you are, but in other places, the person that has been continuously learning new things on their own initiative for 12 years will catch up within 1 year or less, and will be jetting past everyone else by their second anniversary. The downside is that they will be bored by the third year, and looking elsewhere for promotion opportunities by the fourth.

One time I was listening to Artie Lange on the Howard Stern show talk about how he got interested in watching sports. (This is related, bare with me). He said something to the effect of "You want to get interested in a local sports team? Fine. How much money is in your bank account? Ok, $1,200 in your bank account. Great. Tonight go put $1,500 on the Nicks game. You won't be able to take your eyes off the TV."

I'm paraphrasing. The point is if you bet money you didn't have on a game, your stake in the outcome of that game would be HIGH.

Your challenge right now is, you have no stake in the matter. I heard someone say one time (Tim Ferris?) that success is just about incentives. Again, poorly paraphrasing.

The point is; with the right incentives you can accomplish amazing things. When I was single and dating, I was funny, charming and generous. The incentive there was obvious.

So how do you incentivize yourself to learn a new technology? Easy: create a situation where you MUST learn it. How? Sell (or promise) a project that includes finishing something in the tech you sold (or promised).

I would pick something that is slightly outside of your comfort zone, not WAY outside. The more you must get something done, the more you'll learn. You'll learn fast if you make a habit out of it.

Sometimes you can do it with a passion project too. So pick something that is important to you personally and just pick the tech you want to learn.

Programming is hard, the passion will carry you through the really hard problems.

Once I was asked to start working on an app in a new domain, I had never worked in that domain and without good enough knowledge, working on that app would be crazy. The first 2 days in it and I realized, there has to be some systematic way of going about it.

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.

The expert performance that you should be bringing is not your mastery of this particular technology. Your strengths should be:

- 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.

You may want to clarify whether your issues are with the tech stack or the domain or both; they raise different issues. I think of the tech stack as the programming language you use as well as the major libraries/frameworks/services involved, while the domain is the area of business the software serves. So if you went from being a VB6 developer for a bank to a python developer for a health care company you switched both tech stack (VB6->python) and domain (banking->health care). Some info on how long it's been since the switch might also be helpful for gauging reasonable expectations.

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.

I've done this most of my career. There is some great advice already in comments here, but if I had to boil it down to one thing, it would be this: have permission to be the new guy and ask dumb questions.

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.

All great advice here. One other thing to consider is if the roles were reversed. What if you were still in your old field and a new senior member joined your team? She has 12 years of experience, but not in the field. What would be your expectations of her?

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.

I speak from my experience as a contractor in the telco domain, whereby there I would work in some industries I had no clue about. For example, I once worked in health and had no idea about the amount of regulations they had to adhere to.

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.

1. Act like you belong there. If you internalize the idea that you're a bit behind everyone (esp for your age), that you don't really "get" the tech, etc, etc, then your demeanor will reflect that and people will pick up on it; humans, even nerds, are social animals. If you're feeling especially insecure you should reflect on why the company hired you in the first place, and what particular skills or aptitude you bring to the team, and why that's valuable. If the answer to that is, "I don't know", then you're probably at the wrong job.

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!

Make sure you understand the basics of the new domain extremely well. You don't need to know everything in depth, but every piece you do know needs to fit together in your mind.

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.

All I can say that sometimes I feel the same.

You have to accept this: you're at the mercy of your managers. If they hate you then you have no chance, OTOH if they love you, then you don't even have to lift a finger and you will be just fine, even if you're slower than you'd expected. Managers usually trust people based on gut feelings. I am still yet to see a competent manager who can evaluate the skills of his subordinates properly.

Also you didn't mention why did you join the new company in the first place? You have acquaintances working there? The company looked interesting from outside? You had met some employees in a tech meetup/hackathon earlier? Now we can only make assumptions.

Also make sure that you know why they hired you! I can't emphasize this one enough. Many times companies hire experienced people to do mundane tasks under the impression that they will do the shit that everyone hates faster. If this is the case, then RUN!!!! If it turns out that the new company has no roles which an experienced developer could enjoy like leading a team, or participating in design discussions or being a product manager then it's again a sign that you should just simply leave.

One other thing: smaller companies have a flat hierarchy. So there is no chance to step higher on the ladder. You should also consider if this is the case. In small companies it might take years or even decades until you can advance in your career. That might explain why they didn't put you in a PM/TL role.

There is one thing that many people in the tech industry overlooks: there simply cannot be everyone a tech lead/manager. The earlier you join a company or department, the better your chances are.

Also, some companies have seasonal busy periods. If they hired you during this busy period you might feel higher pressure. This might ease by time and you shouldn't take it personally (and you can even ask if that's the case).

Study. Learn. Listen to what your more experienced colleagues say, even if they are half your age. Basically, do what interns should do, because you are an intern now. And be thankful that you are not being paid like one.

I've worked in a number of domains. My CV looks pretty unconventional. I went from telecomms, to renewable energy, then embedded electronics for instrumentation, a stint in academia, from there to high power radio and TV broadcast and now particle accelerators.

They are different industries but have the common thread of engineering with a heavy electrical and electronic bias. I think that is the secret, to have enough of a common thread and to bootstrap using knowledge gained from one industry to move to another. Also, systems analysis and problem solving generally transfer pretty well.

At my company I find the culture mildly frustrating because we do so little to educate the new hires. Our method is to hire experience. So we now have a group of 25 design/engineer level people with a variety of project methods and a ragged list of skills. Because of this we can only accept small to medium projects. We would not be able to execute a large project because we don't have a large team, we don't have a uniform background or uniform method.

In my first engineering job there was training path and there was a "company way" of doing things. We hired all levels of experience and trained them on the skills and the company way as needed. I know a predefined method of project execution can be stifling, and that sometimes happened, but it was a good place to start.

At my current place, a person can roam the halls or chats and ask questions, but it is just too random. If someone is not delivering up to expectations, the engineering manager will visit tell them to improve. That is not what I call training. While it does work, somewhat, those who survive it simply reinforce whatever method of execution they develop in their own heads. The company grows by adding a small revenue stream, but not in the ability work together.

Finding your spot, developing your skills, learning your domain are mostly your responsibility. When you say "jobs were far to come by in my old area of expertise" that implies you are now in a better area to find a company more suited to you; maybe a more mentoring company. I agree with so much of the advice given to you so far. I will be working on myself using what I have read here. Some of the advice, however, was targeted at the time before you changed jobs. That is still possible.

All four of your numbered points are about ego and politics. If that's what you're thinking about, worrying about, and spending time on, that's (ironically) the reason for all four problems. What are you doing to learn the new technology?

You're an expert in some ways and a beginner in others. Now that THIS is your job, you're a beginner in more ways than you're an expert. Act like a beginner does, ask lots of questions, learn the hell out of the new stuff, take notes like you already do and then follow up on them later - look up every single word or concept you don't understand.

Don't believe you should be "having input into things" in meetings because you shouldn't, you're a n00b. Listen and learn like everybody does when they're new on the job.

Don't let colleagues or superiors have "expectations" that were probably unrealistic all along. You need support, and time (mentoring possibly too, but mostly time, if you have a modicum of initiative), to learn what you need to learn. You're not going to be "productive" right away. If anybody hired you under any different expectation, they were mistaken and now need to be corrected. If you had any different expectation, you were deceived as well. If you sold yourself as an expert, that was only partly true. Come clean now. If anybody feels it was not a fair deal in light of this new understanding, then you should offer to end the deal i.e. resign.

If it feels awkward to suddenly change your behavior, you can make an announcement: "I thought my experience would serve me better than it has, so now I realize I'm a n00b and will commence to bother you all constantly with n00b questions." I guarantee the humility and the request for patience will result in a truly awesome outpouring of support. OR, you work with douchebags and should resign.

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 ?

Yes you do, but these guys are not "half your experience" if they are miles ahead of you. If you played hockey 20 years, you'd understand a lot about teams, athleticism, and even the general principle of moving an object down the playing area toward a goal, as a team. Basketball is like that too, but since your basketball experience is 0, you'd still be worse at basketball than someone 19 years younger than you who played basketball for 1 year. And actually, you won't "catch up." All you can hope for is to have one year of basketball experience after one year.

I can only help with 3 and 4, but I'll do so.

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.

Consultants deal with this constantly. Most in my company change project every few years. New customer, new domain, new technology etc., and we do just fine. I think it's the mindset, is it your expectations you're not meeting and not theirs?

Anyways, common for consultants. I think searching for consultant-material would be what you're after.

I'd add that at some point you want to discuss this with your manager. It might be entirely self imposed. Try to figure out if they are displeased with your progress thus far. Your colleagues think they should have hired someone with 12 years experience in this domain. You manager knew they would need to invest in you before you reached the level of your peers, even those with less overall experience. So long as your managers are happy, that's what really matters.

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.

About a year ago, I switched from full-time Java development (15 years, mostly server side -- some Swing) to full-time Javascript development (React at first, then Angular) with all of the mental anguish that the amazingly arcane world of modern Javascript entails. I did have a little bit of a leg up in terms of previous html/css experience, but other than that it was a whole new world.

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.

Define what "catching up" means. If you are like me, you have some idealized version of an expert in this domain, and you may or may not have the right idea. What does success mean in this field? What does success mean in this role? Often times we set the bar impossibly too high, and it makes us procrastinate getting started even more. Set a relaistic goal after researching and conceptualizing what "proficient" means, and break up how you will get there. Believe in the law of serendipity -- lady luck favors the one who tries. By even doing this you are already succeeding. You have my fondness. I hope it works out well for you because I am sure we will all need to do something similar at some point in our lives, especially when the big AI monster comes and eats all our jobs. (last part is a little facetious)

I belive the transition to the new domain - that the new company knew about very well - should be assited by the right tasks to learn. To learn! - which is something we do day by day even by hanging on to existing domains: we miss and we fall. The process of learning will uncover the parts we can ask about. To ask! As others already mentioned: asking helps. Assuming you know what to ask. That's where the learning process helps itself: uncovers dtails and further topics to ask about. Asking includes not only people but information sources like Google and Wikipedia - and the kind you will discover on your own as relevant one to your domain. To me usally the process of learning the product first as a novice client on a basic level is the best to start with (ideally joining an introductory course). Not being sad if half of it is in greek. Remember the greek part as something to study next. Then - or maybe instead of it - receiving important but many times neglected tasks of documentation and testing, fixing outstanding tiny problems also helps. Carrying out these gives the satisfaction to be useful and so boost confidence, which in turn helps asking 'silly' questions. Newcomers ask silly questions, this is a fact, no way avoiding it and should not be avoided since these show lack of fundamental knowledge that the newcomer do not posess yet. Still newcomers afraid to ask because they lack some confidence (at least I do in such situations) so anything that boosts confidence a bit is a huge help. So small but important tasks might help a lot. All this is impossible without the assistance of the domain experts and the experts of the company culture (since the answer many times is not in the logics of the domain but in the culture or even the history of the particular company). It should be accepted that your initial pace is slower due to the requirements of the domain and company switch that comes with things to process. I believe the situation should be discussed honestly with the superiors as the least. They are as interested in productive work as you are and they may not have that high expectations for this period as you may think (being aware of your transition).

At a certain point you have to crunch, but you should take notes but also share your notes. Present lists of questions from the notes you took last time and show off the fact you are trying to catch up. The most frustrating thing to a lot of teachers is people that nod along and then ask the same question next week.

Also another good thing is to dig and ask around for older documentation/simpler versions. It is a lot easier to sometimes work at the task at hand if you can compare the naive version to the one with hard-won fixes. Sometimes the simplest explanation for what you need to do is the first few times the idea was pitched, not where it is now where that is an accepted norm of knowledge.

One bit of advice that I learned in art school and think applies to all sorts of learning is: "Work general to specific". When painting, you first block in large sections, then break those down into smaller sections, smaller and smaller until you arrive at the level of detail you want. I'm now a software developer, but take the same approach when learning a customer's domain or a new language or framework. I first get the "big picture", then break that down further and further by reading, asking, and listening.

Re number 4, yes, you have a chance, unless you got fired today. Have the attitude that you can and will learn this domain and quickly become an expert.

Search for areas of opportunity where you can make an impact with your current skill and grow from there. There are gonna be pockets of opportunity your org can't attack just because there is too much to do.

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.

1. Commit to starting over and learning with fresh eyes

2. Don't rely on old knowledge or pedigree as a crutch

3. Humble yourself to your colleagues and ask questions

4. Seek out mentors with the expressed purpose of learning

5. Understand that new beginnings take time and purpose

I'm doing this right now - Video to MES (manufacturing.) This isn't unusual at all - you understand the value of domain experience so do the things that will make you an expert.

1) Give training sessions to those who are also new. It will force you to learn the software. 2) pick up pager rotation. Supporting the software will force you into new areas of the domain.

Those are the things that will get you there fast. It's scary and hard but just wait 6 months to a year or so and you'll be effective. Any new domain that is sufficiently interesting takes a long time to get into.

I think it's important to stay up to date on technologies/fields outside of your area of expertise so that the eventual switch to another domain is less of a complete overhaul for you.

1. Complete most your tasks on time.

2. Complete all your tasks on time.

3. Come up with new ideas related to your domain.

4. Implement at least one of your ideas.

If you manage to do that within a year, you'll be a good asset to your team at any given point. No one will excpect you to start at step #4. Be humble and keep asking questions until it's clear in your head. The tech world won't change tomorrow, cold, big ego, etc. though, time is your friend in this case so just be patient and follow those steps.

I have done this few times and for me doing a side project in the new area always helped. Few other ways: - online courses - books - take notes, but do read up about them - see if the new team has a 'new joinee getting started' kind of document

Lastly I strongly recommend letting everyone know you are new to the domain. At the min. it will set expectations and usually you will get pointers.

I worry about this sort of thing often.

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.

Learning is social. You can pick up a lot "telepathically" (i use this word loosely) by just spending time with practitioners. They can give you the proper orientation and guidance. Just remain open, humble, courageous, empathetic, and persistent!

Very good advice here. I have done it twice. The first time around I grew fast and was happy. This second time I am unhappy as the organization is slower, less nimble and very little room to grow and learn. I hope you will have luck with your choice!

Just wait for your turn. Spend more time than others. Start with one initiative or issue and see it to the end. Focus on one thing at a time. You seem to be overthinking. Such initial hickups are common. We all have gone through them. All the best

Here are some things I've found helpful:

1. Most importantly, set your own expectations correctly.

No matter how you slice it, switching domains after years of experience is going to be tough. That's not to say it isn't the right decision, or won't be incredibly rewarding. It's just going to be challenging. I've had more personal success in these scenarios after accepting that fact, and not being so hard on myself for the ramp-up time.

2. Identify people with expertise, and talk to them.

Don't get stuck in a research/reading rabbit hole. It can be tempting to sit back and try to replicate your prior expertise by reading/studying your new domain. Rather, find people you identify as experts and talk to them. Learn from their experience. Chances are it is your experience that made you an expert in your last domain, so do your best to learn from those with experience in your new domain.

I hope this helps!

Identify that one person in your company who has both:

- 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?

Can you give us more detail about how different the two domains are?

I assume it's not something like switch from web development to mobile or to dev ops. Something like from programming to data science or quant analysis?

Start afresh by addressing the issue of your experience with your boss and setting expectations based on your current experience.

If that doesen't help, look for a job elsewhere.

You biggest advantage is your ability to learn. Don't be afraid to start learning the basics of the new domain.

Sorry, to be clear, is there an actual (e.g. performance review?) problem, or are you just feeling imposter syndrome?

It depends, if this new field is something growing, something with a perspective (eg ML, crypto) then keep on. Your insecurity will be your biggest motivator pushing you to the limit. In one year you will be better than your peers.

If this field isn't trending (eg VBA, print) then just look for another job.

In other words: Can you boost your personal market value with this job in one year?

What is the particular domain?

You sound like me.

All 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.