If you read my previous post about my 9 years at Google, I am sorry if I left you with a feeling of doom and gloom.  The truth is, my time at Google was also full of learning, growing, and developing.  Summarizing the experience, the rather cliche “9 lessons in 9 years” came up as an obvious topic, so here we are.  My hope is that I will provide a different and deeper perspective than others offer.  My original aspiration was to fit all 9 lessons into a single post, but as I started writing the piece, it became obvious that it would wind up being way too long.  I decided to break it up into nine smaller, digestible posts. This way, I won't need to limit the amount of detail I’d share for each lesson.  

Let's start with Design Documents. Design Documents? Yes, Design Documents!  I know, I know… “how exciting”

To keep you engaged, I’ve put a link to my Design Document template further down.

The lingua franca at Google is the “Design Document”.  Maybe during your first week you won’t hear about it, but by your second, your inbox will be full of them.  Learning how to write a “Google” Design Document is an art and craft in its own right.  But what is it exactly?

In order to fully appreciate and understand what Design Documents are, let’s go back to the DNA encoded in Google.  Google was founded by academics.  Most of the early staff members were PhDs or PhD dropouts from Stanford and other “lesser” institutions.  Larry Page, Sergey Brin, and Urs Holzle (Google’s first VP of Engineering) came from academia.  Rumor has it that Larry and Sergey wouldn’t initially interview Eric Schmidt until they found out that he too had a PhD in Computer Science and many academic accomplishments, in addition to his business track record.  No matter, they put him through the technical interview process nonetheless.  

You have to understand that the way Google approaches decision making is through a very academic style of thinking.  Within academic circles, the most valuable currency is that of “the paper”.  

How many papers have you published? 

How many times have you been cited?  

Have you presented your paper yet?  

What conference are you submitting to?  

Who reviewed your paper?  

When that is the world you are coming from and those are your core values, invariably you are going to try and rebuild it as best you can at the company you create. These are the genetics that led to the Design Document. 

What is a design document?

The simple explanation of what a Design Document is can be summarized like so:

A Design Document is a self contained, written representation of a problem statement, proposed solution, and an execution path to make it a reality.  It is clear, concise, and builds on the work of others.  It challenges the status quo with a new and novel perspective that isn’t immediately obvious, but once presented and read by the audience, makes the new world the only clear path forward.  To quote Jeff Bezos, a good design document should feel “... like angels singing from on high”.  Most of the same questions that apply to academic papers also apply to Google Design Documents, to this day.

“How many Design Documents did you author last quarter?”

“How many people referred to your design document?”

“Have you presented your design document at a tech talk?”

“Who reviewed your design document?”

Being able to author a design document is a quintessential step to being successful at Google.  But what IS a design document, why is it so important, and how does one go about creating one?  

Why is it important?

The reason design documents are so important is because they force you, the author/engineer/designer, to think long and hard about what it is that you want to do. More precisely: Why is it that you want to do it, the specific way you are proposing, and why this method versus other approaches to the problem at hand.  It is an incredible forcing function to get you to think critically about your work.  In a way, doing the writing slows you down and forces you to explain yourself to your peers and stakeholders.  A design Document is the software equivalent of an architectural diagram and a cost breakdown.  

Imagine a contractor came to your house to do a kitchen remodel, and on a first walkthrough just started whacking at a wall with no plan or explanation. That is what writing code without first doing a thoughtful design is like.  On the other hand, the same contractor, drawing up a plan, with a clear sequence of steps, cost breakdowns, alternatives, and approaches and then showing it to you in a visual form is much easier to get behind.  You can provide feedback, “no, we want the vent hood to be like this, and the dishwasher to be over there”, before the changes are too far along and you are way too far into the project to make changes.  I have had personal experience with this. Three kitchen remodels using this strategy worked well, one basement remodel without this strategy did not. 

It is much easier to review an idea as a design than it is to review it as a sequence of code changes.  You will never have a piece of code that entirely encompasses the breadth of a meaningful design.  In practice, a design document translates to dozens, if not hundreds of incremental code changes over a period of weeks, months, quarters, and sometimes even years.  You can’t tell someone “listen, I’m going to put these 250 different code changes, and it’ll just work”.  

Design Documents, especially with collaborative tools like Google Docs allows for iteration and engagement that was very hard to achieve 20 years ago.  The ability to create the Document and share it with collaborators and stakeholders for feedback and iteration is truly priceless.  In the post-Covid era, where so much of the workforce is remote, this takes on even higher value and importance.  In effect, you are bringing MORE voices, perspectives, and opinions into the communal square.  The more views, the more complete your understanding of a subject is, the more complete your understanding is, the more certainty you have that what you are proposing to do is indeed the right thing.  

How do you create one?

“Fine, I get it, I’ll do a Design Document, it feels very English 1A to me, but I’ll do it.  Just one question?  Where do I begin?”

The answer is simple, begin wherever you have the most clarity.  If it's a specific API that you are certain of, describe that. If it is a specific, well articulated problem statement, start there.  If it is a data model that is completely obvious to you, then that’s your starting point.  A critical observation you just made over lunch?  Go for it.  No matter where you want to go, start from what you know best or have the most clarity in, then build from there.  

There are a number of key sections that your document should have, and a link to my template is here, you can make a copy of it for yourself, no credit necessary (although… duplicative language IS discouraged, my alma mater heritage aside).  The below will be “duplicated” into the document linked here.    

Objective

This is the section that describes as clearly as possible what you are trying to accomplish with this document.  It could be a proposal for a new system, product feature, a complex analysis, or a change in plan.  Whatever your “thesis statement” is, goes in this section. You can go right ahead and say what you want to do.  The shorter, the clearer: the better.  

Overview

Include whatever context the reader might not have or that you’d like the reader to have.  Prior art, existing state, published research, pick.  This is your opportunity to bias the reader but also demonstrate that you’ve done your homework.  It really wouldn’t look great if you proposed building a bridge across the SF Bay peninsula when one already exists in the precise location where you wanted to build your bridge.  This is also your opportunity to establish credibility with the audience to demonstrate that you know what your talking about, and here is the proof with hard evidence and level setting.  

Design (or some clever name here)

