December 15, 2020 10:37 am



Building a great organization is a challenge. It is finding the right people, coordinating efforts, making the right things, finding product-market fit. Especially it becomes more problematic when an organization is successful and needs to scale fast. Why do some companies have great results and others don’t?

In this article, we explore the insights from these books:

I highly recommend reading all of them. At least read Good to Great: Why Some Companies Make the Leap…And Others Don’t. This research-based book gave me quite a lot of insights on what makes organizations tick.

I’m a software engineer by craft. So this is heavily focused on Software Engineering companies and my personal experience working in the field.

Let’s start.

Hiring for future

One of the Jeff Bezos sayings (also known as Jeffisim) from Everything Store is:

Every time you hire, it should raise the bar for everyone. 

The idea here is that you cannot hire people who do not fit your organizational culture. Sometimes you are growing like crazy, and you desperately need more hands. But you can’t just lower the bar. If you do, you will have more problems. Not less. Here is why:

Typically high performing people are intrinsically motivated by performance and getting shit done. If you add people who don’t fit, you will start wearing down your high performers. First, the underperformers typically start bothering high performers for help. Secondly, lower performance will slow down your progress:

Let’s say you have a small project, which consists of four independent tasks. You have three great performers and one under-performer. The simple math will continuously show you that the underperformer will be blocking the success of the project. Typically managers know this already and adapt by allocating work differently. They will give important, blocking tasks to high performing people, and nice to have tickets for lower-performing people. 

So what do we do about wrong people? It’s easier to fire them. I know it sounds horrible. But there are some good things about it:

It just wasn’t the right fit, and the person now can have a chance of moving on to a different organization, where the person can flourish. Maybe the person isn’t motivated by your team’s problems?

I had a similar experience, where I quickly decided to leave the company. It just wasn’t the right fit for me. No matter what I tried to do, I couldn’t get anywhere. I wanted to be part of the team, which builds something great together. Instead, I got to be part of an organization where everybody fights for their seat.

But how does a perfect candidate look like?

As discussed previously, getting shit done is one part of it. Another factor is discipline. As outlined in Good to Great, you can’t train a person’s discipline. You can only hire disciplined people. So when interviewing, make sure you check for that. 

Interestingly enough, this approach even applied to steelworkers back in the ’80s. A company that hired only disciplined people created a culture that quickly removed people that weren’t pulling weight. The result was that quality was better, financial results were way better off than competitors and most importantly people were happier.

Similarly, in his blog post “The Guerrilla Guide To Interviewing Version 3,” Joel Spolsky tells you what he looks for candidates. In summary, it’s two things: Smart and Get Things Done.

Interestingly, Everything Store has a similar story. Amazon hires doers – engineers, developers, but not managers. Bezos didn’t want his company to turn into Microsoft, where there is this massive structure of middle managers.

I like this idea. The best of my managers regularly got their hands dirty, and all of them came directly from engineering positions.

One cool outcome of hiring the right people is:

Required skill is not that important. You can learn it along the way. 

Okay, we got the right people on the bus. How do we make it work?

Small independent teams

Another Jeffisim is:

Communication is a sign of dysfunction. It means people aren’t working together in a close, organic way. We should be trying to figure out a way for teams to communicate less with each other, not more.

The idea is that if you need a lot of cross-team meetings to get projects done, you are doing it wrong.

You don’t want a company that is slowly becoming Waterfall-ishYou want small organic teams. Organic is the key. Small groups let you get to know your compadres better, build rapport with them. If your team is responsible for the product end-to-end, you can iterate faster. The team will probably be happier, too, as their work is immediately shipped and used by customers.

Bezos coined small organic teams as Two-pizza teams, teams up to 10 people, who end-to-end own their product and do independent decision making. The vital question of this idea is, how do you then evaluate teams? How do you track progress if everybody gets to make their decisions? 

The idea is that you can measure independent teams using metrics.  You come up with some high-level measurement, which reflects the outcome you want to get. For example, if a team is sending emails to customers, one metric could be their email’s click-through rate. 

Funnily enough, when Amazon tried to adopt Two-pizza teams, it went completely sideways. Teams had to come up with metrics for tracking their progress. Everybody started to make complicated metrics so that teams aren’t judged too harshly. 

Asking people to define their metrics was not a good idea. Furthermore, this approach is not a silver bullet, and some people won’t be happy. It’s not for everyone. Some people will leave, and that’s completely fine.

The most significant outcome of small independent teams is that they move away from large hierarchies. You quickly notice that there is no “Us” vs. “Them”. Everything is a little bit more equal. 

Although independent teams have their problems too:

Look at the current state of AWS. It’s a massive and confusing pile of services. It feels like something was built by completely different companies. What is the difference between SimpleDB (a document store) or DocumentDB (also a document store)? Or look at their Machine learning tool collection. So many different services, that do similar things. The platform is confusing.

Distilling things down to their core primitives

Early on in Amazon, Bezos disallowed doing slides for proposing new projects or ideas. Instead of presenting ideas, you had to write down a narrative. At the beginning of the meeting, everyone would read the document in silence and then discuss it.

I think this is a tremendous organizational change. Talking doesn’t get you anywhere. Too often, people bullshit their way thru, riffing without any preparation, and throwing half-baked ideas into the meetings. On the other hand, writing things down makes sure a person did the work upfront.

For me, writing helps you to think over ideas. It enables you to distill things into its core fundamentals

If you look into Amazon from a broader perspective, they build things from simple units. Suppose you think about Amazon’s two-pizza team concept – it’s a fundamental unit. Another example of distilling things down into their core pieces is AWS S3 or EC2. 


I’m not saying Amazon is a perfect company. I probably wouldn’t want to work in Amazon. All these books had some fascinating insight. And you quickly notice that some of the ideas kept repeating. Check out the books: 

Here are my lessons learned:

  • Hiring for future
  • Small independent teams
  • Distilling things down to their core primitives

If you are interested to hear more from me, sign up for my email list down below.

Sign up and never miss an article 

About the Author

I'm Povilas Versockas, a software engineer, blogger, Certified Kubernetes Administrator, CNCF Ambassador, and a computer geek.