Being non-billable
Tags: career, leadership, innovation, agile
Published: 2020-05-19 10:03:00

# How software houses make money?

If we would have to split all of the software companies in the world, then we might use two groups: product and services. As technology became a business just as the [DevOps Culture](https://martinfowler.com/bliki/DevOpsCulture.html) explains, there are more models of IT companies, but let's flatten it for now.

In the case of software houses, customers come to us and ask to develop a specific project to be later run in the production environment. By doing so, we provide the __services__ of software development.

> I use the word _development_ in the meaning of developing something. Not just coding, but also designing, testing, analyzing. 

# Time & Materials

When providing the services, we use [Time&Materials](https://en.wikipedia.org/wiki/Time_and_materials) agreement in most of the cases (at least in 2020). Customers pay us for every single hour that we spend working on the project and for materials used within' that cooperation. By materials, we usually mean business trips, accommodation, fuel, licenses, etc. 

It is backed up by some time tracking systems such as Toggl, Avaza, Harvest, or Jira. A project manager is verifying every minute the software developer fills in the time tracking system, and then the invoice is being issued.

# The goal of developers

The following scenario creates a specific mindset in software developers and splits them into two groups - people who work on billable projects and those who do not. Comparing that to the fact how most of the projects are being delivered, we might think that we all want to become [cogs in the machine](https://idioms.thefreedictionary.com/cog+in+a+machine) to produce the working solution. In most cases, we want to get the office (or a desk, which is 2 meters from our bed), start the computer, do a daily, deliver Jira tickets, leave the office. 

The ability to work in a billable project provides a [psychologically safe](https://rework.withgoogle.com/guides/understanding-team-effectiveness/steps/foster-psychological-safety/) environment and stable work conditions. 

In Poland, some say that our parents 30 years ago wanted to feel safe at work, so they were spending like 20-40 years in the same job. Now, we change jobs every 1-5 years. However, we can do that because this way, we are getting the same psychological comfort, which our parents were getting back then. We change the job because it is quite easy. And then we start pushing Jira tickets again and again.

The goal of software developers is - psychological safety. It is also a foundation for building high performing teams. However, it is something dedicated not only to high performance but for every human who wants to live a good life.

# Being billable makes you a better human

By splitting all the people within' the software house into two groups, we are all guilty of creating that invisible line between them. The ones who achieved the "goal" feel better than the ones who did not. 

Some people call the second group non-billables, internals, internal project members, etc. In some cases, especially in COVID-19 times, some of these people may feel stressed due to potential layoffs.

# Power of engineers

In my previous article, [Your seniority is a lie](https://rmakara.github.io/Your-seniority-is-a-lie); I mentioned the following quote:

> If you're just using your engineers to code, you're only getting about half their value.
> 
> – Marty Cagan

The biggest tech companies in the world are being driven by continuous innovation. And as usual, most of the potentially innovative projects fail, just like most startups fail. Working in such internal initiatives is like running a startup but in safe psychological conditions.

When we, developers, work on a project to deliver a specific set of features, then we are like machines. Quite often, we do not care about raising the value, testing faster, being more innovative. We deliver the next tasks. How could that change if we would start thinking about solving the problems - just like we like to speak about us: _problem solvers_ - instead of rising velocity? It is especially hard in software houses/service companies, where we are expected to deliver feature by feature to get our clients satisfied.

In the manufacturing industry, we might raise the assembly line's speed to produce more goods. At some point, the quality will go down. Some bottlenecks will arise. Some areas in the factory will be more productive when the other ones are not. At some point, we will start applying Toyota principles. Use Kanban and cycle times for assembly lines synchronization. And so on. If something crashes, we will use [Andon](https://en.wikipedia.org/wiki/Andon_(manufacturing)), [Jidoka](https://en.wikipedia.org/wiki/Autonomation), [Poka-yoke](https://en.wikipedia.org/wiki/Poka-yoke) practices, which lead to stopping the production line when the big problem occurs. Then take a deep breath, fix the root cause and improve our productivity and quality in the long term. 

In software development, scrum masters are supposed to be our out-of-the-battle observators, which are being able to raise an Andon style alert and let the whole team know what is going on.

When to take a breath in a software house?

# Non-billability as a rocket fuel of creativity

The moment for innovation in software houses is - being non-billable. This moment is the best opportunity for creating new solutions within' the company, that will lead to the higher goods of all employees. You may create a new product, a new tool, try a new language, do some proof of concept and share it with the others. Do not be afraid to throw your work to the trash and discover more. Just learn to verify your ideas and then iterate quickly.

Once you get one of the ideas right, your colleagues might spot it and help to grow it into a multi-million business. 

It is how one of the products of my current employer was born. I was not involved in the process of its creation, but my colleague [Filip](https://www.linkedin.com/in/filip-rakowski-a43671129) and my boss [Piotr](https://www.linkedin.com/in/piotrkarwatka/) were. Hats off, guys. It has all started by two people who were non-billable in the software house. Now it is a 56 people big team. 

Consider thinking about your non-billability as an opportunity, not a penalty. 

Just to warn you - this process is way harder than just being billable.

* * *

#### Resources

*   \[1\] [DevOps Culture, Martin Fowler](https://martinfowler.com/bliki/DevOpsCulture.html)
*   \[2\] [Time&Materials](https://en.wikipedia.org/wiki/Time_and_materials)
*   \[3\] [Psychical safety, re:Work with Google](https://rework.withgoogle.com/guides/understanding-team-effectiveness/steps/foster-psychological-safety/)
*   \[4\] [Andon, Wikipedia](https://en.wikipedia.org/wiki/Andon_(manufacturing))
*   \[5\] [Jidoka, Wikipedia](https://en.wikipedia.org/wiki/Autonomation)
*   \[6\] [Poka-yoke, Wikipedia](https://en.wikipedia.org/wiki/Poka-yoke)
*   \[7\] [Cog in the machine, The Free Dictionary](https://idioms.thefreedictionary.com/cog+in+a+machine)