With dApps forming the main basis of Web 3.0, DeFi protocols are becoming integrated into such applications and fundamentally altering how people approach financial services. Gone are the days when traditional banks and financial intermediaries were one's only hope. Today, DeFi protocols allow direct, transparent, and secure financial transactions online, thus rewriting how lending, borrowing, trading, and yield farming are done.
2020-01-217 min read
Great team drives your business forward. Bad team drives you crazy.
We are sure you know this. Maybe you have already prepared a set of perfect crew’s characteristics. Can we try to guess them?
Everyone works in a mode of a full synchronization and harmony. Although each member does different tasks, they are constantly integrating. There’s no arguing and no whining. You will not hear ‘Can I leave earlier?’ and ‘I am tired’. They do not fail and make everything in time. Devs understand clients from the first seconds. They hear “ehm..would you please change the…”, boom! The basket icon is changed in 3 seconds and 20 milliseconds! What else? Oh, sense of humor! You don’t want to deal with bores, do you?
Sorry, not possible. We’ve just described robots. Do you want them? Then wait for the next 50 years and only then launch your project. If you want to initiate it now do not idealize. Read the following guide on how to build a software development team that is highly successful.
First things to consider when building a software development team:
- Budget. No professional wants to be overworked and underpaid. Giving minimal budget and demanding beyond-great results is like asking cats to bark because you give them bones.
- Time. “You, guys, do your job and I’ll go do mine” – not good. Your crew will not build itself. Be sure to make room for it in your schedule. They need to feel their leader’s support.
- Adaptiveness. People have feelings, needs, and fears. When you ignore their feelings-needs-and-fears, they will ignore you. Working with people = adapting to their personalities and searching for consensus.
As soon as you’ve ticked all three paragraphs, it’s time to tell you the main aspects of a good team.
The Golden Mean Size
The team’s size depends on the project’s complexity. A small setup doesn’t require many guys working on it. For big one three people is not enough. Our experience shows that 5-6 people in a team is an optimal number, and it should be no more than 10. Say no to big crews. More people – less personal responsibility they feel. Let’s look at it in terms of maths.
Supposing responsibility for the project is 100%. Divide it by the number of people in a group.
- 100% / 5 = 20% of responsibility by each member.
- 100% / 15 = 6.6% of responsibility by each member.
It’s easier to ignore 6.6% than 20%, right? 6.6% are less noticeable for Jack. He is working in a large group and makes a lot of mistakes. The guy got used to the fact that his teammates would fix everything instead of him. Another example – John, who works in a small team and cannot ignore his 20%. He knows that his screw-ups will be noticed. This dev tries harder to make everything in the best way. This division also explains why bigger projects require more people. 20% of responsibility on a small project is okay. On a big one, it’s overwhelming.
You know the size of your project and the number of people in it. The next step is to determine your development team roles and responsibilities.
Software Development Team Structure
Imagine it as one organism. Will you function well without a liver? No. Same here. Take one part out – some important functions will not be fulfilled. Let’s make an analogy with the human body more vivid. The development team anatomy is at your disposal!
Project Manager, a.k.a brain, controls all other members of the team and sends them (neuro)signals (“Hey, John, fix your bugs!”)
Functions:
- create a concise and manageable plan;
- determine development team goals;
- manage schedule and deadlines;
- estimate budget;
- monitor progress;
- communicate with clients;
- support members in terms of emergency (errors, bugs).
Engineers/Developers, a.k.a. muscles (with team lead as a heart). No muscles – no movement! Without them, the project would not keep going. Devs get the (neuro)signals from the PM and turn them into actions (intensive keyboard tapping and coding).
- Front end developers convert data to a visual interface of a website (looks);
- Back end developers build actual logic of the application (functions);
- Mobile developers create apps with Android and iOS.
UX/UI Designers, a.k.a eyes, devise the visual part and are in a constant search for aesthetic. Usually, there are no separate UX and UI designers. One person fulfills the functions of both. Let’s say, the right eye is UX and the left one is UI.
Functions:
- User Experience Design is about observing people’s behavior patterns and understanding their needs. UX designer determines what the user wants to have on the website and where it is better to place it. Convenience is the main aim.
- User Interface Design is about creating a visual picture. Analyzing users’ psychology, UI designer combines colors, structures, and shapes to arise emotions. Good emotions, hopefully.
Business analyst, a.k.a. lungs, gives life to the project by exchanging the information (air) between the client (outside source) and devs (inside parts of the team). Analyses business requirements and ensures they are met. His work is not about “how”. It’s about “what for”. What user’s problem does the client want to solve by his product? The analyst finds it out.
Responsibilities:
- identify clients’ and users’ needs;
- determine the requirements necessary to create a future product;
- tell programmers and QA about essential features the client needs during product launching;
- elicit requirements in detail.
QA manager, a.k.a liver, filters the product from the bugs and checks quality at the final stage.
Responsibilities:
- set service standards;
- report quality issues;
- monitor the quality of the product;
- supervise staff in terms of quality.
Now that you have understood the structure of this coding organism, it’s time to create job opportunities!
Recruitment process
Hiring the right employees seems easy. Just share a post about the vacancy on LinkedIn or Facebook and wait for devs to call you. Not really. Recruiting requires professionals. What do recruiters do?
- Analyze job features. Do you need a dev who is familiar with React or Angular? With 2 or 4 years of experience? Are there special emotional characteristics? Like resistance to critique or charisma. They pay attention to everything that may have importance for the future candidate.
- Write a job description with all the important info. What are the requirements? Is it an in-house or outsourcing opportunity? What is the salary? What are the bonuses? It helps the right people to join your project/company.
- Seek suitable candidates on LinkedIn, Facebook, platforms with job vacancies. Let’s not forget about word of mouth and personal contacts.
- Research candidates’ resumes and professional background. It is important to know the frequency of job changes and reasons for leaving. Too many shifts from company to company is not a good sign.
- Conduct interviews, and finally, understand whether the candidate is suitable or not.
Our recruiter Kate shared her experience in her interview. You can read on our Instagram page.
After hiring the right people, choose a performance plan.
Methodology
Methodology structures work. Good structure is the frame you need if you want to build a successful development team. It helps to track processes and control results. The most popular approaches are Kanban, Scrum and Waterfall.
Kanban. This method creates balance in work and helps to avoid situations where some members toil nights and days and some – complain about having no tasks. Kanban divides work into stages ‘To do’, ‘In progress’ and ‘Done’. They are shown on boards. You can create them with Trello. Then Project Manager checks productivity. If the task was on board for too long, it is not productive.
Scrum. Scrum methodology includes Product Owner (interlocutor between the team and the client) and Scrum Master (divides project into sprints). Yes, this method consists of so-called sprints. They can last from 1 week to 1 month. Before coming at a sprint, you define requirements and aims to achieve. When it begins, clients cannot change the process. Only after the end PM analyses whether it was effective or not. If not, PM implements changes. It might be inconvenient for the clients because they can see the results only at the end of the work. However, the team gets more flexibility because there is less control from the client.
Waterfall. The main principle of it is providing clarity of all processes to clients. Products have to go through several stages. First, we confirm the requirements and make sure we understand what our clients want. Then we make plans, choose devs, give them tasks and proceed to draft. After it is ready, QA checks a product’s quality. Finally, we are ready to launch the website. SapientPro has implemented a Waterfall methodology to structure our work. Below is the structure of it.
You have chosen methodology. Have we finished? No. Because the next stage defines failures and wins.
How to build a development team’s corporate culture.
Corporate culture depends on the behavior of leaders. It is how they act, react and treat their employees. With all of it, they influence future responses and choices of the team.
- If leaders do not listen to concerns – no one voices concerns, people gossip.
- If leaders overly criticize – people stop trying harder and think they will never be good enough
- If leaders ignore employee`s needs – employees feel unsafe.
When we feel unsafe we either fight with the danger or escape it. This stress response is on the level of genes. In the workplace people either quietly protest and sabotage the work or leave the job. Staff turnover is a determinant of corporate culture quality. If many people leave the place, it means something is wrong with it. Sooner or later, all precarious ventures fail.
HOW TO LEAD A DEVELOPMENT TEAM WITH CORPORATE CULTURE?
- Unblock constructive communication. Let people voice their concerns and speak for themselves. When they do, exclude passive-aggressiveness and sayings undermining the importance of your co-workers. A good leader celebrates constructive communication. Instead of saying “Why is there the same bug again and again?” try saying “Look, there is this bug again. Let’s try to understand the cause of it. Maybe there is something you don’t understand and I can explain it to you”. Do you feel the difference?
- Embrace conflicts and solve them. If you pretend something doesn’t exist, it won’t disappear. Ignored emotions later burst into an avalanche of drama. When you notice a conflict, as a leader it is in your power to ensure the two sides talk it all over.
- Value people. Do not treat them as filled vacancies, ways of earning money and, well, robots. We aren’t. Neither you are. Remember it every time you scold someone for minor faults.
- Create a friendly atmosphere by team building events. It can be a movie session together or the discussions of the latest events at the parties.
Leading a software development team, SapientPro CEOs understood the importance of corporate culture. “Sapient pro is not about work only, it’s about people who do this work” – our value. Here’s how we roll!
- We have flexible hours, so people are not overwhelmed by being late;
- The kitchen is always filled with all the devs’ necessities: coffee, tea, cookies, fruits, and marshmallows;
- We have recently moved to a new cozy office;
- On Tuesdays, we have toasts for breakfast together;
- Each month we have gather-togethers in cafes;
- We provide our teammates with the opportunity to study at courses, conferences, and summits;
- We celebrate. Celebrate like it’s the last day of our lives. It might be if there are too many bugs, right?
- We build a relax-room for our teammates. Effective work is not possible without a good rest.
To conclude, recall the story from the intro. A successful team is not a perfect one. It’s not automatized. It is a group of people who love working together because they feel Respected, Valued and Listened to.