Culture

1. How to work well on teams.

• We have one variable to control : you.
• People are basically imperfect.
• Before you start looking for imperfection in your co-workers, you need to look for your imperfections and think about your reactions, behaviors and attitudes.
• Software development is a team endeavor.
• behavior around the core principles , humility, respect and trust

Help me hide my code

• Insecurity is part of human nature, Insecurity is actually a symptom of a larger problem.

The Genius Myth

• Humans have an instinct to worship idols. For SWE’s they are Linus Torvalds, Guido Van Rossum, Bill Gates.
• Linus wrote just the proof-of-concept of the unix-like kernel. Linux's real achievement was to lead these people and co-ordinate their work.
• Guido Van Rossum wrote the first version of python.
• Bill Gates wrote BASIC interpreter.

The genius myth is the tendency that we as humans need to ascribe the success of a team to a single person/leader.

• You are probably not a genius
• Geniuses still make mistakes, and brilliant ideas and elite programming skills doesn’t guarantee that your software will be a hit.
• Being a genius is not an excuse for being a jerk.

Genius myth is just another manifestation of our insecurity.

• Fear that another program might steal your idea and run it before you work on it.

Hiding considered harmful

• Working alone increases the risk of unnecessary failure, cheating your potential for growth.

Early Detection

• Easy to make fundamental design mistakes. Risk reinventing wheels
• Make sure you are working on the right thing, doing it correctly and have not done it before.

Mantra - “ Fail early, Fail fast, Fail often “

• It is more than about preventing personal missteps and vetting ideas. There is a bus factor for the project.

The bus factor

the number of people that need to get hit by a bus before your project is completely doomed.

• You are the only one who understands how the prototype code works, you might enjoy good job security. But if you get hit by a bus, The project is toast. With colleagues we will double the bus factor.
• A team together is even better.
• Docs on Primary and secondary owner responsibilities help future-proof your project success, increasing the bus factor.
• Working alone is a slow pace of progress.
• Working with other people increases the collective wisdom behind the effort.
• SWE is hard. You need second pairs of eyes.

Pace of Progress

• Programmers work best in tight feedback loops.
• DevOps philosophy code quality evolving correctly bit by bit.
• Rapid feedback loop needed for the whole project level.

QUOTE - “ many eyes make all bugs shallow “

• Group teams of four to eight people together in small rooms to make it easy for spontaneous conversation to happen.

In short, don’t hide

Don’t become another statistic

• Working alone is inherently riskier than working with others.
• Concerned about wasting huge swaths of your time toiling away on the wrong thing.

It’s all about the team

Software engineering is a team endeavor

• Lone craftspeople are extremely rare.
• A great team makes brilliant use of its superstars
• Work with other people, share your vision, divide the labor, learn from others, create a brilliant team.

HIgh-functioning teams are gold and the true key to success.

The three pillars of social interaction

• Pillar 1 - HUMILITY

  • You are not the center of the universe
  • You are not accurate
  • You do not have unlimited knowledge
  • You are open to self improvement

• Pillar 2 - RESPECT

  • You genuinely care about others you work with.
  • You treat them kindly and appreciate their abilities.
  • You appreciate their accomplishments

• Pillar 3 - TRUST

  • You believe others are competent and do the right thing.
  • You are ok with letting them drive when appropriate.

Why do these pillars matter?

• People are messy, unpredictable, and often annoying to interface with.
• Do not underestimate the power of playing the social game.
• It’s about creating relationships to get things done.
• Relationships always outlast projects.

Humility, Respect and trust in practice.

• Lose the ego

  • Important to be humble, that doesn’t mean you need to be a doormat;
  • Ego manifests in many ways
  • Lot of time it can get in the way of your productivity and slow you down.

• Learn to give and take criticism

  • In a professional software engineering env, criticism is almost never personal.
  • The person giving constructive criticism genuinely cares about the other person and wants them to improve themselves or their work.
  • Trusting that the other person has your best interests at heart and doesn’t actually think you're an idiot.
  • Your self-worth shouldn’t be connected to cod you write

you are not your code

• Antipatterns : Do not accuse, demand or tell they are wrong and make them feel stupid. (co-worker ).

