We like to spend time together, sometimes even with our significant ones. Since we are distributed around the globe, we have online events, small local offline events, and even big offline company gatherings. It’s always interesting to meet colleagues from different locations and have fun together outside of work.
Socialization Online
Online random coffee
We use an app called Donut to help us get to know each other better. Donut randomly regularly matches people and encourages them to meet (remotely) for coffee, lunch, or donuts. These can be one-to-one or group meetings.
Before the sync, RWNs can choose an interesting topic to be an ice-breaker or share some information about themselves. The app automatically attempts to find available time slots that work for all attendees and also allows to chat asynchronously if there are no available slots this week.
Occasional online masterclasses and other games
We also have online events where we can participate with our families. For example, we had a mixology event where we mixed cocktails đž and mocktails đč. And after a few cooking masterclasses, weâve advanced our craft in Mexican cuisine đź and cooking chicken pies đ„ź.
Socialization Offline
Local Diners
We choose some nice restaurants in the city and can enjoy the taste of some American, Italian, Japanese, and Chinese cuisine and share some funny stories with teammates at the next desk.
Railsware Weekends and Parties
Every year, we can have one or two offline weekends in Poland and Ukraine.
This get-together time is for fun and social engagement. Itâs the perfect chance to reconnect, have fun, and make new friends.
With our remote setup, many of us donât see each other often, so these weekends are a blast.
Also, during the year we may have summer picnics, winter quests, Halloween and New Yearâs parties or other entertainment activities.
Wow, youâve read it all! It seems that you are really interested in us. Perhaps, itâs time to finally get acquainted?
Railsware unites remarkable people from many countries and cultures. Everyone finds something great here and, on average, stays with us for 5+ years.
We’ve spoken to Railswarians to find out what team’s advantages they value the most. Here’s what we found out.
Flexible Schedule
Railswarians work from different parts of the world. We don’t have a fixed full-time schedule and are flexible in organizing our work and meetings. RWNs know exactly when to book a video call and when to choose asynchronous communication and don’t complicate things by scheduling a call if a problem can be dealt with within a single message.
Remote Work
Not only are we free to choose almost any location to work from (the only criterion is a decent internet connection), but we also provide you with a bonus, you can spend to set up a comfortable home office or rent a coworking space in a chosen location.
Strong Team
In our survey, all RWNs mentioned a strong team as one of the most powerful advantages they felt once joining Railsware. However, we all have a different understanding of what a strong team means. Among the most common phrases we heard were: “I don’t have to carry everything on my shoulders,” “Railsware is an experienced, motivated professional team that can teach you something new,” “Everyone has a great responsibility and ownership level,” “These are the people I can always rely on.”
Life-Work Balance
Railswarians respect and value life-work balance. We don’t work on weekends, holidays (that each RWN chooses for themselves), or vacations. We want to make sure that all teammates have enough time for their families and hobbies. RWNs indicate time off in their calendars, so no one bothers them while they are swimming, playing with their kids, or having an appointment with a doctor.
Benefits
As a distributed team, our main desire was to keep all the benefits flexible and available to each Railswarian no matter the location. Also, we wanted to simplify access to them and reduce unnecessary stress for the team. After some experiments, we created abureaucracy-free approach to benefit, according to which a Railswarian gets an additional sum and uses it the way they feel is right without any reports. Â
Content of Work
A product studio business model provides us with a wide variety of choices. It allows us to create our own and clientsâ products and choose tools, technologies, and approaches that work best in each particular case. Such freedom makes it easy to enjoy our work and lets us forget about pressure and limitations. Â
Company Processes and Approaches
Railsware is a project-driven company focused on automating and streamlining processes wherever possible. We love well-defined processes but we donât let them overshadow our end objectives. That’s why we’re always ready to create, test, improve, and reinvent them as needed, ensuring they continue to help us achieve our goals.Â
Open Feedback & Communication
It’s incredible how fast people get used to openly sharing their opinions and suggesting improvements when joining Railsware. No matter the position, people can freely discuss processes, projects, and strategies and offer their vision of making them better. It leads us to the next benefit.
When building successful products and running an efficient business, our team relies on the craft we started building in 2007. With a history of over 17 years, we have already found proven techniques or approaches that we use daily across all the guilds and squads. Some of those are widely known on the market, and some are modified or developed by us.
Check brief descriptions of the most common techniques that we use daily below.
BRIDGES Framework
There are lots of concepts on the market to use for product discovery, decision-making, and solution development. However, most of those frameworks are usually focused on a single type of subject like a user, a company, or a product.
Using quite a lot of different approaches through the history of Railsware, we have developed our own one – BRIDGeS Framework, a flexible decision-making framework, designed by us and inspired by Pivotal Labsâ Inception. BRIDGeS offers a solid approach for multiple types of subjects that we use to ideate products, design a new feature or solution, build strategies and operations, make work or personal life-related decisions.
BRIDGeS is an abbreviation â Benefits, Risks, Issues, Domain knowledge, Goals, and Solutions. We use Subjectâs descriptors (BRIDG) to investigate the context of the problem and create a Solution that can meet all the essential requirements.
We use BRIDGeS every time we deal with complex, multidimensional contexts. The framework has a well-described flow that explains how to collect, analyze, and process information to develop an optimal solution. Unlike many other tools and frameworks, BRIDGeS is relatively simple, itâs versatile, and has a long list of advantages that helps us make data-driven decisions fast. If you want to try it â just use our Figma template!
Prioritization Framework by Dai Clegg
Daily routine usually includes a bunch of tasks. Ideally, youâll have enough time and energy to cover all of them â but it just might happen that the number of tasks is immense and the resources available are not in abundance. The art of setting priorities shows the efficiency of your workflow and the success of the company itself. Railswareâs choice is the project management framework by Dan Clegg- a simple yet powerful solution to set priorities both with and without timeboxes.
The framework has four priority categories it works with. These are Must-haves, Should-haves, Could-haves, and Wonât-haves. And thatâs how you can define which task falls into which category:
Can you move forward with the project if this task is undone? â if NO, itâs MUST
Will you move forward with the project if this task is done a bit later? â if YES, itâs SHOULD
Can you sacrifice this task till the deadline? â if YES, itâs COULD
Can you get back to it when things go better? â if YES, itâs WONâT
These questions help you correctly figure out the importance of any task/process/feature/etc.
RASCI Responsibility assignment
RASCI matrix is used for the allocation and assignment of responsibilities to the team members in projects, processes, or tasks. Our team has a long history of creating and using RASCI charts for both inner and external projects. Over the years, we have defined some additional roles that allowed us to distribute responsibilities more accurately and achieve better outcomes.
As a result, we have developed a RAtSCNIuo model which stands for responsible, approver, team, supportive, consulted, if no one else, informed, user, and occasional user.
Let us explain what the new roles mean.
Responsible (R). The person who takes direct responsibility for the overall result of the project, no matter what blockers they face. The Responsible controls the execution of all project participants and is accountable for the final successful outcome.
Approver (A). The person who helps the Responsible and the team to make the right choice and approves the final results. Has limited hands-on involvement.
Team (t). Is actively involved in the project execution, does the recurrent work, proactively contributes to the vision, stays on track of the project progress.
Supportive (S). Helps the team on request only to do work, to spread results into masses. Anyone with partial hands-on engagement. For example, a Finance Manager who helps the team to pay for a specific service.
Consulted (C). Shares knowledge and opinions to the team to tune outcomes into what they believe is right without doing any significant work. If RWNs have marked themselves as Consulted, it means âconsult with me before you design the solution/ ask my opinionâ. For instance, some RWNs mark themselves as Consulted during a ââsurvey, related to a new security system, which means they want to be interviewed and they have some ideas on the topic.
IF NO ONE ELSE (N). The person that wants to move away from the activity, but possesses domain knowledge and will help, if no one else is available.
Informed (I). Is actively or passively informed about changes.
User (u). Does not participate in the task, but will use the end result.
Occasional User (o)ïž. Occasionally uses something.
However, each project is different. On some small projects, we may only have a Responsible and Approver and on other ones, we might have even more roles than described above.
Railsware takes advantage of collective leadership based on the RASCI model and makes decisions on different things including prioritization through voting. Team members can express the desire to work on some project, complete a task or pick a solution by choosing from several options like:
Really Want. The context of very high interest for you that matches your life goals or values. This context makes you excited and happy to be a part of.
Want. The context that you are already doing and want to continue or in general something that you enjoy doing.
Ready to experiment. You don’t have much experience in this, only have a general interest, and are ready to contribute when necessary.
If Really Have To. Your contribution will be requested only when necessary and there is no one else to help. Meaning, if there is no other possible option available.
Don’t Want. If you do not want to be involved in a certain context. When used in voting, it means that you do not want to go further with that option.
Ask me again later. You cannot decide right now, you need more time to think and investigate.
I will go with the crowd. You cannot decide at the moment and will follow the choice of the majority.
We designed this framework to ensure every team member is happy to contribute to a particular project. The approach allows us to stay motivated, engaged, and positive at work. When we form squads, we take peopleâs preferences into account. Also, the framework helps make the decisions easier and the choice much more understandable to the team.
Documenting things
Being a remote-friendly and distributed team we understand the value of documenting everything. Documenting is a vital approach meant to put all kinds of verbal communication and decision-making into a written format. This approach helps us stay on the same page and always have access to details needed, no matter what time of the day or part of the world it is. Other than that, documenting promotes transparency and continuity of information and prevents the bus factor.
The answer to âWhy do we need documenting?â mostly depends on the case and was clearly expressed by our CEO Yaroslav Lazor: âNot to forget shitâÂ
However, there are also other purposes for writing things down:
To ensure that all parties are on the same page.
To have a point of reference.
To capture ideas and turn them into actions.
To help people make the most of their memory.
To take a retrospective look at things later.
To make your knowledge or experience shareable for anybody.
To be better informed and prepared. Documenting helps you prepare for meetings based on having questions/agenda/plan typewritten in a doc and this way you save time on the meeting and get the outcome that you want.
To help the brain go deeper. When you capture thoughts, your brain can use them to go deeper. Itâs no longer busy thinking about them.
Processes culture
Railsware is built not only on feedback but on processes too. To be precise, we have around 1000 repeatable process templates described and ready to be used on a daily basis. Those are the checklists that help us make the most of our memory and always deliver high-quality work.
When we have a task that should be done with some frequency but stays more or less the same, for example, the onboarding process for a new person, we write everything down. Basically, we create a checklist detailing all the steps that need to be completed each time for some repeatable activity or task. We make it even more useful by adding all the needed links and details to it. This way we make sure that no small details are left out unseen as everything is written down. Once the process template is ready for usage, each Railswarian can complete a process without additional help from anyone else.
As a result, we get a reusable process template. Usually, those templates are created with help of our SmartChecklist and Smart Templates (a part of the TitanApps suite) and are stored in the task management system. Each Railswarian can create such a process at any time if there is a need and it will be automatically added to Jira and assigned to a needed person.
Inputs culture
Railsware is built on feedback.
Yaroslav Lazor
CEO at Railsware
We encourage Railswarians to share ideas about what can be improved or changed in our cooperation (e.g. finance, hiring, team events, etc.). We have a joint commitment to support and help each other grow, no matter oneâs position or amount of experience. This is a culture where no one is afraid to share feedback and is eagerly waiting to receive it.
At Railsware, we implement feedback on many different aspects of our work. There are one-on-ones where teammates share their thoughts with each other and can thus resolve issues. There are regular retrospectives that allow a lot of feedback to be shared and discussed, helping improvements be made on the spot. There are continuous feedback sessions integrated into onboarding and individual development processes where RWNs can receive feedback from a variety of teammates. A lot of feedback is given casually while working together or reviewing each otherâs work. It can be a quick Slack message or a brief call.
We gather inputs about almost all processes that we have or before/after launching a new project. No matter the form, all feedback will be taken into consideration. This encourages people to share more constructive thoughts without the worry of being judged or misinterpreted.
Pair work
We believe in Pair Work and practice it not only in programming. By working on a problem together, RWNs may create more effective high-quality solutions from the start. Multiple pieces of research show that pair work helps to avoid biased thinking while keeping all team members engaged and accountable in the process. It makes the outcome of work more linear and predictable. When working together we are more concentrated and able to generate better ideas for the project or task receiving better results at the end.
Sharing can happen in many forms, from internal training to talks headed by different team members. It can be a pair-work or mentoring session that more experienced teammates have with newcomers. It can be simple updates posted bi-weekly or monthly, letting everyone catch up and adopt new ideas.