Now you get to switch gears and go into the meat and potatoes of what you’d like to do.  Describe what the new world order is going to look like.  What assumptions you made, data collected, and how you arrived at your conclusion.  Although in THIS writing it is the shortest paragraph, in practice, this is where you’ll spend most of your time. 

Alternatives Considered (Optional)

What other options existed or that you evaluated before settling on your final design.  Why did you disregard them?  What was problematic about these approaches or why is your approach somehow uniquely better?  Although this section is optional, including it along with multiple alternatives, demonstrates that you’ve really thought about the problem.  Once the document is sent for review, a few things can happen. 

1. This section grows in scope without any particular alternative truly challenging the original proposal

2. The feedback winds up being such that an alternative emerges as the front runner because of a missed point.  Remember my reference regarding getting feedback?  I can’t tell you how often I’ve seen a reviewer jump into the “Alternatives” section and propose an idea that is better than the original design or any of the alternatives that were written down, to ultimately become THE solution.  

This is one element that makes the design document so valuable. Being open to alternatives turns the document into a living discussion forum that enhances the original premise and value of the document.  The more participants, the stronger the claim, the more complete the world view.  It is peer-reviewed publishing in real time. 

Implementation Plan

Here you get to tell everyone HOW you are going to make this design document a reality.  What is the sequence of steps you are going to take, what data you will gather, what will be built in which order and how.  How will you validate your solution and what are the key milestones?  Are we making progress?  Is the project working?  Do we have validation that the lights really do turn on?  The more complex the project, the more sequencing and dependencies matter.  Listing them out and calling out the various dangers and pitfalls is critical to ensuring that you’ll have a successful execution.  In this section is where feedback is also paramount.  You are invariably writing from incomplete information, and getting other colleagues' perspectives can help avert a disaster. 

The reason doing this type of writing and exposing yourself to critique is hard is because there is always an ego that gets in the way.  You want to feel like you have the complete picture, your approach is right, and that your insight is amazing.  The reality is that going through this type of analysis will invariably take your personal ego a few notches down.  No one is infallible or untouchable in a design document. And this type of constant polishing makes all of us better. 

The truth of the matter is you won’t be good at writing design documents right out of the gate.  It takes practice, repetition, and openness to feedback and growth.  But once you enter the Design Document world, you’ll never be able to go back to the “let’s just put it together and see what happens” universe again.  

I first learned of the Berkshire Hathaway name in sixth grade when Mr. Hall introduced us to the stock market and investing.  Once a week we’d spend a class period peering over a page from the San Jose Mercury News that had the prior days’ stock prices printed.  That is how you tracked investments in those days.  

“You want to see an expensive stock?” Mr. Hall once asked

“Yeah, sure!” 

“Take a look at WFC - Wells Fargo Bank, it's in the $200s”

“Wow!”

“Want to see another one?” 

“Yeah, sure!”

“BRK - Berkshire Hathaway - $33,000!”

An audible silence and gasp

“That’s more than my dad’s car cost,” someone said, followed by silence.  Even as sixth graders, we could appreciate the enormity of that price.  

I filed it away, and mostly ignored that fact, why bother with something I will never be able to own.  

“Bill Gates, the founder of Microsoft, is now the wealthiest man alive, having replaced Warren Buffet on the Fortune 100 list!” the news headline announced with excitement.   

“Whose Warren Buffett?” I asked my dad, “He works for this company called Berkshire Hathaway, you should see their stock price, it's $45,000 a share, can you believe it?”

Berkshire Hathaway again!

Some more years passed, and my interest in investing grew.  I didn’t understand very much about it, mostly haggling with my high school friends who also didn’t know very much, but liked to pretend to have a scoop on the next hot thing.  I built too many Yahoo Finance portfolios and spent my lunch breaks checking in on how my mythical investments did.  

The more I spent time learning about investing, the more I heard the Warren Buffet name.  You couldn’t escape it.  

What you didn’t hear as much of was the name of Charlie Munger, but one day, “Today, on CNBC, we’ll be interviewing Charlie Munger from Berkshire Hathaway, coming up after the break!”.

I don’t remember the context, nor the specific interview, but I do remember clearly that Charlie left an impression on me much more than Warren ever did.  He was direct, no nonsense, and had no qualms making a tongue in cheek remark, “if people weren’t so often wrong we wouldn’t be so rich.”  I had found my mentor!

“I don’t think there are good arguments against my position, the people who oppose my position are idiots.”  I had been given permission to speak the way I wanted to speak.  If Charlie can say it, so can I! 

Charlie’s life story also didn’t fit the normal narrative I’d been fed up to that point in my life.  The constant message one sees and reads about is of the end state, the final product, the success, no one wants to talk about what happened before that.  Charlie’s early life story isn’t a happy one, it is filled with unbearable tragedy.  He lost his son, was divorced, almost bankrupt, and had to rebuild his entire life from scratch well past the time when others are settling into mid-life comfort and convenience.  Out of those rubbles emerged a person who had all the reason to be resentful, but he wasn’t.  In a 2019 CNBC interview Charlie remarked

I spent January of 2022 reading “The Essays of Warren Buffett”.  It's a typo.  It should really be titled “The Essays of Warren Buffett on how Charlie was right.”  Warren writes as much about learning from Charlie as he does about his own thinking on investing.  What you get out of reading those annual letters is the sense of camaraderie, friendship, and mutual respect that the two had for each other.  Although these are indeed the letters of Warren Buffett, in reality, they are also the letters of Charlie Munger.  

When I started writing this piece I wanted to lead into something else, I wanted to talk about how Charlie is right about hating Bitcoin, and my own deep analysis of it.  I couldn’t find a path to make a segway.  Charlie is right, but the why is for another time because talking about Bitcoin is trite in the face of this enormous loss.  What we lost is clarity of vision, conviction, and honest integrity in a world so often filled with charlatines.    

I wish I had met Charlie in person.  I have a gut feeling I would have really liked him and it would have been a life changing event.  

May we be inspired to have the moral clarity, intellectual rigor, and deep conviction to stand for what we believe in the face of the strongest of headwinds as our collective tribute to Charlie.  

My wife has a way of cajoling me into doing things I really don’t like.  Once done though, I’ve changed for the better.  Opening a Patrick Lencioni book was one of those experiences. 

