• Object’s instantiation is done via reflection ApplicataionContext.getBean(), and after that object’s properties are done via object’s init
• When object A needs another object B, we will recursively uses ApplicataionContext.getBean() to get A, and then inject into B. At this time, the objects are created, but their properties are not set.
• Suppose A has B, and B has A as member, on init
  • A insantiated first
  • A finds that B is needed, getBean() on B
    • B is instantiated
    • B finds that A is needed, getBean() on A. At this time, A’s reference is registered already, so Spring returns reference to A in the first step
    • B sets the member reference to A, finishes the init, and return
  • A now gets the reference to B, set its member reference to B, and returns

Implementation

	protected Object getSingleton(String beanName, boolean allowEarlyReference) {
		Object singletonObject = this.singletonObjects.get(beanName);
		if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
		//first time ever to create
			synchronized (this.singletonObjects) {
			//singletonObjects is { bean_name : ObjectFactory} map
				singletonObject = this.earlySingletonObjects.get(beanName);
				if (singletonObject == null && allowEarlyReference) {
				//bean is marked in creation, but not created, do it now
					ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
					if (singletonFactory != null) {
						singletonObject = singletonFactory.getObject();
						this.earlySingletonObjects.put(beanName, singletonObject);
						this.singletonFactories.remove(beanName); //make sure we init only once
					}
				}
			}
		}
		return (singletonObject != NULL_OBJECT ? singletonObject : null);
	}

RocksDB concepts

• Column family: Each k-v belongs to only 1 CF. CFs share the same WAL (to support atomic writes), but different memtable and table files. Note classic CF mapping would be (row_key, a sorted list of (column, value)), but in RocksDB it is just (cf, key, value)
• Write buffer stores the memtable. Block cache is where RocksDB caches data in memory for reads
• Memtable flushes are by default scheduled on HIGH thread pool, while compactions on LOW thread pool. Stalling memtable flush can stall writes, increasing p99 latency. Set the thread pool with max_background_jobs

Compaction

• Size-tiered compaction strategy: small SSTable to medium SSTable. trade read and space for write amplification. Compaction merges all sorted runs in one level to create a new sorted run in the next level.
  • A common approach for tiered is to merge sorted runs of similar size, without having the notion of levels
• Level-based compaction strategy: Each level has at most 1 sorted run. Some data will go to the next level if current level is approaching limit. Trade read/write amplification for space amplification. In paper is all-to-all merge, but in RocksDB it is some-to-some
  • Leveled compaction in RocksDB is also tiered+leveled. There can be N sorted runs at the memtable level courtesy of the max_write_buffer_number option– only one is active for writes, the rest are read-only waiting to be flushed. A memtable flush is similar to tiered compaction – the memtable output creates a new sorted run in L0 and doesn’t read/rewrite existing sorted runs in L0.
• Sub compaction speed up a compaction job by partitioning it among multiple threads.

Read & write amplification

• RA counts the number of disk reads to perform a query. It is defined separately for point query and range queries
• Flash-based storage can be written to only a finite number of times, so write amplification will decrease the flash lifetime
• LSM with level-based compaction has better write amplification than B-tree

How TiKV uses RocksDB

• All data in a TiKV node shares two RocksDB instances. One is for data, and the other is for Raft log.
  • The default RocksDB instance stores KV data in the default, write and lock CFs
• raft logs are stored as region_id/log_id -> value
• data is stored as key + bit inverted ts -> value. TS is inverted, so that highest bit will be the first item
  • Tikv uses prefix bloom filter, i.e., it predicts on the prefix instead of the whole key
• Use TableProperties in Split Check, MVCC GC, and compact region range
• When adding a replica to a new server, generates a SST snapshot and sends to the new server directly
• Disk space will be released only when tombstones have been compacted

Motivations

• More writes than reads, but still need to keep an index for retrival, e.g., histroy tables, logs, and other time-series data
• The original paper focuses on the hardware cost LSM brings, and claims it is much better than B-tree. The root cause is the lower disk arm cost

Overview

