SCALING BEYOND THE VOLATILITY
Tech companies happened to be the cheapest and easiest to startup these days or perceived to be. A lot of folks around with CCNA certifications or any IT certification out there are flying around business cards as CEO’s of some tech companies. I had also fallen victim of this movement of IT CEOs some years ago after learning some lines of code and read some articles online closer to “Any kid around the world in his or her father’s garage with idea can start up a company”.
Mine was incident on some few freelance jobs that landed me some millions of Naira that got my curiosity of becoming a CEO nourished. Without any job experience and how organization ethics and ethos works i had jump-started a tech company employing about 6 developers. It was really beautiful at first 5 months before i began to encounter problems. With a nice office situated at a very good location within Jos and Staff who appear happy working in an indigenous IT firm, the company was already in debt.
Those who have journeyed through this lane would agree that the first month of non-payment of entitlements to staff can be normal at some times even into the second month but things begin to get messy on the third month and that is usually when you the CEO begin to recount on some wrong decisions you had taken as well as advises you had overturned in the formative stage of the company. I particularly had regretted not taking a paid job in an oil company when the opportunity presented itself. On the other hand, as this formed one of my early misfires, i was glad i really took the bold move of starting up.
What we simply lacked that led to our failure was culture, we had good developers. I later learned about this when i picked up a paid job in one of the tech companies in Abuja after we went bankrupt and had to close down our company. What i learned and attributed to a total lack of culture in my new place of work is what i see as the reason(s) why most tech companies in Nigeria always fail in delivering at timelines and those who are lucky to meet up with timelines failed in delivering support services.
Software developers are the most volatile set of people in any workplace. Very good software developers would always have better offers elsewhere and it is either you up their pay or they bid you a farewell. The only exception to this is if they are gaining some values they would probably need in the near future which might not necessarily be in your company — Values might be some form of experiences.
So let’s take up a scenario:
Company A hired a developer on a full time basis. The company had assigned the developer on a role of developing an app for a client. Four months into the project with about 80% completion, the developer had dropped a resignation notice. He or she had gotten a better place leaving you with the question of who to complete the project. Good luck is to organizations that are able to manage to get developers to complete a project but would still be embattled on how to offer support service whenever a feature breaks. Second problem turns in when you hire another developer and he gives the shitty excuse “Oga (Boss), the former guy wrote some shitty codes here and there, i would have to rewrite the app all from scratch”. You sit down in confusion staring at deadlines as the iteration begins all over again.
What we need is an organizational coding culture. A great coding culture concentrates on making developers productive and happy by removing unnecessary overhead, helping the individual developer learn better software engineering paradigm, and raising awareness among developers to create great and better code.
Once developers stop learning and gaining new experiences from your company then it would be a time to call it quit. I have had to resign from the company when i realized everything in the company was centered around me. I was handling almost all projects, i was not learning anything new. I was dead and nothing seems interesting any longer. I was feeling consumed. At that time, the amount i was paid as entitlement was no longer the point of interest.
When we lunched nHub in 2015 we had to spend 1 year in bringing both professional and amateur devs to speed on good software development patterns. We created our own slogan that fits into our coding culture which is a mix and blend of both Ruby and Python design philosophies. So we coined our developers mantra as thus:
“There is more than one way to do it. But there should be one — and preferably only one- obvious way to do it”
We faced challenges around pundits who believe in a world of diversity but we had to argue on the premise that in as much as we love diversity we should not overlook the confusion it comes with. What we are simply saying is our developers no matter how good would have to undergo some weeks training on understanding how we solve certain problems. Design patterns, variables naming convention as well as namespaces and classes, documentation pattern and many others. For example, our developers using Laravel are always in the know that a future decision could favor Doctrine against Eloquent.
For instance, we had to make it compulsory for our devs into employing the Repository pattern using Inversion of Control (IoC) as the only means for a controller-model communication. Three things inspired this, first our lack of knowledge of what back-end our clients might end up using in production as well as possible future change in the choice of ORMs. Secondly, our love for keeping the controller classes very slim and finally giving room for scale.
While our senior engineers are daily trying to bring out the best patterns to addressing specific problems, our junior developers are using these approved practices on projects. This way we are able to shuffle devs between projects and ensure devs coming into new projects enjoy seamless integration since they already are conversant with the coding culture. Through this culture we are able to keep updating this “nHub perfectionist model” with newly approved design methods and patterns and having our devs go through to get updated. We also mandate that each of our devs serves a mentee from the myriads of students under our fellowship program. This way we preserve continuity.
It is very logical that individuals bends to the organizational pattern of everything than have the organization shifting grounds to an individual’s. If that must happen then it must be documented as best practice that others must adopt.
One other volatile nature of developers i have experienced is getting fed up easily on long surviving projects with numerous back and forth. We employ shuffling of devs across different projects to do away with this type of volatility. This method helps to ensure developers are presented with new challenges and also to get them fresh on the project once they are back. This method also works as the best form of our code review process giving that a newly shuffled developer can easily figure out what is not well written and documented or what goes contrary to organizational standard practice.
“Culture has accounted for our high projects profile but we have had to wait for one year to build it.”
Having said all these, Culture creates a sense of order, continuity, and commitment that permeates every aspect of the organization coding standard, from how developers interact with each other and how they commence and end their day on projects. Culture is often difficult for an organization to articulate, but its impact is far reaching and influences developer attraction and retention thereby ensuring success at good products and meeting of timelines.
At nHub we are helping to shape the future of the tech ecosystems in Africa by building a generation of cultured developers. We can also help you build a very good agile team and send them your way while we can also shuttle them time in time out without breaking your system. You deserve a guarantee on continuity.
This article was written by David Daser, founder at nHub and it’s first appears on meduim