Mitigating The Dead Sea Effect
Some of the worst experiences you will have in your development career will occur at places where the dead sea effect is a major problem. It’s not just that you’ll be surrounded by less skilled developers who can’t work efficiently, but any efforts to improve the situation will be stopped cold. Worse still, if you stay in such a place, you’ll hurt your career for years afterward. It’s also an extremely frustrating environment, which can often lead you to being cynical. Eventually, if you stay in such an environment for long enough, you’ll either burn out, or you’ll become a dead sea developer yourself.
While this all sounds like bad news, there is a silver lining to this particular storm of mediocre clouds. Such environments can be fixed, provided you have management’s help (or if they aren’t paying particular attention).
Getting out of a dead sea situation is a royal pain. It’s difficult to do, takes forever, and is fraught with political difficulties and hard decisions. However, if you want to keep your career going in a good direction for a long time, you may find yourself choosing between fixing the problem and moving on. Never forget that you can fix a dead sea by either changing your company or … changing your company.
Understanding The Dead Sea
What is the dead sea effect?
Essentially, it’s a human resources antipattern. Yes, HR has them too. Essentially, the dead sea effect occurs when the managerial practices of a team result in the competent members leaving for greener pastures, while the less competent remain behind. The metaphor is built around the idea of how hypersaline lakes formed. The water evaporates and the salt remains, eventually killing everything in the lake.
Some characteristics of Dead Sea organizations. Extremely fixated on old approaches, old technology, and “the way we’ve always done it”. The team no longer learns new things. High amounts of technical debt, and a tendency to pile it higher rather than addressing it.
How does the dead sea effect happen?
Usually it’s a function of one or more of four factors. Cashflow problems mean lack of money for training, new technology, and employee retention. Sunk cost fallacy in management means not experimenting with new things while it is cheap to do so. Eventually, there are no small things to try, because the world has moved on. Toxic team dynamics drive off the better developers, while the remainder get more bitter, meaning that even if you get better devs, you can’t keep many of them. Mass firings or situations where a mass exodus occurs can mean that expertise leaves the building. The remaining employees stick with what works, because they don’t have time for anything else.
There is also no point in blame here, at least not yet. These dynamics develop slowly over time. If you are dealing with a complicated product, with lots of people in the mix, it’s easy to miss this stuff. A lot of these things are the result of short-term compromises becoming permanent. These compromises may have been necessary, and it may have been harder than expected to fix them afterward. Because of the high salaries in development, cashflow issues can absolutely destroy a development team, even if the cashflow problems don’t originate there.
Mitigating From The Organizational Level
Training existing staff
The first thing to do is start getting the staff back into a routine of learning. The main reason this is first is that it can take a while to have a useful impact and a lot of people are comfortable with the way things are. The second reason is that this is a good time to probe to see if management is even receptive to fixing the problem.
Training improvements can often be done without involving as much of the command structure in the organization, which helps get around them if they aren’t a problem. For instance, lunch and learns are basically free, or cheap enough that they don’t require executive level approval. If it is free or very cheap and of benefit to the team, having some team training can often produce results that can get management to listen to you.
Training also has the side effect of revealing which employees will be the biggest problem in moving out of the dead sea. Expect some initial resistance because training is extra work, but pay very careful attention to who is most receptive and most toxic. “You” do not fix the dead sea effect. “You, your team, and your management” fix the dead sea effect. You need to find out who is on your side.
Fix broken processes
Once you have started getting some training underway, the next step is fixing broken processes. Training is an excellent vector for improving processes. It’s easier to have a reasonable discussion about how to fix things when people understand the fix. This is also a good time to start recruiting your coworker’s input into HOW processes should be improved.
Some ideas for things that can be fixed and continue snowballing your improvements.
- Source control practices / branching strategy
- Continuous deployment
- Code reviews
- Proper implementation of agile
Once your processes are improved and you are making progress on training, now you can introduce technological improvements where they make sense. Even though poor technology can often feel like the biggest pain point, it’s a hard thing to sell without other improvements supporting it. You also don’t want to be the only one pushing the technological improvements – that’s a lonely road paved with politics. It’s even better if other members of the team start pushing some of these improvements.
Be careful about which technologies you push. Don’t push anything that you don’t think your team can handle without more training than they are likely to get. Basically, doing this right will feel like sneaking new technology in, rather than loudly announcing yourself. The goal is to get a critical mass of the team to adopt a new practice, so that it can’t easily be ripped out. Remember that the old way of doing things lasted so long because a critical mass of the team adopted it.
Improve feedback loops
With improved technology, better training, and improved processes, it’s now time to start revisiting some of the feedback loops that you have in place. Typically, this means more extensive pair programming, testing, and code reviews. You should have already been doing these things, but now is the time to make sure that they are happening on more sensitive areas of code, written more recently. The idea is for early process improvements to give people time to fix their individual coding practices before there is any embarrassment to be had.
However, by now, the personnel problems on your team are probably becoming very apparent to the team. They probably aren’t apparent to management. The point of fixing feedback loops at this point is to start surfacing the problem to management without being nasty. It’s entirely possible that some of your coworkers are in the wrong position. People change over the kind of time periods that cause the dead sea effect. Remember, it’s not your job to get people fired (hopefully it won’t be). It’s your job to tighten MANAGEMENT’S feedback loops too.
Mitigating From The Individual Level
Reallocate responsibilities to strengths
As feedback loops tighten, you start noticing that certain team members are especially strong in certain areas. They may never have had the opportunity to leverage their strengths when the dead sea effect was in control. Try to see what you can do to get people into a position to leverage their apparent strengths where management can see them. You may also notice that some people really start hating their role once things change.
These things may be above your pay grade. When describing how these tactics can help your team, try to figure out how your manager is evaluated by their manager. Make your manager look good and things are much easier. You need to learn how to do this if you want your paygrade to increase. Help the dude above you move up so that you can.
Improve employee interactions and morale
Now that things are on a trajectory of improvement, it’s time to start ironing out whatever interactions are still bad between team members. As the previous issues got ironed out, a lot of “interpersonal debt” probably got aired. It’s a lot easier to fix some of the deeply ingrained interpersonal interactions after there is good reason to be positive. It’s also a good time to start evaluating whether there are some larger structural problems that are still causing friction.
A lot of this stuff is starting to get into management territory, but if you’ve pulled off the rest, you probably have some leverage you can use here. This is also a good time to start hitting up management about things like team lunches and other benefits. By now your manager probably realizes what is going on. It’s a good time to get them to go to their manager with the improved results (if needed) to see if you can get authorization from higher up for things like better pay, better training, and more privileges.
Re-align evaluations to business objectives
At this point, you have effectively fixed the dead sea effect. However, now the hard part begins. You have to keep it from coming back. Your team’s evaluations need to start being aligned to the strategic objectives of your organization. If you had the dead sea effect before, it’s almost guaranteed that your team wasn’t evaluated based on how well they met objectives.
If there was a mass exodus before, you want to make it harder for that to happen. If your team is improving things, especially cashflow, it’s a lot harder for the bean-counters to justify cuts. Part of this is better pay. You don’t want your best people to leave because they can get a lot more elsewhere, and you should have information that backs that up by now.
Remove problematic personnel
At the end of this process, there may still be some people on the team who just can’t perform (or won’t). They’ve got to go. Mercy towards people who actively harm the rest of the team is treason to everyone else. More than likely, if evaluations are correctly aligned, processes are fixed, and there are opportunities for improvement, the people who don’t take them after sufficient opportunity are unlikely to ever do so.
Thankfully, this will mostly happen organically. You shouldn’t have to go to management to ask for this, as having the right information on hand makes the case. Hopefully the individual(s) in question can find another place in the organization that works for them, but they can’t be allowed to continue the way they are. You might even like the person in question. However, it’s important to remember that if they can’t do their job, they are still toast either way. Don’t let them break your team. If you are at this phase and starting to think that the person might be let go, it might be good to start encouraging them to find something that suits them better.
Brian Christian and Tom Griffiths
The next few chapters of the book talk about overfitting, relaxation, and randomness. Chapter 7 starts off talking about Charles Darwin and Benjamin Franklin creating pro and con lists. It then goes into why you want to avoid too much complexity. The idea being that more data doesn’t always lead to a better prediction. Also complex data models don’t always lead to the best predictions. Chapter 8 starts off with the story of a PhD chemical engineering student also planning a wedding and how she found a correlation between seating arrangements at her wedding and amino acid pairings. She found that even with the fast computers at Princeton she couldn’t calculate the best solution. The chapter goes on to discuss optimization and the idea of relaxing constraints to allow for a solution, though maybe not the best overall. Chapter 9 talks about randomness, it starts with sampling and then goes into randomizing algorithms.
Tricks of the Trade
Consider the second order and third order consequences of your decisions. Developers can really get into trouble when they don’t do this, especially when your code changes the behavior of societies or people in your organization.