Reducing the commoditization perception in software development
There’s a wide range of services available in the market when a company requires software assistance. The majority of the conversations involved, happen in a technical context with decision-makers oriented towards controlling both the resources and the software development process. Since they are technical themselves, my main understanding is that these leaders want to conduct all efforts from all people and resources involved the way they think it should be done—either good or wrong.
The software services industry has always been considered a consulting industry. From the inception of any business or a hip Development Shop in this field, the easiest and intuitive way to deliver a proposal or a quote to a new potential customer is calculating the N total amount of hours the company will spend (more abstract conversations will blend this in terms of iterations, sprints or points, whatever the unit) times a rate according to the market-offering, depending on the region, tight to living costs, operational expenses, socioeconomic context; economies of scale in the end.
[Formula] N hours * People Involved * Rate = Investment
Now, the conversation can transcend into a more detailed explanation of how the cost is distributed, and even more, what type of roles are you involving, excluding any relevance in process and practices the team itself is following, along with the culture fostered in the software services company. Again, the type of decision-maker is a controller.
This approach will push conversations into a more resource and costs type of dialogue, where the decision-maker will seek to control every aspect related to cost, whether it is to reduce the investment in onboarding people, acquiring horsepower, or hiring the unicorn every company is looking for. Typically, this figure reports directly to the CFO, CEO and might be excluded from strategic conversations like board meetings or sessions where budget distribution and its allocation are talked.
The problem with the accumulation of those conversations and the way permeate in other industries and alien roles to the technological context are that nowadays everyone feels they can hire a software engineer, or better said, a developer. The perception makes a commoditization of the resource, its capacity, and overall talent access, granting everyone can easily hire an engineer. Many people have manually hired developers, with no formal process or know-how about assessing technical and engineering skills, and a bunch of unqualified businesses for this task (ironically HR firms for instance) have emerged with a core competency in hiring just technical roles, or many adventurers with some dollars have searched and luckily found one (random developer on a bench) via elance.com or upwork.com, or any other similar platform. Attributes such as rate per hour, location, previous projects, are among the typical factors a “purchaser” will have upfront to decide whether to go or not. Now, this doesn’t mean that a particular developer will align with your company values, with your particular needs or that s/he will have the capacity to manage the complexity of the current platform and team dynamics in order to demonstrate the efficiency and succeed.
There’s a misunderstanding of what software development as a process and discipline requires. More than an engineering approach, it is a creative and problem-solving process, where particular characteristics should exist. When collaboration between additional engineers and different disciplines is demanded, it becomes almost an art, where just time will help to grasp the technique, demonstrate its potential with facts and outcomes, and make it worth. When I use the word ‘art’, I am referring to Oxford’s definition:
Art (noun) — /ärt/ /ɑrt: “A skill at doing a specified thing, typically one acquired through practice.”
Anyone can hire a software developer of any level. Computer Science has evolved for the last decades in a way without precedent, still being a young discipline, but being introduced in all universities in every country due to the economic growth the Internet has provided, and new sources for educational support to anyone seeking to join the party. However, this not necessarily means that a solo developer is ready to build a production platform, with the right architecture and aligned with the expected outcomes to achieve business objectives. There’s a big gap in terms of complementary skills, experience and communication capabilities that will make an engineer specialized enough to be part of those exceptional professionals assembling real world-class teams. Additionally, the process they can perform should be flexible and adaptable, according to the different roles involved in a software development journey: Designers, Managers, Users, any type of stakeholder. The entire process becomes a source of valuable knowledge, a differentiator, an art, hardly replicable with some articles and a couple of weeks of online training.
Software developers might start feeling like a commodity in the market. The software development process and discipline are just in its baby steps though, and the industry is just realizing how to improve and efficiently build software solutions to current problems. Finding an engineer: anyone can do that. Hiring the right engineer: not an easy one. Assembling the right team to perform the right process to build the right solution, right: an art.
To my initial point, this is one of the reasons many organizations remain in the conversation along the lines of resource allocation, augmentation, and rates per hour. If the conversation could be led by an empathic role, translated to a value-driven context, where the responsible understands the entire process of acquiring, hiring, assembling and motivating those specialized engineers, the perception of value would be completely different. Having that decision-maker within the Board of Directors, it won’t matter the role; we could expect a conversation more along the lines of ROI, value, and outcomes aligned with the business goals. My bet would be that the software discipline could become more productive and efficient.
The software engineer profession is evolving towards a more specialized role covering a wider range of skills. It is not enough to just know a specific programming language with some years of experience. We are hearing more about the full-stack coverage, jumping into more technical tasks starting on front-end, back-end, developer operations, databases, security and scalability to mention a few. But we are seeing an emerging trend where engineers engage themselves at the beginning of the business strategy, translating those intentions into a feasible and functional reality to continuously align the promise of delivering an impactful software piece. Even more, these engineers are autonomous in the way they make decisions for the best of the organization and the team.
The best archetype of this emerging role is the technical co-founder at a tech startup. Think about the Collision brothers at Stripe. I have always seen hacker-entrepreneurs as a great example to see highly motivated developers performing this type of specialization, jumping into the different activities of the business they are building—from sales, operations, marketing, product development. They introduce and take valuable information from all business angles adding value to each other and building the right product that will make a profitable business.
Hiring software engineers is not a commodity—the opposite is a fallacy. We need to evolve in our mindset and work with people, not just for their technical skills, but complementary capabilities and the outcomes they can produce. Taking into account the specialization of the potential engineer to be hired is critical. Do you have a team ready to support and accelerate those engineers? Is there going to be any available infrastructure to guide the new hires and allow them to succeed? Why do we need engineers in the first place? How did we come to that conclusion? Who is going to manage them? Answering these and more questions is going to be relevant when hiring an engineer, a software partner or simply defining what to do next.
