Building software development company challenges

California dreaming

Last November I had the privilege of spending the month living in and exploring Silicon Valley and the surrounding area. Whether you live there yourself or not, you’re probably familiar with many of the place names and certainly many of the companies that can be found there. I was thrilled to take office tours at a number of tech giant offices, including Facebook and Google. I was even more excited (and a little surprised) to discover the incredible natural beauty to be found in Northern California!

Turns out Yosemite is more than just an OS version, who knew! I’m kidding of course, but there are plenty of less well known national, state and even county parks that are well worth exploring too and it was when I took the family for a day in Big Basin Redwoods state park (just outside the valley) that I was struck by the story of the mighty Sequoia and its dependence on forest fires to survive and thrive.

The redwood story

The majestic redwoods are ancient (in many cases centuries and even thousands of years old) but in the 1960’s it was noted that new trees weren’t emerging and the number of sequoias was therefore decreasing. The reason for this, it turned out, was that park administrators had always had a policy of suppressing fires as soon as possible after they were noticed, ever since the establishment of the national park system back in 1890. This was done with good intentions, to limit the risk that the fires posed to property, life and (it was assumed) to the parks themselves.

It seems like a logical policy, fire destroys and the effect of such wildfires can be devastating as we’ve seen recently. For the sequoia though, forest fires are actually needed for their survival! Their pine cones only open up to release their seed under the high temperatures experienced during such fires. Furthermore, the fires expose bare soil for the seeds to take root in, recycle nutrients in the soil and clear patches in the canopy that allow the young trees to get enough sunlight to grow and succeed.

There are a lot of other benefits that the fires provide, not only to the sequoias but to their entire forest ecosystem. One key benefit is that if there are relatively regular small forest fires (unsuppressed they appear to occur on average once every 9 years in nature), it gets rid of the build up of undergrowth that could otherwise fuel much more damaging larger fires.

Why are you banging on about nature in a technology blog?

This natural system is fascinating and I recommend that you look into it further, but the real reason I’m going on about nature in this post is because of how deeply I was struck by this concept:

The world’s biggest trees need forest fires to survive!

Think about it. Businesses faces all sorts of challenges and problems over the years. Very often when faced with a problem we look for a way to squash it as quickly as possible and move on. But what if we actually need such ‘forest fires’ in order to grow and survive?

The challenges we face

Looking back over the last seven years of building a software development company I can think of several different fires that we’ve fought, as a result of which we actually became stronger, more resilient, and after which we grew as a company. We’ve grown in terms of profits, the number of people we hire and the number of projects we can take on; as with the trees, the fires have enabled us to multiply.

I’m going to talk you through a few specific fires that we’ve faced and how they’ve affected us in the long term. My intention in sharing this is so that you don’t panic when you encounter a fire in your own business. Some fires are good and can help you to grow. Some big, unstoppable fires obviously are bad; fires that damage your corporate culture hurt your very roots and need to be put out as soon as possible. But for many smaller fires, this process can actually help lead to growth and success. Virtually any fire can hold the potential for growth, but here I’m going to discuss the following cases:

We’re offered a great project but it’s harder than anything that we’ve done before and seems like it’s a little over our heads.
A key member of staff leaves the company.
There’s a spike in the workload and we have either much more or much less work than usual.

In each case I’ve split the problem into three parts:

Analysing the size of the danger (even though they now allow some fires and even start some themselves to keep things under control, the park services would always put out a fire that risked endangering life or property).
Responding to the problem
Noticing the opportunities for growth

Case 1 – The “Difficult Project” Fire

Assess the danger. Obviously we want our clients to only ever walk away at the end of the development process with a top quality app or site, so a particularly juicy looking contract for a project which we know will be a challenge for our developers needs to be weighed up carefully. In considering the project, talk with your developers about the difficulty of the technology involved and how long they think they’d need to get familiar with it. Dedicate some time, maybe half a day, to doing some research into the technology to determine how realistic it is that your team can pick it up and make a quality project with it. In my experience, our team is able to handle any new technological challenge as long as it’s within the programming languages that we specialise in, but each new challenge needs to be thoroughly assessed before the project is accepted.
Respond to the problem. To deal with a difficult technological challenge, you should try to become familiar with the technology yourself; you want to make it clear that you’re in the same boat as your team, not just giving them something new and leaving them to it. Now find your most creative, thrill seeking developers who love exploring new things and who you know based on experience are good at thinking outside the box. These are going to be the ones really testing the new ground, but don’t have the experimental guys go out on a limb on their own, try to make the process a group effort, with the rest of the team supporting them by brainstorming ways to implement the new technology together with them during the early stages of development. Try to get everyone excited about the new technology, but be prepared to work overtime and to spend extra incentivising your developers to cover new ground, especially in the beginning while you master the foundations of the new technology and may also be requiring overtime from them.
Notice the growth opportunities. Whilst it can be a painful push to work through the implementation of a particularly challenging new technology, there are plenty of benefits and opportunities for growth both during the process and once it’s done. The process itself helps to keep your developers at the forefront of their field and encourages both an attitude of learning and a creative problem solving approach which can be used with every project and technology. Once this project is completed, you not only have marketable experience in the new technology, which can lead to more sales, it can potentially open up whole new revenue streams and possibly be the beginning of a new department! Ekreative started out purely as a web design company. Back in 2010 we made our 1st app and it was a real baptism by fire, but today we’re in a position where approximately 80% of our work is making apps!

Case 2 – The “Key Staff Member Leaving” Fire

