How to efficiently borrow someone else's expertise
November 13, 2021 1:59 PM   Subscribe

I got assigned a project at work that has suddenly increased in complexity and now requires skills that are way outside my skillset/comfort zone. I told my bosses about this and they were able to "borrow" a colleague of mine who is experienced in this other thing to help me for one day (Monday). I have a deliverable due at the end of the same week and am quietly freaking out - how can I effectively use their time and expertise to jump-start my work?

Some vague context if it matters - this problem is in the algorithms/machine learning domain and has taken a hard swerve into the ML side, where my knowledge is vague at best. I've spoken to this colleague briefly before and they seem nice enough but they are much more senior than I am and I have to admit I am a little bit intimidated by the prospect of having to take charge and steer the conversations here! We are all working remotely. Thanks in advance for any advice you have.
posted by btfreek to Work & Money (5 answers total) 5 users marked this as a favorite
I am sometimes the colleague who gets borrowed. What's most helpful to me in those situations is for the person I'm helping to come to me with:

- Some sort of clear project brief I can read in advance
- How far they've gotten so far or how they think they want to approach it, at least as far as the parts they're more familiar with
- A list of questions they have for me
- One specific representative problem we can work through together

This makes the best use of the time AND allows you to drive the conversation and show that you're a competent and prepared person who just happens to not have expertise in this one area (which should help your own confidence as well!).

In addition to the problem-specific questions you have, it can also be very useful to ask what you're missing, and what common pitfalls/mistakes your colleague encountered when they started working in this area. When I'm the one without the expertise, I always learn a lot from the answers to those.

I also strongly recommend being clear about whether the goal is for them to teach you how to do the parts you're not familiar with, or for them to actually do some of the work.
posted by rhiannonstone at 2:13 PM on November 13 [15 favorites]

Do your research in advance as much as you can - on the project and ML lingo. Watch YouTube videos. No joke.

Have all your documentation ready. Ask yourself what kind of questions might they ask me and then get the document about it (even if you don’t understand yourself).

Totally let them take charge! When I get pulled in I will teach basics, scope out the problem, and give them a map of the solution to fix it (the prescriptive steps to take).

Don’t be intimidated. Oldtimers love to mentor!
posted by St. Peepsburg at 3:47 PM on November 13 [2 favorites]

In my experience this really depends on the deliverable. Are you expected to deliver working code by the end of the week? A requirements document? A mockup? A technical design?

If the deliverable is a document, I would try to think about if there is one section that you can work on together and finish on Monday that deals with the specialized ML part. This way, you can effectively let your colleague "drive" the part of the work that most depends on their expertise. You'll get up to speed by doing it together and asking questions as you go, but ideally that part will be finished as much as possible by the end of the day. Anything you can, you leave as a placeholder to do when you're on your own.

If the deliverable is code, especially if it's code you'll have to maintain, I think you should spend the day learning. The nice thing about having a project to work on is that you can use it as a focus, which always makes learning go faster. But you should think of your colleague not as working on the end product but providing skills to you. In particular, don't let them do the work themselves! It'll be much quicker but then you don't end up in a place where you can own the end product. (That's the difference with the other scenario, is how much that matters). In practice I think this means first some instruction/Q&A followed by mostly pair programming with you "driving".

St. Peepsburg is right that the more pre-work you can do, the more use you'll be able to make of your time on Monday, but I'd also worry about barking up the wrong tree and ending up learning the wrong techniques/terminology/whatever compared to the approach your colleague would want to take.
posted by goingonit at 4:41 PM on November 13

Prepare the questions ahead of time.

Also, make your expectations known... This is NOT intended to add to his workload, this is consulting him on best practices thereof. And if you sound like you may be offloading on him, ask him to push back.

I am assuming you are treating this as a learning opportunity, so even if he is willing to take on additional workload it does not help you. You want to know how WOULD YOU do this and why, not just how to do it.
posted by kschang at 1:54 AM on November 14

In all honesty, if you have any briefs and scope and information on the deliverable you can share before the meeting that would probably help. That would allow them to form an expectation, think through how they would approach the project and critical steps etc. That way they can start by validating their understanding, learn how far you’ve got and how you plan to do the rest. They can then help you structure and focus the efforts over the next few days. I’d also ask them for a reality check wrt the deliverable and the timeline. It sounds as if the scope has changed but perhaps the timeline hasn’t. That may work or may not work. And if it becomes clear that it won’t work the sooner you can start to address that the better. They probably also have strategies for that they could share.
posted by koahiatamadl at 5:26 AM on November 14

« Older Where did I eat in Mexico in 2002?   |   How did you learn a language as a dyslexic adult? Newer »

You are not logged in, either login or create an account to post comments