Let me set the stage. About 10 years ago, I was struggling with an ever increasing pile of work related challenges that had started to overflow and eventually flood our homelife.  My wife’s approach was to manifest, mushroom, place, arrange new books on my bedside table.  First, one book appeared on my nightstand, to which I responded something like, “I don’t need no stinking business self help book”.  That is the polite version of how I expressed myself.  Then another book appeared.  A few days later, there was a third.  Those books just sat there, night after night, week after week, acting as great supports for coffee mugs, bottles of water, and my phone.  If memory serves me right, the books were The Five Dysfunctions of a Team, The Four Obsessions of an Extraordinary Executive, and The Five Temptations of a CEO, what’s in common?  The author, Patrick Lencioni.  

Thankfully, despite my cynicism, I never seemed able to move them off of the bedside table.  One sleepless night, with no other choice, I finally picked one up. 

Since I’m writing this essay, you likely know what happened next.  I read the books, cover to cover.  I’d like to say that I gave them out to others, the truth is that I felt like I gained a secret super power, and handing them out would cheapen my newly found bag of management tricks.  

I went from struggling to understand my own professional situation to finally having terms to describe what it was that I was dealing with.  

Trust.  Communication.  Backdoor dealing.  Lack of commitment and accountability.  

My professional challenges didn’t magically go away. In fact, they kept getting worse, but at least I had the vocabulary for my experiences.  It is an incredible feeling when you go from not being able to diagnose a problem to having a diagnosis.  The mere ability to give a name to the experience can take half the weight off your shoulders.  Not that it solves any problems, they are still there, but knowing WHAT problems need to be solved as well as having the right toolbox of strategies, is in itself empowering. 

Fast forward to a few months ago, when I discovered another Patrick Lencioni book floating around.  My wife bought Lencioni’s latest book The 6 Types of Working Genius and promptly finished it, cover to cover.  With some delay, I eventually got to it as well and this one was different from all the other books.  

Patrick’s usual style is to focus on the overall structure of the team and what happens within it that leads to dysfunction.  Trust needs to be built, and when it is absent, decision making gets stuck.  Accountability puts the right focus on what needs to be delivered and who will own the outcome, but when you have no accountability, you can’t ever seem to ship anything.  Fear of conflict leads to misunderstandings permeating around, “did we really agree to that deal?”, “I can’t tell Jim the recruiting pipeline is awful”, “Suzane won’t like hearing the customer feedback on the widgets.”  It isn’t possible to drive results if you can’t have conflict in the organization and deal with the disagreement openly, quickly, and constructively.  All of Patrick Lencioni’s previous writings have focused on the team and its dynamics.  

His latest book is different.  It focuses on the individual as the foundational building block of a holistic team dynamic.  What Patrick Lencioni zeros in on is what makes us all uniquely human, our unique and distinct set of problem solving approaches and how we engage with the world.  We all have our strengths and also weaknesses, we have that friend that can plan the perfect party but can’t come up with a theme while someone else has the grand vision, but can’t seem to remember to bring the napkins.  You need both individuals to have a complete team, and without a clear understanding of what strengths everyone brings to the table, there is no team.  

I don’t want to give away Lencioni’s analysis and presentation, you really should go buy the book, but I will give a preview of the six geniuses:

• Wonder - Asking the big questions of why the world is the way that it is

• Invention - How the world could be different

• Discernment - Whether the new world order even makes sense

• Galvanizing - Selling everyone on the new world order

• Enablement - Get the new world order roadblocks out of the way

• Tenacity - Crossing the t’s and dotting the i’ss of making the new world order happen

There is much more to the story of how the pieces fit together, but if I told you everything, you wouldn’t want to buy the book.  

There is one key takeaway that should be noted.  We are all capable of performing each and every one of the types of geniuses above.  Some give us strength, others are acceptable as occasional place holders, and yet others drain us of energy and make us not want to get out of bed in the morning.  Knowing what your strengths are is key to being happy in the morning, because if you spend all your time on the energy sucks, then don’t be surprised that you are in a state of unhappiness.  As for me… I’ll give you a pause to figure out my two strengths and two weaknesses.  Drop them in the comment if you guessed them.  

If you’d just like the answer, here it is:

Geniuses: Invention and Discernment

Energy Drainage: Tenacity and Galvanizing

Now, go figure out your own geniuses, you have them, play to your strengths, not your weaknesses, and be happier every morning.  

In my previous writeup, I discussed compensation. I suggested that the metric that we use to set it should be based on value, not cost.  Now, for the astute reader, or those that know me personally, the question that you should ask is “Michael, what got you onto this train of thought?”  Great question! Let’s dive in. 

Over the last few months, my LinkedIn inbox has been filled with recruiter emails.  My policy is that I a) almost always respond to every recruiter, except the very spammy ones, and b) take a look at the job description to get a sense of what the market is looking for.  The one overarching theme I’ve observed is region based pay structures.  But in a knowledge based economy, does that still make sense?  

As the post-covid restrictions began to lift, Google had to contend with the reality that some of its staff had moved away from their home office locations.  The big question was: Do you compel them to return or do you enable them to work remotely?  Remote staff seem to be performing quite well, without ever needing to set foot in the building.  Additionally, what do you then compensate them for, since up to that point, if you worked in Pittsburgh your pay was different from someone in Seattle in the same role and at the same performance level.  Should that policy stay or should it evolve?   

As opposed to figuring out what a new compensation model should look like, Google reverted to its pre-covid policy of region based compensation scales.  What this meant was that if one moved from New York to Tulsa and liked Tulsa, they’d now be paid 10-25% less for doing the same work, merely because they were sitting in Tulsa and not in New York.  As you can imagine, this received a fair amount of internal pushback.  No matter, the change was implemented and many individuals begrudgingly were forced to move back to their home locations, because no one wants to take a pay cut on Monday for the exact same work they were doing on Friday.  

Due to how the policy was implemented, anyone could choose to mark themselves as being permanently remote, even if they were remote from a city within which a high compensation Google office existed.  If you were to argue that there is inherent value in being in-office, and therefore compensation should be adjusted for that, you’d have legs to stand on in paying more for individuals physically being in the office.  Whether that is sound as a policy is for another writeup, here I’d like to focus on the reality at hand.  In this case, both employees, the Tulsa and New York based one could be remote, both are doing the same work, both are on the same Google Meet (or Zoom or Teams) calls and yet one is being paid 25% less than the other.  