• Ask them with humility to ask the question about you. Not them.

• Fail fast and iterate

  • Failure is an option
  • If you are not failing you are not innovative enough.
  • Failure is seens as a golden opportunity to learn and improve.
  • How many ideas they can disprove or invalidate in fixed period of time

Blameless post-mortem culture

• The key to learning from your mistakes is to document your failures by performing a root-cause analysis and writing up a “postmortem”
• A postmortem should always contain what was learned and what is going to change as a result of the learning experience.

Postmortem template

1. A brief summary of the event
2. A timeline of the event, from discovery through investigation to resolution
3. The primary cause of the event
4. Impact and damage assessment
5. A set of action items to fix the problem immediately
6. A set of action items the event from happening again
7. Lessons learned

• Learn to be patience
• Be open to influence
  • More you are able to influence, the more vulnerable you are, the stronger you appear.
  • It’s impossible for you to be right about everything all the time unless you have an unchanging environment and perfect knowledge.
  • If you constantly change your mind, people will think you are wishy-washy.
  • Admitting you made a mistake increases your stat over the long run. With humility, accountability, willingness to take responsibility.
  • Your teammates are collaborators, not competitors. You all have the same goal.

Being googley

• Thrives in ambiguity

  • Can deal with conflicting messages or directions.
  • build consensus.
  • make progress against a problem, even when the environment is constantly shifting.

• Values feedback

  • Has humility to both receive and give feedback gracefully
  • Understand how valuable feedback is for personal development.

• Challenges status quo

  • Able to set ambitious goals and pursue them even when there might be resistance or inertia from others.

• Puts the user first

  • Has empathy and respect for users of google products
  • Pursues actions that are in their best interests

• Cares about the team

  • Has empathy and respect for coworkers.
  • Works actively to help them without being asked
  • Improving team cohesion.

• Does the right thing

  • Has a strong sense of ethics about everything they do.
  • Willing to make difficult or inconvenient decisions to protect the integrity of the team and product.

---

2. Knowledge sharing.

3. Your organization understands your problems better than random people on the internet.

4. You need mechanisms to distributed the knowledge

5. Your organization needs culture for learning.

6. Psychological safety that permits people to admit to a lack of knowledge.

Challenges to learning

• Lack of psychological safety
  • Environment fosters fear of taking risks, mistakes are punished, and creates lack of transparency.
• Information islands
  • Organization do not communicate or share resource in such environment often leads to
    • Information fragmentation
    • Information duplication
    • Information skew
• Single point of failure
  • This mindset leads to all-or-nothing expertise.
  • Critical information is a bottleneck from a single source, bus factor.
• All or nothing expertise
  • People who know everything vs novices.
  • Happens when experts do not develop new experts in the organization.
  • Knowledge and responsibilities continue to accumulate on those who already have expertise.
• Parroting
  • Copy pasting code/patterns without understanding.
• Haunted graveyards
  • Places where code changes might bring wrong behaviour fear of something might go wrong.

Philosophy

• Software development is multi person development
• Personalized one-to-one advice from an expert is always invaluable
• Documented knowledge better scales not just the team but the entire organization.
• Mechanism - team wiki
• Tribal knowledge exists in the gap between what individual team members know and what is documented.
• A human expert can synthesize their expanse of knowledge, use-case, Tribal and written knowledge complement each other.
• No single knowledge-sharing approach is the correct solution for all types of learning.

Setting the stage: psychological safety

Psychological safety is critical to promoting a learning environment

• In healthy environment People feel comfortable asking questions
• Google research shows psychological safety is the most important part of an effective team.

Mentorship

• Psychological safety on team - Assign newcomer to a mentor ( who is not there team member, manager, tech lead )
• A mentor is a volunteer who has been at google from more than a year
• Teammates will be open not just to answering but also asking questions.

Psychological safety in large groups

• Asking help in team is easier than asking in a large group mostly strangers

Patterns and anti-patterns of group interaction

Recommended patterns ( co-operative )

• Basic question or mistakes are guided in the proper direction
• Explanations are given with the intent of helping the person asking the question learn
• Response are kind, patient and helpful
• Interaction are shared discussion for finding solutions

