Why I never advise anyone to freelance

2
I have been in the industry for a while now, and one of the questions which keep on popping up is, “Should I freelance?” or even more directly  “After all these years, why don’t you go it alone?”. The indication here is why don’t I become a dev for hire. While I no longer offer value through hands-on coding, I still feel younger entrants into the industry need to understand a bit more of why I think small scale software consulting is not a good idea.

Let us begin with a story. Years ago, I walked over to a clients office with a proposal in hand. I had just started a new consulting firm and even had two devs in employ. This was going to be our first major client. On my proposal, I had the devs profiles, the company profile, and what we thought we could offer.

The meeting was fairly long with the director of the client firm quickly going through what his vision of the product would be, basically a custom ERP. After our quick paced session, he asked, “So what will this cost us?”.  I am against such estimates https://blog.chenchatech.com/2017/03/why-you-should-never-give-off-the-cuff-estimates/, so I explained we would need more time. Further given the amount of pre-work required, field visits, interviews point estimation, and so forth. We would need to charge just to develop the scope of work and associated project documents.

The mood turned somber as the director took it upon himself to explain just how stupid it was for me to have the guts to ask for payment for the work needed to estimate the real work. New in negotiation, I capitulated and did as he wanted me to do. In the end, they ended up going with another contractor, and we took the cost.

Is this why I ask you not to freelance? No, at least not the only reason. The industry is simply stacked against you. Let me explain further.

Low barriers to entry

There is no other industry where the cost of entry is a laptop, headphones, and a decent internet connection.

Your first response may be, sure, but what matters is not these physical assets, its what is between my ears.

Perhaps this is true, let’s look at it another way. If you are top 1% of the population in terms of intelligence, then a city like Nairobi with 3M residents, there are 30,000 people JUST like you if not better.

The truth is, you are not that special. Continuing to delude yourself in this way maybe fun even satisfying but will prove disastrous to your pocket.

The field will continue to flood with X consulting, X tech, X designs kind of companies. Profits will be suppressed.

The tyranny of time

Time is a limited and precious resource. You can not buy it, rent it, get a loan of it or in any other way extend it. What you got is what you got. Yet all activities need time to gain reality.

Guess what takes a LOT of time? Product development.

Real life coding is nothing like what you get in a teaching environment, there are no neat solutions. Past your fresh start, most of your time will be spent reworking existing code.

Vi has built its entire product successfully based on the idea you spend more of your time editing the code rather than adding new code.

Factor in the time you spend fixing bugs, and you are only coding 30% of the time.

The news gets worse, Business Development is an even bigger beast. Clients rarely know what they want to be built. More often than not, they feel their problem and have a sense tech may be able to help. It will be countless meetings and brainstorming sessions before you have what looks like an addressable problem and even more time to architect the solution.

Optimistically, you will be spending maybe 5-10% of your time coding, aka time you can bill the client. Do you see how this can become a problem?

Scale works against you

We all learned about economies of scale somewhere in Econ 101. The basic idea being our costs per unit reduces with the more units we sell. Did anyone bother to tell you about diseconomies of scale?

Some businesses get stuck in an unfortunate situation where every new unit sold costs more. As a solo tech consultant, you fall squarely in this bucket.

Technical engagements tend to offer little opportunity to apply prior knowledge. Yes, I know you can carry over libraries you have built, but unfortunately, you can not carry over business domain concepts which are likely what the client cares about.

You could always hire more devs, putting aside the question, why would they work for you and not themselves, experienced devs are hard to find, and when you recruit them, the cost will be significant.

Poor bargaining power

The old saying “No one was fired for hiring IBM” still holds its ground to date.

For established clients aka where all the money is, are characteristically risk averse. They have a working business model and don’t want to jeopardize it. Further, after sales support will always be a key concern. In short, procurement departments are allergic to one man shows!

There is some reprieve here, small businesses will be more willing to engage. Competition here will be stiff, even worse, you may find yourself encountering competitors who don’t really care about the bottom line. After all, most people in this industry are here because of the promise of freedom, a chance to work from the beach. It will be tough to underbid such an individual.

So what works?

Advisory services are clearly a profitable industry, so how can you be successful here?

Here is a little known secret, successful advisory firms are NOT paid for performance. If you were to call PwC, they would offer you not a solution to your problem, a hefty hourly rate. You, of course, you have no option, an audit is a regulatory requirement, and you are better off with a known name.

