One of Rulesware’s commitments is to employee learning and growth. So when we began hearing stories lately about a few of our curious employees embracing the chance to not only learn about different practices, but to actually work in other disciplines, we got excited.
Diana Duran, for example, began working at Rulesware a few years ago as a developer, working on a project for more than a year. She then moved to the QA practice for two years, and then switched back to development.
Erick Huezo joined Rulesware as a computer engineer in the Development Practice, brand new to Pega. He trained and learned to appreciate the power of Pega when the chance came along to support his team on the QA side. “I had learned to develop in Pega, so I thought, ‘let’s see how to test in Pega, too.,” Erick says. He initially planned to stay in QA for two weeks. Then it was a month. Now it’s three years later.
Ricardo Castaneda began on the other side: he was working in QA when he first heard about the opportunity for ‘crossing over’ to the development side from his Scrum Master. Thinking the opportunity would help him further grow his Pega skillset, as well as to be able to perform any role at any given time, Ricardo made the switch.
Sari Abdel-Latif had experience in both development and testing prior to joining Rulesware, but joined Rulesware on the development side, as an analyst. While doing his initial Pega training at the El Salvador office, he met with various members from the executive team, He found out about an upcoming QA opening with a client in New York, and having a background in testing and running small teams, he showed interest in the position, some discussions later led to him filling that position.
“So yes, I’m a developer,” Sari says, “but I did have the QA background, too. I thought: Testing is a great way to truly understand how things work and I get to work along more senior developers”
The Benefits of the ‘Crossover’ Experience—For Curious Employees and Employers
Sari, Ricardo, Erick and Diana were all in different circumstances when the opportunity for switching practices came about, and each had a different reason for making that ‘crossover’ decision. But the one thing they all had in common was curiosity about ‘the other side,’ and an appreciation for the lessons learned from the experience.
One of the most difficult things in switching from Dev to QA for Diana Duran “was to learn the business itself: there are so many processes involved that QAs especially need to understand in order to create accurate scenarios.”
Importantly, she says she also learned about the importance of both the development and the QA practice: “they both contribute to a more robust application, and the skills you develop when working in one role will help you in one way or another in other role. For example, I used some of my knowledge as a developer being a QA to have better idea of what scenarios could be valid or not. And now that I am developer again I am taking advantage of the skills I got from my time as a QA.”
Erick echos this observation, adding that making the switch from practice to practice allowed him to widen his perspective, and appreciate ‘the other side’ in a way he didn’t expect. For example, he says that as a developer, he used to see the tester side as a kind of enemy, and that the QA specialists would somehow ‘break your code’ in finding errors.
“Of course you know as a developer that they’re not trying to be mean; they’re are just doing their job,” Erick laughs. “Being in QA, I’ve learned that communication matters: it’s not what you say to the developer, it’s how you tell them. It’s not telling them they did something wrong, for example, but that you found a gap. When you use a friendly approach, they’re more friendly with you. You’re changing the relationship: letting them know that you’re working with them to make sure that what they did in their work is working as it should. And that makes the whole team look good.”
Indeed it does. Hearing these stories of committed and curious employees who are interested in expanding their skill set to help their teams, evolve professionally, and to do better work is inspiring and humbling. Thanks to the courage of employees like these four, we recognize the value of supporting and fostering these kinds of learning opportunities.
Our thanks to you all!