Antipatterns ( adversarial )

• Basic question or mistakes are picked on, and the person asking the question is chastised

• Explanation are given with the intent of showing off one’s own knowledge

• Responses are condescending, snarky, and unconstructive

• Interactions are arguments with “winners” and “losers”.

• No feigned surprise

  • What? ! i can’t believe you don’t know what the stack is!?
  • Members afraid of admitting to a lack of knowledge.

• No “well-actuallys”

  • Pedantic corrections that tend to be about grandstanding rather than precision.

• No back-seat driving

  • Interrupting an existing discussion to offer opinions without committing to the conversation.

• No subtle “-isms”

  • It’s so easy my grandmother could do it!
  • Bias ( racism, ageism, homophobia ) individuals feel unwelcome, disrespected or unsafe.

Growing your knowledge

• Knowledge sharing starts with yourself.

Ask questions

• Always be learning, always be asking questions.
• Biggest mistake for a biggerns is not asking for help when they are stuck.
• New to a team, senior leader, you should always be in an environment in which there is always something to learn or else find a new environment.
• Patience and kindness when answering questions fosters an environment in which people feel safe looking for help.

Understand context

• Learning is not just understanding
• Understanding the decision behind design and implementation of existing things.
• Principle - chesterton’s fence : before removing/chaning first understand why it’s there.

Scaling your questions: ask the community

• Write it down from one-to-one discussion.
• Share what you write down to newcomers.

Group chats

• Group chat can automatically archived
• Group chat can be quick back and forth conversation with whoever is available.
• Group chat does not involve a structure. We should write a mailing list or a document.

Mailing lists

• Google has topic-user@ or topic-discuss@ google groups mailing.
• When you find an answer to the question you asked in the mailing list, as a best practice post the answer back to the list.
• Mailing lists are not without their trade-offs, they’re well suited for complicated questions that require a lot of context.

YAQS: question-and-answer platform

• Yet another question systems, google internal version of stack overflow.

Scaling your knowledge: you always have something to teach

• Teaching is not limited to experts.
• Expertise is a multidimensional vector, this is the reason diversity is critical to organizational success.

Office hours

• Office hours are regularly scheduled.
• Office hours are almost never the first choice for knowledge sharing.

Teach talks and classes

• Google has a robust culture of both internal and external tech talks and classes.
• Topic is complicated enough that it is a frequent source of misunderstanding.
• Topic is relatively stable.
• Topic benefits from having teachers available.
• There is enough demand to offer the class regularly

Documentation

• Documentation's primary goal is to help readers learn something.
• Updating documentation.
  • First time learning something is the best time to improvise the documentation.
  • Engineers feel empowered to update documentation regardless of who owns it.
• Creating documentation.
  • Write your own docs and update existing docs.
  • There is a mechanism for feedback
• Promoting documentation.
  • document author can often directly benefit from writing documentation
  • Writing documentation also helps your team and organization scale

Code

• At a meta level, code is knowledge, so the very act of writing code can be considered a form of knowledge transcription.
• Code documentation is one way to share knowledge.
• Code reviews are often a learning opportunity for both author and reviewer.

Scaling your organization’s knowledge

• establishing canonical sources of information, might be more beneficial for more mature organizations.

Cultivating a knowledge-sharing culture

• We believe that focusing on the culture and environment first results in better outcomes than focusing on only the output.
• Respect
  • The bad behavior of just a few individuals can make an entire team or community unwelcoming.
  • Knowledge sharing can and should be done with kindness and respect
• Incentives and recognition
• Good culture must be actively nurtured, and encouraging a culture of knowledge sharing requires a commitment to recognizing and rewarding it at a systemic level.
  • Promotion criteria
  • Performance review
  • Peer-to-peer awards

Establishing canonical sources of information

• Official sources of information are centralized.

• Company collections of written text provide a way to standardize and propagate expert knowledge.

• Canonical sources of information require higher investment.

• Canonical sources highly visible and intended to provide understanding at organizational level

• Developer guides

• go/links ( google internal URL shortener )

• Codelabs - guided, hands-on tutorials

• Static analysis