What about mutual funds? Well, always read the fine print. The fees are charged against your investment, not against what you earn. In short, they make money whether their decisions pan out or not.

You could get over this huddle by charging per hour as well. A time tested model is convincing the client to embed you in their team. So you take on tasks just like any other dev. This, to me, looks and feels just like regular employment with none of the employment benefits.

Large networks such as Toptal or Upwork may help. They also embed you in a team. In my opinion, the net effect is the same as above.

In fact, the only viable way I see out is to work on a product and use your consulting fees to get by as you wait to land on a product market fit. Once this is achieved, shift all your attention and resources to the product business.

Have you managed to make a freelance operation work? Talk to me in the comment section below, my Linked in chenchajacob or my twitter @jchex

Facebooktwittergoogle_plusredditpinterestlinkedinmail

How to collaborate with your Operations colleagues

null

Twiga tech team currently has 25 members, the business in whole has 400+ employees and rapidly growing. This means for every techie we have 16-20 colleagues in other departments. Even more importantly, Twiga is a Tech enabled business, that is, the tech team plays a supporting role. Working well with other groups is not a luxury for the team, it’s a necessity.

As you can expect, there is bound to be some friction when operations and tech have to work closely together for business success.

As a tech team, we have great appreciation and respect for our operations colleagues. It is not easy to sell to over 2,000 vendors daily from a rapidly growing customer base of 6,000 customers and a network of over 13,000 farmers. Clearly, there are a lot of people doing a lot of things right.

In my experience, I have come to find out the areas of friction originate from two major areas:

  1. How the departments interact with the business
  2. How the people within the company interact with each other

Interaction with the company

Twiga is in the business of aggregating retail demand in African cities to provide low-cost access to better quality food.

To this end, Ops(Operations) and Tech(Technology) contribute in fundamentally different ways.

Imagine if you will, a company-wide meeting has been held, and all teams are reporting their numbers. Ops goes first. The crew talks about 100 tonnes moved from farm gate to vendor, 10 million Shillings in revenue and perhaps 4 million shillings in operating costs. Now, as the person accountable from tech, would you follow that up with, we delivered 100 story points? Even worse, 10KLOC (Thousands of Lines of Code)?

In these cases, you should use different approaches. For starters, try to identify simple to understand metrics. For example, our system uptime was 99% is more useful than our Apdex score was 98%. It doesn’t matter that the latter metric communicates more information. You can make it better if you can find business-oriented metrics, for example, we processed 10,000 orders and 9,000 deliveries without a single failure. Or 100% crash free users.

Given the flexible nature of the work, you must compensate by aggressively marketing what you plan to do, why you plan to do it, and when it will be done. Once it’s done, show don’t tell. Fairly regular tech demos where you invite your colleagues from other departments should help.

The moment a new business process is introduced, you can be positive pressure will immediately mount to have it reflected on the system. Know that businesses processes take time to mature, what seems set in stone right now will likely evolve into something barely recognizable once it hits the actual reality of operations. You want to give the process time. Otherwise, you will end up scrambling to rework your architecture every time the process bumps on a wall.

Interaction with people

Ops move fast! Almost all stock brought in is out within 48 hours with the notable exception of bananas which requires ripening.

Tech, on the other end, moves in two weeks sprints. There is progress in the middle of the sprint of course, but before you show this out, take a long look at an incomplete building or a car out at the garage. If the owner is nearby, their horror as the mechanic hammers, pulls and twists the various parts is palpable. Better to only share what is at least understandable.

Given this reality, I suggest you do far more planning than I would usually advocate for a tech team. You want your colleagues to co-create with you. Invite them to all brainstorms, you will be pleasantly surprised at the insights the non-techies can provide. The joint sessions will also allow them to peek into how you work, hopefully, in the process, they will also learn to appreciate the complexity of building a modern application.

Take the time to educate your colleagues. What you consider common may register as jargon to your colleagues. Don’t for a moment take the statement

“I am not a techie, I don’t understand this thing you guys are the geniuses”

or any of its variants. When it’s said, don’t take it as a statement of your superior cognitive status, interpret it for what it really is,

“You are a cost center who I am still not sure why I need.”

Make a great effort to understand your colleagues, get them to know how what you are doing will benefit them.