• Mutliple level of trees, for the simplicity, we assume 2 levels: c0 and c1
  • c0 is a small, in memory, AVL tree. Implmentation wise, it is the MemTable backed by WAL, which stores keys sorted
  • c1 is an on disk B tree, but its hot node’s pages are most likely in memory
  • In practice,the LSM tree typically consists of multiple levels, each representing a sorted run of data. Levels closer to the top have newer and more frequently accessed data, while lower levels contain older and less frequently accessed data.
• On insertion, the new index entry goes to c0, and will be merged to c1 when c0 becomes too big
• Retrival will look at c0 and after that c1
• The design gives trade single key read for key range scan and write performance

In memory c0

• Recovery is done by reconstrution from the record logs, since c0 hosts only the most recent inserts. However, we still need to define the replay starting point carefully
• Deletion is handled as a special deletion node
• When the MemTable is too huge, convert current MemTable to an Immutable MemTable (IMT),and create a new MemTable.

On disk c1

• single page nodes on each level below the root is place together in multi-page disk blocks. Each node 100% full
• Note direct write to c1 except during the merges. So that we don’t have to read-modify-write an entire block due to the random write
• On disk data is sorted runs of data with no overlapping key ranges
• Implementation wise it is the SSTable. Again, keys are store sorted

Read

• start from lowever level SSTable and keep going deeper until we first find one.

Update

• just like insert. This means we accept that multiple versions of same key exists at different SSTables

Delete

• insert a k-del mark. The value will be truly deleted when SSTables merge

How to merge

• Idea similar to merge sort. Assuming we have a pointer ,for each tree, to the next to leaf to merge
• During the merge the indices are still available except for short locking period
• Starting from the smallest value of c0, and load the next multi-page block from c1 into memory
• Generate the new multi-page block similar to merge sort, and write them back to the right most positon of c1. Note that parent node references will be updated too, and old c1 blocks will not be recycled immediately for recovery purposes
• the merged leaves from c0 will be removed from memory
• The process repeats after the right most c0 leave is written to c1
• Merge process itself will checkpoint and flush to disks periodically

• Every two hours’ data is in the same block. Each of block is a directory with chunks, one metadata file, and one index file
• On average each sample takes no more than 2 bytes
• Almost every section starts with a length field, and ends with a CRC32 checksum

Index file

• Symbol table: a sorted list of strings, which are used in label pairs
• Series (more below): a list of series. Each series hold the label set of the series and its chunks (more below) with blocks
• List of postings: Each posting is a list of series references that contain a given label pair
• Posting offset table: list of entries, each is a label pair to offset to its series list in the postings list section. This section is sorted
• Table of content: entry point to the entire index and points to various sections in the file.

Series section in the index file

• Each series holds number of lables, followed by the tuple of symbol table references
• The next section is the number of indexed chunks, each of chunk index contains the min time and max time of the time, and their position in the chunk file. Note that all ts except the first one is stored as deltas

chuck

max 512 MB, each record of chuck is len + encoding + data + CRC

WAL

128MB by default. A segment is written to in pages of 32KB. Mostly borrowed the idea from rocksdb

• type
• len
• CRC
• data

WAL accepts

• Series records encode the labels that identifies a series and its unique ID
• Sample records encode samples as a list of triples (series_id, timestamp, value)
• Tombstone records encode tombstones as a list of triples (series_id, min_time, max_time)

Example

Suppose i have one serive deployed on two machines, each will output [{service: sid}, {node: nid}] label sets

Inside the index file

• Symbol table: [n1, n2, node, service, sid]
• Series:
  • [2, 0, 3, 4]
  • min time in c1, delta for max in c1, offset in c1
  • [2, 1, 3, 4]
  • min time in c2, delta for max in c2, offset in c2
• Postings:
  • [0], [0, 1], [1]
• Posting offset table:
  • ((node, n1), 0), ((node, n2), 2), ((service, s1), 1)

Note in the design, we have direct index on only single lable pair, or the raw data. This means most queries, we will have to merge to find series entries, and then scatter-merge

Notes form HBR review articles

• What we can learn from Japanese Management
• How to negotiate in Japan

Working with interpretors

