First, meet 1 on 1 with every member of your immediate team. This of course serves as a "get to know you" meet, but your real goal is to get them to explain their work to you. Have them go into as much detail as time allows on whatever they're currently working on. Ask followup questions that start with "why" on everything. Have them show you their part(s) of the product, have them share as many docs as they're willing to (for you to read async later), etc.

Put aside whatever ego you may have, and just get into a beginner's/learning mindset. Ask all the stupid questions.

Then, at the end, ask them who else they're working with from other teams. Put those names on a list, and rinse and repeat with them. This way you'll start local to your role and work your way outward in the company. Eventually you'll find people that are doing nothing particularly relevant to you and you can decide to stop.

If it's a larger company, this is also where you establish your understanding of the org chart and who does what in it, and also makes you known to a ton of folks who may want or need to work with you in the future - which is invaluable in and of itself.

Taking notes during or immediately after the meeting, then synthesizing them to form a narrative is also helpful when you're meeting so many people.

The other thing I do is start a file literally titled "Everything I know about <company>" and just write everything down. I make diagrams, write sentences with highlighted blank spaces for gaps in knowledge, etc. As you get to the 10th meeting, you have a decent mental model of how things are intended to work, and have probably heard about some of the systems the 11th person works with. When you communicate some of your understanding of the system to them, they can fill in gaps or correct misunderstandings.

The other thing I always ask about is what a cadence or work looks like? Is there seasonality in their availability? Finance/accounting are best left alone the first week of the month as they're dealing with month end. Some people are slammed Monday and Tuesday, catching up from things that happened over the weekend. If an entire business is seasonal, it makes sense to prioritize heavy lift projects to the off-season.

One form of seasonality is associated with financial years, in some industries. I found this working on contracts for UK govt agencies, where the FY runs from April to March. The customers usually procrastinated about letting contracts, which sometimes wouldn't appear until after the summer or even just before Christmas. Then there was a mad panic from Jan to March to actually spend the money and submit those deliverables. It followed that the time to do training, internal projects, housekeeping etc, was in April and May.

Identify people they don’t work with, that you would naturally assume they would. Typically this means:

Your understanding of how processes flow in this industry has some gaps, or some thing you thought was crucial is a solved problem that people don’t think about; or

There is tension and some history here, tread lightly while you figure out the office politics; or

You’ve identified a legitimate opportunity! Be careful here though, you need to understand if some higher ups have misaligned incentives to keep the status quo before you suggest changes.

My additional recommendation would be to try to identify limited-scope projects that contribute to your role and where you can start delivering some value. For me this helps set a clear goal and it is usually easier to identify the specific skills/knowledge/information/contacts I need to complete the task. It also usually feels motivating to check off those early projects.

If you are in a leadership role over a team then having a pre-chewed problem ready for new members of your team is a very useful thing you can do. I'm talking well defined problem with a clear path towards success. This helps the new member become use to the team and processes, and gives them an easy win to put some wind in their sails. Also, this can serve as a litmus test to their on the job performance.

Unless they have very good reasons and offer an alternative ("I'm on deadline so can't talk now, but after this sprint I'll have time.") those individuals are actively sabotaging the team and should be dealt with accordingly.

I had two cases of having a toxic coworker and only being able to get them fired after leaving myself. (Step 1 is “oh shit, we lost an important team member”, Step 2 is “aha! we haven’t been able to replace that team member in six months because of the behavior of the toxic employee”). Next thing I see the person is on LinkedIn looking for a new job.

Also, I have tried this on a team and one or two would do it but everyone acted like they are too busy. Basically, it was hard to get one on one time to talk to people on the team outside the manager.

Depending on how toxic the job is too, this could be used against you. I don't think it should, but if they expect a mid/senior developer then they could see this as not being senior enough.

How do you handle the above concerns? Both to make people make time for this and also how do you defend against it being used against you? Yes, there is a grace period. But then it feels like even with a grace period, some still find a reason to use it against you.

Do you really want to work for a team that looks down upon you for trying to learn/appearing like you don’t know something?

That’s like a Petri dish for growing imposter syndrome.

One tweak I do is assume your grace window is half the length you're told or believe. Building up a bit of momentum in case it's needed if something comes up is helpful.

This so much.

Play fool to catch wise sung Bob Marley and it works wonders.

It’s also a fantastic way to get to know how the org is doing, many people will be happy to share what parts of the product they’re happy with and where the dumpster fires are.

