SDC Management Framework
In 2021 the Nobel Prize laureate - Daniel Kahneman and the coauthor of the Nudge theory - Cass Sunstein, have proven and described in detail that all of us are prone to thought pattern mistakes (biases) and thought distortion because of significant noise (world conjuncture, our mood, weather, recent events, etc.). At the Software Development Company, we do not want the mood, opinions, or idiosyncracies to affect the management decisions. We want to be data-driven, unbiased, and less "noisy" wherever it is possible. We want our decisions to be backed by science, and we want to be entirely transparent with our colleagues. To achieve this, we have spent around a year building up and validating the management framework called the "SDC Management Framework." The framework consists of seven core components, each of which is described below. It was built specifically for "remote-first" companies like ours, where the physical office is a "nice to have" thing rather than a must.
PRD and UI Design StandardsThese are the documenting and UI-UX design standards that our product teams use in their work.
PDF File: PRD Example
Figma File: UI Design and Prototype Example
Article: How to Design and Prototype (Case Study)
Figma File: UI Design and Prototype Example
Article: How to Design and Prototype (Case Study)
Hiring and Onboarding
At most, we spend 24 working hours for the initial screening of candidates. Right after that, we contacted them to inform them whether we wanted to proceed with them or not.
Depending on the role, there might be a couple of interviews or one interview + test task. Once the assessment is finished, we take 24 working hours to consider the decision and then inform the candidate about it. You can find a complete list of the effort we put into each candidate here:
SDC hiring board.We've also prepared a separate onboarding process pipeline to cover the first six months of newcomers, which can be found here:
Colleagues Onboarding and Support board.Another small tool we built is called "DQC (Design Quality Control)". As a team of three senior reviewers (one product manager and two UI-UX designers), we've been reviewing test tasks by filling out this form, later cross-checking the scores, and using this data to support our hiring decisions.
One more tool we used for task setting is the C-E Index (Cuteness-Enterprise Index), here.
One more tool we used for task setting is the C-E Index (Cuteness-Enterprise Index), here.
Career PathWith this component, we address the following concerns of our colleagues:
- Standardization of the professional characteristics of our colleagues;
- Roadmap for professional development;
- A clear understanding of steps required for reaching the next responsibility level;
Managerial benefits of using this component are:
- Hiring interview simplification. We know upfront what we are interested in while interviewing the candidate;
- A clear, data-based explanation of why we consider a candidate fit for a particular position;
- Ability to see the average professional level of colleagues across the departments and the whole company.
All the positions described below inherit responsibilities and requirements from the lower levels. For instance, SE2 should meet the requirements and be able to perform the responsibilities of SE1 and SE0. It is also important to note that when we talk about responsibilities inheritance, we mean that the person should be able to conduct the listed activities per need.
The only generic requirement for all the positions is that the candidate should be approved for this role by the SDC management team.
Management Roles and ResponsibilitiesWith this component, we bring a clear understanding of company managers' responsibility zones to all the company members. We also use this document to understand which new managerial position we should open next.
In-house Communication FlowWith this component, we visualize the regular communication topics between the company's management chains and in-house teams. This component aims to clarify colleagues' communication nature. It also aims to maintain team members' expectations and show that higher management is always open to suggestions and any other discussions (The link between 'Everyone' and the Company Affairs Team, HR Specialist, and COO).
Project Processing Regular WorkflowThis document defines the regular workflow of the entire project cycle, from concept, when the CEO (or other business dev) contacts stakeholders, to the project delivery and release to production. It aims to:
- Set clear expectations for both parties - stakeholders and our team members on how we will be moving forward;
- Lower the understanding threshold of our working environment for the newcomer managers so they can quickly grasp what's going on and better understand the side (osmotic) communication they hear.
Other tools we used for project workflow maintenance:
- Solved overengineering and DEMO readiness issues;
- Developed project expenses counter
When the same employee (software engineers, QAs, UI-UX designers, others) works on multiple projects, the cost of that employee (salary) splits between those projects, increasing their cost proportionally to that employee's time spent.
So what we did is we took the data of each employee's time spent on each project, which we tracked weekly via their managers ("I" from SDC RIO Model), and calculated the cost of that time per each employee, which eventually gave us the perspective of how much a particular project costs to ourselves.
Team Availability ManagementWe've implemented a system that allows our team members to see our colleagues' availability (vacation/day off) and request those via Google Sheets. The purpose of having an in-house solution instead of purchasing ready-made products is:
- We use the data from the spreadsheet to make various calculations in other in-house tools
- We can modify it in any way we want + integrate it with the rest of the software we use;
- It is easy to set up;
- It is free.
SDC RIO ModelWith this solution, we aimed to have a clear understanding of an in-house atmosphere - who likes working with whom, how individuals cooperate over a large span of time, etc. Our goal was to have something similar to the so-called "360" HR evaluation but much more precise and meaningful.
So we developed our own solution called "RIO Model" that collected and processed employee data in three dimensions:
- Responsibility (daily updates tracking);
- Involvement (the % of a person's involvement in company projects);
- Opinions (colleagues' opinions about each other, in the form of indexes).
This allowed us to look at any of our employees, see how their workload changed over time, who they worked with, how those factors affected their attitude and many other things.
Solving Overengineering and DEMO readiness issuesAs with many other service companies, at some point, we noticed that we have two common issues:
- Our engineering teams have been actively working on projects for weeks, but it didn't make the product look more ready from the user's perspective. It was hard to show project progress via regular DEMOs to the customer - they simply couldn't see what was there "under the hood" and wanted us to show more "tangible" results.
- After completing and delivering projects, we often noticed that some parts were overengineered. In retrospect, there were cases when a piece of the product was developed, sometimes using twice as much effort as required.
To tackle these two issues, we've developed an exotic solution that serves as a compass to both software engineers and QA, called "PS Plus". Its complete description can be found here:
Babken Gyozalyan - Co-Author.
Anna Papazyan - 'Hiring and Onboarding' workflows co-author;
Karen Melkonyan - Visual design;
Natalie Adulyan - Brainstorming, concept validation;
SDC mentors team - Research, concepts validation, 'Career Path' development.
Released for Public: 30.11.21