Google Behavioral Question 5: Influencing Without Authority
🎯 Best Story: TLA Conflict (Architecture Standards)
Full STAR Answer (2.5 minutes)
Situation (35s)
At LINE, I joined the TLA (The Layer Architecture) Committee - a group creating architecture standards for the LINE app with 150+ engineers. There was already a guideline for iOS following Clean Architecture, and Android discussions had started several months before I found out about it.
I asked to join because I had worked on many different kinds of features - small to large, short-term to long-term - and had good experience with architecture decisions. After reviewing the TLA documents for iOS and the Android discussions, I felt the direction was wrong. The guidelines were too theoretical and would create too much abstraction in the code, which would frustrate engineers if we actually used them.
The TLA iOS idea followed Clean Architecture principles, like separating data layers so you could easily change the database or UI framework. But this is not realistic for a product - these big changes rarely happen, except maybe once in many years like moving from Android XML UI to Jetpack Compose. The guidelines also aimed for big features from day one, forgetting that 50% of LINE's features stay small and big features grow gradually, not all at once.
I had no formal authority - I was joining an existing committee with senior engineers and managers already aligned. The main conflict was with a senior iOS developer who wrote the TLA iOS guidelines. My objections could throw away a month of work and delay the project. My manager and my manager's manager were not happy with me.
Task (20s)
Change the committee's direction without formal authority, while:
- Respecting the work already done
- Not causing month-long delays
- Getting agreement from seniors who disagreed with me
- Keeping TLA's main goals (iOS-Android alignment)
1. Prepared Data-Based Arguments
Instead of just saying "this won't work," I gathered real data. I wrote a simple bash script to analyze the LINE Android codebase:
- Counted files and lines of code in each module
- Focused only on production code (ignored config files and test code)
- Used our company's AI tool to generate a report
- Fixed incorrect values and refined the requirements
The results showed: 50% of features are small, 75% considerably small. Only a handful are truly large (like Home tab, Smart Channel). This proved my point that the guidelines were designed for big features but most of our features are small.
2. Prepared Detailed Feedback
Instead of just criticizing, I:
- Wrote specific feedback on what to change
- Drafted proposed changes that would save the prior work
- Showed how we could reach Phase 1 target by end of term
- Explained how to keep differences with TLA iOS minimal (the main goal of TLA)
3. Organized Face-to-Face Meeting
I suggested: "Let's have everyone discuss what's wrong with the current direction together." Face-to-face was important because:
- Written feedback was not working
- We needed real discussion, not just documents
- Everyone could see the data at the same time
During the meeting, I:
- Showed statistics about LINE Android (50% small features)
- Explained how guidelines should grow with features, not assume big from day 1
- Showed trade-offs: perfect architecture vs good-enough that can grow
- Made clear my intentions were for the product's good, not ego
4. Found Compromise
I didn't reject everything:
- Agreed with TLA overall direction (layers, clear boundaries, Android-iOS alignment)
- Suggested: Fix current work to reach Phase 1 this term, further improvements next term
- Proposed Google's Android architecture approach as reference (more practical than Clean Architecture)
- Showed how to balance theory with reality of the product
Result (30s)
✅ Committee accepted my proposals - changed architecture direction
✅ Finished Phase 1 on time - no delays even though we could have lost a month of work
✅ Managers happy - we made it work together
✅ TLA iOS author understood my thinking - saw my intentions were good for the product
✅ Set example - data + compromise works better than authority
Learning: "Influencing without authority needs data, respect for existing work, and showing how to move forward together - not just criticism."
Key Follow-Up Q&A
Q: "How did you handle the senior iOS developer who was the TLA author?"
"I used respect and data together:
- I recognized his expertise and the work he did on TLA iOS
- I showed specific examples where the theoretical approach wouldn't work for Android's reality
- I suggested compromises that kept his iOS concepts but made them more practical for Android
- I emphasized our shared goal: good architecture for the product
After the meeting, he told me he understood my view and liked that I:
- Came prepared with real data
- Respected his work
- Suggested solutions, not just problems
The principle: Challenge ideas with data and respect, not authority or emotion."
Q: "What would you have done if they rejected your proposals?"
"I had a backup plan:
If rejected completely:
- Write down my concerns clearly (protecting the team for the future)
- Do their decision professionally and well
- Collect data after we use it to prove or disprove my concerns
- Suggest changes again with real data in 3-6 months
If partially accepted:
- Take what I could get
- Do it really well to build trust
- Use the success to push for the remaining changes later
The key: I would have respected the decision while staying involved to help make it work.
Sometimes influence takes multiple tries. Building trust through doing good work matters more than being right immediately.
The principle: If you can't influence now, do excellent work and influence later with results."
📚 Full Version: /mnt/project/8__Conflict_with_seniors_and_managers.md