Scratch the Backlog – There is a better way to plan your work
Long backlogs do not give you the overview and clarity you hope for. Instead they lead to false hopes and set you up for disappointment and wasted time.
From two manual monolithic deployments a week to 15+ automated deployments a day
We did it. Roughly two years after I joined BRYTER and one year after we started the developer experience team, we finally ended the era of manual deployments for roughly 15 teams.
What Developer Experience Engineers can learn from User Experience Engineers
Developer experience engineering is a pretty new discipline. However, there are numerous parallels to user experience engineering. Therefore, DX engineers can learn from the teachings of UX engineering.
DRY – DO repeat yourself
DRY is one of the most misunderstood and abused principles. Copy more, reuse less!
Interaction modes of a developer experience team
As a developer experience team, we are often working in a platform mode but are constantly shifting into enabling mode for better results.
Shaping developer experience teams for autonomy
Once you have decided, that a developer experience team would provide value to your organisation, the question is, how such a team should be set up, how it should be shaped, and how it should interact with other teams.
Why a developer experience team can help your company
Great developer experience is directly linked to great developer productivity and an important factor for company success. This article starts to answer the question how great developer experience can be achieved.
Why companies should care about great developer experience
Companies might fall into the trap to believe that developer experience is a nice-to-have luxury rather than a necessity. However, this is not the case. High developer productivity results from a great developer experience and thus, the companies' success ultimately relies on this.
Should we focus on developer experience or developer productivity?
When talking about developer experience, there are a couple of other names thrown into the conversation that all kind-of mean the same, but IMHO have a slightly different touch / focus and can be perceived quite differently.
Code ownership conflicts as a signal for structural mismatch
Code ownership on a team-level can not only help to identify the team that has knowledge in a certain area, it also can serve as a signal for a mismatch between architecture and team structures.
Code Ownership: Keeping the balance between structure and agility
Code ownership is an important topic when it comes to enabling your teams and allowing developers to improve the system while keeping the overhead of changes low. While today, most companies would (hopefully) agree, that individual code ownership is bad because it creates knowledge silos and makes the organisation dependent on individuals, code ownership still is essential on a larger scale.
A platform team for next-level developer experience
Developer experience is a crucial topic which affects all development teams of a company. Therefore, it can be beneficial to introduce a team that has as their only mission to improve developer experience and productivity as these improvements multiply the impact of the other teams.
Remote can be synchronous, too!
Whether a team works synchronous or asynchronous is not determined by whether it is co-located or not. Both teams have to make an effort, if they want their work to be synchronous.
OKRs are NOT guaranteed deliveries
Objectives and key results are a great tool for collaborative goal-setting and for aligned on a company-wide direction. Problems start, when teams start to rely on other teams OKRs to be finished in time.
Blameless Post-Mortems: Incidents are a learning opportunity
Blameless post-mortems are an effective tool to facilitate learning from failures, to share knowledge and to significantly improve the entire system, including software, infrastructure, and processes.
Bonuses are bad – change my mind
Bonuses shift an employee's interest from the long-term success of the company to the achievement of a short-term goal. By introducing bonuses, you are incentivising the achievement of goals, that should not need any incentives, if they were the right goals to begin with.
Why teams need slack – not the tool
Keeping people 100% busy will prevent them from innovating and improving. Therefore, teams should have slack that enables the to learn, adapt and improve.
Focus Week Case Study: Bringing E2E Tests into the CI Pipeline
In this article I will share details about our last focus week and how it led to a breakthrough on a difficult topic.
Focus Weeks: How to collaboratively crack difficult problems with joy
Focus weeks are a tool for cracking difficult or complex topics as a team while fostering team collaboration and improving team culture.
There is no system like production: Why you should test in production
If you do not test in production, your customers are the only ones, who do. While it sounds scary at first, testing in production is an important addition to pre-production quality assurance processes.