Staying in the loop

• Newsletters
  • Google has many company wide newsletters, sent to all engineers.
• Communities
• Google groups - avoids information islands and duplication.

Readability: standardized mentorship through code review

• Google early day sSilverstein would sit down in person to review code line-by-line
• Now google 20% engineers participating in readability at any given time.
• Readability covers
  • Idioms
  • Code structure
  • API design
  • Use of common libs
  • Docs
  • Test coverage.

What is the readability process?

• Code review is a mandatory at google
• Changelist ( CL )
• Readability certification for the language has approved the CL
• Readability certification = having readability
• Engineers with readability have demonstrated that they consistently write clear, idiomatic, and maintainable code that exemplifies Google’s best practices and coding style for a given language
• 2% are readability reviewers. They are volunteers, self-nominates they hold to the highest standards. Mentoring and cooperative process, aptitude for teaching, Not gatekeeping
• Readability is deliberately a human-driven process

Why have this process?

• Code is read far more than it is written.
• Primary advantage exposes the team more than just their tribal knowledge.
• Engineering productivity research team - readability has a net positive impact on engineering velocity.

---

3. Engineering for equity.

• Software engineering as the broader application
  • Code
  • Tools
  • Policies
  • Process
• Google is still learning how to engineer a product that empowers all users.

Bias is the default

• When engineers do not focus on users of different
  • Nationalists
  • Ethnicities
  • Races
  • Genders
  • Ages
  • Socioeconomic statuses
  • Abilities
  • Belief system
• Google misses the mark on racial inclusion

Understanding the need for diversity

• At Google, being an exceptional engineer requires that you also focus on bringing diverse perspectives into product design and implementation.
• Important to learn how biased outcomes happen in hiring.
• Disrupt the notion, people with a cs degree or work experience have all skills you need to become an exceptional engineer, only people with cs degree can design and build products.
• Approach is insufficient for inclusive and equitable engineering.

Building multicultural capacity

• Exceptional engineers have the ability to understand how products can have advantages and disadvantages for different groups of humans.
• Engineers expected to have technical aptitude but Exceptional engineers find out to know when to build something and when not to.
• Focus on the next billion users. Who might left behind by our products
• Build tools billions of people use daily
  • Influence how people think of huma lives
  • Monitor human activity
  • Capture persits sensitive data - images of children and loved ones other types of sensitive data..
• As engineer you wield more power than you realize, Power to literally change society,
• Responsibility needed to exercise power without causing harm.
• New use cases with AI and ML, at ever increasing speed, we pause and consider the fact that today, some people have the ability to design features of technology and others do not.
• Companies usually opted for speed and shareholder values often fail to effectively drive accountability on product equity across all areas.
• Competitive in the technology sector, we need to learn to engineer for global equity.
• Include more comprehensive, multicultural, race.
• Gender studies education is not only a responsibility but also the responsibility of your employer.
• Tech companies must ensure employees are receiving professional development, development is multidisciplinary.

Making diversity actionable

• We all are accountable for the systematic discrimination we see in the technology sector.

Reject singular approaches

• Must disrupt singular approaches to advance representation in the workplace.
• Lack of representation in the workforce can be addressed solely by fixing the hiring pipeline.
  • Engineering manager who wants to hire more women, don’t just focus on building a pipeline, focus on
    • Hiring
    • Retention
    • Progression ecosystems
    • Inclusivity for women
    • Recruiters to identify strong candidates who are women and men.
  • Focus on psychological safety and invest in multicultural capacity on the team.
• Make tools accessible for people who are struggle to access technology

Challenge established processes

• Building equitable systems goes beyond designing more inclusive product spec
• Building a global hiring requisition system - to drive efficiency, the recruiters asked the engineering team to include a feature that would highlight performance rating.
• Candidates who had received a poor performance rating were likely to overcome the poor rating if they found a new team.
• Performance ratings are indicative only of how a person is performing in their given role at the time they are being evaluated.

Values versus outcomes

• Google has a strong track record of investing in hiring, core values are based on respect and unwavering commitment to a diverse and inclusive workforce.
• Take a hard look in the mirror
• Don’t build for everyone. Build with everyone
• Design for the user who will have the most difficulty using your product
• Don’t assume equity; measure equity through your system
• Change is possible