The result? Two employees who participate in equal ways, contribute in equal measure, have equal performance ratings, but one is being paid materially less merely based on where they take their meeting from.  

To draw a parallel, this is no different than the gender pay gap whereby a female employee sitting next to her male counterpart in a meeting is being routinely paid less merely because she is female.  That’s a moral and ethical problem that at this point we all agree should not exist.  Yet, here it is, right in front of us again, paying two people differently not based on their role, contribution, or impact to the organization, but based on where they sit.  

If we were dealing with a service based economy, where the locality of the employee mattered, the difference might be understandable.  A teacher in New York, providing services to New York students will likely be paid differently than a teacher living in Tulsa, providing services within their community in Tulsa.  While we should definitely be having an honest conversation about the value of teachers and equalizing pay nationally, that is a different can of worms. I will leave that topic to my wife who is an educator and much more qualified to speak on the subject than I.  In a knowledge based economy, where your contributions are not bound by your physical location, paying differently based on where you wake up in the morning is wrong and misguided.  

We don’t know why someone found themselves in Tulsa, it could be family, it could be spousal career, health, or so many other reasons.  Frankly, it isn’t our business.  For industries to actively penalize individuals because of where they choose to take their meetings from needs to stop, just like paying someone differently based on their gender.  If you think I’m making this up, here is a job posting (I will leave the company nameless but I’m sure some Googling will surface the organization)

There is a whopping 20% difference between Zone A and Zone C.  What that means is that someone who is more junior in Zone A could be earning MORE than their potential manager in Zone C.  Imagine yourself as a tenured manager living in Zone C providing great value to your organization and delivering exceptional impact being paid LESS than your report who has less experience, less tenure, and by all measures less Value to the organization than yourself.  If that wouldn’t demoralize you and make you feel not valued and taken advantage of, I’m not entirely sure you have a good grasp of human psychology nor a good moral compass.  

Thankfully this isn’t the case everywhere, some organizations do have their ducks in a row, as an example of this post from Modular:

“The estimated base salary range for this role to be performed in the US, regardless of the state, is $207,000.00 - $286,000.00 USD.” (emphasis mine).

That is just one example of something that Modular is doing right, besides the absurdly awesome tech behind Mojo, but that too is for a different writeup.  

We need to pay people based on their value, what they bring to the table, and what impact they deliver to the organization.  Paying based on someone’s seat location is opportunistic cost minimization at the expense of people’s life circumstances.  It's wrong, it's misguided, it's immoral, and it needs to change. 

The line, ABC - Always Be Closing is forever inscribed in your mind once you’ve watched that scene.  It is a powerful scene, it really goes to move you.  Any you have to wonder, why must he lecture about closing?  Why is it necessary to go to such lengths to bring the point home that you should “Always Be Closing!”, “Always… Be Closing.”  The reason is because it is not natural to close a sale, not natural to close a deal, it finishes the transaction, there is no more, that’s it.  You either got the deal you wanted, or you didn’t, or worse, you got no deal at all.  It forces you to commit and forces you to force someone else to commit as well.  The whole experience is not natural.  That is why you need a motivational speech, if you can call it that, and threat of job termination to get people to do it.  

I don’t subscribe to this ABC rule, I actually have my own.  

“Always Be Constructive”

If you’ve worked for me for more than a week, you likely heard me say this at least once.  I don’t take the Alec Baldwin approach, I try to be constructive and encouraging, but if an issues comes up you’ll invariably hear “Always Be Constructive”.  To be honest with you, in the back of my mind I do have that Alec Baldwin scene playing, and I do imagine myself being a bit like Alec as I pronounce “Always… Be Constructive” statement.  

So why do I feel it necessary to emphasize this so much?  The reality is likely the same that Alec Baldwin’s character felt in Glengarry Glen Ross, it is not natural.  This is something that requires unnatural action, being constructive, but in a very different way than being a closer. 

Let me explain.

When your a closer, and you win, you take the whole responsibility.  I did it!  I made this happen!  I closed the deal!  The emphasis is fully and completely on the “I”, the self, and that scene makes it so tangible.  Notice that Alec doesn’t care about his salespeople, he only cares about himself, his car, his watch, his salary, it is all about the self, the I.  The ultimate self absorption at the absolute cost of everyone else.  

To be a constructive individual mandates doing something completely opposite to that.  In every situation you are being asked to take someone else’s idea, someone else’s initiative, someone else’s mistake and build in a positive way on it.  In a way it is the total effacement of self, it is the complete nullification of the I and subservience to a higher ideal, that of being a united builder.  And that flies in the face of natural behavior.  

You get that email, someone proposed an idea, a solution, or is surfacing an issue.  What is your first reaction?  Its likely some form of a no; its a bad idea, that will never work, who caused this problem!  That is the natural instinct, and yet, if you follow it, the outcome won’t be good.  Being a negative individual, a contrarian to others, is not going to lead to positive results.  It may lead to you getting your way, but is that the objective?  Is the objective for one person to get their way at the cost of everyone around them?  Or is the objective for the team to succeed, for the team to resolve an issue, for the team to build the next great product?  That is arguably what you’d like to accomplish because as cliche as it sounds, Together Everyone Achieves More.  The whole of a team is always greater than the sum of its parts and if you focus on that, it is how you’ll benefit as well as others.  Being constructive forces you to say, that’s a great idea and this is how we can make it even better, that is a wonderful solution you’ve proposed, and this is how we can execute on it even faster and more reliably, it is a shame we’ve encountered this issue, but this is how we can solve it and make sure it doesn’t happen again.  

It sounds wonderful, yet so hard to do, the reason?  You don’t get the credit, you are perpetually in a supporting role, and that may make you feel like you are not significant.  What winners will tell you, is that they know that they could have never done it themselves, there is always a cast of characters there to help out.  Winning teams also know, that everyone there is willing to sacrifice the self for the sake of a team win, as opposed to support the I in exchange for a team loss.  Be a part of a winning team, Always Be Constructive.  

Its Wednesday afternoon, around 2PM, and I’m interviewer number 5.  The poor candidate on the other side of the table from me looks pretty tired.  I offer the cursory bathroom break and a drink of water.  The candidate takes me on the offer and we proceed with the customary chatter as we walk back and forth to the bathroom.

“How has your day been so far?”

“Good” 

