My Learning Journey In A New Innovation Lab
Coming from a system analyst background, delivery and order taking was all I knew. Strict timelines, release cycles, back and forth system design workshops, sometimes unreasonable business requirements were all part of my daily routine. However, the concept of innovation and its way of thinking was always something I desired to try out and put into action. When the opportunity to join a newly formed innovation lab came knocking, I didn’t think twice and jumped into it. Little did I know on the kind of journey I was about to embark on that would push me to my limits.
Establishing Work Processes
It was June 2020 when I first stepped foot into a new office to meet the new team. Including myself, it was a group of 5. I got to know the team, chatted with them on what I was to do next, a direction on how to start, the backlog that was being planned and so on. After spending the morning trying to figure out what was going on, everything still seemed quite blurry. There were some discussions on a new product that was to serve as a DevOps platform, on how it was to combat the existing difficulties of the tech teams wanting to sandbox their ideas seamlessly and how it could be the first PaaS (platform-as-a-service) offering that the bank could take up as a new business model. I didn’t know why we wanted to do something like this, but I followed it anyway.
As time passed and as new developers joined the team, there were many challenges along the way. Having to communicate the concept of DevLabs (which was the sandboxing platform we envisioned) was not easy, especially when we all came from different backgrounds (some were fresh out of school, others never touched infrastructure or cloud) and different levels of exposure to productization. Timelines were planned to be tight as we did not know what we were working towards and even I questioned the point in all of this. Who was the buying customer? How were we going to develop something so technically intricately complex? Was anyone really supporting this initiative? Needless to say, people were frustrated from time to time, but something in me began to spark.
Having started a list of what went wrong during the learning and testing of new technologies, going through problems of delivery alignment, the clashing working styles and thought maturity of the various members, I started to do regular retrospectives with the team. It was a great way not only to hash our problems out, but also a good opportunity to know each other better and build a growing sense of camaraderie among the members.
After 2 months of constant interaction, debating and ascending a very steep learning curve, I’ve come to see so many things improve along the way. Skillsets were improving, determination to experiment and take on new challenges was growing, and we became more driven to convert our opinions into tangible outcomes. Time was never on our side, and we started liking it that way. It drove us to learn efficiently, breakdown barriers between each other and fostered a culture that saw everyone as equals. A bunch of new misfits were slowly becoming a new band of brothers, determined to achieve greater heights together and embraced the fact that there were no shortcuts to success.
It was also great to know that there were local experts and partners that could support our technical growth. They gave us insight to things we could not research on, and we learned a great deal just listening into the types of use cases they had handled in the past. We made new relationships and expanded our network, explored different partnerships and got to broaden our mindsets. There was no problem too big to solve, if you knew who to reach out to at the right time, and with the right objectives.
I realized that I had forgotten my old ways of pre-determined work structure. I was growing in a place where constant shaping and experimentation decided what was good or bad, that there was no “one-size fits all” solution for any team. Tackling problems early and head-on and seeing them through was the only way we were going to see results after all.
I wasn’t thinking about the time we spent on work and research (yes, this included nights and holidays at times). I could only think about how could we do this better.
Hackathon — Our First Showing
Having pulled enough strings and sufficient internal selling, we finally managed to position DevLabs into the year-end hackathon of the company. 3 Months had passed since we started learning, piecing and stitching the sandbox platform together, creating our very first MVP (minimum viable product) and launching it on the open web. There were many places to improve but we were proud of what we were able to achieve with the limited knowledge and resources we had.
However, with the scale at which the hackathon would be at, could our MVP stand up to the test? It was another 1.5 months away and we knew that the clock was ticking to make sure that DevLabs was as good as it could be. With 6 developers (including myself) at hand, we got to work tuning the UX, improving supporting infrastructure elements, solidified the architecture further, all while continuing experimentation on supporting different types of technology stacks (Kubernetes pods, Lambda functions in AWS, different code bases etc). We knew that if this could be introduced as a new norm for company delivery, we would have achieved what we set out to do in the first place.
Inevitably, the time had come after many sleepless nights and countless hours of testing for the hackathon to begin. There were problems along the way and we had to support multiple teams during the hackathon. We were under constantly under pressure to help and respond as the teams were also under a time limit. It was challenging and frustrating, but it also came with a strong sense of satisfaction that real users were giving us feedback constantly. This was how a real feasibility test felt like, and we knew that regardless of how good or bad the feedback was, we had to take advantage of it at its fullest.
After 2 days of supporting the hackathon (even through the night), the team was drained. Attention had to be given to support our first showing on a large scale and we worked together to make sure we did the best we could. We gathered all the feedback and it was back to the drawing board. This time however, instead of frustration and confusion being brought to the discussion table, it was filled with a passion to improve and go above what we could do.
Final Thoughts
Looking back at our first endeavor and knowing how we have grown since then as a lab, I still sit in amazement sometimes on how we have gotten this far. The team had not really grown in size (it was 6 people back then and 9 people today), but it now supported so many more initiatives across business and technology. We still push ourselves to grow, reading wider and exposing ourselves to different experiences more than ever. Truly, the team had matured on all levels. There was no junior or senior members, there was only a bunch of tech-savvy people who were self-motivated to think and dream about what’s next.
· Never shy away from ideas, regardless of who they come from
· Feedback and constructive criticism should drive you to do better, not frustrate you
· Failure is a necessity for anything to succeed
· Perseverance to keep moving forward is the only way to see things through
· Grow yourself with the people around you to become better as a collective
· Anyone can be the next thought leader so don’t be biased just because “you think so”
I have resolved myself to keep fighting the good fight, to keep innovating with a team that maintains its ferocity in pursuing new things, and to mature myself so that I can continue contributing to the team that has served as a bright spark in my career.
We are SCB TechX Saber Labs, where we imagine, invent and influence ceaselessly towards an unknown future.