Stay curious, push forward

• The path to equity is long and complex
• Important to understand how products impact humanity.
• Challenge team, manager to do user research.
• We should Focus first on the user most impacted by bias and discrimination

Goal is to make changes that push humidity forward without further depriving the disadvantaged.

---

4. How to lead a team.

• The person responsible for making it all work.
• No team can function well without a leader.
• Engineering is exclusively team endeavor
• Two different leadership roles
  • Manager leader of people
  • Tech lead leads technology efforts.
• Without a leader you left with a group of engineers burning up valuable time.

Managers and tech leads ( and both )

• Experienced manager come to run the team
• Individual contributor promoted into leadership position in small team
• Sometimes both the roles played by same person, tech lead manager ( TLM )
• Experienced manager will manage a larger team.
• Senior engineers with good experience will step into the tech lead role.

The engineering manager

• Software engineers managers should have an engineering background.
• Training software engineers to be managers.
• Engineer managers are responsible for keeping the team productive, happy, including team lead, while needs of business are met.

The tech lead

• TL who will often report to the manager of the team
• Responsible for technical aspects of the product.
  • Choices
  • Architecture
  • priorities
  • Velocity
• TL will usually work hand in hand with the engineering manager to ensure that the team is adequately staffed.
• TL are individual contributors.

The tech lead manager

• TLM single person who can handle both the people and technical needs of their team for small projects.
• Usually TLM is a senior person, but often roles are taken by recent individual contributors.
• It is very difficult to do both jobs without completely burning out. So we need specialists doing both the roles.

Moving from an individual contributor role to a leadership role

• Someone needs to sit in the driver's seat of the project, you might find yourself helping your team resolve conflicts, make decisions and coordinate people.
• Even if you swear yourself you will never become a manager, at some point in your career you're likely to find yourself in a leadership position.

The only thing to fear is well, everything

• The biggest reason you’ll hear in the software development world is that you spend much less time writing code. This is true when you become a TL or a manager.
• End of the busy day of management you find your self thinking “ i did not do a thing today”
• Quantifying management work is more difficult. But just making your team happy and productive is a big measure of your job.
• Peter principle - in a hierarchy every employee tends to rise to his level of incompetence
• Great response to become a TL or a manager.
  • 1st - It’s way to scale yourself, imagine how much code a team of great engineers could write under your leadership.
  • 2nd - you might just be good at it.

Servant leadership

• There is a disease that strikes managers. They forget all the awful things their managers did to them and suddenly begin doing these same things to manage the people that report to them.
  • Micromanaging
  • Ignoring low performers
  • Hiring pushovers
• This disease can kill an entire team.
• Important thing you can do as a leader is to server your team
• As a servant leader, you should strive to create a atmosphere of humility, respect and trust
• The only management that a servant leader does is to manage both the technical and social health of the team.

The engineering manager

• Before the computing age, management and labor have taken on almost antagonistic roles.

Manager is a four-letter word

• The Carrot-and-stick method of management survived the transition from factory to the modern office.
• Stereotype of tough-as-nails, manager-as-mule-driver flourished in the middle part of the 20th century when employees would work at the same job for years and years.
• SWE working on a large codebase can take months to get up to speed on a new team.

Today’s engineering manager

• Managers wind up acting like parents, consequently employees react like children.
• Obviously that they trust their employee and the employee feels positive pressure to live up to that trust.

Traditional managers worry about how to get things done.

Great managers worry about what things get done ( trust there team to figure out how to do it )

Antipatterns

• Collection of patterns that you don’t want to follow if you want to be a successful manager.

• Hire pushovers

• Ignore low performers

• Ignore human issues

• Be everyone’s friend

• Compromise the hiring bar

• Treat your team like children

Antipatterns : Hire pushovers

• Some managers feel insecure in their role.
  • Hire people you can push around.
  • Hiring people who aren’t as smart or ambitious as you are.
  • Just people who are more insecure than you
