In this Tech Talk from Surge 2015, Brett Huff, VP Engineering here at Fog Creek, discusses how to make hard decisions. He explains a number of concepts and tools to help and then describes how to put them into real-life use with some examples taken from Fog Creek’s innovation efforts.
Brett writes about managing software teams and self-improvement on his blog.
About Fog Creek Tech Talks
At Fog Creek, we have weekly Tech Talks from our own staff and invited guests. These are short, informal presentations on something of interest to those involved in software development. We try to share these with you whenever we can.
Content and Timings
- Introduction (0:00)
- Concepts (7:09)
- Uncertainty Principle
- Hidden Benefits and Costs
- Process and Creativity Continuum
- Tools (14:05)
- Defining Failure
- Exit Ramps
- Money Model
- Creative Time
- Baby Steps
- Talk It Out
- Examples (30:46)
- Summary (47:20)
All right. Welcome, everyone. It’s good to see that not everybody has gone home yet. I’ve actually talked to a lot of people over the last couple of days. For those of you who don’t know me, my name is Brett Huff. I am currently the Vice President of Engineering at Fog Creek Software. I do that happily from my home in Idaho. Yes, I realize that there has been at least one dig on Idaho since the conference started, but that’s okay. I can take it.
I started off my career as a software developer. I got a computer science bachelor’s degree, and I’ve worked mainly in the oil industry, in the financial services industry with Goldman Sachs, and now in software as a service with Fog Creek Software. I was hired there as a developer. I went through their grueling software development interview, and then quickly found out that I wanted to move into management because I honestly enjoy helping people. Hopefully, I can do that with all of you today.
For those of you who don’t know Fog Creek Software, it was started by Joel Spolsky and Michael Pryor 15 years ago this week. We’re having our big 15th-anniversary celebration this week. Joel is famous for Joel on Software, one of the first popular technical blogs. After a few years of Fog Creek Software, Joel and Jeff Atwood had the idea of Stack Overflow. That started at Fog Creek Software. As it built up, we spun it off into a new company. A couple of years later, we had the idea of Trello. That’s built up. We spun that off as a new company.
About this time last year, we ended up in a situation where we had spun off our two biggest properties. We still had FogBugz and Kiln, so we’re still profitable, but we’re looking for the next big thing. We make a plan. Last quarter of the year we’re going to finish up these projects and that will free up some resources so that we can start working on the next big thing. About December and January, we start brainstorming and getting all these ideas of what we might do.
Late January, we start doing what we called Creek Weeks. It was two people, sometimes three for one week on one idea. They would try to attack the hardest problem of it and try to flesh out whether it’s actually possible to solve or not and whether it would be a good market decision. We did a few of those.
Then in April, we narrowed it down to three possibilities and said, “These are the three best ideas we have.” We got some people together in New York for a week, and we played around with them for another week and then said, “This one idea, we’re going to leave.”
The other two, we had a couple of small teams. They worked all summer long on these new projects. Just last week, one of the teams decided we’ve gone through a bunch of iterations of this. Their project was called Fog Horn. They were trying to make something for system administration to be easier for small companies. They’ve been playing with ideas and decided we just don’t have the right idea. It’s not going to work. They put it on the shelf. We still have one team that’s continuing on. They should be going into a private beta within the next couple of months, and we’re hoping that one will be largely successful.
I’ll get back to that, the story about innovation in a little bit. First, we need to kind of have a framework of how to think about some of the decisions that were made during all these process. I’ll talk about some concepts and tools. I know that … I’ve talked to a few people already, and they’ve talked about maybe communicating the decisions. That’s not quite what I’m going to talk about. I’m going to talk more about how to think about the decision, and how to make it easier to make the decision so that, hopefully, when you understand it better, you can communicate it as well.
Then I’ll get into some examples, and I’ll leave some time at the end. Hopefully, you will have some examples of things that you’ve done or maybe that you’re having problems with right now. Hopefully, I or the wisdom of the room can help you with those decisions.
The crux of my talk is that I believe that for every hard decision, there is at least one frame of reference that makes that decision easy or trivial. Just like this Penrose triangle, there’s a spot where you can stand and the triangle looks awesome. It looks like it’s going on forever, twisting always. Just like that, I think every hard decision has at least one spot that looks like that. There’s plenty of others around there where you can kind of see what the triangle is trying to do, or maybe it just looks like a couple of arms raised in fury. It doesn’t quite makes sense. You might be able to guess at the solution. There is some frame of reference that can make it very clear.
Changing your frame of reference is one of the key abilities of somebody who has strong empathy. They can look at somebody else’s situation and say, “I can see how that would be from your point of view. I can see that given this experience, given this perspective or your desires, I can understand why that would hard or why that would be amazing.”
Changing your frame of reference can sometimes happen with large events. This is like the BP Deepwater Horizon tragedy from a few years ago. Before that, in the oil industry, some decisions were kind of hard. You’re like, “Should we go to this well over here? There’s a lot of high pressure underground. Not quite sure if it’s going to be productive or profitable.” Then the disaster happens, and there’s a very real world example of what can go wrong, and what the cost is if it does go wrong. People’s decisions became a lot easier. They said, “That has a lot of high pressure, a lot of weird stuff underground. We’re not doing that.”
Also, in trade-off theory, there is a very smart man named Erik Hollnagel. He talked about the ETTO principle, E-T-T-O. It’s the Efficiency-Thoroughness Trade-Off. This can be helpful in some situations, but I generally try not to think in terms of it because his principles say you can either go for efficiency, and you try to cut resources. You do things as easily as possible, or you can go through thoroughness and you can do everything. Get it all right and then release, or you can go anywhere on that line.
I find that if I try to think in terms of that, then I think one dimensionally. What I like to do with harder decisions is to think about extra stuff going into two and three dimensions, think about the odd things that will happen.
Let’s move on to some of these other concepts. Let’s start with everybody’s favorite, brainstorming. The normal rules of brainstorming are: wild is good, no ideas are bad, don’t shoot down anybody’s idea, you’re going for quantity. Quality will come out of that. Those rules are fine.
I generally don’t play with those rules because the underlying principles are more important. The underlying principles are that non-obvious things are useful. If it’s a hard decision, if you have to go to brainstorming, then all of the obvious things have already failed, so non-obvious is going to be useful.
Social pressure is destructive because when you start to get more concerned about how people perceive you, and your reputation, and your position, then you’re not focusing on the problem. Wild is good, you can throw out anything. Nobody is going to shoot it down. Nobody is going to think that’s bad.
Also, don’t be lazy. If you go for the first solution, it’s probably not going to be the right one because we’ve already determined that the obvious things were not the right solution.
The next concept is what I call the uncertainty principle. This is no relation to Heisenberg. This is that no one is perfect. You will make mistakes. You can’t predict the outcome perfectly.
I like to think of this in terms of a heist movie. You get The Italian Job. They’ve planned out everything. They know what the other guys are going to do. Everything ends up working out. Maybe there’s some drama in the middle there, but you have one guy who has thought everything through and I find that just doesn’t apply to the real world. You’re going to be wrong. Things are going to crop up that you don’t expect.
The other side of this principle is not just that you might be wrong but also other people do tend to exist, and they tend to get things wrong. Sometimes they get things right, and it goes against your plan. There is interference from other people.
Another way I think about this is … Sometimes I play chess. I’m not going to win any tournaments, but I’m reasonably good. I play against somebody who’s new. You teach them all the rules, and you tell them what to do. You’re playing along. All of a sudden, they do something and you’re like, “I can take that move for free. What’s their angle?” I just sit there and stare at it because the mistake that they’ve made just completely throws me off. That kind of thing does happen in the real world as well.
Hidden Benefits and Costs
The next concept is hidden benefits and hidden costs. When you do something, there are side effects. There are things that it may enable or prevent. Also, how does it affect your employees? You’re trying to do things right for your customers. If you introduced something that takes three more support people to support just that new feature, then it may not be the right solution. You may be making people’s lives miserable or just costing the company more by enabling this feature.
Process and Creativity Continuum
The next concept is the continuum between process and creativity. You can have a perfect process, and you have everything defined. All of your decisions are made in advance. Then you have no hard decisions because it’s already picked out for you what you’re going to do. That’s really hard. It also doesn’t leave you a lot of latitude. You’re not going to take the risks that make you big. On the other end, you have creativity. You could have perfect creativity where nothing is defined and you can make any choice that you want. You can find the correct choice, but it’s going to be a lot more difficult that way.
The last concept is balance. In between process and creativity, you have to find the balance there. This also applies to decision-making. You can have one person who is completely in charge. They make all the decisions, and they use their own input. They don’t ask for other people to bring in their input or their ideas. The problem with this is that you’re relying entirely on that one person. If and when they make a mistake, the consequences of that are going to be magnified because it’s all on them. They’ve made the decision. Everybody else is helping, and so the decision and the consequences of that get magnified.
On the other hand, you can have perfect consensus where everybody needs to decide. Everybody needs to agree that this is the right decision. That becomes much harder with hard decisions because people don’t agree.
I prefer the principle of council. That is that you … Every council has a chair or a president. That one person is the one who makes the decision, but it is also his job to listen to everybody else and to make sure that everybody else has some input. He’ll coax people into talking. He’ll make sure that everybody presents their ideas and their side. Then he says, “This is what we’re doing.” Everybody says, “Okay. We’ll do that.” The decision has been made.
Now, that we have these concepts, let’s talk about some tools that will help give us information so that we can better make our frame of reference.
Even if you have somebody else collect the data for you, you have to decide what to look at. Using data is going to force you to decide what you value. You have to say, “This is what I want. This is when somebody has bought something. This is when they’ve done something that is going to hook them into my service.” Using the data will also help you see progress. You get to keep that data and go back and look at it.
The downside of this is that you only get what you look for. You have to decide what you’re looking for. You have to program it in. Anything that’s not in there, you don’t have information on.
Another bad thing about this is that you could ask for the wrong thing thinking that it’s the right thing. Bad data is an automatic failure in this. If you think that you’re looking at a page count, but it’s actually a … You think you’re looking at a unique page count, but it’s actually a total page count, then it could really throw off your numbers and make you think that you’re a lot better than you actually are.
Another example of this is automated tests versus human tests. You say that automated tests are good. We’re going to write lots of those. That takes extra work, but you get lots of data. You get quick feedback, and it’s very repeatable. If, instead, you go with human tests which anecdotally … Stack Overflow mainly uses human tests. They don’t have a lot of automated tests. They release it to the public, and they often have kindhearted developers who notice a problem and point out to them kindly in their meta-channel that they’ve released a bug.
You can have human tests where humans are consistent but not constant. A human will always find the bug. It just doesn’t find it immediately. You release bugs into the wild. You may not know about it for three months if it’s in a corner case, but a human will find it eventually.
You also have different signal strength. There are some customers who are louder than others. You may end up fixing all of theirs and ignoring the quiet majority that isn’t complaining, but they just leave.
Going back to our innovation story, when we started out on the path to create the next big thing, we didn’t decide right at the start what it is we wanted. We said, “We want it to be the next big thing.” We put lots of quotes around that. Everybody was supposed to understand what that was.
We started doing these Creek Weeks. We got an idea about late February, early March. We thought, “This is a great idea. We should do this. It would sell.” We took it to the founders, and we said, “Hey, what about this?” They said, “No.” We had to go through some iterations to find out what it is that they wanted. That ties directly into the next tool which is defining failure.
You have to decide what it is that you’re trying to avoid or what it is that would lead you to put down the project or put down whatever else. Our example here would be rewrites. I don’t know if any of you are familiar with our recent transition from Wasabi to C# for our legacy code. That was a rewrite that only took a month because Microsoft released or open sourced their Roslyn Compiler. That really enabled us to make a rewrite work with one developer for one month. It was amazing, and we now have much more productivity. Some people might look at a rewrite and say, “Rewrite, failure equals true.” Just right off the bat. There’s now way to do a good rewrite, but we did one.
You have to decide what does failure mean. You may say that a rewrite is a failure if it provides no new functionality, if it doesn’t enable something that we couldn’t previously do, then there’s no reason to rewrite it.
You could also say that a rewrite is okay as long as there’s improved development experience. I can spend a month doing this feature now, or we could this rewrite, and then it would take me three weeks to do it under the rewrite. If that’s important to you and that’s what you want, then that would be an acceptable trade-off. If instead you have a program in C, you rewrite it in Scala and nobody at your company knows Scala, that’s probably a failure. You can also say that a rewrite is a failure if it takes over a year of dedicated work.
Going back to the innovation project, when we had that problem with the founders of thinking that we had a good idea and they came back and said no, then we had to define what it was that we’re really looking for. In my words, I would say that failure was any product that could only support 20 employees. We were not looking for something small that would add to our portfolio of FogBugz and Kiln and help us to continue to be profitable, maybe add a couple more people. We weren’t looking for another tool that we could add to our suite. We’re looking for something big. Supporting 20 employees within three years is the right kind of definition, and then maybe supporting 50 within five years or a hundred within 10. That’s the kind of thing that we were looking for.
The next tool is what I call exit ramps. Along the way, you know that things are going to go wrong. You should have places where you say, “This is where we’re going to reevaluate.” If this happens, then we need something that we can divert to. We need a place where we can change our mind. These should be blameless. You don’t want to say, “We were going along just fine. Then Jack decided that we were going to stop this, and so it’s all his fault and nobody likes him.” It should be blameless.
Our example here is Fog Horn, the project that we continued with for over the summer. They went through three different iterations of how this tool might work. At the end, it just … They kind of lost their drive because they weren’t able to figure out how to make it significantly easier, how to make it a pleasure to do system administration for a small team where you don’t have dedicated staff. They used that exit ramp and put it away.
The next tool is vision. This is really more about feeling what’s right than knowing what’s right. A lot of this comes from experience. The more you’re exposed to things, the more you see what other people do, what other people are successful with, you kind of get a feeling for what’s right.
Our example here is Stack Overflow. Joel and Jeff Atwood, back in the day, they were looking at Q&A sites. At the time, there was Experts-Exchange, and there were a whole bunch of different forums where people would go and ask questions. They were all trafficked. They were all entrenched. They all had market share. Joel and Jeff looked at it and they said, “You know what? That can be done better.” They didn’t know exactly how, but they knew it could be done better because their vision or their intuition told them that it could. They started up Stack Overflow, and developed, and played around with ideas, and that grew up.
Our next tool is what I call the money model. This is what they teach you in business school. You may talk to your manager and he may understand what’s going on here. The diagram up there is the floor plan for a bike shop. Over on the left side of it, you have the retail area. That’s where you put out your bikes, you put out your clothes, your accessories. People come in the shop. Pay at the cash register and leave. It’s profitable. You get people coming in and you make some money off that.
Down in the lower right, we have the service and repair area. This is really profitable. People come in. They spent 15 to 20 bucks on parts and give you 100 bucks for labor. You make crazy money in the service area.
Then the top right, you have the storage area. This is where you put your excess surplus, and you put bikes when they’re not being repaired. You just kind of set stuff there. Nobody ever goes there to buy anything. Nobody ever goes there to give you money.
You might think, “You know what? I’ve got these three areas of my store. Two of them are profitable and one of them isn’t. I’m going to get rid of the unprofitable one and expand the most profitable one. Get rid of the storage area. Expand the service area.” Well, what does that do to your business? You suddenly have people who come in to give a bike for repair and then they have to wait. They can’t drop it off and then come back the next day to pick it up. They can’t drop it off in the morning and come back after work to pick it up. They need to wait there so that when you are done repairing their bike, they can take their bike and not be charged rent or not be cluttering up your shop. People stopped coming. Suddenly your service area is not profitable because you don’t offer the right kind of service. You don’t offer what people want.
This is the idea of the freemium where you offer something for free. It costs you but, in return, people are willing to pay for that or something else.
This is one of the foundational ideas behind the Trello business model. They thought from the beginning if we can have 10 million customers and one percent of those customers are willing to pay us $10, then we have a $1 million business. We’re going to offer something for free to everybody, and then a little extra that a small portion of people will be willing to pay for. We’re going to make a lot of money because we’ve got a lot of people. That percent will then be significant.
The next tool is what I call creative time. If you give an idea time, it will either kill it or defend it. If you take it as given that creativity is 99 percent perspiration and you liken that to the real world, then you can’t go to the gym, and in one second do all of your exercises, and come out much stronger. It takes time. It takes perspiration. Just like that, creativity takes time. The longer an idea sits around, it will either die or it will improve.
An example here is writing specs. If you spend time writing a spec, then you will find out … That spending on the idea and you’ll find out whether it’s good or not. We write some specs at Fog Creek and then we say, “You know what? That’s really a lot more complicated and a lot less valuable than we thought, and so we’re going to put that on hold.”
Going back to the innovation story, when we met in April for a week to work on these three ideas, two of those ideas had been around for months that had been floating through people’s heads for a long time. One idea had been around for a month. We thought it was a good idea, but then when we spent that extra week on it and we really focused on what was going on, then we realized that it really wasn’t our thing. There is a market hole there, and there are companies that could fill it, but it’s not going to be a good fit for us.
Another one is baby steps. Just take things slowly, take things easily and break the problem down into smaller chunks. Developers are actually really good at breaking things down into smaller chunks. Example of that is small versus large releases, shrink wrap software. You have large releases. It takes a lot of work to get one of those released. You move to the cloud. You move to software as a service. Suddenly, your releases are a lot smaller, sometimes multiple times a day. Things just get a whole lot easier.
With the innovation stories, the Creek Weeks were limited to one week specifically so that we couldn’t tackle any of the big problems. We wanted to see if the big problems were solvable, but we didn’t want to actually solve them. If there was something that was really important and really going to move the market, then we assume that we can’t solve it in a week. We don’t want to send a couple of people off for a month or two to see if they can solve it. We wanted them to attack it from different angles and try to see if it is solvable.
Talk It Out
The last tool is to talk it out. You don’t even necessarily have to talk it out with a person. Sometimes when you start trying to describe something, it sounds right. Sometimes it just flat out sound wrong. Sometimes when you start talking to somebody, they ask you questions that you can’t answer. This is another way to feel out a problem and to see if you’re frame of reference is right.
The example here is just about every week of my life. I talk to my wife about everything. Sometimes I start talking and I’m like, “You know what? That just sounds stupid. I’m not going to do that anymore.” Sometimes she’ll ask me questions. Even though I’m speaking nerdese and she doesn’t understand that aspect of it, she starts saying, “Well, what about this?” It helps me to understand things a lot better.
In our innovation projects, one of the requirements to take a Creek Week was that you had to sell the idea to at least one person who would work with you. Everybody was limited to one week per quarter. If you had an idea, you had to go sell it to somebody. You can’t work on it alone. That helped us to talk things out.
Now, that we’ve got all these concepts and tools that we can use, let’s talk about some examples. One example is canceling a project. When do you cancel a project? What does that mean? The obvious part here is if you suspected that it is not going to make the company money, then you cancel it. What about the hidden costs? Your company is staffed by people. People generally don’t like it when you cancel something that they like, and so there might be a hidden cost there that you have to consider. There’s also some balance in the decision. Who can cancel that project?
Fog Horn was … The founder specifically wanted no heavy management over the innovation projects. They wanted it to feel like a startup. The only people that could cancel these projects are either the team who we trusted to be responsible enough to tell us when they thought it was a bad idea or the founders, if they said, “You know what? You guys are completely lost, and we’re going to put it down.” Somebody has to have the responsibility to cancel it.
Then also you can brainstorm on this. The decision whether to cancel a project or not does not have to be yes or no. Like I said, with Fog Horn, it went through three different iterations. The first one was let’s make a network graph that shows how all of our systems connect and the traffic. Then things will become very obvious. As they got further down that path, they realized there are actually a lot of companies out there doing that, and they’re making a lot of money from really big companies. We probably can’t be good enough to sell this to smaller companies without them just coming in and eating our lunch.
Then they said, “Rather than cancel it, we’ve got a decent idea. Let’s pivot and let’s try a Slack bot’ where all of your debugging is in Slack and you can say, ‘Hey, show me a graph of the processor on this machine,’ and it would pop one into Slack. You can do that as collaborative debugging.” We played around with that and couldn’t get the feel right. It was always very clunky, and you’d end up with one person driving and everybody else can sit there and watch if they’d like. It didn’t quite work out. The interface was never as good as the tools that you’re getting the data from.
Then last they tried Command Line said, “We like the idea of bringing your debugging information to the place where you solve your problem, so let’s bring it all to the Command Line.” They tried that out. It’s really interesting to see them write ASCII art graphs of processor loads. That, in the end, ended up not being the right idea.
We’ve also all seen somebody’s pet project be on life support for a long time. You get a manager that says, “I really like this idea.” They can’t be convinced that it’s actually not a very good idea, so it ends up being on life support.
The best tools to use so that we can better understand this are defining failure. Decide early on what it means to fail. You say if we’d spent three months on this and we’re not even close to alpha, that’s just got to be a failure. We’ve just got to throw up our hands at that point and regroup.
You can also have an exit ramp and define places along the path where you’re going to do check ups and reevaluate and then baby steps. If you’re building something, you got to break it down into chunks. Break it down into chunks that can be reused if you developed them early. This is going to be a feature for our existing product, but it could be used for this bigger project that we expect to be more valuable. If you decide that the more valuable thing isn’t going to work out, you still got a new feature.
The next example is speaking up. This has been touched on during the keynote. The problem with speaking up is that the hidden cost and the uncertainty are the problems. If we knew from the outset that we find out that revenue is down and we’re going to go tell people about that so that it can be solved, if we knew from the outset that would be received well, then it’s not a hard decision. If somebody is being offensive or inappropriate and you think that if you bring that up, then repercussions might come back on you, then it becomes a hard problem.
The one that was brought up in the keynote is what if your manager is making the wrong decision? What if somebody is taking your company down the wrong path? For this example, we’re first looking at speaking up. Do you think that you would be retaliated against because of you speaking up? The hidden benefit here is that actually people are generally appreciative of you speaking up. For the most part, people want you to bring up your problems and to tell you … They want you to tell them when you see something wrong.
What about the times when you bring up that’s something is wrong, and they don’t appreciate it? The best advice I think I can give there is to try and coax these out of the person making the decision. You’ve told somebody, “I think this is the wrong path. I think we’re doing the wrong thing here.” Go ask them to honestly describe it to you. You’re not trying to bait them. You’re not trying to trap them in their words, but you ask them honestly. Say, “I don’t understand this. Can you please explain it?” Hope that as they’re trying to explain it to you, they can’t and they realize that. They say, “You know what? That might be the wrong decision.”
You can also offer baby steps or exit ramps. You say, “Well, we’ve done some impressive work on this project, and there’s a lot of stuff in there. What if we took this piece of it, and we instead apply that over here to this problem? Then that code that we’ve written and that effort that we’ve done can be salvaged.” You may not want to use the word salvage if they’re fighting you. It can be reused over here and not all of the effort is lost. They can let go of a bad idea and apply it to something good. If they’re not listening, try to coax them into using these tools to understand things better.
The best tools I find for speaking up are using data. By that, I mean, knowing what you want. Why are you speaking up? You see revenue going down, and you’re going to speak about it because you want a job. You want revenue to go back up. Know what you want. Vision, the more you speak up or the more you see times that you could speak up, the easier it will get. Then offering baby steps of things that you can do to change.
The next example is should we ship? You’re doing a new project. It’s going along the way. Is it time to ship? This goes much more with the ETTO principle than any of the other examples. The uncertainty is that you could alienate users if you release early, and it doesn’t function right.
Apple has this problem in spades. If Apple releases something that is obviously bad, then they’re going to alienate a ton of people because everybody sees Apple stuff right off the bat. If you are Bob’s Software Shop and you release something early, and it just kind of flat out doesn’t work, you alienate 10 people. You may convince two people that what you’re doing is important, but you don’t alienate all your customer base. You may actually win over some people who do see the vision.
The best tools for this are define failure. If you were to release and things went wrong, what would wrong look like? Have some exit ramps and, again, vision to … The more you release, the more you get a good feel for what the market will accept and what it won’t.
Another fun one is experimental code versus clean code. You can take the philosophy that we’re going to develop new features. These new features are experiments. We’re not sure if people will like this or not, but we’re going to try. If people don’t like it, we can just throw it away. In that case, we’re going to write experimental code. It can be quick and dirty. It can be ugly. You have to make the conscious decision there that we are writing experimental code. Everybody understands this. If we like it, we then have to go back and write it the correct way, or you can write clean code from the beginning. Write it as if it’s going to be there forever. If you do that and then people don’t like it, then you have to go and cut that out. There’s much of a trade-off right here. You just have to define … It has to be agreed by all people on the team.
The best tools, use data, again, to find what it is that you want. Creative time, I put that because you should be open to change. Realize that your first decision there might not be the right one. If you have a coding convention and everybody decides, “You know what? We really don’t like tabs. We want to go back to spaces.” Feel free to change it. Also, vision here again.
Another fun one is experienced employees. You have this person. She’s been around the company for five years. She knows all the products. She knows the ins and outs. This is the kind of person where something goes wrong in the product. Somebody else could spend an hour trying to fumble their way through this problem and figure out what it is. She goes and looks at a few graphs. After two or three minutes, she’s like, “It’s Redis. We should just shoot Redis and restart it.”
She just understands everything, so what do you do with her? Does she become a fount of knowledge? Then she spreads that knowledge to everybody else, and helps everybody else out, and lifts everybody else up. That is valid. You need to consider the money model. She’s not directly developing or helping with the system. Instead, she’s helping through everybody else and that’s valid. Does she become a super dev? You lock her in a room. Protect her. Nobody bothers her and she just codes magic. Both of those are valid approaches. You really need to consult her, talk to her. Talk it out. Realize that there are benefits both ways. She’s probably going to be more productive picking the one that she wants. Really, really understand her and understand that there are many ways to contribute.
Another ‘fun’ example is firing, downsizing, forced retirement, whatever euphemism you’d like. When do you decide to let somebody go? Unless they’ve been there for a month, then you probably have a reasonable relationship with them. The ones that nobody likes that everybody realizes is really high drama and they don’t do anything, those are easy.
The frame of reference I like here is I think about the low drama producer. Somebody who doesn’t cause waves and they just code. They do great things. Then what about the people who are high drama producers or low drama slackers? Somebody who’s a low drama slacker, they don’t do much, but they also don’t cause waves. Where do you draw the line there? Somebody who’s high drama, they’re always complaining, always ranting about something but they code magic. When do you keep them around? Can you put them off onto some project by themselves, and they cause less drama? That’s a frame that I use there.
The hidden cost there, letting somebody go who everybody likes is a morale hit to everybody else. Sometimes you have an employee who somebody else is like their best friend. You have to realize that if I let this one person go, this other person is going to leave as well. Also, you have ramp up time when you have a new employee. You got to ramp them up.
The tools here that I use are define failure. Decide what it is, the reasons why you would let somebody go and also money model. You understand that there are none direct benefits that some people have.
Similar to this example is the decision to move on yourself. When do you decide that it’s time to leave the company? A frame of reference that I always remind myself whenever I start thinking about leaving is that there are problems everywhere. I’m going to trade the devil I know for the devil I don’t know. I’m gambling on whether that’s going to be a good trade or not. At some point, it becomes really easy to make that decision but, it’s always going to be a gamble. You don’t know what you’re getting into until you’re there.
You can also brainstorm on this. Don’t have tunnel vision and don’t say, “I am a DBA for MySQL. That is what I’m going to be. That’s the job I’m going to move to.” If you want to move to some other job, feel free. You never know what somebody will see in you because a lot of people hire off of what they see in you and not what they see on your resume, not what they see in your past.
Tools here, define failure early, define what it is that would make you leave your company. Creative time, if you feel like leaving your company, don’t do it immediately. Give it a couple of days. Think it over. Talk it out with somebody that you trust and see if it really is the right decision.
We’ve gone through all these examples. We’ve applied these tools. The more that you apply these tools in your own life, the more that you get a feel for them. That they become part of your decision-making process.
For me, I sum all these tools and concepts up into three statements. One is that a decision must be made. When you make that decision, be clear. Explain to people why you made it. Be open to change because if somebody else presents new information, you should be willing to change. When you make that decision, be committed. Say, “This is the decision that we’ve made and we’re going to go with it until that decision has changed.” So make a decision.
Also, you can recover from mistakes. You will make mistakes. Things will go wrong. You’ll be blindsided, but you can recover. Doing something is better than doing nothing. If you set up the right exit ramps and you set up baby steps, then it’s actually quite easy to recover.
Last, have principles. Having principles means that you have decided beforehand what is right and what is wrong so that when you get that call from a salesman saying, “You know what? I could buy all of your email addresses for 50 cents a piece.” You already have that decision made. You know I value my customer’s privacy over this quick buck or any other decision. Have principles and understand what it is that you value. Decide some of these things beforehand.
You’re going to come across hard decisions. You’re going to get some of them wrong, but there is one thing that I know. The more that you apply these principles, the more that you pay attention to your problems and you honestly give it the effort to solve it, things will get easier. Keep at it. Remember your principles and make the decision.