• If possible, share the draft doc/presentation beforehand
• Loudly and slowly, use simple words
• Explain the same idea in 2-3 different ways as checksum
• 30 secs break to let interpretors go
• Number is easy to mistranslate, write it down if possible
• Do not interrupt interpreters
• Use positive form instead of negative wording. Also avoid double negatives

• Use body movements

• Japanese decision process is very democratic - ringi means buying in from all stakeholders, instead of LCA of those stakeholders. (I got burned by the slow process many time)
• When the negotiation is stuck, keep the channel open and ping from time to time
• Ask Japanese lower levels for more info on friends and enemies (nemawashi?)

Reading notes on 俞军产品方法论. Page number in brackets

• AB test lowered barrier to become PM, and weaker PM can use good result to slack off on thinking on customers (13)
• Bar of PM (23)
  • to understand the domain model of a user - able to predict with reasonable accurancy on the effect of iteration
  • research user model, and analyze with real individual as sample
• For user with consistent perference and congnition, no need for special scenarios. Otherwise, need extra work needed to guide user so that he would max expected utility by conducting the desired behavior
• Hierarchy is more efficient than democratic process in the context of company. Note hierarchy here means the professionals and domain experts. Each hierchary inside company needs to have higher efficiency than market, and each expert needs to make better than average decision at his position.
• Outcome of the product (useful to write after action report)
  1. financial gain
  2. domain know-how, more accurate self-evaluation and awareness, and innovation
  3. a team which works well with each other
  4. trust between user and upstream/downstream stakeholders. This reduces transaction cost of new transactions and products
• Once owning something and then selling it means some form of loss. For the same amount of change, negative unitily loss is about 2.5 times of positive gain.
• Problematic to analyze user as a natural person, i.e., # of registered user is a flawed metric - company may ignore what utilities it provides and how many user requirements are satified. Similarly, same DAU may mean much more user value, if the product satifies more user requirements as it goes
• Tech metrics improvement may have low corelation with the utility the user feels. This means we should decompose products into utilities, analyze the iteration’s effect on the utilites, and then predict user behavior change caused by utilities changes
• source of transaction cost (112)
  1. bounded rationality
  2. opportunism: mistrust between parties means increased monitoring cost
  3. uncertainty and complexity: have to price them in
  4. small number/volume market
  5. information asymmetric
  6. atmosphere
• Transaction cost in the context of market (113)
  1. search and measure
  2. compare and decide
  3. execution and warranty
• User’s trust may be far off from facts. In this case need extra work to fix that(115)
• standarize product to make quality easy to manage, and thus to reduce transaction cost (115)
• for bigger platforms, it is about trade off instead of innovation and design (132)
• convert users new to the domain asap, this will increase the conversion cost for competitors (136)
• Data-driven slows down the decision process, and only possible when data is cheap and readily available (142)
• Extra profit comes from people with good judgement - often not data driven (146)
  • When have an idea, write it down and try to disprove it, and update it with new info and context in the future
• User should mean a combination of requirements in a certain scenario (157)
• If your manager or partner lacks critical thinking skills, agree and praise on minor points, make them feel that you are similar, only after than insist on major points (159)
• Discover, but not create requirement(283)
• Use (price user willing to pay) - (company cost) to decide if it is good business
• PM needs to have judgement on the decision’s certainty and feasibility (288)
  • Care about user feedback but not suggestion
• PM needs to decide when to data-driven and when to use data only as reference point (315)
• PM should be gave to able to split the difference. (320)
  • Avoid right but aggressive person
• PM should have good sense in decision making, commercial, and professional/domain. (326)
  • If only one product, then CEO or founder is the biggest PM

• Start from easier ones, e.g., Spring Boot
• Read the dependency first, e.g., kafka -> zookeeper -> java.concurrent
• Create a hello world, add debug points. Go top-down upfront only after you are familiar with the codebase
• Try NOT to understand every single line, just focus on the most important flow
• Draw graph
• Need to repeat this a few times to trully understand it