Finally, you want to be running an efficient support function. Most issues which will come to tech will likely be transactional in nature. For example, I can’t log in, I can’t see my records, etc. Transactional issues have an exciting asymmetry, they are usually easy to solve yet cause a lot of pain for the person experiencing them. This means you can create a whole world of value just by quickly handling them.

How do you handle collaboration between your tech team and the operation team? Talk to me in the comment section below, my Linked in chenchajacob or my twitter @jchex

 

 

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Planning for change

Let me begin by illustrating how change can come rapidly to even the most mature systems.

At Twiga, one of the Tech team’s critical areas of responsibilities is the DMS. This system is an internal propriety system that helps us manage each and every aspect of the value chain.

For a very long time, the business has been focused on Fresh Foods and Vegetables (FFV). For the system, it meant we could use Kilograms (Kgs) as the Stock Keeping Unit (SKU). The idea was, you buy from the farmer in Kgs, you store and ripen in Kgs and finally sell in, you guessed it! Kgs.

The concept of Kgs as a standard unit of measurement worked so well for so many years, you could see the signs of the idea in virtually every report.

Well recently, the business decided to add Fast Moving Consumer Goods (FMCGs) to its offering. FMCG include the likes of Flour, Cooking Oil, Sweets, etc.

The problem with FMCGs is, of course, the concept of Kgs doesn’t map very well. How many Kgs is a packet of sweets for example? Does anybody buy their tea leaves in Kgs?

So we now have an interesting situation, flour would be bought in bales, stored in pallets and sold in packets.

As you can imagine, there was a lot of pressure to bring the system up to speed. Every day we were not selling was a day the company lost revenue.

Eventually we did solve the problem and adapted the system. The key takeaway here is you should anticipate change not just in requirements, but in concepts the business is built on top of.

Here I will point out some of the tips you can use to manage significant changes better.

See requirements gathering as a continuous negotiation.

Tech teams have a reputation of being inflexible. Who can blame us, we are good at delivering on what we promised and its hard to understand why others see it fit to change their minds on a whim.

Yet to go past “meets requirements” to “exceedingly valuable,” we must see tech, not as an external party who checks of items in a scope document, but as an integral partner who shapes the work to be done.

If you do take on this mindset, you don’t wait for the client to simply tell you what they want, you dig deeper and see the problematic situations they face. You try to understand how they came up with their requirements and then see if you can help them refine it so that it better solves their problems.

In this process, you must understand you are dealing with a human being not a machine, some of their needs they may not be able to express. Remember, you are the one with the years of technical training and experience. Still, they must feel respected and listened to, they probably have even more expertise in a different line of work.

In all this, remember to treat your client as a colleague and maybe even a friend. This relationship is what will keep things going in the tough times.

Give the pessimistic date

“All Models Are Wrong, Some Are Useful”

George E. Box

Standard industry knowledge states you should give a range of dates for delivery. For example, we will get this done sometime between 10th Sept and 1st Oct. That’s some good advice if people were able to grasp what you mean entirely. In my experience, what happens is they tend to forget the later date and then push you for not meeting the more aggressive deadline!

Certainty, even when dead wrong is incredibly valued in business settings.

I think a better way is to just give the pessimistic date. This works even better if you already plan your work in sprints. Then you can say this is planned for 4 sprints from now.

A useful rule of thumb would be to plan your work as usual but allow a full day for the team to work on changes every 10-day working period.

The confidence trap

For most teams, especially internal teams. The person giving instructions occupies a higher position in the totem pole. For the most part, it means when they look into their past, all they see is their success and how they have been right while others were wrong.

There is nothing wrong with this mindset, confidence is another highly valued trait for business leaders. Unfortunately, what it means for you is they will likely have a solid sense of what they want to achieve and will actively resist being persuaded otherwise. They will tell you what they want, how they want it done and how long it should take. Conveniently forgetting their expertise doesn’t neatly translate into tech.

For this kind of situation, there really is no clear answer. The best thing to do is to massage the client’s ego as much as possible while actively involving them in the development process. You will come to find there is a lot of value in engaging a committed and smart professional in your thinking.

How do you handle large changes in your own organization? Talk to me in the comment section below, my Linked in chenchajacob or my twitter @jchex

Facebooktwittergoogle_plusredditpinterestlinkedinmail