Less Process, Better Software

The team structure

At Pikker, there are no analysts nor project managers.

Every employee is a software engineer who talks directly with the customer. Cutting out the layers between customer and code means requirements don't get reinterpreted on their way to the people building the product.

The customer is a part of the team

The customer isn't someone we check in with, they're part of the build.

We combine engineering discipline with the customer's business knowledge to deliver the best software possible. The truth about problems often arises in discussions.

Ownership

The person building the software is also responsible for understanding why it needs to be built.

Instead of a handoff from customer to analyst, from analyst to project manager, and finally to developer, the same engineer who discusses a problem with the customer also designs and implements the solution. This gives engineers the context to make decisions themselves, instead of waiting for someone else to translate requirements or approve every detail.

Keeping the feedback loop short

The key to great software is a short feedback loop.

Pikker engineers merge features as soon as they're working and tested, so code ships frequently and customers can try things while they're still fresh. This allows the feedback to arrive as fast as possible and for the team to iterate on ideas fast. Instead of discovering a misunderstanding three sprints later, we catch it in days.

Development disciplines

In development, we value speed and simplicity above all else.

Large IT companies tend to move slowly — partly because they have many people and layers of management, but the development process itself also tends to be slower.

To keep development fast, everyone's changes are always kept together in the main branch, without blocking code reviews. Reviews that block merging slow development down, while keeping changes together means the whole team can see the project's current state immediately. For the same reason, the team doesn't hold daily internal meetings — everyone can already see what others are working on.

Questions or problems are discussed immediately, before a solution is implemented, which makes it possible to find the best approach before time is spent building it.

Speed matters not only in the development process itself, but also in the software being built — the goal is software that is fast and reliable. Since most software is more complex than it needs to be, code and solutions are kept as simple as possible: readable and clear enough that any developer can work with the codebase and modify it.

No vendor lock-in

We never lock our customers in.

Our software is built using standard technologies and can be maintained and extended by other developers. Customers own their data and their code, and we avoid proprietary technologies that would make switching to another team difficult.