• Wait for problems before you introduce solutions (esp. processes or infrastructure)
• Your boss expects you to give input on what should be worked on. Use your down time to research that
• If you hear other teams complaining on a problem, don’t bringing in the solution yourself. Wait until they raise it, or inform that team’s manager, and let him decide
• Need to convince all stakeholder they want you to solve this problem. This buy-in process will take a while. If it is too tiring, then maybe you should not solve it
• If you find a problem in another team with clear examples, and they are not able to address it to your satisfaction, it is time to escalate to your manager, but not before that.
• Solving unowned problem is fun from time to time, but should not be normal - you are not following the right company/boss
• To build trust, teach your team how to show work, and fix how to give feedback
• Talking to customers directly is more effective than any observation data. Observation data needs formal process for evalutaion
• To affect opinions of people, not only the person himself, but also whoever that can directly affect the said person too. Build common interest between the people around the authority
• Easier to advance your career with profit center than cost center

• ReentrantLock is just an encapsulation of AQS: it has a Sync object which extends AQS
• Need to implement tryAcquire in AQS

vs synchronized

• Synchronized is based on JVM, RL is based on AQS in JDK
• RL supports lockInterruptibly, so that other waiting threads can stop waiting
• RL supports fair lock, synchronized is unfair lock
• synchronized uses notify()/notifyAll(), i.e, only one Condition for the whole monitor. No such limitation for ReentrantLock

State: 0 - nolock. Every acq +1, release -1

ReentrantReadWriteLock (RRWL) uses 16 bits to save write lock state, and 16 bits for read lock state

The Stretch Goal Paradox

• Stretch goal means diffculty and/or novel. Note that a series of small wins itself do not lead to stretch goals, because path to stretch goal is uncertain, and can be broken down up front. However, small wins build the resources, energy, and learning needed for stretch gaols
• Slack resources + recent wins = stretch goal. Be self-disruptive
• no resource + recent wins = small wins with incremental successes.
• slack resources + recent loss = experiement for small losses,i.e., mildly risky experiments. This builds resillence and confidence in the org
• no resource + recent loss = small wins with incremental successes. However, orgs in such states are most likely to use stretch goals
• Slack resources has be conciously built. One way is to focus on learning to enchance existing resources

Reading notes on this famous book by Andy Grove

• Manager is responsible for the output of the neighboring orgs they influence
• Leverage is best done via information gathering, decision making, and “nudging” others by providing suggestions
• For mission-oriented meeting, the meeting chair should be responsible that stakeholders are well prepared
• Centralized for leverage, decentralized for speed
• The author favors matrix managment structure, one for functional, one for mission.
  • The decision making will be done via this peer group
• When complexity, uncertainty, and ambiguity is low, the behavior is influenced by the expectations, when they are high, culture is the main driver. Which is more suitable depends on the context
  • However, when user’s focus is more on the self-interest rather than group interest, low CUA means people will be driven by incetives, and such people are not manageable in high CUA
• It is not a problem if people left for money or perks. It is a problem when they feel unheard or unappreciated
  • When people want to quit, just listen. Don’t argue. Wait until the prepared part is let out, so the real issue will emerge
  • Ask for time before you come back with solution
• Pair the the output indicator with the quality indicator
  • Measure output not activity
• Batch up issues and questions to reduce interruption
• No more than 8 people for decision making meetings. No more than 25% of time spend on ad-hoc mission meetings
• turning the workplace into a playing field where subordinates become athletes dedicated to performing at the limit of their capabilities
• Don’t make friend with people you manage if you find it hard to deliver a hard performance review. Otherwise, it is OK
• You need to be optimist to build a product, but that also means you are more likely to ignore bad news
• For conflicts, for each opinion pick the lead, and form a meeting with their lowest common ancestor to break ties
  • Don’t make your own decision
  • Make sure you get involved
  • Breaking tie also means the conflicting sides give up responsibility
• People follow company values way more than strategy

Running meetings

• Mission-oriented meeting: solve one problem. It should have no more than eight people. After this it is hard to reach a consensus. Once the meeting is over it is the responsibility of the chairman to send minutes that summarize the discussion that occurred, the decision made and the actions to be taken.
• Operato reviews: process-oriented,i.e., scheduled at regular intervals, present results to people not related to the area. Supervisor should ask questions