• Lot more work for you, your team won't move without you like dogs on a leash. Team of pushovers.
• Instead you should strive to hire people who are smarter than you and can replace you.
• They challenge you on regular bases letting you know when you make a mistake, these very same people will also consistently impress you and make great things happen. You can take a vacation without worrying

Antipatterns : ignore low performers

• One or two low performers in the entire team fail to excel.
• Most difficult case, when someone just isn’t capable of doing their job no matter how long or hard they work.
• High performers on the team waste valuable time pulling the low performer along. High performers leave the team.
• When someone can’t perform in your team, they can impact somewhere else, and need some encouragement or direction to slip into a higher state of productivity.
• Best way to help a low performer is with analogies, imagine a person limping, learning to walk again, then jog, then run alongside the rest of the team. Requires temporary micromanagement.
• Set specific time, goals, small incremental and measurable. Usually the person will often acknowledge that things aren’t going well and decide to quit. Or they up their game.

Antipatterns: Ignore human issues

• At Google every manager has a strong technical background, ignoring human issues.

Antipatterns : Be everyone’s friend

• Don’t confuse friendship with leading with a soft touch.
• You can lead a team and build consensus with being a close friend of your team.
• Having lunch with your team can be an effective way to stay socially connected to them without making them uncomfortable.

Antipatterns : Compromise the hiring bar

• Just because you need to hire quickly does not build a mediocre team.
• Wrong hire - cost of lost productivity, team stress, time spent managing, paperwork, stress involved in firing.
• Always hire higher quality engineers. Without this you are doomed.

Antipatterns : Treat your team like children

• Treating your team like children or prisoners is the best indicator that you do not trust your team.
• Micromanaging them is disrespectful of their abilities.

Positive patterns

• Positive management patterns.
  • Lose the ego
  • Be a zen master
  • Be a catalyst
  • Remove roadblocks
  • Be a teacher and a mentor
  • Set clear goals
  • Be honest
  • Track happiness

Lose the ego

• humility, respect and trust.
• You can still have self-confidence and opinions without being an egomaniac.
• You should work to cultivate a strong collective team ego and identity.
• Trust your team, respect the ability and prior accomplishments of team members if they are new to the team.
• Help the team set the direction, the team will have ownership, accountability and responsibility.
• Team will accomplish more than by standing over team members with a carrot and a stick.
• Most New leaders feel an enormous responsibility to get everything right, to know everything, and have all the answers. But they will not get everything right nor will they have all the answers.
• It very difficult to find people who give constructive criticism.
• Be a humble leader, apologize when you screw up
• Apologizing don’t make you vulnerable.

Be a zen master

• Be less vocally skeptical, while still aware of obstacles involved in teams work.
• see your company’s organization chart as a chain of gears, the farther you move up the chain the faster you can set the gears below you spinning.
• Leaders are always on stage, everyone watching you, do you read confidence or fear? Leaders should never panic.
• Zen management trick - asking questions.

Be a catalyst

• The Leader's role is a catalyst in helping the team.
• Building consensus is a very common thing a leader would do in teams.

Remove roadblocks

• Knowing the right person is more valuable than knowing the right answer
• Jumping in and removing roadblocks and getting them moving is a common leadership technique.

Be a teacher and a mentor

• Teaching people and giving them a chance to learn on their own can be difficult at first.
• It is a vital component of effective leadership.
• Three things you need to mentor -
  • Experience with your teams processes and systems.
  • Ability to explain things to someone else.
  • Ability to gauge how much help your mentee needs.

Set clear goals

• Ignored by an enormous number of leaders.
• If you’re going to have clear goals, you need to set clear priorities and help your team decide how it should make trade-offs when the time comes.
• Concise mission statement for the team to pull the product in the same direction.
• After direction, give them autonomy.
• Periodic checking if everything is on the right track.

Be honest

• You will be in a position where you can’t tell your team something or, even worse, you need to tell everyone something they don’t want to hear.
• It’s ok to tell the team you are not at liberty to say anything.
• It’s ok to tell the person you don’t know.
• Compliment sandwich - to soften the blow when delivering hard feedback.
• Deliver constructive criticism without restoring to the compliment sandwich.
• Delivery is key to making sure the message is heard and not deflected.
• Recipient on the defensive, They’re not going to be thinking of how they can change.

