Skip to main content

The Last Dance of People Management

The Last Dance on ESPN is a huge hit.  I was a teenager during the Bulls’ era in the 90s and it was a wonderful way to relive the magic of that time.  For those of us who are in leadership roles, there were a lot of great lessons from players, coaches and managers of a  basketball dynasty.  However if you are looking to use some of Michael Jordan’s leadership tactics to your organization - I think it’s critical to know what applies and what doesn’t.

There is a myth around in Silicon Valley about a hard charging leader, who is pushing his team to get them to operate at the “next level.”  There are stories about how Steve Jobs and Bill Gates were mean to their employees, this is lauded as a key ingredient to success.  People who buy into that saw Michael Jordan pushing his teammates as a proof point that it’s the way to get it done.  The truth is that your company is not an NBA franchise.

Tech workers today do not put up with people pushing them and definitely won’t take a punch like Steve Kerr did from Michael Jordan.  During the regular season in the NBA there are only 450 active roster spots, while a medium size tech company can have more than 450 engineers.   All the talented engineers I worked with always got multiple competing offers, the NBA you have hundreds of people who live for basketball competing for the few roster spots.

I know that every startup founder believes that their idea is incredible and special, but on average those ideas are average and most of them will have an average outcome.  Taking lessons from iconic companies at the time when it was clear that they came across amazing opportunities doesn’t apply to most situations.  Of course if you are at Microsoft in the early 90s and the biggest hardware manufacturers are distributing your product, you know that this is an incredible opportunity and you will have a tremendous impact and incredible financial reward. People in those situations push themselves and understand the pushing from their leadership. Ben Horowitz’s book has a lot of great lessons on tech management and this quote is very insightful:

In good organizations, people can focus on their work and have confidence that if they get their work done, good things will happen for both the company and them personally.

Horowitz, Ben. The Hard Thing About Hard Things

This is not an essay justifying mediocre effort or mediocre results, but when looking for leadership tools you need to figure out which ones apply to your situation otherwise you will be out of touch.

The real valuable lesson from The Last Dance was the lesson that Jerry Krause learned the hard way: if you don’t take care of the people who do the work and don’t listen to them you will lose the people who help you win.

A big part of the Bulls’ success was due to the fact that they had Hall fo Fame players signed for a modest contract and the management let that contract situation get so out of hand that the players like Pippen didn’t want to do anything with the organization any more.

I have seen a similar situation happen in many growing companies: they get a great engineer at a Series A salary which is severely under market, then the company grows but the salary never gets leveled up to market rate unless the engineer threatens to leave.  The threat only happens after a few interviews with other companies and all of a sudden the situation is completely out of hand and you lose top talent with institutional knowledge.

Jerry also ignored the fact that he had an incredible team who had a great chemistry with their coach.  Somehow he thought that he could replace the coach and achieve the same results, instead the entire team unraveled.  Jerry’s philosophy was that “players and coaches alone don’t win championships, organizations do”.   Organizations are just people, so when you mess with the winning formula in the organization will stop winning which is what happened to Chicago Bulls.

If you haven’t seen The Last Dance, I highly encourage you to see it - it’s a masterpiece.  There is a lot of lessons to be learned there and it has a high entertainment value.  Just be careful if you are going into your organization and behave like MJ, you might need to be able to score all the baskets all by yourself.


Popular posts from this blog

SDET / QA Engineer Interview Checklist

After interviewing and hiring hundreds of engineers over the past 12+  years I have come up with a few checklists.  I wanted to share one of those with you so you could conduct comprehensive interviews of QA Engineers for your team. I use this checklist when I review incoming resumes and during the interview.  It keeps me from missing areas that ensure a good team and technology fit.  I hope you make good use of them.  If you think there are good questions or topics that I have missed - get in touch with me! SDE/T or QA Engineer interview checklist from Mike Borozdin If you like this checklist you might want to check out these posts: Emotional Intelligence in Software Teams   and  Good-bye manual tester, hello crowdsourcing!

Code versus Configuration

At Ethos we are building a distributed mortgage origination system and in mortgage there is a lot of different user types with processes that vary depending on geography.  One of our ongoing discussions is about how much of the logic resides in code vs. being in a workflow system or configuration.  After researching this topic for a bit, I have arrived at a conclusion that the logic should live outside of code very infrequently, which might come as a surprise to a lot of enterprise software engineers. Costs of configuration files and workflow engines First thing that I assume is true is that having any logic outside of the code has costs associated with it.  Debugging highly configurable system involves not only getting the appropriate branch from source control, you also need to make sure that the right configuration values or the database.  In most cases this is harder for programmers to deal with.  In many FinTech companies where the production data is not made readily acce

Should this be a microservice?

After having developed several distributed systems and been a part of dozens of architectural discussions I decided to put together a way to frame the microservices debate. Microservices have been fashionable for some time. A lot of it stemmed from the fact that big and successful cloud companies are using microservices.  It seems reasonable that to create a “serious system” one must be using serious tools and architecture, today it’s microservices.  No engineer wants to be called out for creating a solution that “doesn’t scale.” The definition for a microservice varies, but overall it tends to be a piece of your system that can run somewhat independently (unless of course it depends on other microservices) and has a REST or queue processing interface.  Overall code encapsulation and separation of concerns have all been around for a long period of time.  Current evolution with containers, fast networks and REST API allows people to easily integrate pieces of their system using web