I also think it’s useful for the people you’re talking to as they get an opportunity to reflect on what they’re doing and if it makes any sense. It’s like an external auditor or reviewer coming in. Just pronouncing what you’re doing in a way that’s understandable to an outsider can be very helpful in building your in understanding imo.

Totally. It's the same idea around rubber ducking!

Another strategem is to ask the people you meet with 1:1 how they feel you may help them be more successful. What can you do in their current workflow that will spread load, help you learn, help them succeed.

Most times you get "just happy to have you on board" but you can get valuable feedback as well as an understanding of stress levels of others on and off team.

Here are my tips:

1. Schedule time to ask questions. Domain experts' time is valuable, and you don't want to be interrupting their other work, so if you can build up a list of questions and schedule a 30 minute period to ask all your questions, that uses their time more effectively, and also gives them the opportunity to take the time to answer the questions you didn't ask. (OP doesn't appear to be a freelancer, but for any freelancers reading this, I don't bill for this time, which helps clients to feel they're getting something worthwhile from it).

2. Ignore "rank". The people on the bottom of the totem pole are often the people who know the most about the domain because they are actually working waist-deep in the domain. There have been cases where I have used my seniority to escalate problems or promote ideas from, say, an intern or junior, that were likely more valuable than the development work I was getting paid for. When you do this, be sure to give credit where it's due--people remember that sort of thing.

3. There comes a point somewhere in the 3-6 month mark at a job, where I start getting a lot of anxiety because I feel like I should understand the domain better than I do. This has never, in my experience, been anyone else's expectation. It's just impostor syndrome.

I've approached it by reading and thinking about the company's relationship to it's stakeholders. Understanding and writing mini-essays on the current customers and their pain points, the main competitors and their products, the history of the industry/segment and more.

Information sources include YouTube, podcasts, press releases, news articles from niche sites, research paper summaries and various websites.

Networking of course plays a role, where I've sought out friendly people a few years ahead of me when it comes to industry knowledge. Mostly through existing contacts I'd do this again if I needed to, and would make sure to leverage each new contact to introduce me to further relevant people.

I've asked ChatGPT specifically to detail out how a MBB-consultant would approach the knowledge acquisition challenge, as they are adept at quickly navigating and learning a new field in a short amount of time. This has helped somewhat and suggested I'd sit down a perform a few different types of analyses.

As for rote learning, I've bought into the Anki flashcard system where i study acronyms, enemy materiel NATO designations, specifications and more.

To wrap up, I've studied finance myself and I have a strong feeling that there's a low correlation between financial-academic success and proficiency in marketing in the industry... Best of luck!

Joining an industry/domain/organization also means learning the language there. The acronyms are vocabulary.

1. find a good text book in the field as narrowly construed as possible, and just browse the table of contents.

This will give you a quick map of the field, and a place to put all the info you gain.

2. Read the management discussion in the 10k of a public version of the company you work at and 2 leading customers, and the transcript from the earnings call.

Fastest way to get up to date on challenges.

YES! Management's Discussion of Risks section of 10ks is amazing, and really easy to read.