“How was lunch?” 

“Very good, nice food”

“Hope you don’t live too far”

“No, not too far, just on the other side of the river”.  

Its a very polite role play that you get really good at after doing a large number of interviews.  In some sense it is an awkward form of foreplay until you get back to the room, close the door, and really dive in.  I run through the routine 

“We’re going to be focusing on a technical problem today, if something isn’t clear, don’t hesitate and ask, I’m here to help.  I’ll make sure to leave some time at the end for you to ask any questions you might have about the role, the company, and anything else that’s on your mind.  Lets start.”

I proceed to write the technical problem on the board.  Python, Java, C++, really doesn’t matter, I’ve developed my technical problems over many years to work in any language and have it focus on algorithms and data structures that work in all of them.  If you know the language that you are conducting the interview in, and you’ve got your fundamental down, my problem shouldn’t be too difficult, if you don’t, you won’t get very far.  To be honest, I know that it will take a very good candidate about 30 minutes to work through the problem, a mediocre one, 35, and a bad one won’t get there in 45 minutes.  

I have a confession.  I’ve done this enough times that I don’t really need to pay too close attention to what you are doing.  I know the areas where you are going to get stuck, I know the first 2 - 3 questions I’m going to ask because almost everyone hits the same roadblocks.  So I can just ever so gently peek up at the whiteboard from reading my e-mails or scrolling through Facebook.  I’m exaggerating here, I take meticulous notes, but on occasion I will do one of those activities without much fear that I would have lost focus on your approach to the problem.  

At the 40 minute mark I’m going to try and start wrapping things up if you haven’t gotten to the answer yet and proceed to the informal questions part.  I turn on my charm face, close my laptop, I’m 100% attention on you.  Phone turned over, light smile, I’m trying to close the deal here!  I do this with everyone, whether you’ve done a great job or completely failed the interview.  I already know what my recommendation is, but I need to play it safe.  I need to sell you on the company, how great we are, how awesome it is to work here, how wonderful everything is, how unique we are.  I need you to leave thinking that you are worth a million dollars.  I need to get you to want, no, need to take the offer if it ever comes.  When I’m in sales mode, I rarely get told no.  It happens, but pretty rarely.  

This is where we part ways.  According to my internal interview statistics, the likelihood is less than 10% that I’ll actually see you as an employee, such is life.  Courtship is over.

Now the real hard question begins.

What exactly was this whole song and dance about?  What in the world was I trying to learn about you?  What was I trying to convince you about me?  And here is the real kicker, considering the fact that the previous 4 interviewers roughly went through the same song and dance, what exactly were we all trying to accomplish as a collective?  

I hope I’m not going to divulge some great secret here, but I’m of the opinion that our technical hiring process is absolutely broken.  

The sequence of four or five interviews, all consisting of some variation of solving a technical programming problem that is loosely based on some algorithm outlined in some textbook that you, the candidate, may have last seen in your Junior year of college and will never actually have to deal with in real life or your day-to-day job tell us, the interviewers, nothing about you or your ability to actually get real work done. (breath).  Yet this is precisely what the technical interview process looks like today.  It shouldn’t be a surprise then that it is such a crapshoot to actually hire a good candidate that is productive, contributes to your team, and gets things done.  Our interview process tests for the wrong things.  

To use Stephen Covey’s term for what we should be doing is “Begin with the end in Mind”.  In order to do that we actually have to go back (or forward) and try to understand what is it that a Software Engineer does in their day-to-day job and what makes a good Software Engineer.  Once we can answer that question we’ll be able to better structure the interview process that selects for those traits.  

So, what does a Software Engineer do on a day to day basis?

Sitting in a corner and solving esoteric coding puzzles is certainly not it.  

What it is though is a highly collaborative and iterative process of trying to solve complex business needs and objectives.  The key here is collaborative and iterative.  As a Software Engineer you rarely work alone, you are part of a team with a cross function of players.  You’ll have a manager, software engineering peers, a project or program manager, perhaps a product manager or two, and if you are more on the front-end as opposed to the backend of the stack then a UX designer or engineer as well.  Depending on the size of the company or product that you work on you may also be interacting with the sales, marketing, and support organizations as well.  This is a very broad and varied set of individuals that you need to be engaged with, yet the interview process outlined above tests for a condition that will only happen once a year and involve only one of the individuals above, the Software Engineering peer.  

We need to re-imagine what our Software Engineering interview process looks like to more accurately reflect what the desired end result is, an individual capable of working in this type of an environment.  

I’d like to therefore propose a new model for an interview.

Lets keep the five interviewers panel as a given.  We want an odd number so that you never have a tie when it comes to making a decision.  Its either a yes, or a no, that simple.  Also, lets start with the end state, namely, the desired cross functional skill set that our ideal candidate should posses.  We are going to simulate through the interview process, the experience of building and delivering a feature.  

Your day will start with an interview with a technical Product Manager where they’ll describe the problem you’ll be working on during the course of the day.  You’ll engage in a back-and-forth discussion, consider a number of high level designs, some alternatives, and by the end of the 45 minute session you’ll arrive at what will be your working base template for the day.  

The next interview will be with a technical lead, you’ll have to present the problem back to the interviewer and then do a much deeper design deep dive on the problem.  You are going to be exploring the deep reaches of the technical problem at hand, solving the various edge cases, and trying to come up with a well worked out technical design by the end of this second 45 minute session.  You are now ready to move on to demonstrating the core technical skills, namely can you write code.  In the third interview you’ll engage in pair programming on trying to implement the feature.  You’ll start off writing some code, the interviewer will engage with the problem you are working on, you’ll work through the challenges collaboratively.  By the end of this session you should have something working, either on the whiteboard, or preferably in an IDE or a text editor.  Maybe even building and running.  

Now comes the fun part, lunch!

Its time to join the entire team as a whole, meet your future peers, chat with them, ask them questions, maybe even discuss the problem you are working on with them.  See how you get along with the group.  Can you see yourself being part of this team?  Can they see you being part of their team?  This won’t be a deciding factor at all but you should feel, by the end of lunch, not only physically nourished but also psychologically and emotionally nourished as well.  You are going to be spending a lot of time with this group over the course of your time here, are you comfortable with that?  

