Talking to Developers

🍎 Today's Expression

Vocabulary and Expression

- get one's point across: 요점이 이해되도록 하다

- main takeaway = main point/thing you should most remember(e.g. The main takeaway from this anecdote is that~)

- last-minute: 막바지의

 

Pronunciation

- Early (you're saying '으lee'): 'err-lee'

- Modified (you're saying 'm오dified'): 'm아dified'

- Crucial: Don't forget the 'L' at the end!

- Terminology (you're saying 'termin오logy'): 'termih-n아-l으gy'

- Fundamental: Stress on the 'M'

 

 

👩🏻‍🏫 Overall Feedback

Hi, it was great seeing you again! I enjoyed talking to you about our topics. Some areas to work on are pronunciation and using various expressions. To work on these areas, I suggest that you take more Ringle lessons for conversation practice.

 

✍🏻 In-depth Feedback

1. What do you think is most important when it comes to communicating across teams? 

When communicating with other teams, the most important thing is to 'understand and use their terminology'. The fundamental principle of communication is tailoring your message to the audience. Without this, it's not interactive communication but rather one-way transmission. For example, As a developer, it's crucial to comprehend why marketers intend to place promotional banners on our website or why product managers emphasize the significance of customer-centered service.

→ When communicating across teams, it's important to be able to empathize with them and use the lingo they're familiar with. The key aspect of communicating is getting your point across to your audience, so without this aspect, communication turns into a one-way transmission. For example, it's important for developers to understand why marketers emphasize a banner or why product managers emphasize customer service. 

 

2. Do you have any memorable experiences with team communications that you could share? 

In the early stage of the previous project, I was an assistant manager in our team. We completed the product plan in 3 days, defining our users and the necessary pages. However, perhaps it wasn't a perfect plan. On the weekend at 1 a.m. (starting function development a day early), a team leader mentioned that we needed to adjust our plan. Just in time, I realized that the particular aspect was unclear, so we clarified it further. Naturally, we documented the conversation for the rest of the team members. The next day, the team leader and I discussed the matter and convinced our team members. Fortunately, we proceeded smoothly with the modified project plan. Through this experience, I realized that when we find something unclear, we need to clarify it further to progress faster.

→ Yes, I have some experiences that I can look back on. In the early stage of my previous project, I was an assistant manager, so I had a lot of responsibility on my shoulders. We completed our project plan in three days, defining our users and necessary pages. However, this plan had some holes in it. On the weekend at 1 AM, the team leader said we needed to make some last-minute adjustments to our plan. I realized that some aspects were unclear, so we had a conversation with our team members and worked to smooth everything out. The next day, we proceeded with our modified plan. The main takeaway from this anecdote is that we must clarify anything we find unclear. 

 

📔 Today I learned

1. lingo는 조금 캐주얼한 표현, term은 더 포멀한 표현이라고 보면 된다.

2. If not 이라는 표현을 so without this aspect 로 바꿔도 된다.

3. 책임감을 지고 있다는 표현 had a lot of responsibility on my shoulders, 많은 역할을 하고 있다는 표현은 wear many hats.