How Google manages projects?

Part 2

About working on product quality

Back when I was in development I used to have separated QA departments. Engineers would do the coding part only, and QA departments would do the QA part and then the process would go in circles.

Actually, in Google engineers are responsible for the big part of testing. They check and comment each other’s work.

Unfortunately, big and small companies have the same problems. Ongoing code refactoring, incorrect application architecture.

In this regard, since we spent a lot of time to get technical specification and architecture solutions ready, it’s up to developers to test their product.

Product managers think of what and why should be done for a user, engineers think of architecture. They communicate with other departments to create a better architecture solution. That’s why there are fewer architecture problems like can we increase our current volume.

Or: «We can’t take this information, this data into account since we haven’t thought of that before”.

We have fewer problems with the process since we take more time on the architecture step.

The review process can take a product manager’s time since you cannot deploy anything without this prolonged process.

We also have legal reviews, privacy reviews.

Everything must be translated to different languages. There are many requirements, we have a checklist of those.

The most important thing is that engineers spend a lot of their time purposefully on fixing their code and their colleagues’ code. They even can review code written by engineers from other departments.

Engineers have their areas of expertise, some are good in one thing, others are good in another. That’s why comments are very effective.

When engineers code something, they comment on that code. If they don’t comment, that may cause questions and a need for discussion. The piece of code will be retired back to the engineer who had created it, so they can describe changes they make.

When I was creating my own product (Zimad Games) before Google, engineers often didn’t comment on their code. Which lead to weak architecture solutions, QA struggles, but they worked faster.

So, basically, we sacrifice our time.

About nature of working with a billion user audience

We’re doing our best to ensure quality, we have a quite accurate process to run rolling updates. We haven’t practiced it before, but now I realize we can’t survive at this scale without it.

Google has billions of users, so we can’t just press a button so all the users get updates immediately.

We roll updates out slowly, run experiments. We take 0.5% out of users around the world, they are picked randomly based on various parameters: country, devices, tech requirements etc.

Then we track metrics. First we have metrics called product health: a number of tickets, speed, sustainability — lots of things that are helpful to understand that your product is going okay and has no issues.

We track the metrics very closely.

It’s been 1, 2, 3 days without changes. Sometimes analytics join the process and say “Ok, so these weekly changes do not matter. Do we have baseline changes? No? Ok, we can expand the feature up to 2–3% of all users.

We run ongoing beta testing on a chosen group of users all the time. It takes some time, obviously. First we run alpha testing on specific users. We offer them to update a new feature and they can participate in alpha or beta testing. They can accept or decline. And then we begin the process.

Regarding other updates that does not involve users, i.e. app performance. We inform users that we’re planning the update on some date and if users want to receive the update they can contact Google.

After the beta besting is on, we analyze results, research if it affects other features.

Is everything doing okay?

If there is something, we discuss it.

Are we okay that something collapsed, and increased here?

Was it expected or not?

Okay, we can move on and expand the feature up to 20% of users, to 40% of users.

We track metrics very closely, is everything okay or not?

So we need to discuss this trade off case, get approval from 3 directors that everything is good.

Metrics that changed can be our benefit, and other team’s loss, it’s called counter metrics. You need to control this.

Then we move on to the roll-out stage and expend the feature to all users. Product managers track tickets and a number of them and then decide what to do next. Should we do a roll back or what? Do we fix the tickets? Should we launch additional custom service? Should we communicate inside the team more to discuss things?

It’s an ongoing give and take, back and forth process.

Every feature should be rolled out, you cannot just press a button and the feature is released.

About the QA part

There are many frameworks designed for product testing: we do regress testing, automation testing. We try to make everything automatic.

During the coding part an engineer usually creates test cases and automatic test that cover 70–80% of the code.

An engineer who creates a piece of code understands it better than anyone, so that’s why the engineer is responsible for automated tests. Obviously the tests are being checked too.

There are many types of tests, which should be covered.

I was very surprised that engineers do the big part of the testing process.

However, this might not be suitable for all companies, so don’t tell your engineers to start automation testing right away.

How decisions about new product are being made

“Making decisions” is overstatement.

I used to make a lot of decisions.

One man shouldn’t make decisions solely.

Talking about products — I’ve had many products. I had those that didn’t work correctly, I had those that worked correctly but couldn’t be scaled, I had those that died slowly, I had those that were used a lot but didn’t make money.

All of these cases are unique and should be considered separately.

It is advisable to proceed from your goal, the goal of the user and the goal of the company.

