Code is NOT the Most Important Output of Your Software Development Team… Here’s Why
The job title “software developer” could not be more straightforward. The output is software, or code, and, if this is your job title, you probably have the impression that you’re measured by the software you develop. However, that’s not entirely true. I’ve known lots of software developers throughout my career. I’ve hired hundreds of them. […]
The job title “software developer” could not be more straightforward. The output is software, or code, and, if this is your job title, you probably have the impression that you’re measured by the software you develop. However, that’s not entirely true.
I’ve known lots of software developers throughout my career. I’ve hired hundreds of them. And through our Exelaration program, we’ve helped create over a hundred more. The really good ones understand that code is merely a by-product of what they do best: collaborate and analyze. Great developers want to know why they’re building something; they have an instinctive need to understand the purpose of the challenge before putting on their headset and entering their coding zone.
So, if the code isn’t the most important factor, what is? Here’s one: full technology confidence. The most enduring and conspicuous output of a high-functioning software development team is a mentality that the organization has a firm grasp on how technology can solve its most daunting business problems (as well as which ones can’t be solved with technology).
Charles Kettering, GM’s famed head of engineering observed, “A problem well-stated is a problem half-solved.” Software development teams have the skills to define a problem better than anyone. That’s a huge reason why top software engineers aren’t eager to start coding. Moving forward before mapping the technology solution to a clearly defined business problem is a common path to failure. Top organizations are confident in their engineering teams to know they will easily deliver once they’ve accurately defined the problem itself.
Another key output of a software engineering team is a high regard for its testing approach. Testing is often seen as the rudimentary task of clicking each button and typing garbage in each field until it breaks the system. You hear this a lot: “let the new guy test our stuff.” In technology-confident organizations, testing means ensuring that the solution meets the clearly defined business challenge. A specific framework and pro-testing mentality are critical to high-functioning organizations, and this depends on both collaboration and empathy from its engineers.
A third critical output of top performing software engineering teams is teaching. Thriving tech organizations emphasize mentorship and advancement because these efforts produce a renewable pipeline of talent. They also form an effective antidote against attrition and poaching, two challenges that seek out low levels of tech confidence. Organizations that are confident in introducing and mentoring new tech members achieve this because their culture is highlighted by developers who see code as one small aspect of their output. One handy way to see how an organization scores in this area is by analyzing the interview questions asked of new engineer candidates. Questions that fixate on coding languages aren’t a good sign since languages can be learned and change rapidly. The focus should be on coachability, collaboration, and a healthy passion for technology as a tool to solve big problems.
Organizations that measure their development teams by how much code they produce is like measuring a restaurant by how many pounds of food it cranks out. And next time someone calls the software engineering team the “coding team,” see if they’d like it if you called their new Lexus a “cup holder.”
To see if Exelaration is a good fit for completing your software projects or creating your renewable tech talent pipeline, contact firstname.lastname@example.org.