Track happiness

• As a leader, to make a team more productive in the long term is to gauge their happiness.
• Spread thankless tasks evenly across the team.
• Use comp time and fun team outings to avoid burnout and exhaustion.
• Ask team members “ what do you need? “ makes the team happy and productive.

The unexpected question

• Asking team members one-on-ones happiness scale.
• Big part of tracking your team members happiness is tracking their careers.
• Ask team members where they see their career in five years.

Other tips and tricks

• Tips and tricks when we are in leadership position
  • Delegate, but get your hands dirty
  • Seek to replace yourself
  • Known when to make waves
  • Shield your team from chaos
  • Give your team air cover
  • Let your team known when they’re doing well
  • It’s easy to say “yes” to something that’s easy to undo.

People are like plants

• Team members are also like plants: some need more light and some need more water, It’s your job as their leader to determine who needs what and then give it to them.
• Your team needs varying amounts of motivation and direction.
• You need to motivate the ones who are in a track and provide stronger direction to those who are distracted or uncertain of what to do.

Intrinsic Vs extrinsic motivation

• Two types of motivation: extrinsic, which originates from outside forces. Intrinsic which comes from within.
• What makes people happy and productive is not extrinsically ( piles of cash at them ).
• Intrinsic motivation : autonomy, mastery and purpose.
• A person has autonomy when they have the ability to act on their own without some micromanagement.
• Give them general direction to them for the product, leave it up to them to decide how to get there.
• Giving much sense of ownership of the product.
• It gives them much greater senses of ownership of the product. The bigger theri stake is in the success of the product, the greater their interest is in seeing it succeed.
• Mastery is it’s bestest form simply means that you need to give someone the opportunity to improve existing skills and learn new ones.
• Give their work purpose.
• Help them see this purpose in their work, you will see a tremendous increase in their motivation and productivity

---

5. Leading at scale.

“the three Always of leadership”: Always Be Deciding, Always Be Leaving, Always Be
Scaling

Always be deciding

• Managing a team means making higher level decisions. Higher level strategy.

The parable of the airplane

• Trade offs also apply to human behaviors
• As a leader you should make decisions about what your team should do each week.
• Guide people solving difficult, ambiguous problems.
• Identify the builders, trade-offs, decide and iterate on solution.

Identify the blinders

• Do not make assumptions about the problem.
• With fresh eyes you can see blinders. Ask questions and consider new strategies.

Identify the key trade-offs

• important and ambiguous problems do not have magic “silver bullet” solutions.
• The best answer for the moment involves trade-offs. Explain and balance them.

Decide, then iterate

• Always be deciding - with tradeoffs make decisions for a month, next month evaluate and balance the trade-offs again.
• analysis paralysis - Your team will be in a trap of finding a perfect solution without trade-offs.

Always be leaving

• Get your organization to solve the problem by itself.
• Antipattern - set yourself to single point of failure
• Bus-factor number of people got hit by buses before the project was doomed.

Your mission: build a “self-driving” team

• Being a successful leader means building an organization that is able to solve the difficult problem by itself.
  • Strong set of leaders
  • Healthy engineering process.
  • Positive self-perpetuating culture that persists over time.

Dividing the problem space

• Challenging problems are usually composed of difficult sub-problems.
• Each team will be in charge of a sub-problem.
• Risk - subproblem can change over team, rigid team boundaries won’t be able to notice or adapt to this fact.

Always be scaling

• Team scaling from a defensive and personal POV rather than an offensive one.

The cycle of success

• Standard pattern cycle.

• Analysis

• Struggle

• Traction

• reward

Important versus urgent

• Protect your time.
• As a leader your job becomes more reactive than proactive.
• Higher up in leadership you get more escalations.

I have two kinds of problems, the urgent and the important. The urgent are not important, and the important are never urgent

• What to work on Few key techniques
  • Delegate
  • Schedule dedicated time
  • Find a tracking system that works.

Learn to drop balls