Goal

• 80% of requirements can be released in 2 weeks
  • Deadline is the best driver: so small deadlines
  • The true end of task - complete work and get evaluation
    • An outcome is typically defined by a quantitative metric. a number that is both meaningful to the business and measurable by the team.
    • Not easy to define the correct metrics and infrastructure to measure it. Part of the reason OKR uses multiple iteratons to refine the metrics
  • Work complicates to fill the available time.
• 80% of requirement dev can be done in a week

• 80% of release can be done 1 hour after the submit

• Assign a coordintor for progress coordniate if >= 3 people involved - most likely owner
• Key to the problem is almost always blocked requirment instead of blocked resources
• Don’t commit a hard deadline unless you have to - your schedule will become highly inflexible

Estimation

• Underestimates do not change significantly during the activity until about three weeks before the scheduled completion
• Imagine 3 times effort from a debugged program to a product, and 3 times effort from debugged problem to the integrated system
• Insider tends to under-estimate time (even with prior knowledge on similar problems), outsiders tend to over-estimate
• However, if we break down tasks, the segmentation effect tells us that the sum of sub-task estimates are greater than the singel time allocated to the whole tasks

Foreach is the syntactic sugar for iterator for that collection

In ArrayList’s Itr

        int cursor;       // index of next element to return
        int lastRet = -1; // index of last element returned; -1 if no such
        int expectedModCount = modCount; //modCount is from the list

        public boolean hasNext() {
            return cursor != size; //size is from the list
        }

If we call ArrayList.remove() inside foreach to remove the non-first element in the list

• hasNext() will return true because cursor is now > size, and Itr.next() will be triggered
• next() will checkForComodification()

   final void checkForComodification() {
            if (modCount != expectedModCount)
                throw new ConcurrentModificationException();
        }

At this moment, because we didn’t remove via iterator, the expectedModCount will be less than modCount, and exception will be thrown!

Note that Itr has a remove() but does not have add

     public void remove() {
            if (lastRet < 0) //this check ensures that we can't call Itr.remove() twice in a row
                throw new IllegalStateException();
            checkForComodification();

            try {
                ArrayList.this.remove(lastRet);
                cursor = lastRet;
                lastRet = -1;
                expectedModCount = modCount;
            } catch (IndexOutOfBoundsException ex) {
                throw new ConcurrentModificationException();
            }
        }

In ArrayList, it has a modCount.

In ArrayList, we have an internal Itr time, which has a expectedModCount, it implments Iterator, i.e., the instance you get from ArrayList.iterator and use that to prevent concurrent change but iterator.remove is OK

Happens before rule

• For a lock, all ops before lock releases happens before ops after lock is acquired
• All volatile writes and before its writes happens after reads and ops after that read
• Thread start and ops before that start happnes before things within that start

1. Volatile forces the program to write the value immediately to the memory in an atomic action by passing cpu cache. reading bypasses CPU cache too, or force the CPU cache to expire early
2. This means if we have only one writer, and all reader/writers are volatile, then the program is thread safe. However, it is not true if you have more than one writer
3. Visibility rule: if the thread reads a volatile value, then ALL variables visible to the thread will be re-read from the memory. This means the order of instructions matter! If you have read AFTER the volatile read, or it got reordered by the compiler, than the vars after the volatile is NOT affected. Luckily, JVM prevents this
4. Note ++ is a syntactic sugar, it is compiled into a read-update-write operation - so you can’t use volatile with it!

Java singleton with volatile

public class Singleton {

private voltile Singleton _instance;

private Singleton() {
}

private Singleton getInstance() {

	if (_instance == null) {
		synchronized(Singleton.class) {
			if(_instance == null)
			  _instance = new Singleton();
		}
	}

	return _instance
}

}

Note that without this volatile the code is incorrect

• Compiler might reorder the so that _instance is assigned the memory address before the instance finishes init
• This means the another thread may get an object with only defaults

static

class King{

private static King kingInstance;
static {
	kingInstance = new King();
}

private King(){
}

public statiic King getKingInstance() {
	return kingInstance;
}
}

