Last Thursday there was another Drupal CXO event. It was the first day of the Drupal business days in Vienna. Microsoft was the host for the event and the first item on the program was a tour of the their office in Vienna. I have to say it was a pretty cool place with plants on the walls and as main asset a slide!
As with the other CXO events the format for the sessions was open space. That means everybody could propose subjects they wanted to talk about. There were 3 tracks with all kind of different subjects regarding running a Drupal shop. From marketing to partnerships to agile processes. I will give a short summary of the sessions I attended.
The first session was about marketing Drupal. Now that Drupal is running 2% of the web and is gaining in the enterprise world we should really think about ways to build the Drupal brand. A lot of Drupal shops are serving customer that already decided on Drupal before they approached that shop. But there are of course a lot of potential customers we should try to reach to grow Drupal.
The central point of information, Drupal.org, is still targeted on users that build sites, like developers and themers, and does that very well. It does not give any answers on the question "What problems can Drupal solve for me?" though. To really help grow Drupal we should try to reach potential customers outside the community like information and marketing managers. They want to know which of their problems could be solved by Drupal.
The big question is how to do that. What is the best way to reach those people. And how do we know what they really want. I think it would be a good idea to have a central organization that can push the marketing of Drupal. There is an initiative now for creating a committee in the Drupal Association especially for marketing. I think this is a good start and hope it will be realized. There is however a lack of marketing knowledge inside the community. Developers just aren't great marketeers. So it would be great if we could get a marketing expert on that committee to help us find the right way. Some people suggested that it will only work if you hire someone to do it. In that way you make that person really responsible.
All Drupal shops also should realize that everyone inside your organization is a sales person for Drupal. Being enthusiastic about the product you work with can be a real strong marketing tool.
Another great marketing tool is organizing events. Nodeone for example organizes a "Drupal discovery day" every year and 300 people show up. I think that is a great initiative to make Drupal more known outside the community and I hope more companies will follow with events like that.
Building teams and finding new talent
The next session was about finding new talent and building new teams as your company grows. Now that Drupal is getting really popular the demand for Drupal developers is huge. Everybody is struggling to get the right people and almost every Drupal shop is looking for new people. So how do you find them? Should you use distributed teams? How do you make a good selection?
There is only a small pool of real (good) Drupal developers. Most companies hire good PHP developers and train them to become Drupal developers. Finding developers that will become good Drupal developers can be hard though. They usually have to switch to another mindset. A good assessment or code test can help find this out. We talked a little bit about certifications, but we all agreed that a certification doesn't tell if someone is a good Drupal developer. You also should not expect them to be really productive in the first month if they have no Drupal experience. There is a lot of good training material available online that can help you with the training of your employees like Drupalize.me and the screencasts by Nodeone.
It might also be possible to let another company train your people. In the Netherlands we have Wizzlern and they can give in all kinds of different Drupal training.
An interesting idea in the session was to be more visible at schools and universities. Possible ways to do that could be giving guest lectures or Drupal discovery days aimed at students. In that way young people get to know Drupal and hopefully get interested and are going to learn more about it. Of course this would also be a great opportunity for your company to scout for new talent. I think this is a real good way to secure the pool of Drupal developers for the future.
We also talked about the problem of finding the Drupal developers that are out there. It would be great if there was an online resource where we could find available Drupal talent. We even suggested to build a new site over the weekend to facilitate that. Of course, that didn't happen.... And I think a normal job site would not be enough for this problem. I talked a few times with Steve Purkiss about this during the weekend and he has some great ideas for building a new platform to find the right people for the right job. I suggest to follow him to stay updated on his plans. Another site to keep an eye on for the German market is Uberjobs.
If there is such a platform it also would be easier to create distributed teams. The pool of developers for distributed teams could be potentially much larger because the restriction of location is not there anymore. Working in distributed teams can be a challenge though, especially in agile projects. My experience is that you want all that are involved in an agile project on one location.
A good source for more information on hiring tech people is the blog of Joel Spolsky.
Agile design and UX
In this session we talked about how the incorporate website design in an agile project. One of the most important things is that designers should look at a website in terms of flow and elements instead of complete pages. For a lot of designers this is not what they are used to doing.
It's also essential that the team is together. The drop in productivity with distributed teams in agile projects can be up to 50%.
Wire-frames can be of great help in an agile design process. Let the client see the wire-frames and train them to see what they mean. Not designing everything in detail will of course save you a lot of time.
In an agile project the design team should be somewhat ahead of the development team. Usually a week is enough.
Selling Agile contracts
The session morphed into the topic of selling an agile contract to your clients. Almost everybody who is developing websites sees the benefits of the agile way of working. For a lot of customers this is still new and they will often be hesitant to accept an agile project.
In agile projects metrics like the velocity and backlog size are very important. This makes the process really transparent for the client. They can exactly see why the project takes longer than expected in case of a delay. The business gets nervous if they have the feeling they are not in control. With the metrics you can keep them informed at every time. Clients wants to be in control and with the metrics you can show them the control they have. They can control how to handle any delays.
The uncertainty is also much more visible for the clients which can be scary at first. In a classic waterfall project failure is not part of the project. In an agile project failure is used to learn and succeed in the long run. Try to convince the customer that you can't know everybody up front. 100% certainty is an illusion. If they have experience in waterfall projects ask them if any of those projects were done within budget and on time with the desired scope. Almost always they will have to answer that that is not the case. It's simply not possible. Try to convince them that you are going to explore the space with them and that the process will adjust the result to their business needs.
Client references can be a good way to convince the customer of the advantages. Also make it more concrete by finding some videos online that explain the agile process. If it's really hard to convince your customer you can maybe give them something for free to win their trust. You can do a grooming session and write user stories or even do one sprint for free.
Don't be afraid that you will miss out on clients because of your way of working. If they really want to choose for a company that still does waterfall projects let them go and let the other company fail. Find the people you want to work with and stay working with them. Maybe if a customer really does not want to do agile, you don't want the project.
The event ended with a dinner in a great place in Vienna with a stunning view!
After the CXO there were another 2 days of sessions. In the next few days I will try to write a blog with a summary of those too.
Triquanta was very happy to be silver sponsor of the event.