Senior Agile Delivery Coordinator Darya Voitava, Principal Java Engineer Alex Nozdryn-Platnitski and Principal.NET Engineer Dima Viaroukin have been part of Godel software delivery engagements with clients from a diverse mix of cultural settings. As such, they have broad perspectives on how different team cultures influence software delivery, and how these cultures can practically be changed for the better.
In this case, we are dissecting the build run own cultural concept. At Godel, teams striving for a product-led approach to software delivery have often found that this cultural model helps product from numerous points of view in the long-term. Here are Darya, Alex and Dima’s views on how and why to foster a build run own culture in software delivery teams.
What is build run own culture all about?
Darya: Build run own culture is a way of supporting a product mindset. It helps teams better understand the product they are responsible for developing and keeps them focused on the product’s value to end-users rather than just its features in isolation.
Dima: It’s when a team starts with a product vision and sees it through all the way to delivery. Along the way, they have all the resources necessary to make this work. It can be proven when teams feel comfortable to put forward new ideas and ask questions without any internal obstructions.
Alex: With BRO culture, every team member has great power, but also great responsibility…
How can this help teams and their businesses?
Dima: If a team is going to take full ownership of a product, they need to be shipshape in how they work together. As a software engineer, I should know exactly who in my team can guide me, support me and help me get a task done — and I should be able to work with them rather than just passing the ball. Build run own culture naturally encourages listening and communication, because it is now necessary for the product’s health. I know from my teams that this is appreciated, so it helps with morale.
Darya: A major advantage is flexibility through ownership of processes. The product team knows their product best and can take the helm to navigate delivery without asking permissions from people outside their team. That’s empowering. It also means things can simply be done faster, which provides advantages from a competitive point of view.
On the other side, the responsibility is ramped up a lot in this cultural approach. That’s just as empowering for teams — knowing that their work decides the success of their product. I think that can have an impact on software quality, too — generally, the whole team is much closer to testing processes in this type of culture and so quality is not swept under the rug.
Alex: When teams understand their product very well — not just its technical features but its values and principles — they are considering its success all the time. Ownership helps integrate delivery into business success rather than seeing requests «thrown over the fence» and having them come back with parts of the product vision missing. Knowing all about business strategy helps build longevity and resilience into the engineering principles as a factor for product success.
What should teams consider before transitioning to a build run own culture?
Alex: If a team comes from a background culture of waterfall delivery, or one with lots of interdependencies between departments, it will take a considerable shift in mindset. The mindset of delivering features in isolation of a wider product vision — «give me a ticket, and I’ll get it done» — is not led by overall product responsibility.
It isn’t a true build run own approach if somebody outside the team always checks pull requests and doesn’t allow the team to set the product’s direction. This can be hard to transition to but realising the power of autonomy can mean a much faster time to market with a product that’s more in-tune with end-user needs.
Dima: Exactly — a build run own culture is one where people don’t have to ask — they just do. There’s a big difference between «Can I work on this feature?» and, «I’m going to work on this feature, what does everyone think?». This confidence comes from deep knowledge of the product.
To create this culture, we’re aiming to have teams be autonomous, which means freeing them from external obstructions without removing them from stakeholder influence and the business values.
Darya: If the team haven’t already adopted this mindset, they need to be sold on it. If it’s going to work, the advantages to change need to be proven, and the disadvantages need to be identified and explained, too.
Things aren’t always perfectly in place from the beginning. Teams — both on the Godel and client side — are on a constant journey when it comes to a true product mindset. In the first stages of many partnerships where there is a product to be developed, we need to sell the BRO culture principles to the client’s leadership team.
It sometimes takes breaking down barriers between departments and introducing the concept of cross-functionality. Like if an engineer hands over code to a QA engineer, who then hands it over to a DevOps engineer, who releases it into production. The first engineer can’t see the full impact their code has on the product. By building teams in a cross-functional model, for example, a SCRUM setup, we can start moving everybody toward a product mindset.
What are the magic ingredients that make build run own culture work?
Dima: When a team owns a product, they shouldn’t think just about what needs to be out of the door next week. True product mindset builds resilience in products and their support. That means looking at product development from all kinds of perspectives.
One of our clients was a global credit management company. We needed to redevelop and migrate three of their platforms to the cloud. In doing this, we realised that security considerations played an even bigger role in feature considerations than was initially scoped. By adding our consideration to the wider scope, we ensured resiliency in the long run. The client was open to our guidance because they had given us ownership, which in turn gave them better results quickly.
Alex: Trust is at the top of the list. The problem with software engineering is that things go wrong. Sometimes, it’s worrying if everything is going too well. When teams are trying to take ownership of product delivery, each participant needs to be confident that if they make a mistake, they won’t be blamed or punished. If that isn’t the case, the team will be reticent towards taking risks and adding value in the future, and they won’t be confident in taking responsibility for their product.
Instead of placing blame, teams should always look at an issue and pick apart why it happened from a place of wanting to improve. No-blame culture is what sets the foundation for continuous improvement.
Darya: I also think that teams need to be coached in all these things for the build run own culture to take root properly. It doesn’t just happen naturally. Teams change, and new members must be integrated properly into the culture. The team’s technical maturity has to be fostered, but the soft skills around product mindset are all just as important. From a practical standpoint, ways to achieve this are hosting regular product reviews, sharing performance updates from the business level and constantly encouraging individuals to ask questions, no matter what the question is.
In our teams, we host 121s between people at all levels — engineer and tech lead, tech lead and Agile Delivery Co-ordinator, engineer and ADC, etc. We want to do everything possible to encourage the confidence to innovate. That means, like Dima said, we need to ensure everyone is being listened to.
More great techniques are innovation days where team members are free to work on personal projects, hosting open tech meetups and events and trying out development practices like mobbing and swarming. All these approaches help teams think differently and gain confidence, which can be applied to their product.
How does technology play a role in build run own culture?
Dima: Usually, teams aren’t reaching their full potential of release cycle speed. When engineers are coming from a background that didn’t prioritise continuous delivery, they can often question the sense of releasing as little and often as possible. I think the waterfall team structure that Darya explained can be the culprit for slower releases, where the code is passed from person to person.
So cross-functionality of teams should be considered from a technical point of view. Having a single branch for a product, testing features immediately, continuous deployment are changes that take place in engineering as well as cultural practices. You can read more about the technology shifts and why they help businesses in my article with Jorge Garcia de Bustos.
Alex: Yes, CI/CD is major — it also helps teams resolve issues much faster. As I mentioned before, that encourages a lot more positivity around mistakes, which sparks innovation.
Darya: Our teams find logging and monitoring so valuable in supporting their autonomy. We have huge screens in our offices that show product health and a lot of other KPIs. It enforces that sense of ownership to see real business KPIs being affected by the performance of code released that same day.
Which skills should someone develop to be able to work this way?
Darya: For somebody joining a team like this for the first time, it’s all about learning — a willingness to be open-minded. That’s far more important than having all the skills and experiences in place from scratch.
There is a concept of the «T-shaped person» — someone who has a specialism, but also a broader horizontal range of skills that support their wider business function. For a cross-functional team, this can be perfect. Being an «I-shaped» specialist certainly has advantages, but it can be limiting when it comes to product mindset.
Dima: In interviews, I like to ask candidates how they have solved an engineering problem to see if they respond from a purely technical or wider product perspective. On the other side when I talk about a product, it’s very interesting to hear what questions the candidate asks about it — again, whether they’re technical or product-focused. Still, the open-mindedness is most important — all skills can be coached, we’re here to support that.
Alex: Technology is always changing. We need engineers that are able and willing to try new things and share their knowledge openly. In a build run own culture, it’s amazing to see a blend of curiosity and the confidence to share new things with the wider team.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.