Amazon has recently opened up some of its internal AI education resources for anyone who wants to use them. They're freely available on its learning platform, which you can use if you have an Amazon account.
I'm currently working through the Machine Learning for Business Challenges course, which has some great content. It's available here:
The basics of ML explained in a non-technical way with lots of useful examples
What kinds of problems are good for ML and which aren't
What kinds of questions to ask to make sure your team is thinking about an ML problem the right way
How to define the scope of a ML solution
The lessons are succinct and digestible, with lots of demystification and straightforward examples that show you how machine learning can benefit you, and when it probably isn't the right solution.
Here is a link to all the business decision maker classes:
When software developers are focused on good design - focused on taking the time to build a system the right way - they are focused on delivering business value for their customers or stakeholders.
They want good design because they know that in the medium and long term a system with good design is easier to support and extend. This has clear business value - you can do more new stuff (features) for less money and you can fix problems (bugs) for less money.
More stuff for less money is good business value. In this way technical value (good design and elegant coding) is business value.
A system with poor design may get more features built more quickly, but before long the productivity will break down as the absence of plan results in fragmentation and chaos.
So in this way, you may get a quick hit of productivity, but in the long term you spend much more to get less which is bad.
There are times in every project where you reach an inflection point and what I described above needs to invert, temporarily. See this earlier article on the topic of technical debt and why sometimes the two can be at odds.
During the inversion, you take on technical debt to deliver some quick hits, once the underpinnings and architecture are in place, so that you can ship a product on time to the marketplace.
Overall I think it is important to remember that the title of this article is true - in the long term good design is business value. Though sometimes you suspend that temporarily to deliver.
Sometimes business people want results right now and impatience with delivery is seen as a virtue. It can be. If it is a temporary inversion, and not a long term state of affairs.
It can be a real hindrance to long term value if that state of affairs is chronic and without respite.
The decision to switch from the long term view (important at the outset and through most of the life of a project) to the short term view (often important at the end of the project, to deliver on time) is an emotional one.
People don't want to stop designing and they don't like the idea of taking on technical debt. However, it can't be avoided.
Your job as a software development leader is to listen and guide your team through this transition, AND to guide the business back, once the release is done.
Be aware of the emotions and motivations on both sides. Make the smart decision to ship. Also, make the smart decision to switch back and pay your technical debt when the next phase begins.
I think that we need to recognize two important things:
A request to finish fast and on a time line can feel arbitrary to people you need to articulate why.
A request to finish fast and take on technical debt can also appear to be a request to stop delivering business value and do a shoddy job, you should avoid phrasing things so that it sounds this way.
A choice to finish fast is a choice for the business value of now versus the business value of later which can be called many things: time value of money, a bird in the hand is worth two in the bush, or "we need to close this account". This can be a good and smart decision, but it is a decision with trade offs. Acknowledge the trade offs and press forward.
The placebo effect isn't something I think about very often and when I do it is usually in the context of dismissing it as a trick of the mind or something like that. Maybe the placebo effect is just someone getting better on their own where it would have happened anyway, with no medical intervention at all.
I suspect a lot of us think this way.
But there are people out there wondering why it's happening. Why does the body sometimes heal itself? Can we understand it? What mechanisms are at work? If it is a trick of the mind, why does it seem to happen so consistently?
For a long time, nearly 250 years, we've known about the placebo effect, but we have done very little to study it.
That is changing now.
Experiments are focused on understanding how the placebo effect works, in the hopes of understanding it and putting it to work for the betterment of man kind.
It's a fasciating article and you should read the whole thing.
There are two parts of this article that interesting as leadership examples, and I want to take a few minutes to talk about those.
The origin of our understanding of the Pacebo effect come from 18th century France and involves a famous American.
Benjamin Franklin was part of a panel that was tasked with analyzing the work of the mesermist Charles d’Eslon. Mesmerists (disciples of Anton Mesmer) claimed to heal people of chronic illnesses and pain using a force called Animal Magnetism.
The panel developed experiments where the patients cannot see d'Eslon, thereby separating the effects of the mesmerist from what the patient might be supplying themselves. In doing so, the panel creates the first blind medical experiments and isolated the placebo effect.
The results of the experiment were quite clear: something besides animal magnetism, something the patient's themselves are supplying, is producing the effects of the treatment.
Having been told that imagination produces the effects attributed to his work as a mesmerist, d'Eslon responds:
the imagination thus directed to the relief of suffering humanity would be a most valuable means in the hands of the medical profession.
I find d'Eslon's reaction remarkable as an example of leadership.
I have seen people go to great lengths defending things not very integral to their livelihood and profession. How many times have you seen people defend turf for the sake of defending turf and maintaining the status quo?
D'Eslon, whose career is on the line, responds very differently.
Imagine being told you're a fraud and instead of reacting with hostility, you analyze the data and retrieve the key insight. Instead of defensiveness, instead of anger you simnply extract that conclusion your detractors seemed to have overlooked.
I've seen some people who are cool under pressure, but I've never seen anything like that. It should probably go in the record books under, Most Reasonable, Self-Aware Reaction Too Bad News, Ever.
I'm not sure what happened to d'Eslon after that. But I'd curious to know what such a man did with the rest of his life.
Imagine seeing your work discredited in public and responding with a valuable insight.
He saw the value in the placebo effect and applying our imaginations to relieve suffering.
The second thing that I think we should think about as leaders:
Some pretty brave people applying imagination to something that had been dismissed by medical science for nearly 250 years. As the article mentions, this isn't an easy journey for them. To take a topic that has been dismissed for that long and try to get people to pay attention to it is a pretty amazing feat. There are a lot of detractors, but they think it is important so they are dong it anyway.
We should take a lesson from the strength of people when confronted with challenge - Do we persevere when people question us? Or do we press on?
Those studying the placebo effect are pressing on because they believe there is something valuable and interesting, that medical science can finally come to grips with.
I'm glad that now there are those in the medical profession paying attention to how the placebo effect might be used differently and I'm glad we have the tools so that we can begin to understand it. New tools (DNA sequencing and MRIs are mentioned specifically) give these researchers the ability to peer inside us and look deeper than we ever could before.
But while the technical frontier that has opened, the frontier of human complacency, tradition, and established opinion must still be confronted and there is no new tool for that. There is only courage and perseverance, just as there always has been.
These are both great examples of human beings facing the challenge of change - one story of someone faced with a challenge/change and reacting with equanimity and grace, and one story of those taking on the establishment because of what they believe is the right thing to do.
Both of these are worth thinking about as examples of how to face challenges and show leadership during times of change.
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:
Technical Debt Quadrants
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.
I've been fired from a company I worked for. I've written about it in the past here.
I've also fired a lot of people over the years.
I don't enjoy it. It's not fun. And it's probably going to be one of the worst days of somebody's life. That's how you should treat it. Try to be as humane as you can be.
But I don't have any problem with it - it's a necessary and valuable part of how business gets done. But if you think that you can do it without emotion I think you're missing something valuable.
I came across this article today about Netflix and their CEO, which is what brought all this up:
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.
It's exciting.
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.
Jonathan Fries on .
