Jira on Steroids: Automizing Recruiting, Brand Exposure Measurement, Financial Processes, and Domain Recognition
Hi, my name is Aleksey Okhmush, and I’ve been configuring and administrating Atlassian systems for three years already. A detached position of Jira administrator is not something that you would commonly meet at IT-companies, especially in Ukraine, where everybody is eagerly trying to optimize the teams and cut personnel funding. The Jira configuration and administration tasks are often bundled upon another tech specialist, be it the system administrator, developer, project, or a product manager. In such cases, those are the basic Jira features that are being harnessed by a company.
What is more, a myriad of crucial points, such as data confidentiality, resources optimization, roles and authorization distribution, are left without the required attention. Today, I want to speak about Boosta in terms of sharing my experience of using Jira in the most expansive of manners and its successful introduction into almost every single process within the company.
Boosta’s Decision to Develop a Major Jira-Based CRM-System Explained
Small companies of up to 30-40 employees require not that many tools to work, while the labor cost tracking process is usually absent at the outset. Google Docs, email, and messengers are used as the repositories for a range of files. As time passes by, one way or another, it becomes difficult to control everything manually. The need for developing rules, devising processes, and tracking results loom on the horizon. The more dynamic is the rise in personnel numbers, the more difficult it gets to backdoor one’s way into a train that’s leaving the platform: the task of introducing new tools becomes exponentially problematic.
From the outset, it was Aleksey Prokashev who has brought Jira to Boosta. It was not long after the company has been founded. Then, Jira was used solely for tracking the development department’s tasks, just like in the majority of other companies. However, the requests for creating administrative systems for other departments and processes emerged did not take long to come.
The HR-department was the first to come up with such a need. The company’s initial team consisted of 4 members, so the employees’ search was carried out mostly sticking to the word-of-mouth-advertisement. Nonetheless, the company’s growth turned out to be quite dynamic, so the newly hired recruiters took over the talent acquisition task. The question of launching a system that would track and record open positions, candidates, and their history of interaction with the company has been brought to the table.
The majority of my colleagues in the company have already had prior experience of using Jira, so we concluded that this variant would smoothen the users’ integration and training process. We have emphasized on the basic interaction, unified processes concentration, and analytics transparency. I shall state in advance that right now, a particular part of our HR-processes is being serviced by the purchased accounts on the specialized platforms. Regardless of the fact that we have more than once considered outer alternatives, the recruiting process is still carried exclusively on Jira.
There are actually a couple of reasons to keep up with this strategy and expand Jira’s features:
Flexibility. All specialized software’s features are put within rigid boundaries. Even their slightest violation, supplied as a request to the service’s support team, comes back with a negative response. Thus, there is a limited set of features to use after purchasing the program. You may feel lucky if they cover for all of your needs, but it’s a rare case. For example, we have once faced the need to link the data from one popular HR-app with our payroll software. Resolving this easy at first sight problem took a lot of effort, as the data have been migrating with a distorted syntax, while the tech support kept us at bay when it came to implementing changes. Working with Jira, we entitle ourselves to an extended stack of opportunities to introduce personalized configurations and widen the software’s features that would meet our individualized needs. Practically, there are no boundaries (well, they exist but in an incredibly extended form). New functions are added as soon as a corresponding request is being supplied.
Implementation Velocity. We understand the principle of prioritizing the company’s tasks, so those are the emergency issues that are being processed in the first place. Every third-party contractor always perceives you as nothing but one of the clients; hence, expecting them to process an out-of-the-ordinary request with immediate effect is a vapid talk.
Engagement. My colleagues and I – we are all in the same boat. If we understand that the profit from dealing with the task instantly would be tangible, we assign it the highest level of prioritization and start processing it right away. Meanwhile, when a request seems to be inexecutable at first sight, we put all hands on deck, involve the internal customer, so we could work out a solution. The outer contractors reject the request immediately, halting any further discussions in cases like these.
Integration. The more software units you use, the harder it gets to combine them together into a single ecosystem. Hence, it follows that security is also a point to discuss.
Security. The more mutual connections are created among various program packages (especially when using additional plugins and apps for launching their connectivity), the more vulnerabilities and opportunities for confidentiality violation and data interception emerge. Third-party apps usually request a high system authorization level (administrator’s level), but they are still not responsible for preserving the data. Thus, if the service is being compromised, the felons are also getting the administrator’s access to the systems connected to services like these. In addition, not all the companies trust platforms that store data limiting the possibility of storing it on their personal servers.
Unification. Telling our managers to familiarize themselves with special software for recruiting, adaptation, administration, and time-off approval, and then to continue with mastering some more software for 360-evaluation, LMS-training, and so on, would have made them spend half of their working hours learning the new interfaces. Add a bunch of the new “login-password” matches used to login to a myriad of new access points. Voila, you have your managers confused. Meanwhile, Jira users are entitled to a maximum coverage of their needs while dealing with a single access point and a familiar interface.
And last but not least: when you analyze the rationale for purchasing additional software and grasp the idea that Jira is successfully covering all of your current requests, the system runs smoothly, while the introduction of a new tool will entail only additional complexities and expenditures, the decision comes up naturally.
Thus, Jira started infiltrating an exponentially bigger number of processes within the company. A lot of new requests have been coming in. Implementing them helped us turn Jira into a unified system for processing all tasks for 85% of Boosta employees.
As of now, we have three separate systems and 80+ projects that are being actively used. I will tell you about those which I consider being the most interesting and unusual.
The “Recruiting” project has been broken down into two types of requests:
The “Position” task is being reported by a manager that opens the position. He fills in the majority of fields, helping draw an image of a preferred candidate (sex, age, skills, compensation, probation term goals, etc.). There are 47 mandatory parameters to fill in total. This is the heftiest task in our system. Nonetheless, such an approach toward refining has helped improve the recruiting quality in the company.
Following the report, the position goes through the approval process. First, a recruiter checks for the correctness and sufficiency of the information provided. Then, the request migrates into the top management approval stage. It might be a 2- or a 3-layer process, depending on how high the one willing to open the position sits on the vertical of managerial hierarchy in the company. As soon as the approval has been granted, the task returns to the recruiter, who then starts processing it.
As an additional feature, the positions are being sorted in accordance with the company’s hiring priorities. Every position, depending on the filled-in parameters, is being assigned a particular score. This feature is needed when the number of simultaneously requested positions supersedes the recruiting department’s processing capacity. This is how the queue for processing the requests is being formed.
This feature has been implemented with the help of the REST Endpoint ScriptRunner, which then renders it as an HTML-page in the dashboard.
The second type of request is the subtask “Candidate”. When a recruiter starts processing the position, they add the potential candidates they have found as a subtask to position. If the company has already communicated with the person regarding another position, the recruiter gets a corresponding notification. Thus, they can see the entire history of communication and interaction, and if there is a skills-requirements match, they can add this subtask (the candidate) to a new task (the position).
The “Candidate” Workflow features the following statuses:
- Managerial approval
- Phone interview
- First interview
- Second interview
- Test day
- Offer sending
- Offer accepted/rejected
The workflow itself looks like this:
The statuses help us track in the real-time mode the recruitment phases that every single candidate, applying for every position in the company, is currently going through. We can compile the reject statistics, evaluate the speed of finding the right candidate. A detailed approach lets us keep a database of all the candidates that have been processed by the recruitment department.
Brand Exposure Measurement
We’ve spent a long time pondering over the way to introduce a permanent brand exposure measurement mechanics and “digitalize” this value. A couple of months ago, we have tracked down a solution within the very same “Recruiting” subtask in Jira.
Now, an additional feature was added, as a “Candidate” migrates from the interview status to any other phase of the recruiting process, and several new fields for the recruiter to fill in pop up on the screen:
“Have the candidate known about the company before?”
(yes/no) – required field.
“Feedback on the company”.
(Positive/negative/mixed/neutral) – given a “yes” answer to the first question.
“Information source” – given a “yes” answer to the first question.
“Information provided” – given a “yes” answer to the first question.
We carry out a monthly extraction of the answers statistics and track the brand exposure dynamics. Such an approach empowers us to see the wider picture and lets us evaluate the efficiency of our PR incentives.
When a new employee joins our ranks, the first thing off the bat is creating a corresponding task in the “Adaptation” project. This is some kind of an employee’s profile that holds the core information about him or her: first and last name, spelled in both Cyrillic and Latin, email, phone number, team, position, manager, office, and so on and so force.
Everyone employee has access to their profiles. Shared access to this project is granted only to the HR-managers. If somebody wants to look up the information about a colleague, they have another (third-party) tool to deal with this task.
Every single task goes along with a standardized set of subtasks. The newbie has to deal with a certain part of them within the framework of their adaptation. Yet, there are some tasks for the other specialists, as well.
For example, the next step following the profile creation is reporting a set of subtasks on the Helpdesk: creating email and corporate accounts, providing access points, configuring the corporate hardware. The assignee is the system administrator of a corresponding office. These and other organizational subtasks are seen by the HR and the assignee, but the newbie himself does not see them, so they could not drown in the overfilled with information sea of confusion.
On the first day at work, the person logs in to their profile and presses the “Adaptation, day 1” button. 18 tasks to be processed on the first day are created automatically. For example, filling out the corporate profiles, familiarizing with a myriad of rules, learning core information about the company, as well as work conditions and key processes.
A similar pattern is waiting for the newbie on the second day. Pressing the “Adaptation, day 2” button adds new subtasks that have their own deadlines. Every task is being checked by an HR-manager after a submission. If there is a need, the HR-manager provides corrections and helps the new employees deal with the tasks.
The combination of the HR manager’s personalized communication with the employee and rigidly structured information in Jira renders our adaptation process as a truly efficient one. Almost each and every employee in the company claimed this onboarding experience to be the best that they have ever had.
All the tasks are saved and stored in the system as long as the employee works in the company. Every person can go back to the information needed at any time they need.
The finalizing part of the tasks (“profiles”) within this project is represented with an exit clearance. When we have to say our farewells to an employee – regardless of the reason – his profile is being transferred into the “Resignation” status. Then, a new subtask with a specific workflow is created. In the beginning, the process involves the employee himself: the person receives commands and direction regarding whom to hand over the reins. The employee transfers all of the unfinished tasks to colleagues. Then, this subtask is being assigned to the manager, who confirms that the accounts can be closed. Next, the Helpdesk denies access points and deletes the accounts. The financial department pays the remuneration remainder, the Helpdesk checks the hardware, while the administrative department requisites the key to the office.
Back in the day, the exit clearance was handed in as a piece of paper. The person had to carry it around everyone involved in his or her workflow and gather their signatures. Now, the automation simplifies and accelerates the process, while preserving the requested chronology and gathering the employee’s history in a unified repository.
One more example of a successful migration from manual data processing and copious mailouts is the “Education” project. The cycle of processing the requests for visiting conferences, training courses, and other educational events is being started and finalized here. Employees submit the participation request and share the materials and impressions following partaking in the event on this platform.
This is how the scheme has been put to life:
- Someone creates event-visiting tasks.
- The task is being approved by the manager.
- The task is being processed by the Education Manager who conciliates the ticket purchase format and the cost reimbursement (in accordance with the corporate rules, the company covers for 100% of the ticket price that costs up to 1,000 hryvnias; those costing more than that are reimbursed by up to 80%), and other details.
- The payment task is being created.
- If the event takes place in another city or country – the task for organizing the trip is being created for the administrative department.
- The employee receives the ticket and all the supporting documentation on email.
- The employee shares the outcome in the comments following the visit. The Education Manager uploads all the provided files and feedback into the educational base of the company.
While the request is being processed, all the updates are being marked with corresponding statuses. Thus, the user can track the request processing stage in the real-time mode.
Introducing “Education” allowed us to track the statistics of visiting educational events, as well as control the expenses in the company in general, as well as in separate teams. Now, the task of budgeting, dynamics, and trends tracking is as smooth as it has never been. The metrics that we had to reckon manually is now successfully processed with the help of a couple of mouse clicks in Jira.
Boosta Hub Booking
The company has its own conference room, mostly used for internal events. From the outset, the process of booking it was conducted in the most rudimentary of ways – via Google Calendar. Still, our HUB is quite an adaptive space that can be modified depending on the needs of the event. It didn’t take long before we observed such a tendency: the folks who had booked space would forget about the need for getting it ready, and would start rushing in search of the office manager, asking him to help, a couple of minutes before the event is about to start. Lots of factors can slip the minds that have nothing to do with event organization on a permanent basis. Well, moving the tables and chairs does not require a lot of time, while charging up the microphone battery or looking for a specific adapter might last significantly longer.
This is why we decided to implement the booking process in Jira. The created in the Boosta HUB project tasks are immediately assigned to the authorized representative of the administrative department. When creating a task, the author fills in the required fields, including:
- Space configuration (he can choose between one large room or having it split into two spaces with the help of a mobile separation wall);
- Seating arrangement (the tables placement can be adjusted as well);
- Hardware checklist (sound equipment/projector/flipchart, etc.);
- Additional requirements (need of catering services, handouts printing, etc.).
The office manager gets the room ready in accordance with the request provided. Thus, everybody comes to a prepared hall, ready to start their event without further ado.
Such an incentive helped increase the standards of organizing internal events and flee from annoying event-organization fuckups that were gradually becoming a tradition in the company. What is more, Jira gave us the chance to set the pauses needed for adjusting the rooms in between the booked session, as well as tracking the statistics of using the HUB.
Financial Processes (Payments + Budgeting)
We have created separate “Payments” and “Budgeting” projects in Jira for administrating the company’s financial processes. The “Payments” project has each and every payment recorded as a separate task. When it is being created all the required parameters are being set their values:
- Payment type;
- Invoice details;
- Item of expense, etc.
All the tasks are preliminary assigned to the approval by the person responsible for the item of expense and are then automatically distributed among the financial department representatives depending on the payment type. As soon as the payment becomes effective, the author receives a corresponding notification.
The budgeting process takes place on a quarterly basis. Every quarter, all the responsible for the items of expense receive a task for filling in the budget in the “Budgeting” project. The expenditure plans are typed into the system and are being approved with the company’s top management. Then, the budget can be deemed active for the aforementioned period.
The “Payments” and “Budgeting” projects are mutually integrated. Every task in the “Budgeting” project with a budget allocated for every item, features all the tasks from the “Payments” project. It also sums up all the expenses and shows the budget usage percentage. When creating a task in the “Payments” project, it is being checked whether its cost does not violate the budget boundaries. If the cost supersedes the budget or it did not receive the budgeting required, the task type is being automatically changed and it follows a new workflow on additional funds approval.
The company’s operational profile envisages the presence of copious domains. Of course, the solutions for keeping a corresponding record and storing information about related registrars and hostings, are aplenty on today’s market. While in real life we faced the fact that every department (financial, development, system administrators, and SEO-specialists) had their own Excel-tables, the data from which required unification for the sake of informational centralization.
The “Domain” project has been created as a solution to this task. Every domain name gets assigned an individual task that stores all the needed information:
- Purchase date;
- Next payment due date;
- Hosting-related information;
- Registrar-related information;
- An assigned SEO-specialist;
- An assigned developer;
- An assigned financial officer;
- Statistics on the domain’s accessibility over the course of the last 7/14/30 days, etc
Statistics on the domain’s accessibility and the monitoring status Jira gets from Prometheus.
The “priority” field lets our development and design departments prioritize the tasks and accelerate their completion in regards to the company’s key projects. Also, when a task is created, it is allocated to a PM indicated in the domain’s profile.
The “Domain” project also automates some other processes. For example, a developer can use it to clear the domain’s cache on Cloudflare without requesting corresponding access: Jira does it automatically and will write about that in the comments to the task.
We don’t pursue a global goal to consolidate all the company’s processes on Jira and create a sole information source on its basis. Nonetheless, we keep on developing the system, launching our new projects within its boundaries. Out next task is to create with the help of Jira an end-to-end goal analytics system that would help every person see and understand one’s impact on the company’s overall goals acquisition. It is a complicated process that will require input from every single specialist. Moreover, there are those minor tasks on adjusting/expanding the functional coming daily from our colleagues, and these tasks are being evaluated and implemented in accordance with the adopted approaches.
Those are the primary plugins that we use:
AIO Reports – the most potent tool for crafting reports.
ScriptRunner – additional JQL-functions and scripts for complex automations.
Project Automation – automation with plain and convenient interface.
Sure, not everything’s that smooth and using Jira has its own pitfalls:
It should be taken into consideration that the system was created with the other goals in mind. Such a customized overhaul envisages using Jira not as originally intended.
You can track rather more adapted to particular tasks tools. Here, we create all the logics manually from scratch, while the specialized software developers have got you covered.
The UX/UI aspect is not flexible enough due to the restrictions imposed by the system architecture. Hence, you’ll have to put up with the design/features. On the one hand, it is an advantage, as the interface is usual and easy to understand for everyone. On the other hand – you cannot expect a designer to come and create a beautiful interface.
The system requires a specially hired expert. It envisages additional expenses for the company. Furthermore, the expert can quit and would be hard to replace due to the labor market scarcity in a corresponding niche.
When you work in a big company where there are reconciliation and approval processes, you will face the need to accept that Jira does not distinguish between the users (those are not the distinct “groups”/”roles” that I’m talking about). Therefore, building the users’ hierarchy in the very system won’t be easy. We had to look for the loopholes to deal with this problem, while the specialized serviced have got this problem resolved, and you don’t have to reinvent the wheel.
You end up dependent on a single system. Imagine that the hosting provider experiences problems in DC. All the departments will experience operational difficulties.
Regardless of all this, Jira let us automate and simplify a bunch of processes. This is practical proof that the approach is a worthy one.