I was reading this great post talking about UX vs UI when an interesting thought came to mind. The post discusses the differences between UX design UI design, and it occurred to me that I've been reading many similar articles lately, covering the software world spectrum.
Many of us in the software industry are discussing the differences between Ops and DevOps, Product and Designers etc.
Discussing the divergence between job titles, talking about what the "other" guys should do, and how they are not doing what they are supposed to do - trying to define each other's responsibilities.
Common ground
When talking about values and beliefs , everyone is on the same page:
We all want to move fast
We all want to build great products
We all want to learn and analyze behavior
We all want frictionless experiences
We all talk about "people first"
One (huge) team
Let’s start to think about all the people in the organization as one (huge) team, which aims to achieve the things we all think are important.
Let’s respect other people's opinions, challenge them, test ideas, make decisions together and also understand each other’s limits and strengths.
Let’s create an environment of openness and respect, where people enjoy their work, their day to day, where being challenged is welcomed at every level.
Talking less about boundaries and more about cooperation between different functions can do wonders for communication, the team and of course the product itself.
I want to take you through the journey we took to break these boundaries, allowing everyone to work together and understand how they can help the user better.
Going to full stack
Back when we were a small startup, our R&D was divided into backend, frontend and DBA teams. As time passed, more and more time got wasted on integration between the teams, blame games which resulted in lack of ownership, rewrites of code due to lack of communication and a very slow pace.
To solve it, the teams were merged into a single group, responsible for the entire development, end to end.
The result was a huge boost in productivity, velocity and quality of the product.
The developer now understood the bigger picture and created better designs, which were leaner and better suited to the problem at hand.
Now with tests
The same issue appeared with our QA department. We noticed that features were reaching the QA stage full of bugs that, even after they were discovered, took a long time to fix.
The QA automation team couldn't catch up with the development rate and although many tests were written, they weren't recognized as an important part of the process.
All that changed when a simple move was made - no more QA as gatekeepers. Let’s make the developers responsible for testing their features.
This resulted in more automatic tests being written and additional safety nets being created (for example, UI and system tests).
Responsibility for the quality of the feature made the developers more attuned to their users, giving them an enhanced perspective of the end user for each feature developed.
Today our QA is responsible for the quality of the production system as a whole from a product point of view. QA are doing risk analysis for features, analyzing their effects on the company's business goals and working closely with the product manager to understand if features are working from a product perspective.
Feature ownership
The next step was the definition of a Feature Owner.
Our developers lead the development of a feature from conception, design, coding, QA, operational aspects, production and post feature analysis.
The feature owner works with the product manager on the spec, writes the design, does/leads the coding (writing tests of course) and deploys to production.
The feature owner creates discussion around the features, giving and receiving feedback from every function that works on the feature, as well as from interested people around the company (from dev to CEO).
Once the feature is in production, the feature owner will use the metrics he/she created, together with other analytics, to analyze the business impact of the feature and fine tune the feature according to the users’ reaction to it.
Many walls between groups broke down during the transition, resulting in better communication, estimation and ownership across the company.
Cross functional
We are starting to experiment with cross functional teams, where the team itself can function completely independently and contain every skill needed to achieve its own goals and, in turn, the company's.
The vision is to create teams that have feature owners, product, QA and even dev-ops, making them completely self-sustained and focused on a specific domain or goal.
Cross-functional teams enable a deeper understanding of the user, once a privilege of the product manager, for each team member, connecting them to the business and allowing them to develop features aligned more closely with user needs and company goals.
In conclusion
By removing boundaries we started to move a lot faster, increasing our velocity and our ability to execute complex features. We also enabled everyone working on the system to meet the real users and benefit from a better understanding of the business.
By talking less about boundaries and more about goals, we started to see an interesting shift in the behavior of everyone in the organization. Minimizing the waste from our work processes, we strive to produce quality both technically and business-wise, from everyone involved.
Working together creates a more productive working environment, resulting, ultimately, in a better product.