In Hockey and Software Development, Avoid Offside
Subscribe

In Hockey and Software Development, Avoid Offside

July 25, 2016

Recently, I started a series of articles in National Mortgage Professional Magazine where I relate my exploits in the mortgage technology business to the game I play in my free time. Actually, it’s the game most folks who grew up where I did play whenever they can. I’m talking about ice hockey.

If you’ve never left work after a particularly difficult day, driven out to your local ice rink, suited up and then skated as fast and hard as you can into another person who just happens to be wearing a different colored jersey, then you don’t know how liberating and therapeutic this game can be. As therapies go, I think it’s even better than debating over which fishing lure is best or which cheese goes best with whatever’s for dinner, though not everyone living in the upper Midwest agrees with me on that.

What has been so surprising to me is that many of the lessons I’ve learned on the ice apply very well in the mortgage industry, especially for folks like me who lead software development teams.

One of the reasons hockey is such a great game, particularly for those of us working in the financial services industry, is because unlike our day jobs, ice hockey has very few primary rules. It’s a fast-paced game that doesn’t get bogged down with unnecessary regulation. I guess a lot of industries used to operate that way, back in the day. Not today.

In hockey, there are really only about three key rules that must not be broken. Today, I want to tell you about offside.

Being where you’re not supposed to be
Hockey would not be the great game it is if one team could just post a player next to their opponent’s goal and wait for someone to send the puck flying to them from the other end of the rink. To keep the game fair, the offside rule says that the puck must cross into the defender’s zone before any attacking player does. If the puck is passed over the blue line into enemy territory and picked up by a teammate who is already there, it’s called offside and play stops.

To avoid this, most hockey coaches warn their players never to pass the puck over the blue line. This advice is not easy to take because as you approach that line, the opposing team will apply significant pressure to keep you out of their zone. The temptation is strong to pass it away. Your only good options are to do whatever it takes to carry the puck across the line or send it shooting into the corner in the hope that a teammate will recover it, which only happens about half the time.

Now, if you’re a software team lead or project manager, you know what it feels like to approach the blue line, even if you’ve never played hockey. It’s that feeling you get when you can see the goal clearly ahead of you, but the pressure to deliver the project on time and under budget has never been higher. You have good people on your team, but no one who can take the responsibility for the project off your hands. You have to take it over the line or, in worst-case scenarios, send it flying into the corner. In most cases, the blue line is the system cutover date.

Good project managers try to always lead the project through a smooth and controlled cutover, replacing legacy systems with the new technology that will take the company to the goal. But sometimes, unexpected pressure can force a project manager to attempt an all or nothing play to keep the project from dying. The closer you get to the cutover date, the more intense the pressure will become.

In software development, just like in hockey, timing is everything.

Being at the right place at the wrong time
Sometimes, you can violate the offside rule just by virtue of when you get into the game. I remember the first time this happened to me. It was my first season playing and even though I knew what offside was, I hadn't experienced it as a player. Like most things, you can read the governing legislation, but still not get the real point of it until you hear that whistle blow or receive that consent order.

Anyway, if you’ve ever attended a hockey game, you know that the two teams have seating areas on either side of the red center line from each other. When the game begins, each team is defending the goal on the same side of the rink as their bench is on. But eventually, the teams switch, each defending the opposite goal. This means that your bench is now situated right next to enemy territory. If you step out on the ice before the puck has crossed the blue line, or fail to get across that line before the puck crosses it, offside.

During my first season, I remember the coach and my teammates reminding me to watch out for offside. I remember thinking, that's the least of my worries. They’re not going to let the new girl carry the puck across the blue line. As luck would have it, as I’m jumping on the ice, trying hard to just get onto the ice without breaking my neck, the puck comes flying across the line. Offside! The guilt I felt at pulling all of the momentum out of my team’s effort to score a goal was very strong.

This happens often in software development. You’ve worked hard on a project, maybe for months; you have everything lined up and you can see the goal. Then, just as you are guiding your client toward the cutover, they hire a new executive. Just like that, someone has stepped onto the ice at the wrong time. Nine times out of 10, that person is going to want to review everything that’s happened up to that point on the project. Even if everything gets approved the timing is horrible and momentum is lost. It’s all about timing.

When it all comes together
It can be easy sometimes, as a player, to see rules as just something to slow down the game and make things difficult. The reality is, at least in ice hockey, that the rules are there to keep the game fast, fun and fair. The officials are there to make sure the game is fun for the players and fun for the spectators to watch. If you doubt this, consider the delayed offside rule.

Delayed offside happens when the puck is passed or shot into the offensive zone while an attacking player is offside but has not yet been touched by a member of the attacking team. If this happens, the official will throw up a delayed offside warning, giving the attacking team the opportunity to "tag up" by getting all of its players out of the offensive zone. In other words, you have the opportunity to sneak out of the area if you make a mistake. If you can do it, then it’s no harm, no foul.

This is a great rule because it assumes that the players want to follow the rules and just made an error that they are willing to correct. This contrasts with industries in which companies are viewed as criminals who just haven’t had the opportunity to break a law yet.

In hockey and software development, rules make for stronger teams. In the case of offside, it forces players to work as a team, communicating together well so that they always know where each other are, especially as they approach the blue line. It also forces individual players to pay close attention to their surroundings, knowing where they are in relation to the rink markings, their teammates and the puck at all times. If more companies were run this way, we’d see a lot more firms reaching their goals.



Amy Bergseth is vice president of Operations for Glencoe, Ill.-based Exceleras, formerly Default Servicing Technologies. She can be reached by e-mail at Amy.Bergseth@Exceleras.com.



This article originally appeared in the June 2016 print edition of National Mortgage Professional Magazine.

Technology