Metrics won’t surprise you. Surely, a number of users is important.

How do users interact with the product? What are their actions? Are those actions efficient and fast? What do they know about you? How viral is the product? Is there conversion? Are there users who return?

After the questions above are solved, only the scaling issue is left.

Can the things you do be multiplied by a thousand, a million, a billion or not? What can you do to not allow economic indicators to turn from plus to minus or so the indicators can be on the plus side in some time.

But actually the most important things for us is users in general.

Do they like the product? Do they use it? You can start with it.

If users like the product and they it, and there are a lot of them, you can keep running your business.

If you solve issues of 5 billion people, you can always find a user.

If you solve issues of 5 million people, it’ll be hard to find those 5 million people.

However, Facebook and Google can help you here a lot.

But again, the smaller problems are, the more difficult it’s to scale it. The bigger a company is, the more crucial the scaling issue is.

About communication inside your company

You should begin with mutual respect. And you can stop there :)

You should listen to everything they tell you and really hear it.

People tend to defend their point of view, I tried not to do that.

In big tech companies it’s a part of corporate culture.

No one interrupts anyone.

If someone did interrupt, they would apologize instantly saying “Sorry, didn’t mean to interrupt, please go on”. Your colleagues listen to you, try to understand what you say and why you say that.

When you talk with someone, assume they’re smarter than you are.

When you say something, you can be sure, they will hear you. And you have to treat your colleagues the same way.

When you talk to a person, listen and ask yourself “Ok, what I don’t understand in this discussion”. Don’t disagree immediately, try to listen, this person may be helping you already.

Of course, management is important.

You need a person who understands what you do there and which issues you solve.

So you won’t face discussion that last 30 mins and you don’t come up with solutions in the end. So the key questions are: What are we trying to solve? What are expecting to achieve in the end? Who is responsible for time tracking?

It’ll help to avoid situations when you discuss something, but don’t answer the main question

I used to have many problems with that.

I read everything I could about time management and I had struggles still — I was surrounded by papers and calendars.

It’s a full time job.

Self-management is vital, but mutual respect is above it.

Everything else is tactical.

If you start with respect and build your team based on respect, you’ll achieve great things, other stuff is minor.

The answer is philosophical but true.

About first reaction from working for Google

During the 1st year I was thinking about where I’d got myself into. Why everyone was so polite, nice and smart. Seemed a weird combination of skills.

I’d expected everyone to be presumptuous.

The reality is everyone is calm, not presumptuous.

When I met a person who told something rude, I was shocked.

When it happened the 2nd time I told the person “You know. If you behave like that, I feel this way. Perhaps, others might feel this way also. I don’t assume you meant it, however that’s what we’ve got. Can you do this differently the next time?

The person replied that he hadn’t noticed and would try to improve.

So even this person who was rude, got to realize their mistake. And it got better the next time. That means the corporate culture actually works.

About books

1. If we talk about product management — take a look at Product Management in Practice: A Real-World Guide to the Key.

2. You can read My Product Management Toolkit: Tools and Techniques to Become an Outstanding Product Manager. It covers roadmaps, what they are, why managers use them, who to use various graphical tool such as presentations etc.

3. Actually I like reading business related books, perhaps, you’ve heard about Zero to One written by Piter Thiel. It’s classic one and highly recommended.

4. Take a look at Lean Startup to learn more about business

5. Then there is Blue ocean

6. If we talk about communication there’s a book called Crucial conversations. By the way, it can be useful in both business and life.

7. There’s a book called Thinking fast and slow, it’s about communication and ways of thinking. There are 2 ways of thinking: fast and slow. The book is about that thinking and replying right away is not the same as thinking and replying after take some time. The book is quite fascinating. A lot of about human psychology and thinking out of the box

8. There’s a similar book — Predictably irrational. It’s not new, it was written 10–1 years ago, however topics are up to date and the book is recommended to anyone who works with users.

Economists believed that a man behaves logically and thinks rationally. Turned out it’s not true and people behave the opposite way.

The book is called Predictably irrational since people behave irrationally but predictably. So even that economists were wrong we can predict and understand how a man behaves in different situations still.

Biographies of great people is a great thing to read. You can learn a lot.

9. If you want technology — read Bill Gates and Steve Jobs related books. Bill Gates wrote a book 20 years ago I think, called Speed of thought, it’s about management.

Actually, don’t listen to me, better take a loot at which book Bill Gates recommends. One of the brightest people in the world and read 300 books a year.

You can read books I mentioned, but listen to Bill Gates :)