class King{
private static final King kingInstance = new King()

static King getInstance() {
	return kingInstance;
}

private King(){
}

}

Lazy loading with internal static class

public class King {

private King(){

}

private static class KingInstance {
	private static final King KINGINSTNACE = new King();
}

public static King getInstance(){
	return KingInstance.KINGINSTANCE;
}

}

• static interanal type will not be instantiated immediately at class loading time, and only be instantiated at the first call of getInstance()
• JVM’s class loading is thread safe, so only class is loaded

• Try to keep only ONE owner who is also the decision maker. Decision by committee is OK if it is weighted
  • Make sure input provider feels heard. Record people’s inputs and decisions
  • After that, vote with weights, privately, and the whole team will commit to the decision
  • The team should agree on for long they will commit the decision before revisiting it. The decision maker has an emergency button to revisit it sooner
  • Email the minutes to all stakeholders. In the email, include input providers, and each options’ pros and cons.
• Avoid the analysis paralysis
  • Have a deadline by which the decision has to make.
  • Don’t wait for the complete info to arrive
• Delegate the decision making to someone on the team if possible.
  • If you are OK with whatever decision the delegate makes
  • Once done so, try not to override the decision in the last minute, which is a sign it should not be delegated!
• The approver does not veto on decision itself, but on the quality of the decision
• People start with opinion rather than fact. So just ask people to search for facts that defend this decision
• Decision is rarely between right and wrong, but between different trade-offs.

Why does innodb pick B+ tree over B tree

• Non-leaves no longer store the data, so each node can store more childs, i.e., the tree height will be lower
• Linked list between leaves means range search/scan is easier
• Leaves goes to disk, non-leaves good for memeory

How to estimate index size

• B+ Tree each node fits into a page, with k keys, k+1 pointers the children, and 2 pointers to siblings
• An OS page is about 4KB, innodb is 16KB
• Estimate 64 bit key + 64 bit address = 16 bytes, so each node will point to about 1k nodes
• Therefore, a B+ tree of level 3 (inlcuding the root and leaves) can host almost 1B rows
• For 1B rows, total index for 1 key will be around 16G. In effect, it will be more considering padding and non-long PKs

Innodb buffer pool

• Two LRU lists, New vs Old = 5:3. Both stores index and data pages
• New list is mostly explicitly hit pages by the query
• Old list is mostly read ahead pages. All pages start at the head of the old list, and will move to the new list once it is hit
• Aurora defaults to 75% of node’s physical memory

Change buffer

• Not avaiable in Aurora
• Uses buffer pool space. defaults 25% of the buffer pool, max 50%
• Cache non-clusterd index change, and merges it only when the said index page is loaded into the buffer pool
• The motivation is that modification into the secondary index is often very random access, and yet we have to read them into the buffer pool to process it

How to act in scenarios

• You are in a position of authority and need to issue an unpopular decision from your supervisor
  • just issue the decision, espeicially ones applying to everyone and/or the decision is from your supervisor
• Sudden bad news/crisis Options:
  1. From competitors, find their weakness to exchange, or escalate that into a common/general problem to shift focus
  2. From public/users, transparent on all known
  3. Product, slient/fallback/stay low.
  4. Note often these things appear together. Need to identify which is the main one
• Authority issues a decision you deemed incorrect
  • Once the boss made the decision, it is our job to fulfill the vision within the boss’s framework. Don’t expect to influence the boss too much on the decision. In general, do not try to change people
  • You may disagree, but have to commit
• Rejected by the authority in front of your subordinates
  • Know that the authority often has a different context - thus, complaining only shows that you are narrow minded
  • One way is to not talk about that, and let time dilute the effect
• Sudden incidents need to address
  • If incidents from external, focus on that as it brings more impact. If it is internal, emphasize on it will give a (false) impression of internal disorganization
• Got blamed for things out of your scope
  • explain that not within your scope
  • offer your solution - put more emphasis on what you can do to help solve the problem.
• Commanded by bosses’s boss directly
  • Should obey the command
  • Explain current context including boss’s direction
  • Let the boss know the change and command as soon as time permits