The post lunch session will resume with another coding interview.  A different interviewer will now pick up the problem where you left off before lunch and work with you on trying to get the feature as finished and functional as possible.  You should be writing code, lots of it.  The lunch break would have helped you think about the problem some more, realize where your initial approach might not be working or better yet allow you to have a new perspective on the original problem.  Allowing for what is in essence a 1.5 hour long coding session also provides interviewers with the opportunity to tackle a problem in complexity and depth far exceeding what is possible in a typical 45 minute slot.  

At this point, the interview panel should have a fairly good sense of your technical abilities.  The final interviewer is the manager.  Their job is to focus on debriefing; what worked? what didn’t? what would you do differently? what would be your feature launch process? how were your interactions with the team? who was challenging to work with? why? how did you overcome that challenge?  This provides a very real world engagement to see how the candidate will be like in a more realistic professional work environment, without fake scenarios or facades.  

By the end of this day, not only would the candidate have received a great insight into their future team members, the company, and the work dynamic, more importantly you, the hiring manager, would have gathered enough signal to ascertain how well this candidate would do on this team.  You would have tested their cultural fit, technical ability, collaboration skills, and ability to execute on a concrete problem.  What would potentially take you many months to uncover as challenges and deficiencies, would have been surfaced within a span of a few hours.  

Building and creating this type of an interview is no easy feat.  It takes a team effort from beginning to end to plan the day all the way through.  The outcome though, would be a much more engaging interview process with a much more assertive hiring signal. 

1. One of the biggest areas of concern that many Googlers raised was that they were harshly and suddenly cut-off from corporate resources.  The argument for doing this was that "we needed to take these security measures'', but in truth, that isn't the case.  At Google, every compute device and user has an access privilege, from the lowest which is just email, to the highest, which is limited to corporate issued devices with corporate managed security credentials and that require Googlers who access those resources to take trainings and internal self certifications in order to be able to access and handle these resources.  Additionally, all access to user data is highly monitored and supervised, so, it is HIGHLY unlikely that anyone could have tempered with truly sensitive data that easily.  That means that all that needed to happen was to downgrade all of the impacted employees to the lowest tier, providing them with email, calendar, and chat access.  This would have provided the right opportunity and way of saying goodbye, sending a message or two, or closing out any remaining items of business.  Additionally, if Google is THAT concerned about our employees tampering with data that much, well.... maybe we should be examining more closely who we hire and how we train them, that might be the source of the real problem here.
   

2. It was mentioned on the call that they simply couldn't work or notify the 30k managers at Google and that doing so would have delayed the process by weeks (or even months).  Now, I call BS.  We've had plenty of instances when we needed to align the managers behind new policies, like the GRAD rollout (another less than ideally executed initiative), and that rollout was done quickly and efficiently - and yes, with all 30k managers involved.  The other point is that the layoffs were not a surprise.  The 6% number has been circulating internally AND externally now for many, many months.  Something of this scope did not just happen overnight, it was carefully thought through.  So, yes, involving all 30k managers was possible AND would have been the right thing to do.  It should have looked like this:

   1. notify the managers that layoffs are coming

   2. setup training sessions on how the decisions will be made, how the managers will (or will not) participate in the process, and what actions they can take, or be ready to take so that they can appropriately support their teams and the impacted individuals.  Focus should be on how to communicate to the teams and impacted individuals with compassion and care. 

   3. notify the managers 1 - 2 days AHEAD of time of the decision and prepare them.  If you feel that you can’t trust your managers with the information, I point to item (1) above.  We routinely trust managers not to share the outcomes of promotion or compensation details for weeks and sometimes months at a time.  We seem to do a pretty good job of keeping those cards close to the chest.  Also, keeping (1) available above would have helped with the communication process. 
      

3. Employee selection - as it turns out, the decisions were not entirely transparent nor really made any sense.  There were many high performing individuals who had great impact on the organization with long tenure who were let go.  While at the same time, individuals with less than ideal track record who got to stay around.  This smacks of favoritism.  This is the point in time precisely when the organization needs to be focused on retaining and empowering its top performers to the best of its ability.  It should not be a surprise that OpenAI is such a threat, of the ~500 employees at OpenAI listed on LinkedIn, about 100 are xooglers, that is a whopping 20%!  20%! Of a company currently posing one of the greatest challenges to Google came from… Google.  That means that these are all individuals that chose to leave, and who knows how many more of the best and brightest that we have at Google are about to walk out the door and go to… OpenAI.  Had Managers been properly involved in the decision making process in (2) above, then we could have really focused on retaining our top talent and identifying the folks who aren't quite hitting the bar as the potential candidates for the layoffs.  Instead… it was mostly random, mostly without good thought, applying some heuristics here and there, but for the most part… random. 
   
   On this quick note I’d like to add, if you are a recruiter reading this, know one important fact.  These were NOT low performers, the people let go were incredible, talented, capable individuals.  You will be lucky to recruit and retain them for your organizations.
   

4. Finally, the big one, did these layoffs need to take place?  I’m going to say that no, they did not.  Here is why (and I’m not appealing to the cash pile in the bank).  Google in general has ~10% turnover rate of its employees over the course of the year.  That means that at Google with ~150k employees, over the course of the next 12 months for one reason or another ~15k employees will leave.  In order for Google to grow year-on-year, it has to recruit MORE people than leave, so if Google needs to be at 160k employees this time next year, in practice it needs to recruit 25k individuals over the next 12 months.  That leads to the very obvious solution:
   

   1. Close out all open Head Count across the entire company, yes, all of it, every, single, open hire is no longer available.  

   2. Figure out the business units that you are planning on shutting down (or roles).  

   3. Notify the individuals in those roles / teams / projects that their role is being terminated, but they aren’t.  

   4. Have every recruiter that was assigned to (a) above, not focus on finding a fit for people in (c) above to those teams.  This will likely take 30 - 90 days to really work its way out, but it will utilize and realign individuals who already know the Google way towards areas that need to be moved faster.  An internal transfer is always less risky than an external hire.  

   5. If after reshuffling all of the individuals and assigning them to new teams, there is still more individuals looking for roles than there are available teams, then you can do the layoffs, but it will likely be much smaller and much more targeted

   6. Even after this is done, don’t open hiring for the next 9 - 12 months.  So, what about the recruiters?  Easy.  Recruiters are the public facing face of the company that is in touch the most with industry trends and direction.  They are also uniquely positioned to understand the marketplace.  Take each and every recruiter and assign them to an internal team to embed with them.  To what end?  This will get the recruiters to see how the different teams run, get them to get on calls with customers, and talk to potential customers.  This may not fit for all recruiters, but I suspect many of them would enjoy the experience and learn a lot from it.  When the day comes that you do open up hiring again, these recruiters will be much more effective advocates for Google and be able to relate to the new hires because their experience of the teams and the work won’t be anecdotal, it’ll be real and visceral.  Oh, and by the way… remember that issue that Thomas Kurian raised that we needed to have more sales people attracting new business?  Yeah… we could have some of our recruiters pitch in.  At the end of the day, recruiting is a type of sales role - you are sourcing candidates, building a funnel, and trying to sell them on Google.  

