Experience in Working in Large Organization
15 May 2024
Experience in cross BU communication and “Break Barriers and Build Consensus”
A summary of skills I found - [Negotiation Skills] on non-easy discussions with stakeholders
1. First, before online, battle test your own conclusion and logic offline.
Attack it with every direction. Think in-depth about every implication.
Make notes. And group discussion with team internal first.
2. Be extremely patient. Don't give up to pushes from the other people. It can take many rounds
Carefully evaluate whether commenters are saying the correct results and assumption.
Gaps won't go away because powerful people said something. They must be verified with logic.
Be nice. We are collaborating with people. Express objections politely. Apologize for hurtings.
Be open minded. We are not fighting for winners. Anyway, love to discuss with people from different angles. They are very good chances to learn.
Understand what you can give off and relax, and what you should grasp tight.
Move on agreement. Move on consensus.
3. On discussion, make sure you understand people's assumptions and results correctly.
This is not as easy as it looks when people are thinking from different angles.
Try ask from different angles, examples, elaborates, and narrow downs.
Say I'm OK to what, not OK to what, what are the anti-examples.
Similarly, make sure people understand what you are expressing correctly.
Express redundant contents from different angles, with examples and narrow downs.
4. Ability to innovate new ideas and new angles.
Throw out new inspiring insight is easier to win people agreement, and generate impact to people in the online meeting.
5. When agreement can hardly be met, the reason is usually DIVERGENCE ON INTEREST, while LOGIC SHOULD EVENTUALLY CONVERGE.
Listen to people's true ask. Probe what's the need underwater.
Make trade-off. You have to give something, so that people agree in return.
But first beware of what you have in hand. Don't give too easily. Protect your team.
Leave / push hard items to future. So it won't block today. And future changes and clarifies today's views.
6. Discussion should make progress, on the path to consensus.
We should breakdown the problem. Find where dispute happens. MAKE CONSENSUS SMALL STEP BY STEP.
First start to sync on assumptions. Then piece by piece path selections. Then boil down to dev efforts.
Try to guide the discussion. Choose what's the breakdown topic to discuss next to reach agreement.
7. About choice by faith. How to evaluate people's proposals.
Ask what is the problem to solve. Is it a true problem to solve?
Must have benefit. Any benefit must map to money. COGS saving, customer satisfactory, less dev efforts.
8. Meeting manner. Include small group of people. Even private 2~3 people talk.
Experience tells that, people are easier to discuss with on small talks.
Large people meeting usually result in stall and dispute. And less efficient.
9. Handy questions to ask
1. Why XXX (you think this way)? Why XXX is XXX (ask why to people's proposal)?
2. What's the ideal picture (and complete) to the problem?
Handy methods to resolve tie
1. Eventually we should bring up a table of alternatives PRO & CON compares. And score table.
2. Ask what is the criteria that a conclusion is made
3. Ask questions. Use heuristic questions rather than direct statement to guide people to the point of doubt
1. Ask: Is the problem [Fundamental | Fixable | Trivial]? Is the effort [Big | Medium | Small]?
What are the true problems the proposal cannot get away without solving?
Can these be quantified or estimated? Useful to understand potential impact.
2. Ask: Can you breakdown the problem, the blocker, the difficulties you said? Then goto 1
Don't hear conclusions, opinions. Always ask for breakdown to reach the rationale points level (facts and criteria)
3. Start by setup the new thinking perspectives, views, frameworks. From which, our conclusion will seem natural to them.
Explore and find more commons and similarities between us and them (the opinion points). Rather than focus on debating differences.
10. Documenting results
1. Discussions and evaluation results can be put into a shared document.
So that people are engaged to leave notes. You know what they are thinking.
11. A summary
Essentially, evaluation is conducted with strong logic. Anything applicable to logic should eventually be consensus-ed.
What lefover cannot consensus is usually dispute on interest. Trade, with politics and negotiation skills.
Time can be spent to propagate points. You or people understand each other is not as easy as it sees. Communication skills
----------
12. Meeting learning
1. Try argue from the partner's angle.
Ask questions, to understand how the partner formulates the problem, and why the partner proposes this way
Evaluate from the partner's angle, claim the benefits and trade-offs
2. Find partners and allies/ally. Get the support from them.
And then goto the opponent partner, or ask your supporting partner to help argue with the opponent partner
3. To influence people isn't about telling them over and over again why you are right. It's trying to understand why they don't think you are right.
And listening to those discussions. And having an open collaborative discussion.
You have to ask people why they were thinking differently. Get a different view, get the discussion. You may find you are wrong, or you may find a different angle you were missing.
13. We ask the other component team to help. But if not, can we build the solution by ourselves?
14. Re-thinking pushing project with cross BU leaders
1. First, reach agreement on the right problem to solve.
Setup the right framework to solve the problem. They map to final cost & savings, (and trade-offs we have to pay).
People may have concerns. Concerns are not final. They must map to final cost saving framework.
For example, about design separation, usually pushbacks at cross team boundaries
Key problem is at performance plane. Decouple is not quite applicable to performance plane. We cannot even hide cache/memory/disk patterns.
Pushbacks are not final. You must USE A BETTER ALTERNATIVE TO REJECT THE EXISTING ALTERNATIVE. BACK THEM WITH DATA.
2. The skill more map to CONSULTANT THINKING. Strong logic, breakdown analysis, issue tree framework, MECE.
-------- updates -------
1. Collect all the proposed options from both teams.
2. Understand the evaluation dimensions. Each team can have quite different concerns.
Proposed options + evaluation dimension should compose the MAXTRIX.
3. Make sure both sides reach the agreement on the comparison matrix.
This will be the cornerstone to push progress and reach the final solution
1. You will find different teams may have different priorities.
They will be reflected in the comparison matrix that how to weight two columns
2. You will find different teams can have VERY DIFFERENT conceptual framework when they understand the problem and understand the solution.
This is why communication is very important
1. Usually, a member will try to understand things with the concepts he/she is daily working on.
So, unique concepts in internal team should be avoided to use. They are easy to cause confusion.
Try map things into their language or industry common concepts
4. Distill information and make it in a clean presentable format. The simple brief COMPARE MATRIX
People from different teams may not have the same background with me, and may not have time to read through a long document.
This is an effective and usually THE ONLY way for a larger group of people to stay on the same page.
EXPRESS IDEAS IN PARTNER TEAM'S CONCEPTS AND LANGUAGE. Even neighboring teams can have great difference in how they think.
This is non-trivial. But the benefit is straightforward. It's much easier to get ideas accepted and quickly when expressed in the right way.
15. Several heuristics thinking questions
1. What's the ultimate state, vs our current solution that is easier to build?
For example, the ultimately XXX should ... Today's XXX is doing ...
Guide people to think what is the optimal best solution putting aside all noise and reach agreement at the direction
16. Besides backing with data, a valid concern must be accompanied with its solution. I.e. SUPPOSE I HAVE A MAGIC WAND, WHAT I CAN DO TO RESOLVE YOUR CONCERN?
--------
18. Leading the discussion. Learnings from past discussion.
1. In high level architecture design discussions, TERMINOLOGY USAGE MUST BE VERY CAREFUL. An incorrect usage can lead the discussion into wrong tracks and people spent much time shooting points but no progress.
2. Keep the track on high level. AVOID FALLING INTO THE DOG FIGHT (drilling into details). For example, when you are replying the proposals and points from other people.
3. And, try to LEAD THE FOCUS, lead and put the focus to the right panels you set. For example, to reply the proposals, rather than inline comments to each point, I can extract the comparing points, lock down them layer by layer, and push for progress.
4. Need to reframe the perspectives.
19. Ask, is the problem coming from system complexity, or from the fundamental problem domain?
Many pushbacks actually come from system complexity, risk, performance. They are not fundamental. They are solvable, or just optimization problems.
Capture what's fundamental, that's the true driving force that will eventually lead to the converge.
20. Back every point with data. It's desired, but expensive.
Sometime logical analysis with math models is more effective to steer through a spectrum of proposals.
21. Try express in your partners terminologies and concepts. Say in what the people can understand.
BE CAREFUL TO AVOID COINING NEW TERMINOLOGIES, or bring terminologies that is familiar only in your team.
--------
22. Emphasize on making progress
1. Explicitly emphasize on the pressure of boss, timeline, the deployment schedule. Hardware changes need to ship. Etc
2. AVOID DOG FIGHT. The opponent may throw out a lot of point attacks, or misunderstanding to your proposal, or incorrect assumptions. There is a lure to drill into points and attack back each point. DON'T do it. Instead,
1. TRY MAINTAINING THE DISCUSSION ON THE SAME HIGH LEVEL. Try stick to the main thread of topic, rather than being jumped to another.
2. TRY LOCK DOWN THE OPPONENT. Reflect/mirror what the opponent threw out.
1. For example: so your proposal is .. so what you propose to pursuit is .. so your concerns are a,b,c,d.
2. These captured lockdown is a progress made. They provide one more cornerstone that we can step on to move forward. The lockdown avoids the opponent to randomly throw out points to form a DDOS attack.
3. THE TECHNIQUE OF REFLECT/MIRROR is powerful.
3. Longterm vs shortterm solution. The opponent may try to raise a shortterm solution that is conservative for today. But we need to solve the longterm solution. This is the problem we are solving.
3. Solve the opponent's problem. Ask and lockdown the problem. Avoid dogfight.
AVOID DIRECTLY DENYING WHAT THE OPPONENT THROWS OUT. But instead capture it and lockdown.
Avoid direct attack back when the opponent throws out an incorrect point. DRILL DOWN THE CONCERNS.
4. MEETING HOST ROLE. Practically the role is virtual and mixed into other participants. But there should be someone caring about the discussion is heading to the right direction, the progress is being made, the discussion is conducted in the correct way.
5. THINKING IN HIGHER LEVEL.
1. It's not only to think in higher abstraction level, but also to think from the view or your boss, from the eye of a more higher management role.
Think how a higher view point would see the argue between you and your opponent, and how to shift the balance
2. Also, think from the view of your opponent, usually also a higher management role, and from that higher view point
--------
23. Transparency, honesty, integrity, 真诚. TRUST IS THE MOST VALUABLE and needs to be maintained and eventually pays off in the longterm.
It means to consistently provide high quality work, data driven, and being transparent.
24. ASK FOR EXPECTATION FROM THE OPPONENT.
1. E.g. What kind of evaluation do you think can make XXX confident (rather than criticizing not production realistic)?
2. E.g. What are the upgrade speed numbers do deployment team expect that we can proceed with XXX?
25. If people say your data or simulation is not realistic, another way out is to
1. Build a simple model and say to applies to all scenarios and proves to be better. MAKE PEOPLE UNDERSTAND.
26. People may naturally send more kudos to people that are similar to themselves. But note WE USUALLY LEARN THE MOST FROM THE PEOPLE THAT ARE UNLIKE US. At this time, we need to act on counter-intuition.
27. The path to consensus is a Manageable Process that can be broken down into series of small steps. AGREEMENT CAN PROGRESS PIECE BY PIECE:
1. Common process
1. Agreement on assumptions
2. Agreement Production observations,
3. Agreement on the problems we see
4. Agreement on the evaluation numbers
5. The collection of alternatives
6. Align on the concepts
7. Clear out the bias
8. Exclude some alternatives as non-starters
9. comparison matrix with dimensions
2. Issue tree framework
1. The MECE test
2. The conclusiveness test
3. The bias
1. DON'T UNDERESTIMATE HOW MUCH BIAS people can have when they are working in different teams.
The concepts can be incorrect. Important things can be missed out. Compare can be made not apple to apple. Etc.
2. The working style of thinking in high level is vulnerable to bias.
Once you lost the ability to break high level concepts into physical moving parts to verify, you lost the ability to get out of bias.
This is applicable to managers, and especially to manager of managers (MoM).
For being a manager
1. Either you maintain the ability to drill down into low level. I.e. Elon Musk's "First principles".
2. Or, you need a group of senior devs to work it out for you. Given they don't have bias.
3. Or, you rely on a lower level manager reporting to you. But the other manager can also be actively propagating bias if it's favorable.
4. The general principle is always to listen more broadly and listen more to someone in a distinct background.
1. But the problem to MoM is they usually don't have time to allocate for such meetings.
2. And Power makes you alone. Your lower level workers will always try to filter messages passing to you, or you rely on them to filter things out.
28. Instead of diving into a wool ball of communication, I realized the consensus process can be broken down into a series of small steps, and the agreement can be made piece by piece. For example, agreement on assumptions, production observations, then to problems we see, then to evaluation numbers, and eventually the collection of alternatives, non-starters, and comparison matrix with dimensions. In another word, CONSENSUS HAS A WORKABLE PROCESS.
--------
29. Service level interface design - clarifying boundaries and responsibilities
1. Thinking in higher level.
1. The right communication is not we have solution to a problem, which sounds to the audience like denying that the problem will never happen.
2. Instead, assume every part can have problem. Answer that if had problem, how to triage responsibility to each side, how to troubleshoot. Put a concrete solution as a blackbox.
3. The more important things here are visibility, metrics, how to measure, how to control, how to contain. Think as management.
4. NOT too much focus on the solutions itself, documents, work item completions, interfaces, APIs.
1. NOT the solutions itself or a document. What senior managers want to hear is the questions are addressed and tracked. And the questions are high level about how to cut services responsibility.
2. What makes a good boundary or protocol?
1. It may more relate to collaboration process in management
2. Cover all interaction scenarios.
3. Ensure all major problems are solvable.
4. Define who's who responsibility. Clear responsibility cut at each point at each side.
5. Make sure visibility metrics and troubleshooting methods to support the responsibility cuts.
6. What can possibly go wrong, key risks, and major solutions
7. Handle worst cases.
Thinking about team silos.
1. Cross team collaboration is challenging. Break barrier and build consensus. The main challenges can be
1) Different teams have different goals and priorities. It's natural to let one dev help another dev to contribute one project.
But when two teams have two managers, they have each own silo to protect, that let one to give a part to another one is less easy.
2) Neighbor teams are more frequently required to collaborate. However, managers of neighbor teams are more frequently competing for promotion headcounts and budges.
This sounds like an organization setup that however makes the required cross team collaboration less easy.
There are some attracting points that when work in cross team collaboration
1) You can easily get to know a lot of people from different teams, practice skilled negotiation, hear and communicate with high level managements, propagate visibility.
2) It's the precious time that you can hear how members from the other team think about the big picture, your projects, different perspectives and priorities.
(Just like new hires are precious resources with limited window to learn new perspectives about our projects and products, before they get "mature" and "polluted" by the local team.)
Seldom are people perfect. But it's sure that you can always pick up something useful from anyone you worked with.
2. Team silos. First, what's the problem and status. Then, what's the solution? What's the correct organization and incentive structure?
1. Products map to BU silos. Components map to Team silos. Features map to the next level, Feature silos.
2. If it's a single one unified team, then communication and coordination is easy. It's easy to let person A help person B in another project.
But when it comes to cross silo, let silo A to help silo B becomes hard. Break the barrier and build consensus becomes hard.
3. For example
1. Each silo has its own KPIs and priorities. Silo A to help silo B means
Silo A will make its own KPI worse due to spending resources to silo B. And it injects risks to silo A.
Not only resource, building something that is not needed in silo A adds complexity and makes silo A performs worse, even the thing can be useful in silo B.
2. Silo A is more constraint in future when inventing its own projects. Because silo B's things are injected into silo A.
Silo A cannot make decision on its own, it has to involve silo B. The communication chain drags down silo A's evolving speed.
3. Cross silo projects are more likely to be needed when silo A and silo B are neighbor teams.
But this is also when it's more likely that silo A and silo B are competing for resources and head counts.
Project impact is not equal to each participants. When silo A is helping silo B, silo A is a "helper", silo B is the "leader".
That means silo B gets most the impact, gets most promotions and resources. But silo A is the one to pay the cost.
In the end, silo B team gets more resources and grows bigger and stronger and is able to eat more from silo A.
Silo A's "helping others" behavior is eventually killing itself.
4. Due to the above. Managers from each silo tend to develop the tendency to "protect its own silo".
Managers who don't choose to "protect its own silo" will eventually get eaten up by its neighbor teams.
Such culture is self incentive.
Simply saying "You should contribute to the success of others", but no change to the incentive structure, is the same like saying
1) "Don't help others" is the true underlying main stream.
2) We don't actually have a way to change it, except saying "Please help others".
5. Communication break. To protect itself, silos then tend to
1) Restrain from disclosing its internals. Pretend to be transparent but don't really be transparent.
As a result, you won't really hear any valuable information from the other team.
As a result, when the other team gives you a reluctant pushback that is incorrect, you don't have the information to point out where is wrong.
Popular words, don't get the information if you don't have business justification.
2) Occupy lands. The feature is owned by "me", and any external person should not touch the code. If they do, they must pass through my control.
As a result, the team tends to declare exclusive ownership of a feature and then exclusively own all the information.
Any team that tries to be transparent to other team, means they are more vulnerable to external attack, to lose the battle.
They get eaten by other teams, and the other teams then hire more alike people that won't be transparent and instead be protective.
What if we ended up trained managers to have perfect skills at pushback, politics, protecting information and silo, rather than technical skills or decision making?
6. As a result, you won't reach the optimal product. You will reach the local optimal.
Your product breaks when it instead requires strong cross silo work.
Eventually, it falls into "Conway's Law", that system structure becomes alike organization communication structure.
https://martinfowler.com/bliki/ConwaysLaw.html
The system design is not aiming the best, but instead takes "organization tax" into design.
4. From the view inside the silo
1. What should I help another team? In a competitive environment, it's team suicide and betrayal.
2. I should be ready to protect my own team interest anytime.
3. If I find value idea to another team, should I tell them? Usually it won't work and it's not wise.
5. Thinking about the best ways to work with Team Silos
1. When two teams have a tie on decision making, eventually we would escalate it to the high level boss to "拍板"
1. But, the high level boss would still need data and information to make the informative decision making.
1. Then it comes to us, we should
1. Make solid data. Data-driven decision making is a good practice anytime. It helps reach the agreement finally.
2. Make high quality investigation, logical coherent arguments.
3. Reputation and relation. Maintain the longterm trust. It's the valuable asset.
2. Then, if we follow the data-driven approach, it seems we don't even need to involve the high level boss. We can make the decision and reach the agreement already.
1. Note that even high level boss to make decision, it would still need to compete possibly another high level boss.
And, let high level boss to do it, it consumes the political capital of the high level boss, which doesn't seem a well choice.
2. Sometime, the necessary data to make decision is in the scope of another team
1. The other team may not have or provide that data. So the local team may still need to spend effort for data collection cross scope or cross team boundary
1. Then it implies
1. Cross team knowledge is important and useful in this scenario
2. Team culture should be transparent. It allows another team to work cross boundary to collect the data and view the internals.
3. Trust is valuable. Don't offer false things to another team while try to hide things inside into team silo.
2. Also, the other team may not provide the necessary evaluation, even it involves what's in their scope
1. So, the local team cannot exclude the effort to do evaluation that is cross boundary.
2. And, it's vulnerable to DoS attack that the other team can bomb you with
1) Many more proposals
2) Bring/mix into picture many more components
3) Keep attacking any piece of possible issue
Then, it will require the local team spend much more time do evaluation (asymmetric load). The project time can be dragged prolong. Denial of Service.
Experience in management, leadership, and communication.
1. I need to periodically refresh the priorities to drive my team members to work on the progress.
However, Instead of just push ETA, I should encourage people, motivate people. How should I do that? That's the difference of leaders.
2. Anti-examples in cross-team collaboration
1. Avoid deliver clarity. Avoid saying Yes or No. Avoid expressing the true concerns or opinions directly.
2. Avoid making any commitment. When being asked, circle around the question or throwing out more problems.
3. Block anything that you dislike, by throwing our more problems. DDos attack, that you can always throw out more concerns to block it.
4. Throw out the problem one by one rather than all at once. When one problem is solved, throw our the next one. So it blocks longer.
5. Don't seek to understand the true problem. Don't seek to understand it in a cross-component overview.
Rather, translate the problem into your own domain knowledge, with your own stereotype and bias.
Then point out the problem generated by the biased understanding. Wait for clarification, which also extends the blocking time.
Further, propagate the biased understanding to more people, especially to higher level management. So that the opponent team's clarification is even harder.
6. Get very busy. Don't have time for discussion. Don't have time to resolve concerns. So it blocks things for longer time.
Refuse the clarification. Become angry. Claim it's a waste of time. Be the bottleneck to block teams.
7. When the higher level management try to ask about the conflict between two teams, do blame the other team isn't doing things right. Blame the blocking time is due to their problems.
A judge would naturally try to hold the scale balanced for two sides. So do muddle the water, that a higher eye can hardly find out what's the problem, which is wrong.
8. Bring new things into the picture, to make it more complex, to creep the scope to beyond handle. So that evaluation becomes harder and it extends the discussion and blocking.
3. Coaching performance issues
1. Scenario
1. Team member didn't deliver the task result in a long time. Tried to set ETA, effective at beginning, but then soon the habit becomes violating it, breaking the commitment.
2. Analysis
1. Performance issues are usually not because your team member has low performance. Usually it's because he/she is busy with something else.
2. Make sure it's not another project that is distracting much. Not too many projects are doing context switch. Not being blocked by a hard to solve problem. Not busy with a not important task.
3. Address delivery scheduling related problems early. The only chance to save the day is to address it early, rather than things already fall behind.
4. Send transparency of the schedule falling issues to higher level management early. Make sure they have expectation, no surprise. Make sure they are aware of the potential problems, so can offer help when you need.
3. Solutions.
1. Setup the expectation. Setup the ETA. If deadline missed but not results. BE SURE to drill down why into details. Don't let it slip away.
2. Refresh priorities. Do it often. 1-on-1 meeting. Encourage people for productivity.
3. 1-on-1 meeting, ask the resource investment of committed vs actual. Members may be doing too many projects with context switching, or hitting some hard projects. Work with more people to coordinate for resource and dev bandwidth.
4. Ask higher management people to get more context about the motivation of the project. Why the project is important. Why it's in priority. Get these chatters and use them to encourage your team members.
5. Try daily SCRUM. Use a morning or evening meeting. Ask what is done, what is promised, and drill down why not delivered at per day ETA.
4. Presentation to seniors
1. Prepare wording lines beforehand for each slide page. Senior leads may ask a lot of questions with different threads. Some questions are inspiring and complex. It would definitely need the prepared wording lines to ensure to do speech with fluency and can go back from distraction.
2. How much content to prepare the slides? 10 pages for a 1-hour session. Frequently this may not even have enough time to finish. When the topic is right, people can have a lot of discussions.
5. How to encourage and motivate for productivity
1. Be curious to how people think. Think in a relation/connection based way rather than treating people as task delivery machines.
2. Align project goals the team member personal goals. Explain why the project helps them, why they should care and love.
3. Give them problems and challenges to solve, rather than tell them what to do. Thank them for solving problems. Delegate roles to them, including the role carried impact and growth to them.
4. Provide review, make sure team members are solving problems with the right way, on the right track, rather than telling the answer of the problem.
5. The car racing experience. You need do good communication. So the team knows how to improve, together build the faster car.
Win the game, and get the team encouraged, so team gets more involved. It builds the positive feedback loop.
6. Leadership charisma
1. If you leave the company to a new start up, how many people would follow you?
2. The followers of you are betting their career path on you. This is the weight of trust you should carry.
3. Mirror play. Practice talking with charisma in front of a mirror.
4. When you talk
1. Can you talk with confidence that inject confidence to others that move away their anxiety?
2. Can you be a thought leader that everytime people talk with you, they feel inspired?
3. Can you make people feel comfortable when they talk with you?
7. Team first
1. Avoid myself being the bottleneck. Always address team needs in high priority than my own work.
2. Delegate and most importantly trust my team members can do things well. Need to delegate first and then expect my team members get experienced.
3. Hold the quality bar. Be sure the team member outcome is no worse than I do it myself.
Expect to gradually increase the quality bar as the team built improving platform, tooling, process, knowledge base.
4. Use questions, problems, challenges to guide team members, rather than directly tell them what to do (close the solution explore).
Socratic questioning method is an effective way.
Don't be in the role of making concrete solution, but be the host to make sure the right methodologies are to get to the solution.
5. Be prepared for push backs, e.g. in work item assignment, work life balance, rewards, etc. Find a private place to discuss, rather than on a public meeting.
6. Managers must be role models themselves.
Experience in mentoring and coaching.
1. Instead of assigning the next steps, ask the member what's the next step in their minds. Ask how he/she would do/breakdown/organize the work.
Do this early before the next meeting session, in case they do something unexpected or stall.
Especially, make sure the member isn't building something different from what you asked, then try to make proposals for his/her own built.
2. Arguing on choosing proposals.
1. If someone is trying to point out a problem of the existing solution, a better ask is to let him/her give a usecase.
1. If he/she is proposing a new solution, first verify the existing solution has the right problem with data driven.
2. If someone is proposing a new solution and we have concerns, the better ask is to him/her to drill down and supply data and evaluation for the concern point.
1. And per evaluation, the him/her may throw back questions. Need to push to do the evaluation. Don't let the monkey jump back.
3. A method to compare proposals is to ask how much dev effort is needed in each side. Just note the estimation needs to be thoroughly examined.
1. Don't use simple or complex to compare two solutions. Use how much dev effort are added
4. To express negative opinions. It's better to ask questions to point out problems, than to say with a negative close statement
1. Guess I need to learn how to say NO politely
2. Things that can end up in arguing and bringing up emotion reacts should better be put into 1-on-1 meetings
3. Talk about priorities. The high priority task is to finish the original job, side proposals are of lower priority.
5. Ask what's the problem the proposal is trying to solve
1. The goal should map to COGS, customer facing experience, or dev efforts. Map concept pros/cons to physical financial pillars.
3. A bad guy example is
1. When I ask someone to solve a problem, to resolve a design work, he/she comes back with more problems for me to solve
2. When I challenge or try to push to a direction, the someone immediately pushback. The question is bypassed, and answered with more questions, or side paths.
3. When I ask someone to do a piece of work, he/she comes back that has done a different thing that I asked. Then he/she tries to make new proposals
4. When he/she tries to make new proposals, too many details are missing. When I try to push drill down, the work is stalled or got pushback.
5. When I try to ask someone to do the work for me and I review the results, he/she comes back with more questions/challenges to me. As if I'm working for him/her.
6. When I turn down someone's proposal, he/she refuses to collaborate further on the work.
7. When I reply to strike the original question or pushback, he/she quickly jumps around to another question and keeps attacking. Such pattern repeats.
4. Structured guidance questions
1. What is the problem to solve? What's the problem of the original solution?
2. How the new solution is solving the declared problem?
3. Are there other alternatives in the spectrum?
4. What is the trade off made?
5. More experiences
1. When arguing about a solution / attack a proposed solution. DO NOT attack a solution with another solution.
Attack the analysis method and critical thinking method that is being used by the proposal. This is where a manager should hold the line.
2. Before a large meeting, organize a small or 1-on-1 meeting with team members to review the proposals/results first.
Just like a common manager office talk to go through the new results.
3. When to express pushback or to reject proposals, express with confidence language and inspiring language. With the soft skills to smooth things out.
Motivate and encourage team members for productivity.
1. Big picture
1. Compare our status with the top competitors. How our project is a core pillar.
2. Paradigm shift for future market and technology landscape.
3. Industry leading approaches in technology and design.
2. Longterm work available
1. Big project. Major component as sized in a big component.
2. Much much future improvements are possible to "grow" out.
3. Personal boost
1. Driving/owning a big component.
2. Solving great tech challenges, system complexity, and rollout complexity.
3. Big component can grow, many many future improvements are possible.
4. More needs on system design, architecture, design, analytics skills, solving new problems.
4. Need your experience
1. Senior experiences on developing code in project, with proper design, and rollout safety.
2. Analyzing large, complex problems, involving many moving parts.
3. Driving the project, driving for progress and results.
5. Grow your impact/visibility
1. Senior management is tightly watching the progress.
2. Working with senior devs & managements across the world. Components involve big scope.
3. Get more people to review and to demo your new problem solution. Roadshow.
6. Major technical challenges
1. Industry leading technologies and designs.
2. Big project. Major component as sized in a big component.
3. Things are new, many new problems pending.
Interviewing people with nice interviewee experience.
1. Thinking from collected from interview experience, especially how to interview design problems / design skills
1. It's not the learning more and more papers. It's the keep solving the problems, and repeatedly practice applying the design skills and depth knowledge, that can make an expert.
2. This is also the fun part. So, currently there are two directions for improvement: 1) practicing solving design problems 2) practicing solving algorithm problems.
1. Rather than relying too much on learning comparable system to solve the problem, try how to improve and solve the problem by oneself.
3. An example design problem asked in interview and an example answer
Append Only file system
- infrastructure support
- how to fragment
- At least one master server
- meta-data is stored on master server
- 3 meta-data nodes
- locate where the data is
- data movement
- rebalancing
- redirecting read / write to the storage nodes
-
- data nodes
- node written to the journal
- data is written to 3 different nodes
- latency
-
- data format
- batch writes
- index small in comparison actual data written
-
- client node and data nodes
- retry logic
- cache
- client policy
- cache hit
- batching
- logging
- how much delay
- metric aggregation
4. Let's ask myself the same questions and give the answers, and then compare with what I get from interviews.
2. Prepare an outline before you start with an interviewee
1. Introduce myself and yourself
2. Motivation to Join company
3. Technical background
1. Describe the process of a request is raised from client to server to storage to kernel. Drill as you want
4. Coding / Problem solving - https://codeshare.io
5. Design skills
1. How to design a distributed file system.
2. How to design an data repair mechanism.
3. More
1. Given different workload, mem/disk, append/random, metadata vs data node, performance/reliability/storage overhead/scale, we can drill down into different design approaches.
2. And integrate with 4+1 view we can bring down more. and have the general framework to examine.
3. And further dive into each components, we can have a range of technique tracks to select 技术选型.
4. Drilling further, we can have many more paper and depth knowledge and optimization reflected.
6. Project experiences
1. What's the working scope of the candidate?
2. Asking the project details
7. Technology sense and recent learning
1. Recent learning. Depth in understanding. Integration to projects. Sense in technology picture
2. Opensource experiences
3. Future directions of storage and distributed systems
4. Improvement directions for company product
8. Do you have questions?
1. Don't miss this question.
9. Is there any your featured skill that I missed in interview?
1. Don't miss this question.
Paradigm shift on how to work efficiently and effectively.
1. The fundamental way of improving work efficiency is to build better tools and platforms
1. Don't repeat yourself. Make complex things easy. Error proof, prevent manual steps that are error-prone. Reduce mental burden.
2. Build tools that help others, grow visibility and impact.
1. Contributing to others. Helping and sharing is one way that dev can grow impact exponentially rather than linearly (contributing labor).
2. Leveraging others, even it may not be smooth from start. Help others work in a way that you can leverage.
3. Minutiae and task pipeline compaction are just lower-level ways. Need to work smart. Rather than a "factor of actions".
4. Be "scalable".
3. The tools accumulated in the company is the asset to make company more efficient.
1. In general, tool can be more things, e.g. knowledge, practices, process.
2. Instead of hero smartness or moves whose impact decay with age, transit them into assets that are longterm effective.
2. The fundamental way of doing innovation is to measure things first
1. Unless you can measure it, you won't find out what's truly wrong in production. New measurements added usually reveals new opportunities.
1. Many times it is not a sparkle of innovation.
Instead, we first setup some metrics, and then discovered things are not right, and then proposed an innovation as improvement.
After rollout, we start a new round. This feedback loop constantly produce innovation.
2. Measurement is the fundamental for data-driven decision making and data-driven work style.
1. Data-driven is also useful in break barrier and build consensus.
3. Frequently we meet that, want to do A, found A needs B1, B2, B3 first. And then Bi needs again Ci1, Ci2, Ci3 first.
1. This should be good. If think deeper, it's easy to bake more innovation projects here.
Like NASA, go to moon even living in the space pod needs to handle a lot of errands.
Those trigger great innovation today, like dried vegetables, water filter, GPS, etc.
2. Missing step stones are good things. They are where you introduce new technology and innovation to make impact.
3. New things about how to improve work efficiency. Paradigm changes after years of work
Level 1: Efficient task scheduling, parallelism, do things quick
Level 2: True efficiency is by building better tools, which can shift how we work.
And to work smart, which means change a better way to solve problem.
Tasks will never finish. Prioritize the right thing to do. Analyze the correct organizational bottleneck.
Level 3: It's NOT how to improve work efficiency, it's how to improve the work result impact.
10x people use it, we have 10x impact, i.e. 10x "efficiency". This is extremely more scalable than Level 1.
So, contributing to other people, means NOT to just share, but also make sure people use our results
From the organizational view, effort => asset => efficiency of asset being used. That's how to improve the third part.
4. By observation, to improve work efficiency, the improvement on tooling, infrastructure, and using a nice methodology and process, are much more effective than busy overtime work.
1. So, its more reasonable to invest into tooling/infra asset, intellectual asset, condense into them, rather than just do overclock working.
2. Besides, the former one requires innovation and nice perceptions, it demands mind energy, then is naturally against working overtime.
Doing effective PR review, code review, design review.
1. Did we analyze correctly the root cause? Are we resolving the root cause of the problem with the most critical path? Are we solving the right, ROI effective problem?
2. Do we understand what's the cost and benefit of the change? And what's the system impact? All should be backed with quantitative driven numbers.
3. Did we include all the scope and scenarios that have been touched, no missing, and addressed them all?
1. What can go wrong. Possible fallbacks. Metrics to addressing each.
2. Metrics to detecting problem and triaging problem.
4. Do we have graceful degradation? E.g. a runtime config switch to wrap all changed code. A fallback approach when livesite happens. Some tool for fixing; debugging, visibility tooling support.
5. Is the code leveraging what we already have? I.e. it can reuse but missed out some existing code, libs, frameworks, tools.
6. What's the biggest risk of the newly introduced change? Is it addressed and protected properly?
7. Do we have enough metrics to capture
1. The root cause of the problem. the alerting. the degree of severity. E.g. performance is lower than expected.
2. Metrics to capture the negative side of cost and system impact.
3. Metrics to capture the expected benefit of the change.
4. Metrics for system overhead.
8. Do we have logging at all the necessary places? Especially status log, error log, alert logs. Are logs linked up in one tracing id E2E?
9. Think about the coding solution. If I was to code the PR again independently, what is my approach and compared to the current PR?
10. Did we went through all solution alternatives? Made compare, and decided the current PR is the best one.
11. Go to the component design level. Are the design make properly, w.r.t. to OO design?
1. Are the classes and interfaces designed available for reuse?
12. Is test case covering enough every key points of the workflow?
13. PR comments for the key problem and key solutions. Function comment for key interfaces.
14. Coding style.
15. What are the true use cases behind the PR?
16. What are the trade-offs we are making by doing the PR?
17. Review the Problem Solving
1. What's the true specific issue this PR is to capture? Goal and scope must be clear.
2. What are the criteria about solving the problem, and to which degree? Define the framework of criteria and path.
3. Verify the logic that connects every piece in the tree from goal to criteria components to pieces of code.
18. Who is driving the related feature or project, the contact?
Visioning into the future.
1. Vision and Strategy thinking are necessary while ranking up the ladder.
1. Higher level managers need your input to help clarify the picture. Deliver clarity. Define the problem.
2. Tracks to grow experience
1. Understand competitor and ecosystem landscape.
2. Evaluate driving factors behind.
3. Technology spectrum in industry and academy for each design points.
4. Internally, our product growth and bottlenecks.
5. Externally, position of our product in the world industry and academy.
6. Organizationally, the way how teams organize the work in 3~5 year.
Vision starts from answering "Where should we be in the next 1 years", or "in the next 3 years".
Internally, it involves system-level understanding, data-driven, in-depth, battle tested, to find where we are and gaps, positioned in a timeline track. Externally, it involves seeing industrial momentum underwater, the technology spectrum landscape, and comparator strength.
It challenges the active learning into the next level. Instead of simply reading more papers, need to reorganize knowledge into landscape, identify missing and be adaptive, and apply the taste. Need to practice deep thinking and apply knowledge and design spaces into daily work.
3. Visioning, answer the questions with analytics skills.
1. What should we do and where we will be in the next 3 months - dev scope.
2. What should we do and where we will be in the next 1 years - tier 1 manager scope.
3. What should we do and where we will be in the next 3 ~ 5 years - architect scope, senior management scope.
Create an Issue or comment below