Six lessons learned building the software consultancy unit at iHub
About three weeks ago, a former colleague at the iHub invited me to share with my former team some of the lessons I learned building out the consultancy unit at the iHub. At first, I was a bit hesitant as I didn’t think there was much to share. However, upon reflecting on my journey over the past four years I realized there was a lot to share.
When the consultancy unit at the iHub started out, I was the only employee. Less than four years later, it was made up of seventeen people (11 full-term, 6 consultants). This growth wasn’t accidental. I ended up spending almost two hours chatting with my former team about the journey. Why not document it here?
Do these lessons apply to everyone? Definitely not! It applies mostly to freelancers looking to grow beyond being an individual freelancer or small service-based business seeking to expand. Why should a freelancer, especially one who is doing well, build a company? At the end of the day, as an individual, you only have at most 60 hours in a week. Even with 100% utilization rate and a high hourly rate, you will stop making more money at some point. The only way to change this is by building a team. The best way to manage a team is by building a company.
I learned a lot over the four years but six lessons stand out the most.
1. Start small and don’t be your own competitor
Like really small! It can be one person in the beginning and then more people come on board as work increases. From experience, it is easier to meet demand than to meet supply. I worked as the sole employee for almost a year. My first hire wasn’t a developer either, but a business developer. We used freelancers to get the work done thus reducing our recurrent expenditure.Working with consultants will definitely present a different set of challenges but you can overcome this.
Once you decide to build a company, don’t be your own competitor. Almost all the consultants I worked with came in as individuals. I urged to form companies and once they did encouraged them to only work as companies. As an individual, you are more likely to charge less than your company. Basic math dictates that your overheads are lower than a company’s overheads. Additionally, as an individual, you will directly pocket all the money. This probably won’t be the case for a company as you have co-founders. However, being your company’s competitor is a guaranteed way to kill it.
2. Team and culture
If there is something that can break your young company, it is your employees. This is particularly the case for service-based businesses.
Back in 2013, the team at iHub Consulting was quite unreliable. Most of the freelancers had many other gigs on the side and as a result, our projects would suffer. This only changed after recruiting a fresh batch based on what we thought would be expected of them. Our culture relied on employees/consultants who could work with minimal supervision, make decisions on their own, build trust within the team, and work in a bossless environment. Everything was then structured around the culture outlined above. Follow-ups were minimal and each team member was relied on to deliver on their own. In the beginning, it didn’t work out very well as not everyone on the team was on the same page. In a team of five, you would have three team members who fit the culture and two who didn’t. To mitigate this, if someone had the right attitude he/she was given additional training and support. If not, that person would be removed from the team after an adequate number of warnings.
This might sound cruel but it bonds well for the rest of the team. Mixing teams don’t is a recipe for disaster. The As will always wonder why they have to work with the Bs. This will erode trust within the team. Interns and junior staff members were recruited based on their potential.
3. The importance of processes and methodologies
Once we had a good team, things good better. However, we were too reliant on individual brilliance to get things done. This was particularly visible every time we added a new member to the team. It would take a significant amount of time for that person to understand how things were done as each project team had their own way of doing things.
To solve this issue, we came up with a process that would be used across all projects. This was done collaboratively as I have always believed that you hire good people so that they can tell you what to do. Most developers cringe when you talk about processes as each developer has their own style of working. However, teams don’t work that way. Additionally, there are certain practices that have been known to increase team productivity. We choose tools and methodologies that would be used across the team to ensure that we worked in a uniform manner. I have highlighted the most significant ones below.
- We chose SCRUM as our project management approach. We had sessions to train the team members on this
- We combined design thinking and elements of the lean startup methodology to help us think through problems and build solutions that would delight the end users. Before I left, we were experimenting on kicking off every project with a design sprint.
- We created a project implementation checklist. The list covered elements such as the activities carried out when kicking off a project, how we deployed and managed our infrastructure, the handover process, how we managed the client, and so on and so forth
- We selected tools to be used for the different activities— Slack for communication, Github for version control, Ansible for deployment, Amazon as our preferred deployment environment, Trello as our project management tool. The list is long!
- We narrowed down our stack — Python/Django, Android (no longer offered iOS because we couldn’t find enough developers), AngularJs — and built core competencies around this
It is important to note that this is list is not static. Team members were free to suggest modifications or new ways of doing things provided they could sell it to the rest of the team. This is still an ongoing journey.
The process also apply to how you manage the unit/company? How do you track your leads? How do you know whether you are making a profit or a loss? I have written at length about this in a post titled “I started using a data-driven model to manage my team — here are the results”.
You don’t necessarily need to use a data-driven model but you need to ensure you have a methodology used to track your performance as a company.
4. What are you selling, who are you selling to and when do you say no?
This is probably the hardest thing to learn! Consultancy companies and freelancers generally take all the work they can get. As a result, you don’t build a core competency that you can sell easily. In 2013, iHub Consulting would take on any work that came our way. We would respond to all RFPs we came across.
Between 2013 and 2014 we wrote tons of proposals. The success rate was quite low. This prompted us to look at the relationship between the proposals we wrote and the work we won. We quickly noticed that we were doing a lot of automation projects. We couldn’t compete with other companies when it came to developing corporate sites. Our price was too high and our portfolio had few of those. We also noted that specific types of companies were our biggest clients. Based on this, we shifted our focus to automation projects requiring a lot of back-end development. Our team basically became an engineering team and not a design team. Anytime we received a request outside what we considered our core market, we would politely refuse it and do a referral.
It is, therefore, important that you really understand your market and the unique value proposition you offer. A quick and easy way to do this is using the Lean Canvas template to think through your service offering.
5. Evolving your offering
The only constant thing is change. What worked last year might not this year. Additionally, it is important to use the lessons you have learned running your business to improve the business.
At iHub, we constantly looked at ways we could evolve the services we offered. In the beginning, our main focus was fixed cost projects where we would scope out a project and deliver it within a certain period on a fixed budget. This kind of model doesn’t work very well especially with consultants. It also made it hard to take on short-term projects.
Based on these facts, we designed an offering that allowed clients to contract our developers for as short as 8 hours. This service was called developer-on-demand as we could quickly mobilize for it. It was billed on an hourly basis. We also noticed that there were many clients seeking to either supplement their developer teams or outsource the building of a product to us. A service called developer-for-hire was created to meet this demand and was billed on a monthly basis for each resource hired out.
By having three different ways (fixed-cost projects, developer-on-demand, developer-for-hire) through which clients could engage us, we were able to leverage our team fully and broaden our offering. The developer-on-demand service allowed us to take on high-end services such as DevOps. Typically, you need a DevOps engineer just for the setup. The developer-for-hire service helped improve our cash flow as the minimum engagement period was three months and we billed every month. Fixed-cost projects allowed us to experiment a lot with clients and show our full expertise.
Your offering might be very different from what we did but it is important to consistently evolve it.
6. Tell your story
There is perception and then there is the reality. How people perceive you is as important as who you are. As a company, your work might be stellar but if few people know then it isn’t working to your advantage.
It is, therefore, important to tell your story as this is the cheapest way to market yourself. One of our most read articles were the articles profiling our consultants. It helped build showcase the kind of people we had in our team and consequently drive the message that we could deliver. One of the most outstanding profiles we did was Eugene Mutai’s which you can read here. Another great piece was the profile done for Mobidev by my former colleague Mugii. You can find the full list of profiles here (James Mwai’s link is missing but you can read it here).
We also talked about some of the interesting projects we worked on. One of the most read piecees was a two-part series we did about a project we had carried out in DRC Congo.
We also did stories on topical issues in the software development space. A post by Chencha talking about how you can learn SCRUM in four easy steps was well received.
The entire reason for doing this was to show the world and more specifically potential clients that we were the best in the development space and that it would be a mistake not to hire us. We didn’t have someone dedicated to writing these stories but instead, everyone was encouraged to do a piece once in a while. Another company that used to do this really well was Skyline Designs. You should definitely check out the Chronicles of Martians.
Did this guarantee that we always delivered? Of course not! The only thing guaranteed in life is death and taxes. We had projects we messed up big time! We learned from the failures and improved as a result. It is a never-ending journey at the end of the day.
That is it! What do you think? What has worked for you and what hasn’t? Don’t hesitate to leave your comments below or ping me on Twitter.
Enjoyed this piece and keen to share this with the world, colleagues and friends? Hit ‘Recommend’ a.k.a the lovely little heart at the bottom left of this post.
