What are good ways to structure a group that has both a product development team and a professional services team

Question

I am the development manager for a small software company. My team focuses on developing our product, and we have some partner companies that do the "professional services" work for our product: things like developing custom add-ons and doing user training and system implementation. We are planning to start doing some of that professional services work in-house, because some customers have said that they would feel more comfortable working directly with us.

Does anyone have experience with this kind of thing? I'm trying to figure out how to structure the development resources for this new team.

One option that comes to mind is to just add some new people to our main development team and then have everyone rotate through that job. This would help spread the knowledge around, but I think that some of the developers would be unhappy about switching projects like that.

Another option would be to form a separate development team to be responsible for the new services work. This ensures that people can focus on the work that they like best, but it has the downside that the new team might not inherit the strong culture of quality that our main team has.

Are there any other options that I'm overlooking?

Answer 1

I see a few approaches you may choose to tackle the situation:

• Have separated teams to deal with professional services and product development (you mention this one). On the plus side: you can recruit people in a way they do what they like -- some of them would prefer building new products and others would enjoy contact with clients. On the minus side: building two separate teams would probably make communication between teams more difficult and you might appreciate shorter feedback loops between your clients and the development team.

• Have people in the development team taking professional services gigs as a rotating role (you also mention this one). On the plus side: feedback loops between your clients and development team will be shorter and you may actually find people in your team who deal with such engagements astonishingly well, even though you wouldn't know unless you actually tried it. On the minus side: it is likely some people in development team would hate the job and if their turn takes like a few months they may get frustrated and leave. Also if you don't organize it in a way that everyone get their own fair share of the workload it may bring some unnecessary conflicts to the team.

• Make professional services tasks a voluntary assignments. On a plus side: feedback loops are short and you likely to find people who actually like such tasks and are willing to take them. Also you may find people who just want to try it just once, to see how it is and, even if they don't really like it, they definitely learn a lot from such events. On the minus side: you may and up with no one really willing to do some tasks so you need some kind of backup plan either way. Also it may mean that some of folks who are crucial for your product development are also those who are most willing to do professional services work so you might need to make some tradeoff decisions.

• Just put professional services endeavors to your work queue so whoever is free at the moment would get the task. On the plus side: you make your feedback loops short. Also eventually everyone will try to do such tasks and see how it is like. Not only will they learn a lot from that experience but also they will share the pain with clients, if there's anything to share that is. On the minus side: quality of some of your professional services might be a bit worse as not everyone is great at such work, especially when we're discussing developers. Also it means you will be trying to make some sort of generalists out of your people which means quite a big investment in learning.

You can pretty much get any of these approaches working well so if I had to choose one I'd consider who I have in the team and would choose one of paths basing on what's going to work best with the people. It's always all about people.

Answer 2

I would say that when it comes to adding a professional services team, you need to form a team that contains a very specific set of skills. Communication skills are important for any role, but when it comes to professional services, you need developers with outstanding communication skills, who are extremely smart, and who like talking to people.

Because some developers prefer to keep to themselves, this may prove difficult.

The developers who would fit these roles would command a much larger salary than the developers who build your product.

It's also important for developers to have domain knowledge of a product, system, or feature. This factor may prevent job switching. It's very time consuming for a developer to switch from a product he/she built to one that he/she knows nothing about. Your professional services developers will be no different. In fact, the professional services developers will need to have a very strong mastery of the subject, feature, or product that they are building or extending for the client, and they'll have to have knowledge of the business problem or domain problem that the project is supposed to solve.

One approach to ensuring professional services developers know the product and domain is to select them from the existing team by advertising the position internally and having interested developers interview for the position. You'll want to select candidates who are passionate, smart, and who know their stuff. Remember, you're trusting this person to accurately and professionally represent your product and company to a client.