You want to hire a new developer to
support your team, or want to build up a new development team? New
trends show how everybody is investing their money in software
development. In my opinion, every company today has to do some
software (or should), but there are very different ways to go about it.
You could have some kind of project managers supervising an outsourced
team in Bangalore or Rio doing your software. If that works for you be happy, but you should
be aware that you are not investing in software as in creating value
for your company. Your software is costing you like you were leasing
a machine. Lots of companies have found out the hard way, that this model
does not suffices. Different to leasing a machine, you will not get the new model in 2 years just like that. In order to be competitive in today's market you need
to invest in the knowledge that is reflected by your software
applications and house them intern. If your company has decided to build
up a team of developers for this purpose, I can probably be of some
help.
For
this article I will assume you are sure you want to build a software
application of some sort (or are already developing one or several) but
are considering hiring new people. I have been on both sides of the
interview table and I would like to share my impressions with you,
hoping this might make a better world for both, the developer and you:
the manager hiring them.
Here
is a list of possible roles for developers in a team. Later I will go
into details of how you figure out which one is the one you need. How do
you find out the skills of interviewees is a complete different
question, that I will try to sort out another day. I do have some tricks and methods I've developed over the years.
The first thing to do is to be sure of what position you are trying to fill exactly. In order to do that you will need to understand what kinds of developers you will find out there:
The first thing to do is to be sure of what position you are trying to fill exactly. In order to do that you will need to understand what kinds of developers you will find out there:
Lead/Chief developer:
the guy who figures out everything before everyone else and has a very
strong opinion on how to do things.
Of course he is a programmer, not always the orthodox one. He knows all
the rules but might choose to break them now and then. He is proficient
in lots of languages (computer and natural) and is tough discussing with
(needs a whiteboard all the time). Can make points extremely clear and
when confronted with facts does not get emotional. He can listen to
others too and actively tries to understand the point of view of
different people. If you have a classic team of 5 you need one of these
on the team. It scales only linear, because this guy does code review for
most of your application's software (even if the team members don't
notice).
Application/Software Designer:
a visionary. This guy can see the future. No kidding! This is the guy
that makes from your software an application by giving it a purpose. He
has been an excellent programmer for most of his life, but it was the
means to the goal. He has done all: logic, object oriented,
functional and procedural programming (I probably left some out). He is
not religious about it. He knows that from great software
comes great responsibility and stands by his design. He is creative (he
probably plays some music instruments or paints). Depending on the size
of your application, you will have one or two of these for redundancy,
no more. Don't mix him up with a so-called software architect (see
below). He will only be able to take care of a certain amount of
software, i.e. an application of a certain size. After hiring this guy
you will be talking mostly to him (if you are the product owner). He
will be the first point of contact to your application, knowing things
your application could do before you, but also showing you the limits of
the current design.
Features/Software developer:
senior or junior (depending on experience) you should try to have 5 of
these guys in your team. Not everybody is a leader. You need this
positions to get the work done. These people understand things fast and
are on the border of being obsessive compulsive about The Build.
They are masters in unit testing and they all can Linux --no exception.
They handle the back log on their own terms and tackle the application
one task at the time. They are interested in peer review, resistant to
criticism (in the good way) and are excellent team players (which is the
tricky part). Most of these guys would solve the same problem in
different ways, just to try something different. They learn fast on
their own and would go the extra mile for something they consider to be
the coolest solution.
Integration/Test developer: again
with experience or junior this guy is not the QA. This is also more a
role than a steady position. You will want to keep this rotating among
your developers. You need a guy to take care of the difficult parts of
testing your application. Some designs get complicated with time and you
need a developer that has a clear understanding of the how of the software more than the what
(that would be QA). While your normal developers should be
able to test
the software they write, there is much more to the software than just
the sum of its components. This is where this guy comes in: by not
having to directly add features to the software he is able to focus on
how to test the interaction between components. He creates software to
assist the testing of your software. Part of this job is also to look
into design concepts and make prototypes together with the designer,
figuring out the best way to integrate new ideas into your system.
Software Architect: this
is probably the most misleading role of all. An unhappy analogy to
construction work in my opinion, but the name stuck around (although in
some countries this is an official title and you can not call yourself an architect). For certain size of
applications (or complexity) you will need a guy that takes care of
putting all things together by enforcing standards and trends. Most
companies see this as an overall consultancy job, which in my opinion is
not correct. This guy should be in constant dialog with the designers,
because he will not be able not follow the developing of the application
to the point of understanding every detail. Why you need him then? If
your company is big enough to have mixed environments and different teams
with different sets of skills, you will need a guy that levels
heterogeneity by trying to apply common sense to your system. He would
need to have his hands on the software at certain level. He should be
capable of doing the things he wants and to enforce them leading by example.
How do you decide who do you need?
If you start from Zero, then it is easy: you will need to hire someone to help you hiring others. This task would be best fitted by a Lead Developer or a Software Designer. In fact, every developer you hire first will automatically become the lead developer (at least for a while). The difference to a Software Designer will be very small at the beginning, so there is no point arguing about who should be first. For a very small team, this roles are in my opinion interchangeable. This guy can help you defining your application and will be able to refine your ideas and make them into software. He will help you build your team.
If you are already running a team of developers, the task gets more tricky. I'll go by the size of your team. If you have less than 5 members, then first check the roles above to see what you already have. Probably some of the roles overlap. This seems to be a common state out there. Try to pin down the role of the Lead Developer. If you already have one (and are happy with him, if not, this is the guy you are looking for!), then both of you together should consider whether a Designer is needed yet. This depends on the size of your team and the complexity of your application (or the complicity that you expect in the future). If you feel like you need more hands to do stuff, but cannot tell what way your application is going, you could hire another Application Developer and reconsider the Designer position later on.
If you have a team of 5 or more, you should be looking into structuring it. Again pinpoint your roles and fine out the closest one to the Lead Developer. He should be able to tell you how to divide your application developing into 2 groups. Teams larger than 7 members are hard to handle and not very productive in the software world. You will find it all over the literature about software teams and developing methods like scrum, extreme programming and that kind of agile stuff. That number is mostly based on experience. The upper limit is 10 members, then you will need to split it. At this point you should be looking to hire a Software Designer. Different groups tent to do things different and evolve their own dynamic. The Software Designer is the one that will allow you to synchronize results into a common vision: your application. At this point, the teams will be too big for you to manage directly, and you will have to trust the application developing to the Software Designer and your Lead Developers (yes, one per team).
If it hasn't happen yet, you will need to appoint one of your developers to be Integration Developer. If you don't have the man power, you should be looking for someone to fill this role. In my experience this is a difficult place for anybody to start in a new team, and it becomes very challenging for a Feature Developer to do both things. You don't want to hire an Integration Developer from scratch, because his ramp-up phase would cost your team more productivity than the ramp-up phase you'll need for a Feature Developer that can start small doing pair programming.
The last person you will need, if your application becomes really big, is a Software Architect. You'll be probably be willing to ask around in your team if someone wants to become this before you look to hire one from outside. Unless you are trying to introduce new technologies, techniques or infrastructure for which you could use some experienced outsider (in big companies, this happens more often than you'd think), you will be better off putting a motivated developer, that already knows the application, into that role. You should prepare a plan together with him of how he can work in the necessary skills for this position (seminars, technology certifications, etc), and how to gradually handle over developer tasks his successor.
I based this guide in personal experience and that of friends of mine that were in need of hiring developers into a non typical software domain. I have been a developer in a start-up, a middle sized and a large company, each time dealing with projects but also product development. The hardest thing to understand is that although you can make software like you do other projects (planing, specifying, implementing, blaming), you will by far not be as effective and qualitative as a dedicated team would be. The capital represented by your applications is not the software itself nor its features, but the team that holds the knowledge to do them.
If you do not understand software development it is OK, as long as you understand your team.
If you start from Zero, then it is easy: you will need to hire someone to help you hiring others. This task would be best fitted by a Lead Developer or a Software Designer. In fact, every developer you hire first will automatically become the lead developer (at least for a while). The difference to a Software Designer will be very small at the beginning, so there is no point arguing about who should be first. For a very small team, this roles are in my opinion interchangeable. This guy can help you defining your application and will be able to refine your ideas and make them into software. He will help you build your team.
If you are already running a team of developers, the task gets more tricky. I'll go by the size of your team. If you have less than 5 members, then first check the roles above to see what you already have. Probably some of the roles overlap. This seems to be a common state out there. Try to pin down the role of the Lead Developer. If you already have one (and are happy with him, if not, this is the guy you are looking for!), then both of you together should consider whether a Designer is needed yet. This depends on the size of your team and the complexity of your application (or the complicity that you expect in the future). If you feel like you need more hands to do stuff, but cannot tell what way your application is going, you could hire another Application Developer and reconsider the Designer position later on.
If you have a team of 5 or more, you should be looking into structuring it. Again pinpoint your roles and fine out the closest one to the Lead Developer. He should be able to tell you how to divide your application developing into 2 groups. Teams larger than 7 members are hard to handle and not very productive in the software world. You will find it all over the literature about software teams and developing methods like scrum, extreme programming and that kind of agile stuff. That number is mostly based on experience. The upper limit is 10 members, then you will need to split it. At this point you should be looking to hire a Software Designer. Different groups tent to do things different and evolve their own dynamic. The Software Designer is the one that will allow you to synchronize results into a common vision: your application. At this point, the teams will be too big for you to manage directly, and you will have to trust the application developing to the Software Designer and your Lead Developers (yes, one per team).
If it hasn't happen yet, you will need to appoint one of your developers to be Integration Developer. If you don't have the man power, you should be looking for someone to fill this role. In my experience this is a difficult place for anybody to start in a new team, and it becomes very challenging for a Feature Developer to do both things. You don't want to hire an Integration Developer from scratch, because his ramp-up phase would cost your team more productivity than the ramp-up phase you'll need for a Feature Developer that can start small doing pair programming.
The last person you will need, if your application becomes really big, is a Software Architect. You'll be probably be willing to ask around in your team if someone wants to become this before you look to hire one from outside. Unless you are trying to introduce new technologies, techniques or infrastructure for which you could use some experienced outsider (in big companies, this happens more often than you'd think), you will be better off putting a motivated developer, that already knows the application, into that role. You should prepare a plan together with him of how he can work in the necessary skills for this position (seminars, technology certifications, etc), and how to gradually handle over developer tasks his successor.
I based this guide in personal experience and that of friends of mine that were in need of hiring developers into a non typical software domain. I have been a developer in a start-up, a middle sized and a large company, each time dealing with projects but also product development. The hardest thing to understand is that although you can make software like you do other projects (planing, specifying, implementing, blaming), you will by far not be as effective and qualitative as a dedicated team would be. The capital represented by your applications is not the software itself nor its features, but the team that holds the knowledge to do them.
If you do not understand software development it is OK, as long as you understand your team.
Kommentare
- Windy -