Stopping chaos while still being helpful
This is one of the rules you’ll find in the small book of few big rules. This small book contains the core values to be successful at OutSystems. I guess it’s actually a key part why the CEO says that “80% of people will become great when in the right environment”. And people take these small rules *very* seriously at OutSystems. You can go around the office and feel this, like if it was something you could touch. People guide themselves by this book, it’s amazing. Now, focusing on the help rule:
“People at OutSystems are open to helping you. Use this to your advantage as much as possible. And do the same yourself. Offer help even if it is not in your job description. We believe you should extend yourself outside the boundaries of your work and into other functions to get the job done. Remain aligned with the Ultimate Goals when offering assistance. When it is your turn to look for help you will find that people will quickly reciprocate.”
Pretty simple right? In essence, it is. However, my team actually struggled with this rule. We helped too much, in a chaotic way. How is this possible? The mobile team is highly exposed to pretty much everyone, from support to customers, to peers, to…It’s the main entry point in the R&D for anything you can think about related with mobile. Remember that OutSystems 10 brought Low-Code development to mobile apps. But, of course, it wasn’t all done by the mobile team. We had literally hundreds of people involved from dozens of teams (IDE, Frontend teams, core teams, you name it). Think of us as a group of pretty organized ants, carrying blocks of “value” instead of sugar to a big platform.
At some point, a combination of this exposure with our strong feeling about the small rules became toxic. Too many requests together with our willingness to help resulted in a huge growth pain. We created a monster. That’s not necessarily good in a R&D department and can highly impact value delivery to customers.
Too many channels
First there was skype. Then Hangouts. Then… Without realizing, we had incoming help requests coming from all sources of communication channels. People would jump to our spot in the office, interrupting all the time in search for help. Some would “skype” a team member privately. Some with hangouts. Feedback would come through mail, support cases through JIRA, mail… Slack, which appeared later was the final “stone”. A public #rd-mobile-team slack channel you could use to get help? Sounds awesome, except you would divert the attention of an entire team. And private messages, now on slack too? Awesome (…)!
It started to be too easy to reach the team. All team (and more) distracted because someone entered the team channel to ask “which plugins in forge are supported?” Or… Of course, we replied to everyone on every channel because we wanted to be helpful. But it was taking a huge hit on both team performance and focus.
What to do? Well, what we do best at OutSystems: change!
Back to the drawing board. First step? Notify management that we were not working properly and ask for their input. Ideas! “Call me a whiner any day”. And they did gave us a great starting point. We merged their ideas with our own and we had a plan.
Executing the plan
We’re a fast growing company that’s in constant mutation. Everyone is open minded and always willing to change. And top management supports change and encourages autonomy of people to apply these changes. So, let’s do what best fits our team. But first… how do other teams around us work? How have they dealt with this issue in the past? We talked with the most similar to our team and got great insights. Again, we would to whatever would best fit our working methodology, but ideas are welcome.
“You can’t manage what you don’t understand”. We started with a small impact analysis: how much was it costing to be so helpful? Impact on team speed? Also, a small risk analysis: what are the risks of helping through private channels? What if some erroneous information ends up in a support case and a customer gets the wrong expectations? Well… we were surprised with so many risks that we didn’t think of. We never stopped for a moment to look into this issue. Hell, we’re growing at the speed of light!
Write down action items and owners. By action items we’re saying what must be done to improve and the owner is someone that will assure things will happen (not necessarily the person who implements it). This will get things rolling.
The “bad boys”
It’s so easy to just open a chat window and ask things that it’s the most dangerous part of this equation. So, our first targets were the chatting channels:
- Reduce scope: No answers through Skype or Hangouts. Our official, internal, company wide tool is Slack. Period.
- Redirect from private to public: private Slack chats shouldn’t be used to ask for help unless you specifically want to talk to that person. So, ask in the team channel. Not only you’ll have proper help but everyone in the channel will have the knowledge (e.g.: support engineers, product owners, etc). If someone has the same question again in the future, it will be easy to answer and everyone can do it. So…
Still a bad boy
Ok, so, it’s set: internally, anyone should just go to the #rd-mobile-team slack channel for help (help is different from support). But we still don’t want everyone in the team to be distracted.
- Don’t use @channel and @here unless it’s critical. This alerts everyone in the channel that has notifications active for that channel. Someone will answer when it makes sense.
- Maintenance only! Only the person in the team doing maintenance can reply unless it’s critical. Block interruptions from the remaining team members and make sure 2 individuals aren’t answering to the same request.
- Wait: Yep, probably no one from the team will reply in the first 15–20 minutes. That’s due to two main reasons:
1) Most people ask without giving it a good previous thought (because it’s so easy to just ask and some are just “rubber ducking”)
2) Maybe someone from support or similar will be in the channel with all the context and will help even better.
The not so bad boys
Slack is great to ask for help. But sometimes people just want to report a bug or provide feedback. Slack is not good for that. Mail the same. Why? We’ll have to grab that feedback and create issues on our backlog. So, we opted-in for the internal tool that was already in use by other teams for this purpose. It’s called Sauron and it’s, in essence, a centralized way for all teams to receive feedback, prioritize and manage that feedback. Yep, we look at everything you provide as feedback (e.g.: Service Studio). Again, only the person doing maintenance can look at this tool for a given sprint. After the initial analysis, the maintenance member can decide all sorts of things, like the priority, impact, risk, etc. He can also send the issue to another team if it fits or immediately to team backlog (if it’s something that the team should work right away).
Customer success is our success
Ideally, we wouldn’t have any support cases. And we wouldn’t have support at all. The product would be so good and so intuitive for everyone that no customer would need help. We’ll get there, dream high.
However, while we don’t reach the sky, we do want to make sure every customer gets all the attention he deserves. So, we treat support cases in a different way. Whenever a customer opens a ticket and it escalates to R&D, we have to make sure we react fast. So, if support needs to escalate they will automatically open an issue to the team in our “special board”, we get notified and the maintenance person will quickly look into it. Support provides all the info through that issue and we iterate really fast with them. It’s a high speed lane to us.
All customer related issues coming through proper support channel has a huge advantage: centralized knowledge in support. Only strange issues require R&D escalation nowadays as support gets more and more expertise on the product. And all customer communication is done in one place.
Be helpful… Be helpful… Be helpful!
It’s a big rule right? And we love it! So, we still want to help everyone and live, on our spot, is still an option. Just pick a good time for it (middle of the morning is not a good time, focus days are a “nooooo please” — unless you bring food) and, if possible, go directly to the maintenance guy. It’s the one with the fire extinguisher.
Summing up, all this seems simple and pretty obvious right? Well, it is. But the “monster” didn’t show up from one moment to the other. It was something that slowly appeared without us realizing. And it was a huge release by OutSystems, with everyone, including OutSystems developers still absorbing all the information. You can see that we still have a lot of communication channels. But it’s ok. The issue was chaos. We have brought some sanity to the team and we can help in a much effective way. We are a happier team.
Sorry about the drawings. My skills are not that good and this was done on a plane. But hey, communicate to be understood :)
Originally published at www.cesarafonso.pt on May 9, 2018.