One of the things we often say here at Bonitasoft is, “Never say it’s not my job.”
This is to encourage everyone to stay curious, and take initiatives to improve Bonita and our life at Bonitasoft.
The risk with “Never say it’s not my job” is that one may at times lose the focus of their core activities.
However, as we will see here, some projects could never happen without this spirit. After all, teamwork is critical for success.
I will show in this example how
resisting “it’s not my job,”
sharing mutual respect, and
communicating honestly
really worked for us to succeed.
The automation project
I was recently part of a team assembled to create the new Customer Service Center, which offers a central place for Bonita Enterprise customers to access services: technical support, expertise, audit, software version updates, training requests, and Professional Services requests.
Our job was to develop an updated, improved user experience for our technical and business end users.
Here is why it become pretty special.
The development platform
To start with, after a lot of research, something became really obvious: in order to create the new “Customer Service Center” for our customers who use Bonita on an everyday basis, we had everything we needed to develop this project on our own automation platform.
So we decided to use our own Bonita platform - not only for our internal processes (which we have already been doing with a number of other company applications), but also to interact with our customers.
On top of that, it is now deployed within our own Bonita Cloud offer.
The team
I was recently part of a team assembled to create the new Customer Service Center, which offers a central place for Bonita Enterprise customers to access services: technical support, expertise, audit, software version updates, training, and Professional Services requests. Our job was to develop an updated, improved user experience for our technical and business end users.
Everyone comes to a team with their specific job description: to contribute what they have been hired for, or what their job description says.
Those skills are necessary for projects in the company.
Our core team included:
A technical support manager, responsible for the team who works with customers to address technical issues with the software
A product owner, responsible for the company’s software product development roadmap and improvements
A professional services consultant, bringing technical expertise and experience working with our software product along with our customers
A marketing manager, responsible for visual design
But among these core team members there was also an array of skills and experience that turned out to be ideal for this project, some of them surprising.
The technical support manager took the role of product owner for this project. He understands so much about what the end users need from the Customer Support Center, he was able to describe the data and processes to define the requirements and use cases very well. It was his responsibility to research and find the best solution among the many available products on the market (open and proprietary) for the Customer Service Center. (He also turned out to be an excellent software test writer!)
My role in this team was not product owner (my Bonitasoft job description), but rather I brought my usability specialist and training skills to the table. I kept the team’s focus on the end user’s needs for a customer-centered Customer Service Center. I also contributed to the test writing. And - key to the central theme of this article - I supported the technical support manager for his product owner role.
Our Professional Services consultant has deep experience as a developer, and in DevOps. He also knows so much about the company’s software that he was able to offer to develop the Customer Service Center on our own Bonita platform. (He was able to help the project’s product owner understand how developing a solution from our own digital automation Bonita platform was entirely doable. (In some circles this is known as “drinking your own champagne!”) This might seem an obvious outcome, but the product owner dove into his research with a fully open mind about what solution could work. This team member’s skill set completely defined the technical path of the solution.
The marketing manager’s role in this project was as a graphic designer - even though, also key to the central theme of this article - marketing managers don’t usually participate in software development - just because she is good at it and was willing to jump in!
And of course everyone on our team all still had other significant job responsibilities to attend to during this project!
3 ways to make it team + work
Because of the special roles we played for this project, we approached it with an open mind. In addition tof our technical competencies, it was easier to express our soft skills:
1. Work through the natural tension between “business” and “technical”
Here are some things I’ve seen from other contexts about how developer-usability and developer-product owner relationships function.
In my experience as product owner and usability specialist, I’m not deeply familiar with the technical capabilities and limitations of the development team or the approaches and solutions available. What this means is that it is not always obvious what is difficult, what is costly, and what is easy to implement.
The excellent development teams I’ve worked with in the past always wanted to do the best technical implementation they could while producing what they believe the product owner or customers really want. This is great, but as a result, they would sometimes not even try to negotiate or offer alternatives, and spend a lot of energy and time on creating something that turned out to be very costly, when a simpler implementation would have been good enough from a usability point of view.
And then, when the project begins to run late, there is no good way to catch up. The building tension would be counter-productive, the unplanned issues get harder to manage, and the pressure to get it done would certainly not help the business / technical relationship in the project, nor does it help for future work together.
Now, here are some insights I gained working with the Bonitasoft Customer Service Center development team in a role different from the one I usually have.
- Work hard to build trust. Ok, not surprising. But once there is trust, there is no more fear, and the communication opens. It becomes easy to say “I don't know” or “I don't understand.”
- For the product owner, communicate a lot, and with a lot of detail about business needs so the developer(s) understand what the end result is intended for. We all needed to understand the “must haves” vs the “nice to haves” to create the right implementation.
- For the technical developers, it's ok to simply and calmly say “no” when a first suggestion is too expensive.
- But always counter with another, cheaper, more optimized option. When that happened, we almost always found another option that saved time and complexity (ie, later maintenance) and still resulted in good usability.
- During discussion of options, recognize the good aspects of each option, so everyone is acknowledged for the value they bring.
- Accept errors with some humor. Everyone makes mistakes at some point!
- Be flexible regarding changes. Regular project planning reviews change priorities, force us to look for other options, or even ask for some rework. This is how a project goes. Taking that as normal is key to keeping the team together in the midst of the project constraints.
What could have been tense and frustrating was instead a team relationship of mutual respect, trust, open communication and willingness to listen and be open to options.
2. Understand the gap between “what I know” and “what I need you to know”
It’s not always easy to share expertise, tutor or mentor someone in a new skill set, even when they’re open to learning. Here’s what we learned as we brought the Customer Service Center from idea to reality.
From my point of view as a mentor, assisting our team’s Product Owner with this new role, I could have found myself a little too eager to assume that what I say must be taken for granted, forgetting how hard it can be to have to learn from somebody else!
And from the point of view of the mentee, well, it can be hard to recognize that there are things that you indeed do not know. It would be a rare person who would be happy to be given “help” for something they can do or learn by themselves.
As for the developers, they need to be able to translate the technical constraints they were facing into clues to help the team make the right project decisions.
This team showed me that a mix of empathy and humility is key to teaching, learning, and communication.
What could have been confrontational was instead a sharing among equals and willingness of all of us to learn from each other.
3. Meet the challenges of working remotely
In addition to being spread across the globe (France, Spain, and USA), all of our work on the Customer Service Center project took place during pandemic social distancing, which meant working remotely for us, always. Although we had video meetings, much of our work was done individually from home offices - no “dropping in” to chat. (One of the discoveries of the past year is how much information is shared by “just dropping by.”)
As a consequence, we found that we really needed to pay attention to synchronization. Due to the natural evolution of project expectations on the business side, some work that was done early had to be redone after a closer analysis of requirements and potential approaches and solutions. To keep communication happening, we formalized our project work in Jira and used it to synchronize progress on tasks. We made heavy use of Slack to “drop in” and chat, and made sure to have regular “face-to-face” meetings using our corporate Google suite (Google Meet).
We had formal meetings weekly, to give us maximum time to work on the project, but also time work on our “regular” jobs.
And finally, we started all our meetings with a little personal status: someone's kid in the camera, curious about the noise in daddy’s office; chatting about the day’s plumber or electrician visits; sharing the evolution of the pandemic situation and its impact on social lives around the globe.
We avoided what could have been wasteful wrong paths with good communication, synchronization, progress together, and the sense of belonging to a team.
Want just ONE takeaway? Here it is!
We can recommend that project managers pay special attention to ALL the skills that individuals are bringing.
We took on this special project by accepting to not say “this is not my job”. This project gave us the opportunity to create a special team spirit, opening our communication and showing respect, empathy, and humility.
Did we always have perfect communication and alignment in this project? No of course not, because we’re all human, but we worked together in good faith and with good intentions. We helped each other through false starts and mistakes, which were all part of our learning journey. And we now have the brand-new Customer Service Center live and working - mission accomplished!
Which leads me to the last, maybe the most important conclusion I realized:
When we are ready to share whatever skills we can offer, whether it’s in our job description or not - then we really are living the value of mutual respect (including empathy, patience, humility, willingness to connect and share) in team relationships that creates truly open communication.
Open communication: this is the value that makes teamwork work for me.
