Having a "keeper test" seems like a reasonable thing to do. I wouldn't do it the way that Netflix does, but that's their business. They're a successful company. How they keep their top performers, get rid of people who don't work, and put out an amazing product is their business. More power to them.
My problem with the article is that they say they do this without emotion. If you think you're making decisions without emotion you're not just wrong, you're deluding yourself about how decision making even works. You have to have emotions to make decisions, it's part of it.
If you go out and Google that topic you'll find lots of people saying that you should avoid emotions in decision making. And if you read the articles, they're right - you should avoid making decisions when you're really angry about something and when you're feeling euphoric - those aren't good states to make decisions in. But that's different than saying there's no emotion involved in decisions or you're completely analytical, that just doesn't work.
The trick is to look at data, be analytical, but be realistic about what you're feeling and why.
Often, business leaders have to make decisions with incomplete data.
If you're totally without emotions or gut feel, what are you going to do if you have to make decisions in absence of data?
The best book on this subject is Dr. Alan Watkins' book Coherence - specifically Chapter 3 in the section "Why Emotions are Important in Business".
When Netflix execs say they're firing people without emotion I suspect they really mean they are making these decisions, "without sentimental attachment to things that happened in the past and regardless of what my relationship may be to the person who I'm thinking of firing." That's a mouthful, but it is a lot more meaningful.
So, if I believe that is what they're really saying, why does it matter what was said?
It matters for 2 reasons:
What they said shows a misunderstanding of emotion and it's role in decision making. If you say things like that you are wearing blinders about what emotions you're feeling.
Saying that you make these decisions without emotion feeds the notion that decision makers are robots. I think that is dangerous for company culture and human beings.
If this is true, then they are using some emotions at Netflix to make these choices. What emotions are they (or should they be) using?
They're using emotions that derive from their commitment to the business and its vision. They're trying to build the greatest entertainment company in the world, they really care about that, and they're willing to get rid of people who don't quite live up to that ideal.
Those are probably pretty strong emotions. Strong enough, even, for you to fire an employee who was once successful and now is struggling.
But you definitely aren't making such decisions without emotions.
The question I would ask, but to which I do not know the answer is, "Is one of those emotions fear?" It's hinted at in the article.
I doubt the CEO is doing these things out of fear, though you never know. The rest of the organization could easily be affected by fear of "looking soft" as the article says or by fear of losing their jobs.
If fear is a big part of the emotional cocktail, that is not healthy in the long run.
Whatever the formula is, it seems to have worked thus far.
As it relates to my second point, there is a sense that the ideal CEO is someone who is able to make these decisions like a computer or robot. Does that match someone's ideal? I've worked with a lot of executives and I can't remember one who wanted to be a robot.
Visionaries, yes. Great leaders, yes. Builders of great companies, yes.
Even some who saw firing as a key component of building workplace culture - by which I mean they would never keep people around who didn't work hard and contribute at a high level. But this was not because they were cruel, and not even because they were ruthless in pursuit of efficiency.
No, it was because they responded so significantly to those who gathered around them and shared their vision. The leaders understood the emotional toll it took on those hard working, results-driving people to have to prop-up someone who couldn't cut it.
Non-contributing and failing team members can drain the life out of a team quickly. Suddenly hard fought gains are lost and the team is struggling.
This is to say, emotions were at the very core of why those business leaders chose to remove some team members.
So, I understand the sound byte. I wouldn't have said it that way and it is not what he meant, but I think a lot of people will read that article and see the CEO of Netflix acting "without emotion" and take that to heart.
It's wrong and misguided. I hope that at least some people stop and think about that.
What's a better approach? This is off the cuff, but I'll throw out some ideas about how to deal with emotion in a firing decision process:
What emotions are impacting this decision I'm about to make? Be clear with yourself - emotions are impacting you, which ones are they?
How does this person's performance impact those around them?
Is this person a fountain (someone who brings energy to those around them) or a drain (someone who sucks energy away from teams)?
Are these challenges temporary (life-change driven or tied to a new position) or permanent (a person is constitutionally unfit for a job or role)?
On this last point, it is important to note that people rarely change. And even if you think someone can change, can they change in time to make a difference? The odds are against them changing. Do you want to base your business plan around the need for a person to fundamentally alter their behavior?
It's difficult to change, though I have seen it happen.
But if you've put a person into the position in which they're struggling you owe it to them to at least ask the question.
All of these things relate to emotions. Emotions are important and we can't make decisions without them.
Even as an executive you need to be human. You can't help it anyway.
Acknowledge what you're feeling and why. The most successful executives I've worked with all understood exactly what's impacting them and they have been good at communicating it to others.
They don't let it blind them. They manage it and use it to their advantage.
Software and technology are bringing a lot of changes to our lives - just think of the things in the news set to make waves in the near future - robots, AI, blockchain, and self-driving vehicles.
If only part of the revolutionary claims for this tech comes true, the world will look very different.
This cocktail of technologies brings a lot of opportunity as well a great deal of upheaval.
One thing I've noticed about this digitally transformed world: every technical requirement of a project is also a business requirement.
I've often heard these words spoken: "That's just technical detail."
But I agree with less and less as time goes on.
It sounds wrong now. Just a technical detail? What product are we building here?
Yet it's true, in a way. It is a technical detail. But that doesn't mean that it isn't important or you can just ignore it or you can pretend to ignore it until it becomes a problem.
So how do we deal with this?
Over time we'll all benefit from current changes in eduction - more focus on reasoning, outcomes, and learning code will help. More people who know what code is and who have written a line or two will help demystify the whole thing a bit.
Business people: You need technical awareness and patience and you need to ask the good questions. Again, eduction will help.
Technical people: You also need patience and improved listening and communication skills. I've written before about the pain of the unasked question. Ignoring hard questions because you don't like the answer isn't OK. Ask the question you know is there.
We all need to get better at explaining trade-offs in non-technical ways. This really shouldn't be that hard.
But what is the quickest fix? What can happen now? Where do I see people stumble?
The answer is more agile adoption and commitment to great product owners.
Needed to spend half their time talking to people buying the product (getting their thoughts on the latest incremental release and how it delivered value) and half their time with the team creating the Backlog (showing them what the customers valued and what they didn't).
That would definitely help a team move fast and understand the right technical/business requirements very quickly.
It's why I believe so strongly that Agile is the right methodology and that following as closely as possible to the recommendations makes sense. I've seen a lot of product owners who did a lot of the first or a lot of the second, but only a few who did a great job of balancing both (and who were given the organizational bandwidth and charter to do it).
Today everything - every part of an application - is a business requirement. Waiting around for business experts to answer questions, when they have many other responsibilities, is a delay that almost no one can afford any more.
We all have to go fast.
And we all need the business expertise and customer awareness built into our teams.
I recently conducted a book club using Dr. Alan Watkins book Coherence. The most useful tool in the book is the idea of the emotional roller-coaster related to change in an organization.
The basic idea is that for every change in a company (and we all have no shortage of those) the individuals that make up the company must pass through a spectrum of emotions that looks like this:
Yes, every time, with every change.
The picture in the book is better, but I don't have permission to reproduce it so I've Cliff-Noted it for you.
We've all seen this before. When confronted with change, people resist. This turns out to be normal (and required) human behavior to process this change.
The key insight for leaders? You can't force people to move forward on the roller-coaster. You can appreciate where people are, acknowledge it, and help them move toward the future.
This was a very helpful insight for me. I know that several times over the course of my career I have tried to force people to where I was on the roller-coaster. I remember one series of meetings in particular where a group of unsuspecting people were essentially expected to attend a 30 minute meeting and arrive on the right hand side, without any time to process at all.
I've also questioned why they couldn't instantaneously reach acceptance (at the tail-end of the upswing on the right). They can't because none of us can. Though time and the right kinds of experience can help you move faster.
But something has occurred to me after all this. The roller-coaster image is very helpful in order to grasp the initial idea, but it misses something important. As a leader, you need to help people with the left side so that you can gain their help on the right.
In real life the down part of a roller-coaster is the fun part. It's the pay-off for have ridden up to the top. So, with organizational change: you work through the hard part on the left to get the help you need on the right-hand side.
So initially I wondered if something like this wouldn't be more useful:
This is nice in that it matches how you actually feel on a roller-coaster. Trepidation going up, thrilled going down.
But it doesn't work at all and here's why. It flies in the face of the up=good, down=bad metaphor that is deeply written into the brain of every human on earth.
Even looking at it and seeing negative emotions going up sort of gives me the heebie-jeebies.
So, that's a no go. What it gets right (in addition to how it feels to be on a roller-coaster) is the notion that in the emotional build-up is a build-up of potential energy. Going through the necessary negative emotions helps us to be ready for what comes next. We wouldn't be sent careening down the thrilling part of the coaster without the build-up of potential energy that occurs.
Similarly, people who can work their way through the change and the associated negative emotions are really positioned to truly accept the change, embrace it, and become champions once they reach the right-hand side.
The processing of negative emotions are what sets that positive trend in motion in a real way.
So what visual does capture this? The best visual I've been able to come up with is the idea of the slingshot. In the slingshot, potential energy is captured as the sling is drawn back - nicely matching the work required (as both a leader and individual) in order to actually pass (constructively) through the negative side.
Then, with the potential energy of the work captured, you can release the slingshot and actually draw all the momentum you need on the positive side.
I could not come up with a way to capture this in a single drawing, but I think a two part drawing does the trick:
My apologies to the artists in the room.
This is really a leadership view of this path through change. I think the original roller-coaster is probably best and sufficient for everyone else in an organization.
In searching for images on potential energy, I came across this image:
This turtle is about to undergo a change (and probably highly negative emotions).
But that doesn't have much to do with organizational change. I'm not sure it has a lot to do with potential energy either - at least the turtle part.
The result of a recent discussion of some side projects and whether or not it was professional development.
The project had business stakeholders separate from development team.
The project had testers separate from development team.
The project had end users separate from development team.
The project had a development plan.
The project was deployed to production.
The project has end users who continue to use the system.
The project had at least three significant challenges - challenges not solved by Googling or reading stack overflow. These are hard things you had to solve as an individual or team.
1, 2, and 3 need not always be completely distinct groups, but they do need to be distinct from development team.
1 through 6 can be easy at times, and can happen very fast, if you know what you're doing.
It is usually number 7 that distinguishes professional development from amateur work, hobbyist side-projects, or other simple coding endeavors.
Notice that there is not a Number 8 - 'You got paid for doing it.', becaucse being paid for it isn't an absolute requirement to make it real work. I've seen a lot of people get paid for things that don't count. And I've seen a lot of great work that was created because someone cared enough to do it, even though they weren't getting paid in dollars or other currency.
If your work checks off number 7 on the list then you were getting paid in experience, and this can be invaluable to you.
Clients frequently request that we use existing applications as the basis for work when we are rebuilding or recreating a system with them.
This is very difficult. It can work, but it is much less effective for developers and results in a lot of iterations as the dev team goes back and forth figuring out what an application needs to do. It leads to a lot of bugs that are only discovered in UAT.
In the beginning it is much more efficient for your business stakeholders, which is why they ask for it. Why go through the existing application and document it? That's a lot of work for users and business people, not to mention the BAs you have to pay to do it.
In the end, the same people who didn't want to go through the process of documenting will be mad because it is taking so long. It is your responsibility as a developer, lead, or PM to set the right expectations in the beginning.
If your stakeholder (whether client, boss, CEO, etc.) requires you to work this way you need to expose the risk and set appropriate expectations. The very best case scenario is that you have to set aside time for late project iterations when you run into these challenges. The worst case scenario is that the project will drag on so long that will be cancelled. It happens all the time. Also possible: you fixed-bid the project and put your company out of business trying to complete it.
Setting the right expectations can be difficult, and that is a topic for another post some time. My goal today is just to describe a few of the ways this has come up over the years, so you know what to look out for.
Just make the new app do what the old one does. Why do you need requirements? An all-time classic. Why not? I mean there's already code, how hard can be to just: read it, understand it, understand all the subcomponents and UI, assess whether or not it is still necessary, talk to users, and figure out how to test it. It definitely wouldn't be easier to have that done and approved before you start development. Danger level: Red Flag
Preserve the business logic, everything else you can get rid of. This assumes that preserving the business logic is easy, which it usually isn't. Even when someone has done a good job of separating business logic from UI and data access (very rare) often the technical and business requirements of the rebuild make reusing the code in its original form impossible. Danger level: Yellow Flag
We'll figure it out as we go along. This one can seem reassuring in that your stakeholder has seemingly granted you permission to iterate. But be careful here: set expectations, ask follow-up questions, establish what 'figuring it out' will really look like. Danger level: Yellow Flag
There's a lot you can re-use. Just tell me what it will cost to rewrite the things that you can't re-use when it comes up. You should assume that you are rewriting everything. If you get to re-use something that's a win. It will most likely save you a little time in testing, but not anywhere else. Danger level: Yellow Flag
You don't need to talk to users. Bob knows everything about this application and Bob is your main point of contact. Unless Bob is the only user (and even then) he almost certainly doesn't know everything. Even if Bob isn't an ego-maniac (and he might be) you are still facing delays in understanding the system because Bob has to go ask someone instead of you asking them. Danger level: Red Flag
This spreadsheet will tell you everything that you need to know about the system. AKA Our old system was a spreadsheet, just look at that. Usually these are worse than looking at code because in addition to code (like VBA) you also get things like embedded charts, formulas in cells, and obsure data access thrown into the mix, requiring even more detailed reading to understand. Danger level: Red Flag
Jennifer developed most of the original system and she'll be working closely with you on this project. Usually Jennifer is retiring, and that is a hard deadline. Also, what does most mean? Danger level: Red Flag
We have all the requirements from 20 years of work we did on the old system. You can read through that. To paraphrase Sartre, Hell is other people's requirements documents There are a few reasons why this is true, but probably the most profound is that writing the requirements document immerses the team members in the system. Without having written it, asked the questions, and fully digested the material then you or your BA will always be at a deep disadvantage. I wish this weren't true, but it is. At least 50% of the reason for documenting stuff is to make sure the person responsible really understands it. Danger level: Red Flag