CTRL-Shift-Escape - #3
Developing the developers
We've grown our business organically and carefully. We started with a product idea and for at least 5 years put a lot of time into development without really selling a lot. As the product got more comprehensive, we created workload in our support team and invested in good people and good systems so customers were well looked after.
The market matured and we had a good reputation for service, so needed more sales people to spread the word. Sales went well, so we had a lot of pressure in our projects and testing teams. And on it goes - every time we build up a department we create positive pressure elsewhere. If there is such a thing as an 'equilibrium state' we haven't found it in the last 20 years.
We've got some big product ideas (and yes, some of them include AI of course!) so this week we've been discussing our plans to significantly increase our software dev throughput. More people will certainly be a major part of the plan, but we are also looking at the structure of the team, release cycles and also the working environment.
We have a very senior team (I won't call them 'old') with very wide skills. It's a great opportunity for us to mentor the next generation. We've hardly ever used contractors and never outsourced or off-shored our development. It's essential to us that we are completely invested in our core products, so we can support them and continually improve them, and that works best with a growing in-house team.
And of course, we are going to create a backlog in our software testing and documentation teams...
Recommended by LinkedIn
Building a sales machine
Working 'on' the business rather than just 'in' the business I've been taking a look at how we manage our sales processes. In some places it really isn't pretty! We have a lot of opportunities to make life easier for ourselves and also make it easier to buy our products.
The catalyst for this has been implementing Hubspot. It probably wouldn't have mattered much which system we'd chosen. Consolidating many systems into one forces us to challenge and change how we do things. To put it into perspective, in the next 6 months we will switch off
It's been surprising just how many processes we have that span multiple systems and are harder than they should be.
Let's take the humble sales enquiry. We have a form on our website which allows people to request a call. It asks for email and/or phone number and also whether they want a morning or afternoon call. That generates an email, which we then reply to.
It clearly makes no sense to ask for a phone number and time, when we always email back! We are going to sit down and work out exactly how this should work for a customer - with the aim of giving them exactly what they ask for and very quickly.