Yes, there were alternatives to how this could have been executed, and it would have resulted in Google differentiating itself from the rest of the pack and continuing to show that it is an innovative company truly focused on its people and not like all the rest.  

Last weekend, Sundar Pichai’s compensation package was making the news rounds. Why was it the topic of conversation? $200M. There are only three possible reactions when we think about compensation: too much, too little, or just right. In this post, I’m not going to examine whether Sundar’s compensation was any of those. I am going to examine the more thorny topic of what should be the right amount and more importantly how to think about the process of setting that compensation level.

Out of those three options, there is one we can rule out, which is the “just right” case. In the hundreds of compensation discussions I’ve had over the years, I have never been the recipient of a “wow, this is exactly what I was expecting and I feel this is the absolutely right number!” as the reaction. Neither have I felt “incredible, this is exactly what I think I should be paid!” in the many discussions I’ve had with my managers. That means that the “just right” option can be taken off the table as having any legitimacy. The feeling is either “that’s too much”, like so many felt last weekend about Sundar’s compensation, or “that’s not enough!” which is likely what most of us feel when our updated salary finally arrives

The age old paradigm has been to squeeze as much as we can out of our labor force while paying them as little as possible. On the one hand this is fiscally correct and fiduciarily responsible, on the other, it seeds resentment and dissatisfaction. Employees aren’t eternally grateful to their employers, looking for ways to please their paycheck signers with favors and sweat equity. The bottom line is, an unhappy employee is an unproductive employee. In our financially driven world, we exchange our time working for a particular employer for compensation. The main way for an employer to truly show that they value the contributions of their staff is to pay them, and pay them well.

Compensation should not be determined on anything other than value. If we think of a particular employee, the question shouldn’t be “how little can I pay them?” but rather “what will it cost my organization if this employee walks out tomorrow?” That is the value of that employee, and you should likely be paying them just a little over that number to keep everything working smoothly.

To give a specific example.

Imagine you have a long tenured employee with deep knowledge of your customers, the business process, and the relationships that enable your organization to succeed. They are well liked by their peers and respected by the management chain. In the cost minimization view of the world, you look at what the market pays the Customer Success Manager, give a small multiplier to their tenure, and call it a day. When that employee complains, you say “you know, you are right, but this is the market rate for your role, and in fact, we are paying you above market rate”, but obviously not by much.

Lets pause and imagine this employee, knowing exactly their value add to the company, is upset enough at their compensation, and then chooses to walk out the door. What is the direct and indirect cost to your organization? How much will it cost your company to figure out all the knowledge gaps that the individual had? What about all those emails from loyal customers that won’t be answered, or the fact that they knew the name of that supplier in North Dakota that no one could ever get to ship the widgets on time, except this special employee. If you are a business owner, you are suddenly crunching the numbers and likely breaking out in a sweat as this nightmare scenario unfolds. Then you start to worry even more, what if they went to your competition across the street taking those accounts with them, and Monday morning a LinkedIn congratulations is going to land in your inbox.

There is a big difference between not giving your employee a generous raise that maybe overwhelms them a bit and seeing multiple $xM accounts walk out the door. Suddenly, that raise they asked for looks like a bargain. This is why you should always be looking at the value of what the employee brings and enables as the way of setting compensation, not cost minimization.

I work in the technology sector where our compensation consists of three parts, base pay, bonus, and equity. The bonus is what the company pays you for the work you did last year, equity is forward looking for your “future” potential value to the organization, and base is what they have to pay because that is what everyone else pays in your role.

On paper, this structure seemingly makes sense. In practice, equity isn’t guaranteed, often referred to as “Golden Handcuffs” when in fact, people are happy to leave equity on the table when unhappy. Bonuses are paid out infrequently while being hampered by multipliers and guidelines that don’t truly reward for the impact delivered. Technology is an exception in how it pays. Most of the industries out there don’t even have an equity component and bonuses often mean a tri flavored popcorn tin or a $50 Amazon gift card during the holiday season. Therefore, the only retaining element month after month is the base compensation.

When thinking about the compensation number, don’t bother to look at what others are paying. It’s irrelevant. Your objective is to retain the talent that keeps the wheels of your organization churning. In order to do that, you need to start backwards and ask yourself, how much is this employee worth to my organization? If you are a glass half empty type: how much sleep will I lose if they walk? Then, figure out what you can pay, and do that, market rate be damned. Employee satisfaction isn’t about bargain hunting, it’s about value maximization and business enablement. If that Customer Success Manager is the one holding millions of dollars of revenue together for your organization, I’m certain that you can find a way to pay them an amount commensurate with their impact. If you choose to pay them 5% more than the competition across the street then be prepared for the consequences.

Bringing us back full circle. Is Sundar Overpaid? Underpaid? Right paid? Ultimately it doesn’t matter, because if Sundar walks, the cost to the organization just might be much, much more than his compensation package. Consider this, during Sundar’s tenure he’s grown Google’s value 2x to over $1.3T. Using that metric, the $200M compensation doesn’t seem that much at all, in fact, it almost seems like a bargain. On the other hand, maybe Sundar leaving will enable a new crop of leaders to emerge who will find a way to 2x Google’s value moving forward. Since this question isn’t up for debate now, that means that for the foreseeable future, we all get to sit on the sidelines and gossip about the $200M.

“Abba”

The sound is coming through ever so slightly

“Abba”

Its clearer now, I’m becoming aware of it

“Abba”

The sun isn’t up yet, it is still dark outside, it could also be 1 AM, but my suspicion is that it is pretty close to morning.  