I think it's nuts to work at a public company and NOT follow your employer's 10ks and earnings calls (at least on and off, or at least when newly hired as well as for context any time there's Big Corporate News)

It really helps cut through management's BS when you can just read how they're describing the situation to the shareholders rather than the spin for internal audiences. It's the One Secret Trick that will give you an idea of what the motivations and interests of your company's leaders are, as opposed to what they claim or you guess that they are, which then ends up being super useful for say, judging which project has a better likelihood of becoming important, how to sell things internally, etc

I used to work in tech at an investment bank. When I first joined I was all starry eyed and eager to learn about the business, even to the point of trying to get a CFA (which some of my colleagues apparently had done).

Fast forward many years, I came to the conclusion that the limited time I had was best spent becoming a better technologist/engineer instead of a halfassed banker/trader/investment professional. Of course it’s still useful to know the basics of the industry and anything specific to your role, but beyond that the returns diminish sharply.

FWIW most of my engineer colleagues that spent all that grueling time and effort to get a CFA no longer work in the finance industry, so it’s arguably all down the toilet unless they ever go back. AFAIK none of them want to

1. No-one’s going to go out of their way to guide you. Esp at smaller companies, the fact that you’ve been hired means you’re joining a time-poor company, and there likely won’t be a formal onboarding process. So...you’ve got to onboard yourself.

2. Adopt a mindset of personal responsibility. This isn’t going to be a passive process, but an active one.

3. Don't meet everyone for the sake of it. The goal isn't to set-up endless meetings and become a burden. Limit yourself to a few, and make the most out of them. Make your ask clear when you ask someone for their time — e.g. 'I'd like context on X and what's been done so far'

4. Get some small wins on the scoreboard. Although your priority is to learn the key skills of the job, you also want to make a great impression during your first 60 days by showing you’ve made an impact. To do that, identify some smaller projects you can knock out to get a few small wins under your belt.

5. Be ‘seen’. Make your presence known. And communicate upwards so people know you’re busy. How? Tell your manager, “Can I send you a list of 5 things I think I need to hit the ground running? I’ll then set up a 1-1 and we could go through that.”

the full essay's here [2] (and plug: the newsletter I write is called Coached. If occasional career strategy is your thing, feel free to check it out)

[1] https://coached.com

[2] https://careersupplement.beehiiv.com/p/cs233-onboarding-hard...

Your point 3 validates that as well.

Pluck some of the low-hanging fruit so they can get to know you and try not to be a burden on the core maintainers. And...have fun?

It's why being a loud jackass that deploys something horrendous has better outcomes for your career.

Ive done these rounds at every job and 2 times I left that job immediately after the interviews.

Why?

* Putting in time to learn the product as a user of it before trying to develop for it is time well spent. In my experience it makes it easier to read the code afterwards

* When a codebase is old and you're reading a file where 10 to 20 developers have done a pass of bugfixes on it, it may not immediately be obvious what everything does and why some checks are being done. Going through the history and checking earlier versions of the file sometimes helps me getting the basics of it down

This should always be priority #1 when you first arrive. Not only is it beneficial for understanding your work, but you can never get back that opportunity to see through the eyes of a real user. Once you get used to a product, the warts will be less apparent.

Put the product through it's paces, and take notes on what's confusing or unintuitive. You don't want to tell everyone their baby is ugly immediately, but you can slowly address at least some of the issues over time.

Much of it will be foreign. Over time, more and more will make sense. It will begin to gel.

Take notes on words and phrases that are unclear. Google them. See who you can ask about help (see the 1:1s strategy).

Repetition is important in learning. Everyone learns differently. I like multi-modal reinforcement. Listen in groups, QA in 1:1s, read books, search Google, try by doing. It all somehow comes together and all of a sudden you're riding the bike without paying attention to your feet and hands.

By the end of the first days it is clear to me that most people there, even some veteran product managers have a very incomplete ideas.

By the end of the first few weeks I generally end up being the most knowledgeable person in the team (or at least among the top) because generally most people don't give two damns and are there for the paycheck so I'm reminded of how low the bar is in pretty much any environment.

A nice side effect of my approach is that you end up learning a terrific amount about the other team mates and you force people into questioning their knowledge themselves.

Anytime I got stuck on a problem for more than a few hours, I asked the greybeard for a quick chat. He was pretty always willing to hear me out, let me break down my understanding, then rebuild all my faulty assumptions. His time was relatively cheap but his knowledge base relatively valuable, so with him I did deep dives.

The smart hacker guy I watched from a distance. Any time I saw him merge some ludicrous Rube Goldberg type commit I’d send him a quick DM, knowing his time was precious. I’d fire off a few quick questions and try to glean as much insight into his critical work before he scurried off to the next apparently invaluable task.

I think approaching the problem this way, leveraging the “implicit theories” embedded in the teammates heads, is the surest and most efficient way to ramp up, besides the obvious advice like RTFM and gloss over the relevant textbooks. Always remember to make yourself useful first. No accomplished engineer will ever turn down a well intentioned and friendly favor! “Team work makes the dream work,” as they say.

Good luck!

To speed it up, write an interview script with a set of questions. Use an LLM to make the questions non-leading if you want, but point is to show colleagues who have customer contact your script. If you manage to do the interviews, record them, transcribe them and share them around. You are now a customer advocate who knows the customer's needs and wants.

Don't wait with doing this only after you've met the team, start immediately. Let this be your driving force to meet colleagues. It's useful, offer to share the results, or ask for question ideas to whoever wants to listen to you.

You now have laid the groundwork for your success. Now you can focus on the organisation, the team, the mission, the proposition, etc. Everyone you now meet, talk about how customers want to do A or B but can't, or about their challenges. People will appreciate your insight and you're off to a great start!

Generally, there's no hack around learning, other than learning more efficiently. The faster you dive in, the sooner you'll have a sense of what you know (more than you think) and where to actually focus in the next 3-6-9-12 months.

There is a course called learning how to learn that focuses on how adults learn differently that's worth checking out before going into fintech or other topics. Highly recommend checking it out as a first stop.

Fintech is a broad and vague category, not specific.

In this case if it's new to you, focus on first principles learning whether it's in finance, banking.

If you can saturate your time, consciousness with meaning full content, there is a good amount of passive spaced repetition from hearing different explanations of concepts. Podcasts can be helpful, but for learning you will probably find some things on youtube to subscribe to and work through. Have a playlist ready to go, whether it's in your ears, or on a speaker while getting ready in the mornings.

First principles learning means learning the basics and using that to build up to the other concepts. Luckily it also can mean learn it like you're 5 and don't expect to learn it as quickly as something that is partially familiar or similar. When you do this, your brain will point out what's familiar or similar anyways.

What's nice is if you're not great at math, there's still a lot of people and process interactions that can have value added too. The math can be learned too.

I haven't gone too far out of the way to learn aspects of finance other than through exposure and osmosis. As long as there's someone on the team that really understands it on a deep level, you don't have to be that person to be effective, at least on the frontend (which has been my focus for this client, although I am doing a bit more backend now).

Hasn't stopped me from implementing complicated features as requested and discussed, just asking questions for what's expected, what the data should look like when it's done correctly, etc, but now I do understand it a lot better and I can mostly follow along during deep discussions (some of it still goes over my head though).

That being said, you can pick up books on finance to help you understand things better. For me, I discovered recently (stumbled upon it at a used bookstore, actually), that I should probably pick up textbooks on Quantitative Investment Analysis and Portfolio Management in order to understand those deeper discussions better, but the focus of your startup might be different.

I think all the other comments saying "read a lot" and "talk to everyone" are correct first steps, but for me, consuming information has diminishing returns after a short while. After you've reached a point where your brain feels like it's exploding, you should switch your focus to outputting information.

If you're a "write things down" person, then write a synthesized document explaining everything you've learned, and then ask a few trusted coworkers to tear it apart.

If you're a "talk out loud" person, schedule time with coworkers to have a "teachback session" where you give a presentation about everything you've learned. Again, ask them to tear it apart.

It's crucial to build trust with a few coworkers who are willing to critique your output. Get them to rip everything you've created to shreds. Whenever you write or say something that's even slightly off compared to how someone in the industry would say it, make sure you learn about that, and learn how someone in the industry would say it.

This focus on getting the language right - especially the colloquial language of how people actually describe things day-to-day - is important for every role, but I assume it's especially important in marketing, where you need to be able to use the precise language that your customers use.

tl;dr: Read/talk to people at first, but switch to writing/presenting ASAP. Solicit and internalize as much critical feedback as you possibly can.

First - recognize that there is a significant difference between the two.

Second - chat with peer PMMs, Field Marketers, Growth PMs, etc to get good tips and advice.

Finally, I recommend reading Monetizing Innovation [0] in order to understand the Packaging and Pricing portion of Product Marketing. For Content Marketing/Demand Gen, I found Hacking Growth to be useful, but honestly there are a number of YC and adjacent podcasts that are fairly useful for that.

Finally - if you feel you don't like the role or the space, make sure to let you CEO know ASAP and make a transition plan with them. In my younger days I burnt a bridge with a good friend when I became an inexperienced VP Marketing/Demand Gen at their startup.

[0] - https://www.simon-kucher.com/en/insights/monetizing-innovati...

Scenario 1:

My first job out of college was developing automated pretty HTML for emails for this marketing company in the hospitality industry. It was still start-upish at that time, so the business was centered around account management and business relations. I was hired to be a developer, so I found problems to solve. When those solutions saved business relationships I could walk on water. I got good at task lists and account management even though account management was handled elsewhere.

Scenario 2:

I once did cyber defense for the US Army back before Army cyber was a thing. I started getting pretty good at it until I was promoted out of that organization into a logistics organization. All that cyber expertise didn't matter so much anymore, I had to be a manager in a group that different things. I was basically a people manager of a help desk plus other stuff. In order to protect my staff I had to learn logistics. I had to know how to do other people's jobs so that I could push back with better answers when leadership made decisions or other managers tried to poach my people. I have now been in logistics long enough I know the management of logistics operations better than many of the logistics managers even though I am just the IT guy. This provides me a lot of pull.

Scenario 3:

I spent a lot of time as a developer in the online travel agency space. I learned a lot about the retail side of e-commerce and the behavior of travel planning. As a junior developer I was promoted to a senior in about 2 years because I the A/B test guy for this major .com brand. I learned to master DOM traversal without abstraction layers so I could write tests really fast that did amazing things and were often more durable than the actual real code later released to production. Because I had also learned the business of e-commerce and the travel industry I could also design better tests and than many of the business owners recommended. So long as velocity, durability, and quality of test remained high I could walk on water.

Showing an interest is important, learning the lingo is important but it will be a learning curve and it’s important not to expect too much from yourself too soon.

What were some of the reading material and books? What area of fintech?

I went the other way, from finance into non-finance. And from bigco to smallco. It took a solid 6-12 months to start feeling competent. It was worth it. I now have a lot more breadth on the business side, and technical depth from having to read code to learn a bunch of new stacks and end to end integration flows. At the smallco there wasn't much for docs to read, and the ones they had were out of date.

Forcing myself into the mindset that I had to explain it to others in a meaningful and comprehensive way - AND to be prepared to answer questions - I learned and understood the product in record time. It wasn't perfect, but holy moly was I motivated to know it well enough to explain it.

I ventured into a new domain 3 years ago and got comfortable within one year. Then found out I know nothing around year two. Then again. Back and forth. True seniors, experts, whatever you call them - they don’t get comfortable.

To clarify, sometimes I get the sense that the sort of people, also like myself, who come on here, have this delusion that this tech stuff will cheat reality. That you do this and that, you play your cards well and you will skip ahead of everyone else in all the other professions in society. A sort of technocratic megalomania.

I absolutely do not know that the OP is like this. My experience „switching” domains is that it can help to find the common familiar denominators with what you know in the new thing. And then, like an anthropologist, to develop a respectful understanding of the people who are experts in this domain. You keep it respectful by recognizing that you’re not going to catch up with them. It’ll be their job to convey to you what their problems are, and yours to listen carefully. You might be good with that hammer you’re holding from your earlier experiences, but they might not even have nails for you to bang on. That’s where the discomfort comes in.

There are probably old time finance people running the company ir advising it. Find out what they did back in the day and look at things from that point of view.

1. Immersion. I learn more German in Germany when I visit for a week than I do in months of study. Why? Because I can see it all context. I can guess what a Hauptbahnhof is context, and other words. You start to see the patterns. Work is much the same. Get in there and learn! There is a reason why the first thing every software developer should do is fix a pretty easy bug. It gets them to do so many essential things they will need to do day to day as part of their job.

2. There are no dumb questions. "What is Alpha?" "What are the Greeks?" etc. All VERY valid questions. If in Star Trek parlance if someone says to "Tech, tech the tech." ask some questions. :) (Tech was used by the writers as a stand in to allow them to write the script without looking everything up.)

