The book is a collection of thoughts from a Silicon Valley engineering manager, on software development, managing people, working with managers and shipping products. The content mostly rehashes his blog, randsinrepose.com, and that leads to the only valid criticism of this book – that it doesn’t flow well. This post distills down / rehashes the memorable parts.
Picking a manager to work for – answer the following questions for yourself for each prospect
Your boss has as much of an effect on your career as you do, pick one wisely. If you don’t like your manager, you can leave and go elsewhere, but there’s a manager there too and he’s got his own obscure agenda as well.
- Where does she come from?
- How is she compensating for her blind spots?
- How does she talk to you?
- How much action per decision? Does she do what she said she would do, does she make things happen?
- Does she speak managementese? (even if you hate it, this is required if she interfaces with other managers/orgs)
- What happens when she loses her shit?
- How do her peers talk to her?
- Is she running her meetings?
- How does she react to pride, when things are going well with the product and the org?
- Does she take care of those who got her there? (her team)
- Does she have a plan for what’s next?
- How does she react to panic, when layoffs occur?
- Participating in a layoff – often the first time you see that the organization is bigger than the people.
Checklist for the first 90 days in a new job
- Stay late, show up early – long days of watching people will give you insights.
- Accept every lunch invite that you get.
- Ask about acronyms
- Say something really stupid (this goes towards mapping out the consequences of what happens – better to make a mistake now than later, and make a mistake now and figure out what price you’ll pay for it)
- Have a drink
- Test your influence – tell someone what to do.
- Have an argument. Can people argue without losing their shit? Who swoops in to save the day?
Things you want to understand about your manager / team
- What does she want?
- How does she deal with a crisis?
- How does she communicate?
Each time you figure this out, it is an arrow in your quiver. The next time you see a similar problem, you grab the right arrow, carefully aim and shoot. Having said that, human beings are confusing, erratic and emotional. What worked one day, won’t work the next.
Traits of a great manager
- Someone you can make a connection with no matter where you sit in the org chart.
- Someone who works terribly hard to spot the subtle differences in each of the people working for her.
As a manager
- Your job is the team. Build a team that accentuates your strengths and fills your weaknesses.
- Each person has a vastly different set of needs – fulfilling these needs is one way to make them content and productive.
- You need to constantly assess your colleagues, figure out what motivates them, and determine what they need.
- It is your ability to construct an insightful opinion about a person in seconds that will make you a phenomenal manager.
Dealing with a manager who’s not technically great and ‘wedged’ their way in
- Remember that they have solid information detection skills.
- Talk whatever language they talk – if they came from QA, describe your work to them in a way/mechanism that makes sense to them (“This is what I do and this is why it matters”). Your manager is your face to the rest of the org. The organization’s view of your manager is their view of you.
- Take what skills they have – the ones that got them promoted, figure out how to make them scale. It’s more than about just your immediate job at hand – that being done well is necessary, not sufficient.
- “Where do you need help?” – Ask the same question in every interview you have.
- Politically active managers aren’t bad – They know when change is afoot, and what steps to take to best represent their organization, in that change.
There is no magic organizational osmosis – managers need to talk to everyone on their team, regularly.
- Freak-outs normally happen on a Monday. The person freaking out has been stewing over the problem the whole weekend.
- Don’t participate in the freakout.
- Give the freak the benefit of doubt – they likely have something important they are unable to voice correctly, and it’s your job to get that out in detail.
- Hammer the freak with questions.
- Get the freak to solve their own problems – after all, they’ve been chewing on those problems since Friday.
- A freak-out is a management fail. It tells you two things –
- There is a problem.
- Someone in your org thinks the best way to get your attention to this problem is by freaking out.
- Know the typical meeting roles
- Know what these roles want out of the meeting.
- Meeting types –
- Informational (easy)
- Conflict Resolutional (tough)
- Meeting attendee types –
- Players (have an incentive, will speak up)
- Pawns (silent, instrument of the meeting)
- Identify the players –
- Pros are the ones who benefit from the current situation, and are ok with it. They can be difficult, as a pro can pretend to be a con e.g. the product manager criticizing the sales folks for promising something that hasn’t been built yet, could be doing so just to convince the engineers she’s on the same side of the team.
- Cons are the ones who are unhappy – they are why the meeting is unhappy, and they are easy to identify because they are screaming and shouting.
- If no players, and all windbags, get out. This is difficult to detect when you are new to the org.
- The players fall in two categories – pros and cons. Find who the pros and cons are.
- Figure out the issue.
- Typical meeting personalities –
- Anchor (the one who has decision making authority) – Know who the anchor is.
- Don’t be the laptop Larry, one who shows up to a meeting he is not required at, and pretends to work with a laptop.
- Mr. Irrelevant could be a mole gathering information for someone else.
- Chatty Patty – contain her
- Translator Tim – use him to your advantage, he helps bridge what two different people are saying.
- Curveball Kurt
- Sally synthesizer
- The snake – watch out for this one. They are the anchor but don’t wanted to be outed as one, for reasons.
- A manager’s role with a mandate –
- Deliver (again) # You do this to convince the team that this is a mandate.
- Mandates are the friends of the silent majority – the ones who don’t care about the outcome either way and just hope there is a decision so that they can get back to work.
- “I still piss off those who disagree with the decision, but they know they were heard.” – This is a sign of a good manager. There is no other way out – as the alternative is to let the team keep debating and lost productive time.
- “Deliver (again)” – When you deliver the mandate again, it reinforces the decision for both the losers and the winners. It gives everyone involved a chance to speak up.
- This moves your karma towards motivator and away from tyrant.
- As a manager, you cannot have a yawn opinion about a mandate. Because someone on your team cares and wants to know. As an IC, you can have a yawn opinion.
- There are local mandates (what is decided by you or someone in your upward reporting chain) and there are foreign mandates (those that come to you, and you’ll have to deliver down).
- Mandate justification often does not travel well through a large organization.
- Someone in the food chain often did not care to gather a justification or had a ‘yawn’ reaction to it.
- This poor communication is what leads to companies with reputations for tyrannical CEOs. You can never tell sitting where you are, if they are poor communicators or just tyrants.
When a manager hears gossip in the workplace, she thinks about –
- What is actually being said here?
- What informational gap is being filled by this fabrication?
A good manager prevents information starvation. She takes the time to pass on each piece of information she cannot deem ‘discardable’ in a few seconds, and she does so with a bit of personal context. This helps until the team is working so closely together that they have a common mind.
Employ aggressive silence – in this silence, you are forced to listen, and your team will tell you what it needs.
In most businesses, everyone’s basic agenda is visible after they’ve talked for about 30 seconds.
Read “The 48 laws of power” by Robert Greene.
- Conveying things subtly, with humility, finishing with elegance.
- Risky, but this is what leads to “skunk-works” projects outside of direct orders.
“You can stop coding, but stay flexible and don’t stop developing”
2×2 matrix of skill v/s will
- Skill and will fade together, if you focus on one, you will improve the other.
- High skill, high will – these are the top performers on your team
- High skill, low will – can you move them to something interesting? Else be prepared for their skills to rot away gradually.
- High will, low skill – these need management, training and mentorship. Good news is that they really want it, and will soon be after your job if you give it to them.
- Low skill, low will – the manager screwed up here. They no longer have the skills necessary to do their job and they don’t want to do it either.
“I tell everyone I hire the same thing – I hired you because you’ve got enough skill and enough will to have my job one day .. whether you want it or not. There is nothing like having bright people nipping at your heels to keep you running.”
- Don’t promise what you can’t do. Your guilt will cause you to commit to things you can’t finish in the time you leave. Don’t give in to it.
- Respect your network. Make sure everyone you think needs to do of your transition, has been told so, personally. Don’t need to go too far (like a tearful hug in the hallway) but make a small gesture that shows you care.
- Update your rolodex. When you start your own company someday, the list of people you’ve collected over all the past jobs will help.
- Don’t take cheap shots. It serves no good, and will only serve to negate all the good work that you did.
- Do right by those who work for and with you. If you are a manager, make sure to write their latest performance reviews before you go, and finish any pending responsibilities.
- Don’t volunteer to do work after you leave.
- Don’t give too much notice.
As a top manager, you wear a shiny velvety black hat. The front of it says “I’m the boss”, the back of it says “…for now.”. It’s not at the back for lack of space – its at the back to allow you to assert yourself where needed. But the back must be respected, your team is collectively smarter than you, period.
“Mechanics” v/s “Organics”
Mechanics are people who work like a checklist in their ways, and in their means of dealing with others. Organics are the opposite, they give away vibes that they are blowing away wind about irrelevant things, but in reality, they are gathering, disseminating useful information in between the conversations, and getting work done in ways the mechanics don’t understand. If you are a mechanic, you need to have worked for an organic manager to understand this. Organics will find mechanic bosses to be micro-managers. Organics have an advantage, since they, unlike the mechanics, are not predictable and are difficult to game.
- A purely mechanical organization lacks inspiration.
- A purely organic organization is total chaos.
- Mechanic v/s organic – the author successfully dealt with a mechanic boss by learning how he ticked and working to that.
Incrementalists v/s Completionists
- Incrementalist: “they look so busy, but what is the goal of the busy”. Incrementalists like motion, motion, motion.
- Completionists often get mistaken for curmudgeons, they don’t have the communication skills and people skills to convince the company of the truth!
- For incrementalists, do this –
- Make them see the plan from soup to dessert – they normally can’t see past the next meeting
- Get them on board with the big picture. This gives them the sense of foundation that they don’t have.
- Incrementalists have no concept of done – WARNING.
- “Architects are the only recognized completionists.”
On building a 1.0
- Its stressful.
- How you build that 1.0 – think of it as a pyramid, from top to bottom – pitch -> people -> process -> product – will define the ensuing culture of the company.
“I’ve dealt with the “showstopper-bug two days before ship” scenario in every product I’ve ever built. It might look like I am thinking…”
- Take time to think: You won’t be a successful manager without well-developed react instincts.
- A quiver full of arrows gives you all sorts of arrows to shoot at problems.
- Your quiver will slowly empty unless you take time to think.
- Thinking is hard to pull off at work, or otherwise, into a manager’s schedule –
- Hard to put into a schedule, no beginning or end.
- Doing more thinking pays off, but how do you do that in a week with 3 deadlines and 5 meetings?
- More people in the better => better thinking due to better stewing of ideas. However, the process slows down at least linearly with each new person.
- ‘Thinking’ during ‘off-site’ doesn’t work either. Plan for thinking sessions twice a week in the natural office setting. Once a week doesn’t work as people forget what happened over the weekend and rehash the same things next week.
- How do you know if thinking/brain-storming meetings work?
- Are decisions being made? Good.
- Are decisions being revisited? Also good, team can go back and refine.
- Are decisions being constantly revisited? Bad.
- Are the players changing? No way you got all stakeholders in the room at the very beginning, so you should be adding folks as you go.
- Are basic truths about your design showing up?
- Is it therapy or work? Vent-outs should be 1-2 meetings post a release, not more.
- Are ‘holy shit’ moments occurring?
- Is the to-do list growing (early phase) or shrinking (later phases)?
The “Soak” / Good Decision-making as a manager
- The soak is the opposite of immediate emotion-led response. It is what you should do when faced with a sudden, insurmountable problem or a flame-throw from a colleague.
- “Soaking” is what will provide the inspiration to transform your response from a predictable one to thoughtful.
- Two ways to ‘soak’:
- Active soaking: Ask dumb questions, think through it, pitch a stranger on your ideas, write them down, rewrite and refine.
- Passive soaking: Let your mind wander while you work on other activities.
The point of emphasizing ‘soaking’ is that any big decision requires time and consideration.
- Events that have butterfly-effects, that come from overlooked decisions or scenarios during design and development, or misguided assumptions. A large part of a manager’s job is to avoid these events by having the intuition about them earlier.
- The only way you’ll learn to identify such events is by going through some horrible experiences arising out of these first.
- One way to avoid butterfly-effect events is to succeed at managing ‘artifiacts’ (e.g design docs, specs, etc). Three things matter about these artifacts –
- Availability – wiki page, bug tracker, something that the whole team accesses.
- Agreement – make sure everyone has buy-in.
- “You’ll know what failure sounds like, but success is silent.” Management is the care and feeding of the invisible. Nobody notices when that release goes almost smoothly because all bloopers, show-stoppers were detected on time, and proactively planned for and mitigated. This is very true for most Bay Area engineering managers.
- Most good organizations do a good job of capturing context in their version control systems.
- What problem is being solved with a given change, what is the history of the problem-solving before that change, what evidence points to this change being good – these are all useful pieces of context.
- Try to adapt the same mindset in everything you do, as you go about your day. Writing a chapter for a book or a design doc? Capture context. Coding up a prototype? Capture context.
- Future-you and others will thank current-you for doing this.
- The most important consumers of these are managers and execs. And it helps for you to give them good status reports – sometime in the future, you may have to go ask for a 2-month schedule slip. All the context provided thus far will help then.
- Think of status reports as your weekly litmus tests – highlights, lowlights and any open issues.
- How well are you handling your weekly PR?
- Technology angle on killing status reports. We need our tools to capture the context of what we’re doing e.g. can a summary of git logs become a status report?
On conquering difficult tasks
- “Progress + Momentum = Confidence”. Just start, don’t think about how behind you are or the mountain you have left ahead of you.
- “An individual tends to be very bad at work estimates until they’ve begun the work.”
- Mix it up. Always helps to have a task-tracker spreadsheet, so you can pick up the next battle on your list that doesn’t seem like a battle at the time.
On Manager Hierarchy
3 kinds of manager run a (relatively large) firm:
- Inwards: They stay focused on their team and shipping product, always devoting themselves “inwards” to their team and immediate issues.
- Holistics: Their job is to figure out what is happening cross-functionally, and spread that information where it needs to go. They can afford to do this because they have good inwards working for them who are focusing on shipping.
- Outwards: Their job is to make sure the organization stays healthy and good for the outside world. They don’t run the organization – they have good holistics hired to do that.
Start by caring about the quality of one product (inwards), end up caring about the health of an entire company (holistics). Watching this growth is essential to your personal growth.
Dealing with free electrons
A ‘free electron’ is the rare, brilliant, restless engineer who can rewrite layers of your stack in a week. You can build an entire business around a free electron. If you get two junior free electrons in 20 years, you are doing something right.
- Keep them engaged – they must be defining the bleeding edge, else they don’t stay happy.
- Don’t let them be misdirected. A free electron can chose to rewrite a layer of your stack over a weekend, but is your QA team prepared to deal with a rewrite?
- They may not explain ‘why’ to you or give you context. It can be frustrating but you’ll have to get over it. If you tell them to do something and they ignore it for two weeks, it could be that they knew all along that the task was not worth doing, but decided to let you figure that yourself over two weeks, rather than take the trouble to explain.
Classic “rands” quotes that don’t fit any theme
- “Job security comes from actively adapting to the world around you.”
- “The perception of unlimited money makes people stunningly stupid.” (said in the context of Netscape, but relevant more generally)
- “The only source of measurable truth regarding the product is the bug database.”
- Use “managementese” judiciously – leave it away when talking to your own team, talk like a friend instead. Across functional areas though, managementese (like “I’d like us to double-click on this moment”) helps get information across faster.
- It is a good idea for the manager of a team to own a small feature or test-case. That ensures they are regularly able to build the codebase, stay in touch with everything.