Guy's Blog Blog from June, 2009

By now everyone will know about us making our plugins free - for those who missed the initial announcement, here's the slides and some notes on what I talked about...

We're growing

Most people don't realise how fast Adaptavist has been growing - we've been doubling in size every year (in terms of staff and customers). In the last financial year, we saw turnover increase by almost 400%.

This massive increase in turnover was caused by the services side of our business really starting to kick in - something we've been working on for the past two years.

We're evolving

While we still work with lots of charities and smaller companies, the majority of our customers (and turnover) relates to large enterprises - governments, military, finance sector, education, telcos, etc.

As a result, we've had to evolve every aspect of the company to be much more in-tune with larger customers and bigger projects. At the same time, we don't want to prevent smaller organisations from using our plugins.

Part of our evolution has led us down the path of what is increasingly known as "Constructive Capitalism". If you've not seen it yet, I highly recommend watching this Daytona session with Umair Haque - it'll give you a great insight in to the way we think and the direction our business is taking.

People, not product

Overwhelmingly, our customers want the skills of our people, not a bunch of products. Products are really just tools on our utility belts, it's the specialist skills of our team that our enterprise customers value most.

As a predominantly transactional company, shifting increasing numbers of product licenses each month, our team were bogged down with lots of small sales, invoices, license key generation and management - all of these things made it much harder for us to fully dedicate our team to the needs of customers.

Connections, not transactions

Our larger customers don't want to just buy something and never hear from us again. They're looking for a company that will help them get set-up and then work with them to ensure the project is an ongoing success and wherever possible enable them to take full ownership of the delivered services.

In addition, larger customers want much more in-depth support than a transactional license-based model can provide. Likewise, smaller customers don't want to subsidise the extra support load we get from larger customers.

Creativity, not mass production

Note: In "Constructive Capitalism" this is termed "Creativity, not productivity" - while it sounds better, we have to stress that productivity is vital: things need to get done. We tweaked the title to "not mass production" as we feel that's far more accurate.

In short, one size does not fit all. It never has, it never will. Yet with licensed software, that's generally the direction things always take - something we want to avoid at all costs.

By focusing much more on the services side of our business, we can offer solutions and services that are far more tailored to the specific needs of each customer. We don't want to be all things to all men - we want to provide specific solutions on a project by project basis that achieve valuable outcomes...

Outcomes, not incomes

This has been by far the biggest shift in our business to date. When we were just started out, our sole focus was on incomes. You can't start a services business without existing revenue streams - put simply, we needed money otherwise we wouldn't have survived. The transactional product model enabled us to do this, but only as a stepping stone to longer term goals.

As our business grew and, in particular, the services side of the business became self sufficient and eventually dwarfed the transactional products side of the business, we were finally in a position to make the transition from valuing incomes to valuing outcomes.

When you offer services that provide customers with exactly what they want, they pay for them. You no longer need to focus on lots of little incomes, services are all about outcomes - make them spectacular and your incomes will also be spectacular (like a 400% increase in just 12 months).

Tomorrow is today

Why put off to tomorrow what you can do today?

Constructive Capitalism depends on sustainability. We've all seen what old-school capitalism leads to - raping the environment, coercing people, waging wars with competitors, etc., has led to global recession the likes of which have not been seen in the past 200 years.

So, we were faced with some challenges to not only our own sustainability but also that of customers and even Atlassian partners:

• Transactional products were dragging our company backwards, in opposition to the services that were dragging us forwards - we were tearing at the seams.
• As more large enterprises get in to collaboration, several changes take place:
  1. They need better services - and we want to be there to give them those services
  2. The collaboration sector changes to favor large enterprises, pushing out smaller enterprises in the process - yet it's those smaller enterprises that bring the most innovation and are tomorrow's large enterprises
  3. Increased pressure is placed on service providers - they need to cut costs and increase profits

By making our plugins free, we can:

• Focus on services that are needed by large enterprises
• Reduce barriers to adoption for smaller enterprises, making it easier for them to compete
• Enable competitors to offer new services (such as services, support and customisation) based on our products

That last point makes lots of people think we're nuts, but think about it:

• Stronger competitors forces us to constantly improve and adapt = we become stronger
• This results in a far better range of services for customers
• Customers can do more with less, making them stronger
• More customers enter the market to take advantage of the great ecosystem
• More customers means more work means a stronger ecosystem

Everyone wins. It doesn't matter that our competitors take a slice of our pie - in doing so the pie gets bigger and we get stronger and our customers benefit more.

It's therefore no surprise that...

Theme Builder is now free

Allowing customers of all sizes to customise their wikis - making them easier to use, adapt them to different kinds of uses (documentation, websites, etc) and so on.

And...

Community Bubbles is now free

Allowing customers to increase adoption by not only making people first class citizens, but using things like forums to change the interaction model within certain parts of the wiki - think about it, have you ever created a wiki page to ask a question? It just doesn't feel right. A forum topic, on the other hand, is a very natural place to ask questions - that's what forums are for.

Existing customers

Existing customers obviously now get free upgrades for life = WIN!

They also get to keep their existing support period - because it's for a specific plugin, it's cheaper than more encompassing support contracts.

New customers

New customers no longer need to battle with our crappy transactional sales processes and have no barriers to adoption. There's nothing stopping them from trying the plugins and, just as important, there's nothing motivating them to keep using the plugins if they don't like them.

Need direct support?

