Who is a 'Developer'?

The definition

💻A team member who got the right technical skills to do the implementation work is also known as a software developer, programmer, coder, or software engineer. Developers write code, test, debug and maintain applications.

This is the simple, ‘by the book’ definition of a developer. But, I am here to tell you that they go way beyond this definition.

The misconception

• A common, yet fatal mistake that most product people make is their belief that developers are techies who are programmed to do what is asked of them. Let me tell you something - they are not, and they shouldn't be.

In fact,

👉"If you are using your developers only to code, you are getting only half their value."

The rest of this article will serve you with facts and reasons to support this argument.

Let’s take a step back into how a product/feature typically comes to life.

• In most company environments, someone who has assumed product ownership is responsible to get an end-user problem or a viable opportunity into a product backlog or a requirement set, which then gets passed on to the development team.

• Every requirement comes down from an idea, an opportunity, or a problem to which a solution has already been decided upon by the product team.

• For product personnel to bring a set of requirements/user stories to a ready-to-develop state takes a lot of thought and time. Most often, they formulate the solution to the problem. This is not easy work. Critical thinking, analytical capabilities and so much more plays an integral role in the process.

• Once this phase is over and done with, the product person sends out these artefacts to the development team, explains it, gets an estimate, tweaks a couple of things based on what they say is feasible and not - and finally expects the team to get it done and deployed.

Now during the ideation process where the product person chronicles a solution, they may talk to other product owners, business analysts, and data analysts.
However, most often developers are overlooked and are not included in this solution-making process. 

They are brought a bit too late into the picture - when the problem is a documented solution.

What you may fail to process, is the fact that a developer possesses a mind of their own and comes with a vast experience in not only technical aspects but also on product aspects. Never underestimate the power of their knowledge.

Now if you are thinking - No, no. Before we fixate on a solution, we check up on the technical feasibility with our dev leads. Again, this means that you are presenting the developers with solutions A, B, and C, and asking them to pick one. Yes - you give them a chance to negotiate a bit, but that’s it.

This is still not the ideal way to yield their input and creativity.

Instead, what you should do is co-create and co-elevate the solutions to the problem with the entire team.

If you are thinking - developers got plenty of other work to focus on - it is our duty to formulate the solution and if we involve the tech team in this process, it is counterproductive - you are incorrect.
There is a fine balance that exists - which takes some practice to master.

While the product owner or the business analyst is the person responsible for the product backlog and getting things ready for development, in agile principles, it is a best practice to include the technical team in the elaboration process.
In every elaboration meeting, it is integral to have someone representing - 

•  The VoC (Voice of the Customer)
• This person should be the product owner or a subject matter expert (SME) depending on the circumstance.
• The technical side of things
• Good understanding of the current system, quality aspects, and user experience side of things depending on the situation.
• This could be a quality assurance engineer or a UI/UX engineer.  

So where does the balance exist?

In a strong team, product, design, quality, and engineering teams all work together to design and build solutions that customers LOVE and use it because it solves a real problem and they really want to use them to make their life easier.
Make it a habit to factor in a few couple hours a week from a developer’s time to have discussions with you about these problems/features or challenges. Get their ideas, elaborate on them and put together a solution.
However, there is no right or wrong answer to this. You got to do what works best for your company and team.

Some tips to keep in mind

Choosing the right development team also plays an integral part. Along with the skill, the ethics, choose a team of missionaries. Not mercenaries. “Mercenaries build whatever they’re told to build. Missionaries are true believers in the vision and are committed to solving problems”.

Also, flat structures work best with cross-functional teams who know how to do their job and do it right. Micromanagement is a productivity + mood killer. In other words, what I’m trying to say here is that - there should be no people manager.

Even when you do have a lead, ensure that they are a servant leader who focuses on growth, facilitates productivity, and does not try to rule over. Trust your team to get the job done.