Developer 2.0 - Redefine the Role of Developer to achieve Success for All

Can we bring phenomenal changes by doing small changes in the mindset of developers in the organization?

Gone are the days where the developer was responsible for just writing clean code. The traditional definition of developer affects the individual developers more than it affects the organization. The developer tends to concentrate on getting better at just the area of coding and ends up not learning the nuances of building a successful product.

As a Developer 2.0, the developer performs all of the following roles. 

1. Coder 

2. Devil's advocate 

3. Code Reviewer 

A developer can work in multiple stories but cannot do more than one of the above tasks for the same story. For example, the same person cannot be both the coder and Devil's advocate. A team at Gainsight worked with this improved definition of developers and saw higher product velocity, better awareness about product and increased responsiveness to issues. This session will take the audience through the improved definition of the role of developer and present some thought-provoking questions to the audience to make them realize that the traditional definition of role of developer is just not enough.

The audience will work through some activities for two sprints and see the difference for themselves.


Outline/Structure of the Tutorial

  1. Introduction - 5 min
  2. How do we develop software usually? - 5 min
  3. Sprint 1- 20 min (Work in teams using traditional definition of the term 'Developer')
  4. Can we redefine the term 'Developer' to do better? - 10 min
  5. Sprint 2 - 20 min (Work in teams using improved definition of the term 'Developer')
  6. What are the benefits to
    1. Developers? - 3 min
    2. QA Engineers? - 3 min
    3. The organization? - 3 min
  7. Pre-requisites to try Developer 2.0 in your organization - 5 min
  8. Perceived roadblocks to adoption of Developer 2.0 - 3 min
  9. Tips to address roadblocks to adoption of Developer 2.0 - 4 min
  10. Some Interesting Observations during implementation - 4 min
  11. Questions & Answers - 5 min

Learning Outcome

Audience will leave the session with

  1. An understanding that "Great powers come from small changes"
  2. What is collective ownership?
  3. Some new development process to try at their own organization
  4. Hands-on experience of the philosophy of Developer 2.0

Target Audience

Scrum Master, Developers, Team Leads, Organization Leaders, Managers

schedule Submitted 4 years ago

Public Feedback

comment Suggest improvements to the Speaker
  • Venkatraman L
    By Venkatraman L  ~  4 years ago
    reply Reply

    Dear Vivek,

    "The audience will work through some activities for two sprints and see the difference for themselves."

    Can you please throw some light on the kind of activities (sprint activities) you have in mind for the participants. Given that we have "Developer" focused activities, and it is a conference, are you expecting them to do some hands-on play using paper, lego, etc and then move on to being dev 2.0 being the devil's advocate and reviewer ? any one example would be great. 

    • Vivek Ganesan
      By Vivek Ganesan  ~  3 years ago
      reply Reply

      Hi Venkat,

      The activity that I am planning is user stories in the form of Practical Geometry exercises.

      For example, each team will be provided with 5 practical geometry exercises and their challenge is to complete as many stories as possible, with some people acting as Dev, QA, etc.

      Please let me know if this answers your question.

      Thank you.

  • Srinath Chandrasekharan
    By Srinath Chandrasekharan  ~  4 years ago
    reply Reply


    In addition to the exercises would there be any specific examples of how and by how much it has improved the velocity . Another iteresting aspect to see if this increased velcity impacted the quality of the code ( defects etc). Would you be covering this ?




    • Vivek Ganesan
      By Vivek Ganesan  ~  3 years ago
      reply Reply

      I will be more than happy to present the results as I have already started collecting data from the team that started this approach.


      By the time of the conference, I will have a paper written on this positively.

  • Naresh Jain
    By Naresh Jain  ~  4 years ago
    reply Reply

    Hi Vivek,

    Can you please help me understand the difference between Developer 1.0 and Developer 2.0? 

    These days I hear the term full-stack developer. How is this different from Developer 2.0?

    Also you are suggesting that: As a Developer 2.0, the developer performs all of the following roles. 1. Coder 2. Devil's advocate 3. Code Reviewer

    That's it? What about Collaboration with other stakeholders? Problem Solving? Evolutionary design? Performance Optimization? Monitoring? etc.

    • Vivek Ganesan
      By Vivek Ganesan  ~  3 years ago
      reply Reply

      Hi Naresh,

      Developer 1.0 and Developer 2.0 differ in their mindsets about what they are responsible for.  Developer 1.0 thinks that he/she owns design and development of the user stories.  Developer 2.0 thinks that he/she owns design, development and Quality certification of the user stories that the team owns.  For a story, he/she may be coder and for another, he/she might be a Devil's advocate.

      To answer your second question, full stack developer is different from Developer 2.0 in the following aspects:

      1. Full stack developer develops solutions and writes programs that sit in server side, UI and database but not necessarily contributes to the Testing, test design, code review etc.  Developer 2.0 need not code in multiple languages but contributes in coding, testing, test design, etc.  
      2. Full stack developer owns the technical implementation but the role definition does not force him/her to understand how user will use the software that he builds.  Developer 2.0 forces the user perspective on him/her.
      3. Full stack developer owns the design and coding of the solution for a user story.  Developer 2.0 owns the design, coding and quality control.  It's just that he/she owns different aspects for different user stories of the team.

      Regarding your third question of who owns the other functions, I used the word coder for lack of a better term since Developer is a name given to Dev+QA under Agile methodologies.  I am happy to rephrase that to Solution Developer if that is ok.  Solution Developer takes care of all parts of development for a thinly sliced user story.  Code reviewer will review code keeping in mind the performance in consideration.

      Also, our organization has already started seeing a 'services' role, played by one person each sprint on a rotation basis.  So, the new structure that we now follow is :

      Product Roles:

      1. Solution Developer

      2. Devil's Advocate

      3. Code Reviewer


      Service Role:

      1. Service Rep


      I agree that this number of roles will only grow as we encounter more challenges in our work life.  But, this has made us realize this is better than what we were practising before.

      Please let me know if you have any questions.

      • Ellen Grove
        By Ellen Grove  ~  4 years ago
        reply Reply

        Hi Vivek

        Will you be sharing the story of your organization's experiences with this approach through the workshop?  Your comment to Naresh indicates that this workshop is based on work that is going on in your org - I think that people would be very interested in hearing about that alongside running through the exercises.




        • Vivek Ganesan
          By Vivek Ganesan  ~  3 years ago
          reply Reply

          Hi Ellen,

          Thank you for the suggestion.  I just now updated the outline/structure of the session to include an additional topic "Some interesting observations during implementation".

          I have already started collecting data and will be able to share some of the moments from our experience.