Assess the danger. To assess this situation will require an effective conversation with the person who’s leaving to understand why that’s what they’re doing. There are plenty of good, legitimate reasons why they might be leaving eg. relocation, family obligations, a change in career path. But there can be bad reasons for leaving which will require some additional fire quenching eg. they feel that the office, team or management is hostile or unwelcoming, they don’t feel that they’re able to grow professionally or display their potential or they don’t feel that they’re compensated at market level. In any of these cases the issue causing them to leave would also need to be addressed as well as the hole in the team.
Respond to the problem. Responding to the problem may well begin during the same conversation that you use to assess the danger. It can’t be an emotionally charged conversation from your side, you need to listen carefully to what the leaver is saying and if their reasons for leaving are non-critical, try to convince them that the company is changing, that you recognise the problem and will start working to change things or that the things they’re missing will come at some point. If the person is definitely leaving, don’t act like it’s the end of the world, the rest of the team are watching you and your reaction. People switch jobs all the time, this is normal. You’ve got several tasks ahead of you now: go over the leavers job description again and understand exactly what role they played, now find the people who are in the same category of staff as the leaving person and spend time with them, motivating them and empowering them to take on the role of the missing person. You’ll be surprised how often junior staff are ready to step up to the challenge of a more senior post. If the gap simply can’t be filled by your existing employees though, whether due to workload, experience or the specialisation of the tasks, it’ll be time to start looking for new hires.
Notice the growth opportunities. In my experience people who left us were often those that didn’t really fit into our corporate culture. When such people left, the remaining team actually became stronger. Especially when a key team member has left I’ve found that the space they leave creates opportunities for other people to shine that you might not have expected it of. Very much like the forest clearings which allow new trees to get a head start.

Case 3 – The “Unusual Workload” Fire

Assess the danger. Unusual workloads, both small and large can be at the same time a blessing and a curse. It’s your job to work out how to maximise their positive impact.
1. Having ‘too many projects’ seems like an enviable position to be in, what’s dangerous about it? For a start, if you’re getting a lot of projects offered to you it might be a sign that you’re charging too little! A wise man once told me “If half of your clients aren’t telling you that you charge too much, you’re charging too little”. On the other hand, it could be that the glut of work is because you’re over-promising. Can you really comfortably take on the excess of jobs without sacrificing on quality and delivery times? It’s also worth checking on your team’s stress and exhaustion level, if you’re riding them too hard (especially if it includes evening and weekend work to cover the jobs), this is a situation that can’t be sustained.
2. Having too little work seems more obviously negative, but you need to work out exactly why it’s happening. Is it seasonal? As in every industry, software development work comes in cycles. After a summer slump things tend to accelerate in September and October when people come home from summer holidays with fresh inspiration about how to solve the problems they face. The workload seems to slow down around Christmas and New Year. Then there’s another spike in activity at the end of February and the beginning of March as people (especially in the States) try to use up budgets before the end of the financial year on April 1st. If the lack of work isn’t seasonal could it be related to a problem in your strategy, marketing, quality or client relations? Check your client feedback as word of mouth recommendations are crucial leads. Finding negative experiences there can highlight concrete areas to work on.
Respond to the problem.
1. If you’ve got an unusually large workload, don’t rush to hire more people! First check if your existing people are working as efficiently as possible. Optimise procedures in your company to get 100% from your staff. If you don’t have a project workflow developed, now is the time for it. If you haven’t got a project management platform, do it now! Check the efficiency of communication between different teams within the company eg. managers to designers, designers to devs, devs to testers, pms to clients, etc. Make sure that you’ve also got clear scopes of work set up as projects tend to get delayed and cause problems for clients when the people doing the tasks aren’t totally clear about them. Make sure your programmers know their deadlines and can see their progress. On the topic of deadlines, finetune your estimation process to the best of your ability! Spend time with your managers, observing how they communicate with clients, their tone, their response rate.
2. When it comes to sales channels, both scenarios might require them to be tweaked, that said, you really want to be adding new avenues of work only when things are going well, not when you’re struggling for work. If you’ve got one main channel of sales, it could be that it’s reached capacity and its time to build up new channels, whether that means website inquiries, referrals, connecting to people via events, via linkedin or even cold calls/emails, never stop experimenting and trying out new ways of getting clients, never become comfortable and stop trying.
3. If you’ve got an unusually small amount of work, it might well be the sort of fire that takes a long time to get through, so be prepared for a period when you have free, unutilised resources at your company. This is a good time to do all the things that you always lacked time for before: work on your own site, try some internal projects, improve internal processes. We’ve made internal projects for time tracking, recording manager/client communications, project management tools and development efficiency tools like our iOS test app deployment platform. It could also be a time to venture out and try an idea that you always wanted to do, ie. your own startup. This is a big decision though, not just a throwaway idea to give people something to do. It’s key that you don’t stop when the tide comes back in. If you’ve started these projects, see them through to the end, they’re not just placeholders. You can also use this time to learn new things, whether languages, frameworks, or systems and approaches to work. Use this time to explore new things while there aren’t project deadlines to rush you.
Notice the growth opportunities. Hopefully the opportunities for growth here are inherent in the action points. If you have a glut of work it’s a time first of all to fine tune your processes and make sure you’re working as efficiently as possible and only then potentially to expand your workforce. If you have a lag in work, it’s actually also a good opportunity to improve your internal processes. In addition it’s a great moment to learn and try out new things.

I’m hoping you’ve got the idea now. These specific examples are just a few of the different fires that your company might face. But whatever comes your way you need to see it as an opportunity for the company to grow and improve. This isn’t just about having a positive, can do attitude, but about recognising problems for what they are, analysing their cause and actively trying out solutions to bring about change. Just make sure that when you’re done dousing the fire you appreciate and even celebrate the growth that it’s brought about.