3. You have time. Nobody expects you to know anything. Ramp up for an industry to basic levels is usually about 6 months.

4. Suffer. Try to learn the concepts. This won't always work, but it'll teach you tons of extra concepts you will need later. Time spent learning is rarely totally wasted. It just may be the knowledge you need to cross a gap later. Also it makes it obvious to the people around you, you are trying, thus you are more likely to get help.

5. Don't be afraid to be stupid. When I used to work with TLAs a wise boss once told me if he didn't know what some word/acronym meant. He'd just ask.

It was amazing how many times nobody in the room could expand it. Despite us all working with it ;)

I've picked up this habit from him. It hasn't hurt me... But it can be a great way to rattle people.

If you're not, you won't.

Nothing else to it.

Get a ChatGPT4 subscription and ask away. It may hallucinate, but it lets you ask questions and immediately clarify points you don't understand. When you get the basic understanding, check it against a more reputable source (e.g. Investopedia?)

Here's an example question (which I obviously made up):

"Hi! I'm about to get a job in finance but I feel that I don't fully understand some of the important concepts, such as compound interest. Can you explain compound interest to me?"

https://www.amazon.com/Dictionary-Finance-Investment-Busines...

And since the resale value is extremely high, so you can always resell if/when you don't need them anymore, possibly for a profit.

whenever you see a term or concept you don’t understand, WRITE it down. The brain-body connection works well for your memory.

I’m gonna get flak for this, but going out drinking and to the smoking area will give you an inside track to how the company operates.

edit: actually, i've seen this work. The marketing person has to be honest and upfront about being new and take down any questions they can't answer and then follow-up. I've found clients/customers to be sympathetic, everyone has been thrown into the deep end at some point in their career. A humble and honest approach can even endear them to the customer. So, it can work but the you have to upfront, honest, and absolutely follow-up.