• Someone wants to gossip with you
  • Be very explict you are not interested
  • Change topic
  • If keeps happening, report to his manager

REMEMBER

• Shut up on issues related to money and people management - that is the management’s job
• Importance is to bring value to the boss. Do not use threatening with resigning and active rejection
• Don’t mention things you hear in different locations, at least don’t frame as such
• NEVER complain your company or your team’s task in front your subordinates and stop the complaints at you! However, it is OK to complain to your boss!
• Corrective/negative feedback should be executed by the direct supervisor, even if it is from upper management

Training

• Training is one of the highest leverage activity can be provided to a team. Do it yourself, or have the best employees in each area run trainings
• Change how people think by letting them practice different behavior over time
• Mentor is strong reason an employee stay. A cheap, effective, but time-consuming motivator
• No need to be formal, but need to be intentional
• In training, spend more time on practice/repetition, and less on content

Finding interesting work for the team

• If you want to be able to find interesting work and also work on important things, you generally have to go find the interesting important things yourself. This requires that you to talk to a lot of people and listen to their problems, and then place a bet on a solution to one of these problems that will actually both be feasible but will also be seen as important. Your manager might help identify people that you could talk to, but you must take responsibility for doing the legwork and making the final choice in problems to address.
• A critical feature of effective complex organisations is that they make people do all the jobs.
• Most companies design jobs and then slot people into them. Our best managers sometimes do the opposite: When they find talented people, they’re open to creating jobs around them.
• The best go out of their way to help people do work they enjoy — even if it means rotating them out of roles where they’re excelling.
• In the first week on the job, managers sit down with their new hires and ask them about their favorite projects they’ve done, the moments when they’ve felt most energized at work, the times when they’ve found themselves totally immersed in a state of flow, and the passions they have outside their jobs.
• Build a searchable database of experts. The goal is to put employees’ strengths on display so that people know whom to contact.
• Let them experiment. Let them obsess. Let them scratch that itch. If there is no project on their plate that you know is engaging them, create time for them to explore whatever they want to obsess about. I absolutely guarantee there is an investigation somehow related to their work that they are dying to tinker with.

Perks

• Many companies have over-invested in hygiene factors. High pay, tons of perks, and over-investment in superficial aspects of “company culture” represent the wrong end of the 80-20 rule for impacting the motivation of your people.
• Perks can be expensive, but they’re easy. Once you add a perk, it just continues to be a line item on your budget. There’s little you have to think about.
• The next time you think about adding a perk, challenge yourself how beneficial it will really be for your company. Avoid the trap of choosing perks rather than the hard work of improving your managers
• Talk about great managers as your company’s No. 1 benefit. Manager quality is the single best predictor of whether an employee will stay or leave. Good managers also cause their reports to have higher performance scores.
• People refer friends because it’s a great place to work, not (primarily) for the referral bonus.

• Non cash rewards, whether they are experiences (dinner for two, a trip) or gifts (a new phone) trigger an emotional response. When people are surveyed they say they prefer cash awards, but they report higher levels of happiness when receiving experiential awards.

• Rather than just look at how to engage employees, it’s also helpful to look at how to lose them, and do the opposite.
• Spread mundane, chore tasks evenly between teams
• Stress is stress, fatigue on one task spills over into another
• we need to be mindful that what is going on in our players’ minds, and in their personal lives away from the training ground, plays a huge part in what we get from them on a day-to-day basis

• Have to be interested in people when face-to-face
• Start with your own shortcoming and the counterpart’s supriority before criticizing
• Quick feedback loop!
• Specific details when you compliment
• Give people a fine reputation they live up to. Use titles and responsibilities as toys for people that they want to own
• Always makes people happy doing what you suggest. What benefit will they gain from doing what you suggest?
• Rejecting people is OK, but see if you can provide an alternative solution at the same time
• Avoid insult, ridicule, criticize in most cases - they are just not productive. (On a side note, i see so many people violating this by trying to be funny)
• Use the person’s first name as much as you can
• Do not tell other people you are wiser than them
• Don’t teach people, guide them to find it within himself
• Presenting facts in a vivid, dramatic way with multiple senses