As a software engineer, you probably sharpen your skills by staying on top of the newest, coolest technology. This is an obvious place to focus for growth, but there’s a less apparent area you should consider that will make you stand out among your peers: Business Analysis.
I started my career as a software engineer but took several side roads along the way (some of them more interesting than others) and eventually found myself in a BA role. After a few years of gathering and communicating business requirements I realized I’d strayed too far from where I wanted to be. As I began clawing my way back into development, and learning all the new technology I’d missed, I found the skills I picked up during my detour ended up putting me in a strong position as a developer.
Let’s explore a few of these skills and see where you can apply them in your career.
1. Seeing the Big Picture
While you’re working on a new feature, have you ever wondered, “why do they want this?” The card you’re working on has few, or no, details about “why” this feature is important and instead just outlines “what” the client wants. Understanding the business need gives you critical insight into how your feature fits in your overall project.
2. Understanding Requirements
Business Analysts are skilled in eliciting requirements from project stakeholders which is a very valuable skill for developers. Asking questions and truly understanding the request will result in delivering a product that meets your client's needs instead of your interpretation of the requirements. NEVER be afraid to say, “I don’t understand”.
3. Learn about the Business
I’ve worked as a developer for manufacturing, health insurance benefit enrollment, and logistics and found that understanding the business is a huge bonus when writing code. Oftentimes a BA or stakeholder will use terminology specific to their business. If you don’t understand what they’re talking about, you’ll miss key information about the problem you’re solving. Ask the BA or a key stakeholder to spend a little time giving you an overview of the business and see if there are any resources they can recommend. For example, while working with benefit enrollment EDI, I became Human Resources certified so I could have a deeper understanding of the laws and various complexities of different benefit types. This gave me a huge advantage over others on my team because I had knowledge that wasn’t explicitly noted in the requirements.
4. Communication Skills
I can’t stress this enough: being able to effectively communicate with the business and others on your team is key for any developer. Whether I have a question about a feature, or want to propose a solution, the time spent interacting with clients as a business analyst has paid off in spades. Be sure you can communicate complex ideas without using technical jargon. Non-technical stakeholders know their business, not software development. If no one understands your ideas, they’ll discount anything you propose.
5. Understanding your Users
After you get the “big picture” and have a handle on who your users are and what problems they’re trying to solve, you’ll be in a great position to develop user-friendly and intuitive software. This will lead to happy users and clients.
After all, that’s why they hired you!
Top comments (2)
Laurie, this is great! Thanks for sharing. I've definitely had some awkward moments before in performance reviews where my managers have had to say "Matt, we know you're a rockstar developer. You don't need to regularly trash the office and leave cans of diet doctor pepper strewn about to prove it!".
Kidding aside, these points are incredibly relevant. It doesn't matter how technically competent you are if you build the wrong thing or target the wrong users or usage scenario. Understanding the data you're working with is another key point to consider. All of these points relate to how well you serve the business' needs - not how modern, concise, or fast your code is.
Reading this list makes me realize the things you've mentioned really are the things that separate a good developer and a GREAT developer.