What’s great about championship sports, is that there are moments where players rise to the occasion and step up to challenges in ways that significantly affect the outcome of the game. And being the championship game, where players are the best of the best, it makes those who rise that much more special.

Like championship teams, world-class software development teams have key players that rise to the occasion to get the product across the finish line.

In software, these key players step to the plate and perform key tasks that lead to a successful project. These tasks aren’t based on seniority or job titles as much as they are based around leadership, perception, and a sense of ownership.

Rather than hard “skill sets”, these are “mindsets” that anyone can adopt to build a better software product. Whether you’re an entry-level developer out of college or a seasoned architect, anyone can develop these traits to become better technical leaders.

There are three mindsets, throughout the software development lifecycle that technical leaders can fill that are quite literally the difference between good software and great software. If you can grow these skills, you’ll build your reputation as a “championship winning” technical leader — even if you don’t have an official leadership role (yet).

The Architect:

The Architect is able to convert general requirements of a project into an actionable plan of attack. They make design recommendations, set the direction of the project, and use their experience to avoid pitfalls.

The most coveted trait of Architects is that they can identify patterns quickly. Having seen other projects take form over time, they can identify patterns in past successful projects and map them to the current project so it starts on the right foot. Wise design decisions pay dividends down the road, and Architects help avoid potential pitfalls before a single line of code is written.

The Architect has the experience and knowledge to say “This is what you want to do. I’ve done a lot of similar things and know this will work” They outline the foundation that other decisions will be based off of. Mind the “big picture” and not the minutiae.

Here are some questions you can ask if you want to become a better Architect:

• What’s the Essence of the Thing We’re Building?: As much as we think we’re building something unique, oftentimes what we’re building falls into a handful of software archetypes. Identifying this upfront will guide your design to something that already exists in the wild that you know works.

‍

• What Does Minimum Viable Architecture Look Like?: Building out a full architecture might take too long and be too resource intensive at the moment. What’s that initial morsel that’s good enough for a successful launch? How will this minimum viable architecture set you on the path to the achieve you next set goals?

The Starter:

‍

At my first internship, I met another intern who recounted his first day of internship not knowing how to turn on his own computer… and he was a developer!

Sounds crazy today, but in the early 90’s computers were just becoming commonplace at home. All his experience with a computer was in a computer lab, where they were always turned on. So not surprisingly, when he was put in front of one powered off, he was unsure of what to do.

I’m reminded of this story when it comes to building new software; more often than not developers spend their time adding on to existing projects than starting new ones. We take for granted that starting a project is the same as contributing to an existing one, but there are some different muscles used when starting from nothing. If you haven’t exercised that muscle before, you might find yourself not knowing where to begin (analysis paralysis) or working on things that aren’t important.

The Starter has the critical skill of starting the coding. A good Starter not only knows where to start, but also where NOT to start and what NOT to do. This goes back to the pitfall of trying to shoot for scale too early. A Starter will help you focus on what you immediately need to get you to the next phase.

Starters can execute to the standard that’s been set by the Architect. Rather than trying to build the next shiny thing, they bang out code and focus on the immediate task at hand.

Here are some questions you can ask yourself to be a better Starter:

• Where to Begin?: What are the basic components needed to get the team working and in lock step (environment, configuration, building, project structure). How do you set the pace that other developers will follow?

‍

• What’s the Shortest Path to Visibility?: Not everyone can read the code to see how close you are to launch, what’s the path to getting something tangible and testable so you can start getting feedback?

The Closer:

‍

Unexpected crises have a way of rearing their ugly heads just when a project is near completion. Whether it’s a last minute change to the specs, or a newly found bug, it has the potential to delay or derail the entire project.

Sometimes these are self-inflicted wounds. For example, it’s common to delay the riskiest parts of the project to a later date, proverbially kicking the can down the road but you eventually have to tackle it (we had a project once where we started a third party integration on the back third of a project, and only then did we find the gaps of that third party that led us to scramble for a solution). You may test it and realize that your multi-user chat room starts to grind to a halt after five users.

The Closer is the person that can solve that problem for you; sometimes it requires brute force and working through the problem, other times it takes finesse and discernment to quickly solve the problem to get to the finish line. Sometimes you’ll have a lot of pieces that should make a whole, but they just aren’t hooked up together yet. That’s where you need someone to come in and get something across the finish line. The Closer can help put all of the pieces together. As big picture thinkers, Closers are good at providing healthy pushback so the project doesn’t drag on.

Sometimes you don’t release because the business side of the house wants to add more features. A good Closer can put a cap on that and say “There are always 15 other things we want to add, but let’s focus on getting this to market and let user feedback dictate what else to add”

The Closer is the guy that you need to get you to the end. Having a good one tremendously helps you get there. Here are some questions you can ask to be a better Closer:

• Where’s the Fire?: Understanding the system and understanding usage patterns will help point you to the problem you need to solve so you can launch.

‍

• What’s the Shortest Path to Launch?: Sometimes the shortest path means sacrificing functionality to get to launch. Sometimes a solution means having a short term fix and a long term fix.

Conclusion:

It doesn’t have to be one person that fills these roles, it’s ok for multiple people to fill them. But as a leader, your ability to embrace these roles and their subsequent responsibilities will help you stand out among the crowd.

Be mindful of these roles because somebody will need to step into them for the product to succeed. You’ll build your reputation as a leader if you adopt at least one of these roles. People will take notice and you’ll increase your value on the team. You won’t find a job description for any of these. It’s your job to understand what the situation is calling for and be able to step up and fill that role, no matter how junior you are.

‍

‍