I'd go so far as to say, I'm going to expect developers I work with to read it and tell me which kind of technical debt they're talking about.
You should take the time to read the whole article. It's great. I'm not going to summarize it, only talk about a couple of things that I think are valuable and interesting.
Here's the quadrants for technical debt as Fowler defines them:
The first part of the article discusses the concept of technical debt and how it works as a metaphor to financial debt. Largely this distinguishes the concept of prudent from reckless debt, which is a useful distinction to have on hand for discussing projects with developers and clients.
In the financial realm you have prudent debts that you take on carefully, after doing your research, in order to further your goals. Buying a home, buying a car, purchasing rental property.
And then you have reckless debt that is taken on without proper research or out of alignment with your goals like buying a luxury items you can't afford.
There are two parts of this that I want to talk about in a bit more depth.
The first piece has to do with the concept of prudent, deliberate debt and where we begin taking it on in a project. I've had many conversations with developers over the years who may struggle to shift their mindset as you reach the end stages of a project.
Developers like to do things the right way - the scalable way, the smart way, the most effective way. I certainly did when I was a developer, and all the good developers I've known share this characteristic.
But there are times when you just need to finish off a feature or two and launch a product. Delays are dangerous in this situation. This is the moment to switch from avoiding all debt to taking on prudent, deliberate debt. It's time to say, "Yes, we could design it that way, but we need these features and we need to go to QA next week so please get it done."
Business realities drive us to these decisions, and most importantly, it is not wrong to do this. If you were a very savvy PM or product owner you might even put a date on the calendar when you think the decision making may change.
This doesn't negate the value of the all the design and hard work that went before it, nor does it mean you can't go back and revisit these items in the future. It just means, right now, in this phase of the project, we are making pragmatic decisions to ship and that is 100% OK and in line with best practices.
The second is the concept of prudent, inadvertent debt. Every project has it. No good developers are ever really satisfied as a result of it. But we can't ever truly get rid of it.
Why is that?
Just for clarification: prudent, inadvertent technical debt is the idea that some parts of system design will only really be apparent after the project is complete or once a particular phase is too far along to alter them.
This concept has no analog in the financial debt metaphor. There isn't a financial debt you can take on inadvertently and still be prudent. Being prudent implies that you don't have inadvertent financial debts.
But software is not finance - every software project has things that the development team would like to refactor toward the end.
If every project has this type of technical debt, why can't we eliminate it?
We can't eliminate it for two reasons:
Technology changes too quickly. New tools come along and those tools have real business value so they can't be ignored. We bring them in to projects knowing we don't have every design ready for them. We do this because we push for ever greater scale, effectiveness, and feature delivery. We do it knowing it results in imperfect designs.
Business Spaces are too diverse and changing too rapidly. Just when we think we understand an audience or a business, it changes. You can't be complacent, you can't rest thinking you know everything, you don't. Neither can you be paralyzed by such knowledge.
So, when you mix 1 and 2 together you get a situation where you can't design everything in advance. You look at the past, look at what you've done wrong and right, look at what you know about the tools you're using. And then you take the leap. You know you will taken on prudent, inadvertent debt by doing so.
The best bosses and clients understand this. It's why we like working for them and why work hard to eliminate everything else and build the great products we're capable of building.
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.