• Protect your attention.
• As a leader of leaders, your time and attention are under constant attack.
• If dropping a number of balls is inevitable, it is better to drop certain balls deliberately.
• Divide your pile of balls into three groups,
  • the bottom 20% are probably neither urgent nor important, very easy to delete or ignore.
  • Middle 60% which might contain some bits of urgency of importance, but it’s a mixed bag.
  • Top 20% of things that are absolutely critically important.

Protecting your energy

• Personal energy is another piece of the equation.

• Leaders gradually learn to manage their energy more intelligently

• Some good energy management.

• Take real vacations.

• Make it trivial to disconnect.

• Take real weekends too.

• Take breaks during the day.

• Give yourself permission to take a mental health day.

---

6. Measuring engineering productivity.

• Google has found that a team of specialists focus on engineering productivity is very valuable and important as the company scales.

Why should we measure engineering productivity?

• Engineer Productivity increases your business scope.
• While organization grows in size linearly, communication costs grows quadratically
• To address the scaling problem, we can make people more productive.
• What makes engineer more productive
  • Inefficiencies in process
  • Fixe identified problems
  • Improvement loop cycle.
• Improve engineer productivity efficiently
  • Create team of researchers dedicated to understanding engineering productivity
    • SWE research field
    • Generalist SWE
    • Cognitive psychology
    • Behavioral economics
    • Social science
  • Human side of software development
    • Motivation
    • Incentive structure
    • Strategies for managing complex tasks
  • Goal of team to do a data driven assessment

Triage: is it even worth measuring?

• Measurement itself is expensive
• At Google, questions to help teams determine whether it’s even worth measuring productivity in the first place.
  • What result are you expecting, and why?
  • If the data supports your expected result, what action will be taken?
  • If we get a -ve result, will appropriate action be taken?
  • Who is going to decide to take action on the result, and when would they do it?
• Good reasons to not measure the impact of a tool or process on productivity
  • You can't afford to change the process/tools right now
  • Any result will soon be invalidated by other factors.
  • The results will be used only as vanity metrics to support something you were going to do anyway
  • The only metrics available are not precise enough to measure the problem and can be confounded by other factors.

Selecting meaningful metrics with goals and signals

• Google sues goals, signals, metrics ( GSM ) framework to guide metrics creation
  • Goals are the desired end results.
  • Signal is how you might know what you achieved the end result.
  • Metric is a proxy for a signal.
• GSM framework suggests, create goals first, then signals and finally metrics which prevents the streetlight effect.
• Streetlight effect - “looking for your keys under the streetlight”
• GSM helps prevent both metrics creep and metrics bias by encouraging us to come up with the appropriate set of metrics
• Traceability - each metric should be able to track back to the signal that it is meant to be proxy for and to the goal it is trying to measure.

Goals

• Goals should be desired property without any metric
• Everyone has to agree on goals before proceeding to signals, metrics
• Identify the correct set of goals.

Google research teams 5 components of productivity “QUANTS”

• Quality of the code
• Attention from engineers
• Intellectual complexity
• Tempo and velocity
• Satisfaction

Signals

• A signal is the way in which we will know we’ve achieved our goal.
• Every goals should have at least one signal
• There is no 1:1 relationship between signals and goals.

Metrics

• Metrics are where we finally determine how we will measure the signal.

Using data to validate metrics

• Created a metric for measuring each engineer’s median build latency
  • Goal - capture the typical experience
• experience sampling study
  • Survey about their experiences and expectations of build latency
• Quantitative metrics are useful because they give you power and scale
• Quantitative metrics don’t explain why an engineer chose to use an antiquated tool to accomplish their task
• Qualitative studies can then provide insight on the next steps to improve a process.
• Evaluating the impact of readability on productivity in 3 steps
  • 1st - survey specifically about the readability process
  • 2nd - large-scale survey tracking track items not specifically about readability
  • 3rd - fine-grained logs metrics from dev tools to figure out how much time logs claimed it took engineers to complete specific tasks.

Quants - goal - signal - metric

Taking action and tracking results

• Goal is to take action and improve productivity.
• Google always prepares a list of recommendations for how we can continue to improve.
  • New features to a tool
  • Improving latency of a tool
  • Improving documentation
  • Removing obsolete processes
  • Changing the incentive structures for the engineers.
  • Tool driven