Most of our customers are happy with community support. It never ceases to amaze me how many software vendors assume that their customers are thick and need support - customers are clever (they wouldn't be in business otherwise) and can sort out most problems for themselves. If a customer needs support, they know how to find it - it shouldn't be shoved down their throat if they don't want it.

We've been making changes to our support services to make them far more useful to customers who do need support, in particular we often find that customers don't need support due to lack of skills, it's often lack of time that makes support contracts useful - the ability to get questions answered very quickly, instead of always having to wait until time can be allocated internally.

And because one size does not fit all, our support service can be extended with service level agreements - customers who need things dealing with faster can subscribe to a higher service level that provides guarantees on response and resolution times, as well as different contact methods (like telephone and email).

Future plans

Theme Builder and Community Bubbles are damn important to Adaptavist, and our customers. And even our competitors and their customers.

As a result, we're not going to neglect them. We're going to keep working on them, making them faster, more stable, more scalable, easier to use, etc. Development will be an ongoing process.

Larger customers now also have the ability to pay for modifications to the plugins - both the general releases but also private releases that meet their specific needs. This is something we couldn't really do under a transactional product model.

We are also going to be open sourcing the plugins, but its going to take some time - we've got to rewrite our contracts, licenses and remove any commercial libraries from the plugins.

We value outcomes

We're now a services company, not a transactional products company. As such we value outcomes. That's what our customers want and what they pay for.

We've been making massive internal changes to the business to ensure that we can interact with customers in a more streamlined manner (a new service will be appearing in a few months that will reflect this) and achieve a much deeper focus on customer needs.

Your wiki, our speciality

Need I say more?!

I've just sat in on one of the weekly team meetings run by our dev team - they've been getting really good at these meetings lately so I thought I'd share some of my observations...

There's lots of other stuff that can happen in meetings, but the core foundations are listed here - without these core components, the meeting will be a shipment of fail.

Before the meeting

Start by creating a wiki page for the meeting (at least 3 days in advance):

• Page title should be in "yyyy/mm/dd - meeting title" format
• When / where will the meeting will take place
  • If it's a webinar or teleconference be sure to include login details, PIN number, etc
• Who is attending
• Outline the objectives and the agenda (which should be based on objectives)
• The first objective should be "Weekly roundup" - each member of the team recaps what they've been working on since the last meeting

The meeting should last for roughly 1-2 hours depending on the topics covered. Most team meetings last about 45 minutes.

Above all: The meeting must happen! It doesn't matter if key people aren't able to attend, the meeting must go on.

Chairing the meeting

The meeting should ideally be chaired by a project manager, not the team leader. The chair is responsible for making sure everyone takes part and recording notes from the meeting.

In face-to-face and webinar meetings, it's a good idea to make sure everyone can see the agenda page in the wiki. As soon as the meeting starts (see below), the page should be put in to edit mode so that the chair can add action points and tick off objectives and agenda items.

The chair should tick off objectives and agenda items as they are discussed (in wiki notation use (/) which gives ) - you can then see at a glance what's been discussed and what hasn't.

About an hour before the meeting starts, the chair should Yammer (or use some other form of group notification system) the start time and ask participants to get in touch for the meeting wiki page URL. This allows the chair to quickly ensure that required participants are online and ready for the meeting - as well as flagging up any missing participants who can then be located prior to the meeting.

At the start of the meeting

Allow a few minutes for everyone to get settled - but as soon as everyone is ready idle chat must stop so the meeting can start.

Each member of the team should start with a quick recap of what they've worked on since the last meeting (remember, these meetings are weekly) - in particular where are their projects up to and are there any problems.

To keep these recaps short, ignore things that are going well - if a project is finished, say that and don't elaborate. Save time for discussion of any problems.

If any problems are raised they should be added to an action list if they can't quickly be dealt with during the recap.

Middle of meeting

Once everyone has recapped what's happened in the last week, discuss upcoming projects and events, changes to procedures, etc. It's at this stage that the key meeting objectives start getting ticked off.

End of meeting

Any longer topics need leaving to the end of the meeting and need to be strictly controlled by all participants so they don't run on for too long.

In the meeting we've just had, the "long topic" was a discussion of our plugin release process both for open source plugins and also bespoke plugins commissioned by customers. We identified that some additional info was needed on project wiki pages in our intranet so that any member of staff can quickly determine a) when the plugin will be released and b) who it can be released to (eg. is it open source, or just for a specific customer).

All of these notes were added to the meeting page as well as an action item to write some formal documentation in our developer intranet.

A key ending point is to check over the objectives and agenda to make sure everything has been done, make sure the action points are assigned to people responsible for doing them and then arrange the next meeting (usually same time next week).

In-meeting chat

You should also have some sort of IM or other chat service available to meeting attendees - both for broadcasting info (such as "look at this URL which relates to the topic we're now discussing) or direct messaging. There will often be small bits of information that need sending to everyone or one person during the meeting, often resulting in discussions being cut short because problems have been dealt with via text chat.

An example - if someone has a problem with something, while it's being discussed someone might IM a URL to a likely solution, which can then be quickly checked to see if it will work - if it does, end the discussion in the main meeting and remove the action point that was added to address the problem after the meeting.

Remember that Adaptavist is a bit of an odd company...

I must remind you that all our staff work from home - getting together for a face-to-face meeting is a bit of a nightmare, particularly when you have people working in different continents / time zones. As such, we've been adapting our weekly team meetings to make them highly efficient, focussed and effective.

Members of the team are constantly communicating with one another at all times via IM, Yammer, twitter, VoIP, Confluence and JIRA - the weekly meetings are designed to punctuate the distributed conversations in to one focussed meeting of minds, ensuring that everyone knows what's happened in the last week and what's going to happen next week and at any upcoming events.

Almost everything that's discussed in the meeting is usually already available in our JIRA issue tracker or Confluence wiki (the intranet parts that the public can't see) and has often been discussed between two or more members of the team prior to the meeting. The meeting either confirms or clarifies discussions held over the past week and ensures that everyone is aware of what's going on.

Now, if only we could make our management meetings that organised...