How to set up a high-performance team (part1 – roles and skills)

Creating software is all about people. Yes, you need tools and a strategy and so on – but the people you work with define the baseline from where you are starting and how fast you can go.

The level of creativity, experience, motivation in your team is the result of the personality mix of your people. Good leadership will build on that and make the team stronger over time, and this blog is much about how to do this. However the team’s limits as well as its unlocked potential are to a large degree defined by who is part of the group. So choose your setup wisely if you can. In case you are not flexible and don’t have any choice: stop reading here and focus on the many other topics that can help to optimize whatever team you have.

When I had to hire people for the first time and did some reading on the topic I found this frightening statement :

”…only 20 to 30% of all hirings are considered successful after the first 6 months by both parties”

Huh – if this is true and only 3 out of my 10 new hirings are ok I’m set up for trouble. It means sooner or later I’ll have to spend once more time on finding and training new people all over again. And most likely my project won’t run as successful as it could. In the end all went well but this statement (may it be true or not) motivated me to spend the time and effort required to find the right people. What does that mean?

Think about your dream team setup

First of all think about what you need. Imagine your dream team setup as tangible and concrete as possible. Hint: you are not looking for “5 good developers”. Each team will have some role split, be it on purpose or not. Compare that to a football team. Each player can run and hit the ball, hopefully. But great teams will have an ‘expert’ gate keeper and another guy up front who’s specialized at scoring goals. Have you ever seen a world class team where everybody is doing everything? It seldom happens. Humans tend to be particularly good at certain things and less good at others, this is just how it is. Accept it and work with, at least as a starting point. If over time the team members broaden their scope and work at peak level in various areas this is great and an amazing work experience. Just don’t count on this to happen from day one.

Rather think about what expert skills you need. This may be someone good at front-end or UX, or someone with back-end development experience. Or architecture. Or requirements management… If your team is small some skills may need to be combined to a single role, which will make it a bit more difficult to find the perfect candidate. If it is larger you may have several positions with same or similar skills. Then for each position take a sheet of paper (or use the template from the download section) and follow these steps:

(1) Write down team roles

write down what the person will do within the team. What are the responsibilities and goals? What will make up the usual work day? This is one of the most important steps in your team setup process and lays the ground for whatever comes next. Note that you don’t start by drafting a hiring offer. You are not writing down what skills or experience you are looking for. This comes later. Don’t take the shortcut. Invest the time and think about the position as such. Remember, your team members are one of the most important success factors and you need to get this right. Do this for each position you need, on a separate sheet. Write down the number of open positions on each sheet.

(2) Look at all roles in context

Put all sheets next to each other and look at them in context. Do they match up? Is everything covered to set up a working team? Talk it over with colleagues. Sleep over it and check again a day later.

(3) Define skillsets per role

Now think about the required skills for each of the positions. What will that person need to know in order to be successful? Try to find a balance between being to general (“needs programming experience”) and being too specific (“must know AwsomeLibrary V2.3 because this is what we plan to use”). This will go into your job offering description. It’s important that whoever reads it gets a good idea of what the position is about. You want to attract the talents – make sure to put in whatever makes your position interesting. Note down the desired experience level for the major areas. If certain skills are good to have but not absolutely required note that, too.

(4) The final touches for your job offering

Add a general overview about your company, your setup and why it is fun to work with you. Then get your job offering published on the platform of your choice. If you are looking for contracted resources for a limited time period there are freelancer project portals. Or companies specialized in hiring out. Or if you work for a larger company you’ll anyway involve HR and they’ll place the job offering for you.

Permanent hiring or contracting?

How about permanent hiring vs. contracting? You may wonder why there was no differentiation so far. Isn’t offering somebody a permanent employment totally different from contracting for 6 months? Well, yes and no. In 6 months (or whenever your contract ends) it will feel very very different. And filling a permanent job position may take some extra lead time. Otherwise – for your team it will feel very similar. There will be a new person that needs to be onboarded, go through the ramp-up phase, go through the team norming and storming phases until finally the first tangible results show up. You don’t want to go through this more often than required, so choose your team members wisely.

When will you try to hire permanently? In today’s volatile world companies are more and more reluctant to engage in long term. Not good, but this is often how it is. So you may not be allowed to hire anyway. If you have a choice think about this: your software will most likely never be ‘done’ once and for all. Whatever software is used in real business life will need at least some maintenance, and new requirements will come up sure as day follows night. Each person leaving takes knowledge away from the team and reduces the team performance. New people will need to go through the learning curve again. It takes teams usually several months in stable setup to reach peak performance. Whenever possible you should go for permanent jobs, unless you have a project with definite end date at hand or need very special skills over a short time period. Today ‘permanent’ does anyway not mean ‘forever’ any more.


Continue reading here:


 

Rate this post:
[Total: 0 Average: 0]

Leave a Reply

Your email address will not be published. Required fields are marked *

Thanks for commenting. This form collects your name, email and content so that we can keep track of the comments placed on the website. For more info check our privacy policy where you will get more info on where, how and why we store your data. Your email address will not be published or shared with anyone. Please check this box before submitting your comment.