I have never been someone who wanted to work on boring, straight-forward tasks over and over again. That’s why my CV is full of short running jobs: there was no growth and no opportunity to find a better way to work.
That experience was at the top of my mind when I first saw the job at OpenPayd – I wanted to be sure the role wasn’t going to be a dead-end.I went ahead and applied for a position as a “Java Software Developer”. An online interview, followed by a task and then a face-to-face interview followed, before I got the offer. It was by far the best one I’ve ever had, with a salary and benefits that were very competitive. Even then though, I still had concerns in the back of my mind about what my role would involve and whether the work would challenge me. After three years, I can certainly say it has delivered!
Why am I still working for OpenPayd?
There are lots of reasons that I could list here, but the first and most important one is the total freedom I have in my work. No matter who you are, what your religion is or beliefs you have, you can be your real self. Most companies promise it, but here, finally, the promises were real. At OpenPayd, Diversity and Inclusion feels lived by, it’s not just a social media statement. As a person who didn’t internalise the norms of society, it was really what I was looking for.
But, like most engineers, I was also looking for the freedom to select and build a tech stack that best fits our business requirements. It’s something that many of us have faced: no one listens to you if you are new and (relatively) young. Here, finally, it was different.
I couldn’t say all my technical suggestions were accepted immediately, but it was good to see respect and consideration from the team towards my ideas. I believe you have to prove yourself: even if you’re a popular content creator within the development community, no one gets a free pass. But I can also say that it was appreciated having the freedom to contribute your ideas as the “newbie” in the team.
After a short while, when we all got to know each other and understand our strengths, putting my ideas into action became even smoother. I am proud that I was able to make my mark on how our technology was engineered. And I know it also contributed to my promotion to “Software Architect” after 18 months in the business.
How do we code at OpenPayd?
Before beginning a task, at the analysing phase, we start with a deep investigation into the feature we want to develop. After all the participants have completed their investigation, we hold a session to brainstorm ideas and find the optimal solution for it. I can definitely say, it’s in those sessions that you’re really expanding your horizons.
The brainstorming phase is followed by the team coding in pairs formission criticaltasks, and working individually for the straightforward ones.
Sometimes, developers can find better solutions on the way, but that could be a bit risky or could take longer time to deliver. That’s why we have a “Technical Debts” period, 1.5 months each year that we only use to focus on technical problems and debts – no business development.
We follow the rule of “no blame” for individuals if production issues occur, even if it’s painful or costly to fix. Instead, we take an immediate action to fix the problem. Then, we simply take actions to understand what we need to do so it doesn’t happen again. These are the times which helped us to embrace the journey and move our mindset forward.
How we work
Long story short, we follow the rules of the Scrum methodology. The main idea is to keep the motivation and trust within the team as high as possible. I believe this is key for tech-driven companies.
With trust-led, motivated teams, there’s no room for micromanagement. This way, the code is a result of our multiple brains and ideas rather than a single engineering manager.
What else works for us? The answer is quite simple: Embracing the entire team! That’s easy to say, so I want to give you some real-life examples:
No task begins unless it’s understood by the entire team
We don’t start any task unless all of its requirements are totally understood by the team. Poorly understood tasks create unnecessary pressure for developers; they hold up projects and lower motivation while we wait for clarification from our stakeholders. As developers, we have to get a clear understanding of a task’s requirements, in order to schedule our days more precisely.
Including new items in our existing tech stack
As developers, there are always new tools to learn about and, sometimes, we can feel like we’re getting old and out-of-date if we keep using the same old technologies for years. That’s why we often challenge ourselves to incorporate new solutions within our tech stack.
At the very beginning of the year, we included theDebezium ProjectandKSQLDBinto some of our less critical solutions, so we can start to get real-world experience under our belts. We invested and paid attention to the way that they worked and now I can proudly say that Debezium is the backbone of one of our mission-critical microservices which is responsible for our transaction fee calculations. Those fee calculations are incredibly complex and we now have 10–15ms response times.
The most recent example is choosing between Golang or GraalVM, which came from one of my colleagues. After long discussions, we decided that using Golang would be much more beneficial for the company – as well as the careers of our developers. We felt Golang and Rust will dominate the development communities in the near future, so it’s important for our teams to understand it.
Yes, we’re a technology-driven company. But the plan is to eventually open-source our internal libraries and frameworks to the communities to bring greater value to the developer community.
Properly arranged Sprints
The most important thing about the sprints is, I believe, the timing. At times, in my past experiences, I found myself in quite stressful circumstances when teams weren’t running proper scrums – they were running a “Zombie Scrum”.
At OpenPayd, we hold refinement sessions for tasks that are ready to refine, vote and agree on story point estimations. Later on, we estimate the time required from the developers. We always get an estimation from the developer who is going to be in charge of the given task. That’s a crucial part of our inclusive way of working. The development time for a task can differ from one developer to the next. We don’t want any of our people to be at risk of burnout: the first thing we care about is the mental health of the developer.
Free Times
Our sprints are for 10 working days. But, during the planning session, we only fill the first 8 days of developer time. The only things we planned for our last 2 days are 3 hours of refinement and 1 hour retrospective sessions. If engineers complete their tasks with no bugs, they’re totally free to do whatever they wish in those working days. This could be reading articles, something new for their personal growth or playing guitar, whatever they wish.
We do this because it motivates the team to pay more attention to the task we’re working on. We all know if we could deliver the task with no bugs, then we can get two more free days that we can use for our growth in other ways.
Build a bicycle, collect feedback, evolve it into a motorcycle
Most of us are faced with very complex problems throughout our career. There is no doubt that we will encounter high expectations with complex integrations and limited time. That should come as no surprise within the business world, especially within a competitive space like Banking-as-a-Service. But the key question is: How do we deal with this here at OpenPayd?
When the development team receives a requirement from the business, the first thing we do is to split the requirements into smaller requirements in an abstract way. We always want to know the whole story, so we analyse, refine and chunk the project into smaller pieces. Knowing the whole story makes you and your code ready for the next request. The idea is quite basic: if our stakeholders want a motorcycle, we aim to give them a bicycle first. If they need more functionality, then we evolve it towards a Scooter. But if they’re happy with a bicycle, that’s a great result – you’ve saved your codebase and architecture from unused code you have to maintain for no reason!
Is it just co-working or more than that?
It is common for most of us to only communicate with our colleagues about work. But here there’s much more to it.
When we find time and motivation, we get together and spend time with each other. Climbing, trekking, going out for fun, barbecues, competitions about various things and so on. Each of us is not only a colleague, we are also good friends. We’re here for each other beyond the workplace, for good times and also for when times are tough.
What is it like being an OpenPayder?
As you can imagine, personality is a vital part of becoming an OpenPayder. That’s because all the things I mentioned until now heavily rely on who you are as a person.
There are no strict rules about what to expect within the company. We embrace the differences as a culture and value that in interviewees. That’s because candidates with different backgrounds can add value when we’re considering various technical directions. It happened in my case and is why OpenPayd has been the longest role of my career.
Now, I can simply say I broke the learned helplessness just by being an Openpayder.
If you’d like to know more, check out ourLinkedInpage and we’re alwaysinterested in hearing from youif you think OpenPayd is right for you.
