I just hit my five-year anniversary at Rocket Mortgage, and I’ve been reflecting on the past. In this two-part series, I’m sharing some of the tips, tricks and lessons I learned while creating software at a large fintech enterprise over the last five years. If you haven’t already, check out Part 1 and the first eight lessons I shared.

Collaborate With Team Members, Not Teams

“Individuals and interactions over processes and tools.”
– The Agile Manifesto

I never trust these sorts of statements:

“I spoke with Team X.”

“Team X is aligned.”

What you really mean, is closer to “I spoke with Jim (on Team X) and Greg (on Team X), and they’re aligned.”

When collaborating across any enterprise, working with a specific team member will typically get you farther than working with a faceless team. If you need to work with a team, find a point-person — a dedicated buddy you can collaborate with.

Recycle The App Pools, Network Blips, Etc.

“We are only as blind as we want to be.”
– Maya Angelou

One of the dirty secrets of the tech industry is that no one really knows exactly how everything works.

Collectively, we understand how various bits and pieces work, but individually, many of us have a surface-level understanding of many parts of the technology stack. When something breaks, and the “owner” is on the tech incident call, they often don’t have enough understanding and/or context to know why the issue occurred.

People are generally not great at saying “I don’t know,” so we’ve come up with alternative ways to describe the fact that stuff just happens. For example, network blip, network hiccup, etc. are ways of saying the network is having issues, but we honestly may have no idea why. This is where the famous rule “Turn it off and on” comes from, because sometimes it helps, and we don’t really know why. Don’t be afraid to ask questions that get to the root of the problem. By calling out what is, and what is not, enough information to share with others helps make sure the problem doesn’t happen again. We can’t prevent something from happening again with vague excuses.

When Something Breaks, First Get It Running Again

“Heal yourself, first. The rest will come later.”
– Unknown

There are two different angles from which we can approach tech incidents: get the service back up and running at all costs (possibly by restarting, rolling back) or identify the root cause and push new code to fix things.

Imagine we found an injured person in the woods and rushed them to the hospital. The first thing we need to do is stabilize their health, not start a complicated surgery to repair broken bones. The same is true with our technology. We should focus on stabilizing our services before we turn our attention to identifying the root cause.

Automate To Deal With Expanding Responsibilities And #DevSecOpsBizData

“ The most powerful tool we have as Devs is automation.”
– Scott Hanselman

Many moons ago, when the world was young, there were mythical creatures known as “.NET Developers,” “jQuery experts,” “SQL developers,” etc. Today, in the era of full-stack, all of that has changed. The complexity of the technology landscape and the cognitive load on engineers continue to rise.

First, operations got added to development, followed closely by information security. Then came database responsibilities, then business knowledge. All of this has led to a world where no one completely understands one of these areas of expertise. Everyone has a half-baked understanding of all these different topics that can impact our work. Some team members are great at juggling all these different topics with ease, and for some it’s not a strength.

As an engineer, if you start getting overwhelmed, you need to leverage automation and tools to “farm out” complexity as much as possible. AWS and “The Cloud” are some of the obvious ones, but there are a ton of tools in our collective toolbelt. Learn how to use the resources around you to save your sanity. If tools don’t exist, convince the enterprise to buy them or just create them yourself.

Beware Of New And Shiny

“As we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say, we know there are some things we do not know.”
– Donald Rumsfeld

Throughout your career, you’ll see new and shiny solutions that promise to solve old problems, but they rarely do so without introducing serious problems of their own. Ultimately, any technology solution can solve any technology problem. It’s all about using the right tool for the job and balancing the trade-offs.

When you jump into a new technology, there’s typically a honeymoon period where everything seems great, followed by a “What have we done?” period that leads to regret. It’s important to fully understand the tradeoffs of switching to a new technology and be sure they are worth it. Being the first one to jump into the pool is the riskiest. Beware the unknowns.

#AlwaysBeLearning

“Once a new technology rolls over you, if you’re not part of the steamroller, you’re part of the road.”
– Stewart Brand

Technology moves fasts. So fast in fact, that universities are often years behind the industry. We live in one of the only business sectors where doing something for a long time can be held against you. If you stop learning, you’ll wake up one day and realize you’re a dinosaur. The only solution is to learn every day. Take on things that you’ve never done before. Never stop learning. It’s that simple.

Don’t Forget About The Users

“Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning.”
– Rick Cook

At the end of the day, the only thing that really matters is working software. Are the users happy? Do they have software that meets their needs? If yes, you’ve succeeded. However, improving technology never ends. Google still has thousands of engineers working on its search engine. It can get frustrating knowing that you never reach the end of the road. Success in technology, though, should really be measured in terms of happy users. Do you have happy users? Well then, you’ve succeeded! The best way to tell if your users are happy? Talk to them.

It’s All About Alignment

“High-performing teams use synergy and alignment to pursue organizational goals.”
– Some Thought Leader Guy (I’m sure)

I learned this lesson the hard way. The most difficult part of building enterprise software is not the software, it’s the enterprise. More people means more opinions, which can lead to more confusion, which can cause messy, complicated software. If you locked an engineer in a room for a year and said build X, it would be beautiful. But alas, we have to communicate. Communication leads to alignment. Alignment is the act of getting everyone on board with a common vision and plan. This is what great leaders do. You should try it too.

Questions? Thoughts? Leave some feedback in the comments below.