“Abba”

There is a strange creature standing next to me, a smile all over its face, curly hair in all directions, and my eyes are beginning to focus on this being.  Yep, it is still dark outside, I can see the early rays of the sun though, morning is here.  I can also hear crying from downstairs.  I can also hear the slight grunting and squeaking across the room.  I can finally muster a sentence as the list of items ahead of me for the next few hours begins to come into focus.

“Yes dear, how can I help you?”

“I’m hungry, I want breakfast”, says my almost four year old.

“Ok, what would you like for breakfast?”

“Chocolate chips, I want chocolate chips and mango juice”

That sounds like a great breakfast to me, full of all the nutrients for a day of energy, courtesy of being almost 4.  

“That’s not real food dear, would you like some eggies, or oatmeal maybe?”

“Eggies, I’d like some eggies, with chocolate chips, make them fluffy, and chocolate chips on top”

She really won’t give up the chocolate chips.

I’m home with the three younger kids while my wife is away for a few days at a wedding taking our oldest in tow with her.  This arrangement seems to have won me some points with the local moms and lost quite many more with the local dads.  This isn’t the first time though that I’ve taken on the burden that is more often carried by my wife, and likely not the last.  I’d like to say that me volunteering to be Mr. Mom for a few days comes from a place of altruism and pure love for my wife, but I’m afraid that wouldn’t be the whole truth.  In taking on this role I actually have a somewhat different plan, one that my wife very much might not approve of once she reads this.  I do it in order to get a better appreciation of what goes into running the house, because as any Engineer, my gut instinct is that I could do it better.  By seeing the ins and outs of the operation I’m certain with every fiber of my being that I’ll come away with some magical operational optimizations that my wife, the English major, couldn’t possible have come up with.  

Its pretty arrogant, I know.  The emergent reality is quite different from my mythical vision of harmonious and flawless execution.  Most of the time, midway through the morning routine I’m frantically dialing my wife, hoping that she is still awake half a world away, and with an ever so calm a voice I ask

“Hi, quick question, where are the diapers?”

“Where are the wipes?”

“Where are the jackets?”

“She doesn’t want to wear leggings and she hates all her shoes, what do I do?”

“She says she wants just bread for lunch, nothing on it, without the crust, cut in half, is that right?”

“There’s a Dr. Appointment?  Today?  Wait, there are two Dr. Appointments today?  For two kids?  Can’t be late to the second one.”

“Just one more thing, where are the sandwich bags?”

As you can guess, usually midway through the first day while I’m holding the baby as she has peed through yet another set of clothes and won’t go down for a nap with my backlog of emails piling up, I’m regretting this act of self sacrifice.  It is Thursday.  Is it really that many more days until Tuesday afternoon?  Did I really agree to this?  

A few days ago I was interviewing a candidate.  My interviews are fairly straight forward, I give a 30 - 60 second introduction to myself, who I am, what I work on, we then spend the majority of the time discussing some technical problems, and I leave about 5 - 10 minutes at the end for questions.  I mentioned in my brief introduction that I’m an Engineering Manager to which the candidate at the end of the interview decided to ask “I’m surprised an Engineering Manager is interviewing me, I would have expected only Software Engineers to do interviews.”

There was an implicit assumption in the candidate’s question.  The two worlds don’t intersect.  Engineers who do real work are on one side of the fence while their task masters are on the other.  The two shall never meet.  There is some cordial, poorly understood relationship between the two, but they have very little to do with each other.  Unfortunately that is the reality too often of the time and it creates animosity and misunderstanding.  

As a manager I take on myself some engineering load.  I carry a pager like everyone else on the team and participate in on-call rotations.  I’m a manager though, why in the world am I not walking around with a cup of coffee and going to golf games, isn’t that what managers do?  

Some managers, maybe, but not me.  

When I sit in my weekly one-on-ones with my team members, I need to have an appreciation for their challenges.  If I’m locked away in an ivory tower unable to relate to what they have to go through on a day to day basis, I can’t effectively coach, mentor, or provide guidance.  My need to stay involved on the low level details, to have concrete understanding of the workings of what takes place is very much driven by my desire to do good management.  There are many times when I’ve sat in a weekly one-on-one, took notes, smiled politely, and provided no feedback or guidance.  I knew exactly the challenges that my team member was going through, I had walked in their shoes, I felt their pain and struggles, and the best thing I could do in that instant was listen.  

There is a very specific way to describe this, empathy.  In order to have real, honest empathy, you need to have walked in the other person's shoes.  Felt their pain.  Experienced their triumphs and their failures.  As a manager the only way to have real empathy is by doing the work that can so easily be offloaded from you and onto the other people on your team.  Yet it is empathy that is so often lacking from good managers and is so desperately needed.  By having real genuine empathy for your employees and their struggles you can better advise them how to tackle those challenges, you can coach them better and provide them with the necessary tools to grow and develop.  At the same time, your team knows in a very real sense that you are not coming from high-on-up but can relate to them and their experience; they respect you more for it.  In the end of the day, by having real empathy for your team members you become a better leader, you achieve better results, and that as a consequence that makes you a very good manager.  

By me taking on some of my wife’s responsibilities for a few days, it gives me an opportunity to develop empathy at home too.  As much as sometimes I’d like to come home and provide my ever cynical view of how things could be better, having walked a few days in my wife’s shoes, I know that the right answer sometimes, is to just listen.  Knowing full well that as hard as you may try to have the best outcome you can, the day will be what it will be, best efforts were truly exerted, and the often pain of exhaustion and sense of failure as a parent will be there no matter.  I hope that having empathy in this situation makes me a better father and a better husband, but to answer that question, only time will tell.  

The Humanly Newsletter is here to bring the human experience back to our everyday life with a focus on what happens between the hours of 9 and 5. Whether we realize it or not, we spend more of our waking hours immersed in our professional lives, shared with our professional colleagues than we do in our personal lives, shared with our family and friends. As much as everyone is afraid of AI taking away our jobs and disrupting our career trajectory, it is precisely within that domain that a human touch is necessary today more than ever.

I’m going to write about that!

How to be more human - show more empathy, understanding, and care for those who have the most to gain and lose from a meaningful human interaction.

Join me on this journey as we explore the professional human experience.

Subscribe now