When it comes to becoming more effective at our jobs, most software developers tend to think about self-improvement through a single lens. By default, we equate becoming better software developers with improving our technical ability.
We imagine "leveling up" our skills in a linear fashion through studying programming topics like new language features, frameworks, libraries, and architectural patterns.
It makes logical sense why improving our technical skills comes to mind first. Technical ability sets the foundation for where and how much a software developer can provide value.
If you can't write a decoupled service layer that interacts with a DB in Python (or your chosen language) as a back-end developer, or implement a grid system in CSS as a front-end developer, then those essential skills must be learned first.
Once that foundation is established though, and acknowledging that there's no end to the amount of programming knowledge out there, you can begin pursuing other ways to create value.
As a prerequisite to enhancing your value as a software developer, you have to build your technical foundation first.
To begin, you have to be aware that there isn't always a 1:1 mapping between improving your technical ability as a software developer and the positive impact that you have on the business and the environment around you. There are other skills to learn, and this holds especially true if you want to advance to leadership roles.
How to Lock Onto Business Needs
Understanding the value you provide to the business is one of the most important skills you can establish as a software developer. You have to understand your role and how it fits into the bigger picture in order to know where to best place your efforts in increasing your own value.
To start, one of the basic, high-level distinctions you should determine is whether or not your department is considered a cost center or a profit center by the company you work for.
For example, if you work for a bank and your team builds internal software to speed up workflows for another department, you're probably considered a cost center. The work you do isn't building out the bank's core offerings and doesn't directly drive revenue, so the value you create is either seen as more "indirect", or sometimes in more cynical terms, a necessary evil.
On the flip side, if you're part of a product team that's building out a new product that your company will sell, you'll be categorized as a profit center. Your team will be primarily recognized for your product and how it generates revenue for the company.
The benefits of making this distinction are two-fold: this immediately gets you thinking about the bigger picture, and it also sets you up for beginning to strategize how you can best provide value as a independent contributor.
To increase your value as a software developer, leave the developer cave every once in a while and think about how you and your team contribute to the bigger picture.
For cost centers, you're not directly tied to the money. But you're probably doing various things that are considered to be essential business functions - keeping systems up and running, increasing efficiency for other departments, and reducing overhead.
In this sense, think about how you can increase value in these areas. Can architectural decisions be made at the beginning of a new project to ensure future stability? Or can efficiency be increased if some performance tuning is done on a legacy application?
If you're part of a profit center, it's probably easier to gauge the value that you and your team provide. Everything revolves around your product or service, and if it solves user's problems to an extent that it generates revenue when coupled with the proper sales and marketing infrastructure.
To think about increasing this type of value from the role of a software developer, ask questions directly related to the revenue drivers that your team builds. How can you better understand what your users need? In a fast-paced product life cycle, how do you best serve those needs while also building systems that last? Can you help your PO identify "easy wins" where developer effort is low, but there are significant gains for your users?
As an aside, I know that classifying software development as a cost center vs. a profit center can be controversial. The line can appear a bit blurry sometimes, especially since technology is now a vital aspect of any company's success, in any industry. However, this doesn't take away from the exercise of identifying where your team provides the most value for your company. In general, thinking about the bigger picture will reveal areas where you can enhance that value.
Why You Should Scale Beyond Just Yourself
Even after recognizing the business impact that your department has, your impact as an individual contributor can still be somewhat limited. Since you're assigned a set of tasks and expected to execute on them, it's easy to keep the blinders on and only direct your focus to your immediate work queue.
Like mentioned earlier, this can lead many software developers to only think of increasing their value in terms of what they can do themselves. However, especially after your technical foundation is built, there's a much more powerful approach to increasing your value as a software developer than just that.
Since you've identified how your department provides value in the section above, scale down just one or two levels to your own team. How does your team, as a collective group, contribute to that value? And how could you help your team deliver more value?
Maybe developers could take the time to write cleaner code when timelines allow, or internal team processes and communication could be streamlined.
I'm sure you can think of a few areas where your team could improve. Identifying these problem areas, and then influencing your team to improve upon them, is how you can scale up your value beyond just yourself as a software developer.
Now, I use the word "influence" very deliberately here. Unless you're a manager or a team lead with explicit management responsibilities, it's likely that you can't just dictate changes to your team's workflow.
Instead, you have to pitch changes to your teammates in a way that demonstrates their positive impact. Think about a scenario in which handoffs between developers on your team and QA aren't clearly defined. Which of the two approaches below seems more likely to get a positive response?
- "You all need to improve your handoffs to QA"
- "I'm thinking that if we demo our user stories to QA before we mark them as 'Ready to Test', it'll smooth out the handoff process for all of us"
Obviously, the second will likely elicit a more positive response. This is because you've identified the problem, provided a solution, and communicated how it could benefit everyone - ALL while not blaming anyone for doing anything wrong.
Pretty smooth, huh? It's like communicating how everyone can have an easier time at work vs. directly telling them what to do, just because you said so.
As an added bonus, if these proposed changes become a reality and they truly do create a positive impact, you'll be more trusted by your team in the future when you pitch other changes.
Being on the lookout for improvements to make within (and beyond) your team will begin to establish your reputation as a leader.
You can try pitching changes externally, too. For example, if you're part of a Scrum shop, you could setup a quick chat with your Product Owner to see if the development team can provide better input regarding technical requirements for user stories.
Adjusting Your Attitude
When discussing improvements to be made both internally and externally, you'll need to ensure that you have a baseline of necessary soft skills.
Communicating both within your own team and externally with other teams requires lots of empathy, patience, and knowledge of how to properly articulate your ideas to different audiences.
In all cases, an important consideration is your overall communication tone - when suggesting improvements, it's important to keep the focus off the person/group you're talking to.
Just like in a code review, you'll likely get a negative reaction if you act like you're chastising someone for doing something wrong, or behave like you're superior to them. Instead, identify the area of improvement and keep the focus on the benefits that your solutions provide.
Pitching your ideas to different groups, with the right attitude, will increase your influence and enhance your understanding as a software developer.
Keeping an upbeat attitude is of the utmost importance as well, especially when discussing problem areas for team dynamics and processes. If you have an overly negative tone when you discuss these issues, you'll probably come off as a complainer.
Once again, remaining solutions-oriented is the key here. If you are open-minded in your communication style and continually focus on solutions to problems, whether they be technical or non-technical, your team and the teams you interface with will start to see you as a leader who looks out for them over time.
And to be clear, staying solutions-oriented doesn't mean completely brushing off issues in a robotic fashion. It's healthy to vent from time to time. But don't establish a reputation for it, and instead work on coming up with solutions to get past pain points.
By both continually improving your technical ability and leveraging soft skills to implement solutions to organizational problems and inefficiencies, you'll be providing value on two different levels as a software developer. Use these strategies wisely, and you'll become a more influential software developer and a better teammate.
That's it for this entry! As a sidenote, I've recently relocated from Chapel Hill, NC to the wonderful city of Austin, TX. After an intense work deadline coming up soon, I'll be establishing a more regular writing schedule here. There's loads more to cover on soft skills in software development.