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.

Interests approach

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.

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.