TL;DR: Quit forcing developers to update their status in Jira.

Too often in organizations that are responsible for the delivery of software products or information systems, we optimize for the non-builders rather than the builders.

Who is a builder?

A builder is someone behind the keyboard who checks code into version control, that eventually makes it into the product or system.

This could be:

  • Front end developer
  • Back end developer
  • Infrastructure engineer
  • Documentation writer
  • Anyone who does git or svn commands
    • If you don’t use these commands regularly, you’re not a builder

When it comes to delivering software, those who write code that move bits around are the builders.

Who is not a builder?

Non-builders are those involved in a software project, but not making commits to version control.

Typically these are:

  • Project managers
  • Product owners
  • Q/A engineers
  • Testers

The non-builders are important roles in the project. I’m not trying to minimize those roles.

They exist to guide and support the builders.

They provide direction and feedback for the builders.

However in the grand scheme of the project, the non-builder roles are enabling roles. They exist to help the builders produce.

Non-builders are important roles, but not the most important.

Well, I’m not sure I agree…

Imagine you’re in the middle of a software project, and you have a deadline for a new feature.

Would you rather:

  • All the builders quit
  • All the non-builders quit

In which scenario does your team have any hope of making this deadline?

You can have the most effective Project Manager who can bend Jira to their will, organize tickets effectively, and map out a project 50 sprints out.

But if there are no builders to implement those Jira tickets, you produce nothing.

How are we not optimizing for the builder?

Project managers love Jira. Non-technical product owners love Jira too.

Jira is a fantastic tool for software projects. Non-builders live in Jira.

What about the builders?

Builders, on the other hand, live in their version control tool. If they don’t they should.

I’m going to use Github as the example, but you can substitute Github with GitLab, AWS CodeCommit, or whatever SVN tool you’re using.

Github is the source of truth for the software project.

The builders spend their day writing code, and commiting to Github.

Github has features like Issues, Pull Requests, Project boards, Wikis, etc.

These features make it so easy for builders to link the commits/PRs they’re making to relevant issues.

These features exist, but too often the builders are asked to do their work, then spend their time updating a Jira ticket using language the non-builder can understand, so that the non-builder can provide status updates up the hierarchy.

When this happens, the builders function as an enabling role for the Project manager, rather than the Project manager working to enable their team of builders to be effective, and actually build.

Any time spent by builders not building, is time wasted.

Also, builders want to build! That’s why they took the job!

Every time a non-technical PM asks me my status, I want to answer “I have 2 Pull Requests in that have passed all status checks, and waiting for the tech lead to review and merge”.

When I do answer that way, I’m often greeted with a blank stare and asked “Can you just write a quick status update on the Jira ticket?”.

Which requires me to stop what I’m doing, and dumb down the code changes I’ve made into language the PM can understand, and update a Jira ticket.

What are you suggesting?

The non-builders involved in a software project need to take their roles as enablers seriously.

Learn your way around Github. See what the team is doing. Watch how amazing Github is with enabling builders to collaborate around code.

Orient your tools and processes around enabling the builders to be successful.

Don’t ask the team to double document their work so that it’s easier for you to load a Jira dashboard and present to upper management.

Awesome. Do that. But the non-builders should click those links to observe the source of truth on what has actually been done.

But I’m not technical! I don’t understand what’s happening in the git commits!

Non-builders don’t need to be technical.

Builders can write thoughtful commit messages, be descriptive when logging issues in Github, and be clear what is happening in a Pull Request.

The non-builders need to hold the builders accountable for doing these things.

Still don’t believe me?

Look at some of the more popular open source projects out there. React, Ansible, or Tensorflow for example.

Thousands of people contribute to those projects (all used by Fortue 500 companies), and they somehow do it without Jira tickets! Amazing!

Conclusion

If your organization is responsible for delivering software, optimize your practices/policies/procedures around what helps the builders build most efficiently and effectively.