Introduction
This is embarrassing to admit, but the people we have hired in Fukuoka — or taken on as contractors with a view to hiring them permanently — have not lasted, and so far it has ended within a few weeks with "this isn't a fit, is it…" and a goodbye. At a tiny company like ours, hiring one person takes a considerable share of our resources in bringing them up to speed and in the various formalities, and when they do leave we then have to run around rearranging the work. Going to the trouble of hiring someone only for them to be gone immediately is enormously inefficient. So: better to set out our style in advance and have people come who fit as well as they can — hence an article like this.
Quartile's Odoo business
We provide implementation, operation and maintenance services for Odoo, an open-source integrated business system out of Belgium. We began this business in Hong Kong in 2013 and for a while earned our daily bread supporting customers outside Japan, but as customers in Japan gradually grew in number we set up a company in Fukuoka in 2018, and now work mainly out of these two locations.
Compared with older ERP systems, Odoo can be implemented very quickly, it extends well, it keeps costs down — it has a great deal going for it. As an open-source ERP system it has been far and away the most popular in the world these past few years. In the Japanese market, though, recognition is rising only gradually and it is still not widely known. There are various reasons, but the big ones, I think, are that Odoo the company does not push sales activity aimed at the Japanese market, and that there are almost no players doing community work such as localisation for Japan — as of now, we are effectively the only ones doing open-source community activity here.
As a product Odoo is extremely well made, and we hold a great many options for meeting whatever a customer needs, so there is nothing whatever about it that cannot be used in Japan. My own view is that when a small or medium-sized Japanese company is looking at a core system, it may as well try Odoo first. Looking abroad, I understand cases of moving from a flagship ERP system like SAP to Odoo are increasing, and I have worked on such a project myself. Its prospects as a product are strong. And that an Odoo market has grown in Japan at all, small as it still is, must owe a good deal to our own activity.
The state of Odoo talent
The trouble is, there are almost no consultants or engineers in Japan who know this application thoroughly and can use it well. Set against the potential of the Odoo market, the talent pool is very small indeed. Hiring under those circumstances necessarily means hiring people with no Odoo experience and bringing them up ourselves.
Our Odoo implementation method is also, in a core-systems world that tends towards a waterfall approach, decidedly agile-leaning, and consultants are expected to understand how Odoo works fairly deeply at code level in order to run projects efficiently. The open-source community work we do to support the Odoo ecosystem also calls for the ability to communicate in English. Most of the ERP consultants out there do not hold that combination of skills. So even hiring someone with an ERP consulting background, I imagine there is a fair amount they would have to catch up on.
Roughly, the timescale I hold in mind is this: the first six months are all cost, results build gradually from there and recoup it, and getting to break-even in a year would not be bad. At the long end it might take two or three years. I go in assuming it takes time, at any rate. When you are hiring and nobody in the market fits on skills, it cannot be otherwise.
On the other hand, we have next to no brand strength when it comes to hiring. We are simply one tiny company. With Odoo growing we get plenty of enquiries from customers, but on the hiring side, sad to say, nothing much at all. Bearing that in mind, we put terms to whoever we hire that are not embarrassing.
What we hold to
Looking back at what we have held to whenever a call was hard to make, it settles into these:
- creating value
- being fair
- being open
We had never set them down in writing, but pressing on what sits underneath our everyday behaviour and the picture of how we want to be, I think this is what it comes to.
1. Creating value
I often put the question to team members: is what you are doing creating value?
On what basis can you judge that something has value? I think value is judged, as a rule, with your weight on the market. There are broadly three markets here: the customers who buy our service, our own team, and the ecosystem our business rests on. Each has its problems, and solving those problems is where I take the value to be.
2. Being fair
We do nothing underhanded — not to customers, and not to team members. Readings of what is fair may differ from person to person. Where they do, we lay out the facts, hold them against what society generally accepts, and think about what ought to be done. If unfair terms are ever pressed on us, we resist thoroughly. An organisation that cannot manage to be fair will be strained past bearing somewhere, and will stop being able to create value continuously.
3. Being open
Personal data and other sensitive material aside, within the team we share all information as a rule. We take an active part in open-source community activity, and rather than only using open source, we give back to the community. Being open is what underwrites being fair. Put the other way round: where something is not open, we take it that something unfair is lurking there.
At the risk of being misread: it is not that we hold things like "freedom", "diversity", "creative" and "fun" as values in their own right. We are probably a good deal freer and more diverse than the great majority of companies. Solving problems has the interest of working a complicated puzzle, and the work itself could fairly be called creative. (Whether it is fun depends on the person, so I will not claim it. I find it fun.) But these are no more than by-products that show up when you doggedly pursue the things above.
Acting so as to create value
Handed the seemingly vague proposition "create value", few people can act on it from the outset. But I believe it becomes possible by making a habit of the following cycle:
- Grasp what would have value (find the market's problem)
- Set a concrete goal (define the output)
- Work out the steps for reaching the goal
- Carry the steps out
- Return to 3, 2 or 1 as needed
It looks basic, but at first it does not go at all smoothly. To begin with, it is rare for views on "what has value?" to agree straight away.
What the team finds value in is judged, as said above, on the axis of those three markets. So understanding the market is indispensable. Creating value without doing that is not possible.
As an approach with new members, I do not lay the market's problems out neatly and explain them (time being limited). Nor, as far as I can help it, do I set their goals or instruct them on the steps. I tell them to set their own hypotheses and turn the cycle above.
In practice we do hand out tickets created within a project, so often 1 and 2 get skipped and they start from 3 — but what we want is for them to become able to work from 1. Without 1, working as a team ends up costing more than it should in management and in communication.
Incidentally, where a member and I differ on a judgement of value and the member argues their own judgement is sound, I hear them out, but in most cases I end up pushing my own view through. Given whether the management perspective is present, and who carries responsibility for the outcome, it inevitably turns out that way.
Speed of output first
That cycle needs turning fastest precisely in the early days, when views on value have not aligned and it is not yet clear what a new member can do.
The essential thing is getting concrete output out early, however rough its shape. Once something concrete appears, you can hold it against how things ought to be and see plainly where the gaps are. Once the gaps are visible, all that remains is the work of closing them. Along the way you align on value, surface the problems, and move on to the next cycle.
However hard a new member is studying Odoo, if no output comes out, their record stays at zero. With someone whose record is zero, understanding what they can do now and what growth curve they will trace is impossible.
As far as I have observed, most people left to themselves take the opposite approach. They start by studying Odoo's features without a clear picture of the output. Studying Odoo is indispensable in the end, but between studying with a concrete picture of where you are landing and studying without one, the difference in effect is night and day.
What happens when you produce output
Once concrete output appears, all sorts of questions come at you from me and from the existing members:
- "What are you trying to do with this?"
- "What value is there in being able to do this?"
- "Why do you think that has value?"
- "Why did you take this approach and not another?"
- "Can a reviewer understand the test cases from this?"
- "Why did this take as long as it did?"
- "Is it fair to bill the customer for this?"
- "How would you do it better next time?"
And so on.
For someone used to digging into "why", this is nothing at all. For someone who is not, it may feel quite unpleasant. Nobody is telling you off, and yet you take it as being marked down. You take it as being cornered. Anyone whose only experience is a Japanese workplace where reading the room counts for a great deal will, I expect, feel that way readily.
Honestly, there are many cases where this is the point at which someone concludes they cannot settle here, and leaves.
That is a real shame, but I think it also cannot be helped. So long as the job is serving customers as a consultant, holding a critical eye on your own output is indispensable, and if you cannot withstand review inside the team, the aptitude is not there and it is better not to continue.
The gap in hiring engineers
Delivering Odoo services efficiently calls, in a great many situations, for a software engineer's grounding and skills. So we try hiring engineers — and this often goes wrong, I think, precisely because they are engineers.
"Precisely because they are engineers" may be putting it badly. But as inclinations and tendencies among engineers — varying by person and by role, naturally:
- they like developing
- they do not talk directly with customers much
- they want to build a product together in a lively team
Those seem common enough. Whereas here, it goes:
- creating value does not begin from development
- you talk with customers often (much of it communication to get on the same page)
- the team supports you, but you are expected to run under your own power
In short, the consultant side of the work weighs heavier here. So the stronger someone's identity as an engineer, the more they tend to feel a gap with what is being asked. Personally I have a sense that, aptitude permitting, an engineer covering a consultant-like role gets to the required skill set in the end more easily than the reverse — but changing how you face the work is, I suspect, quite hard.
The pressure of being asked for results
One more large wall that makes new members feel pressure is the question: how much can you contribute to revenue and to building up the team's assets?
Most of our revenue at present is time-and-materials consulting, and with that method it is unavoidably clear who is contributing how much revenue. So it is a setup where an expectation — "your cost is this much, so as a rough guide your revenue contribution would be around this" — is easy to compare against the actual. In short, for better or worse, there is no fudging it.
As said above, I do not expect anyone to cover their own cost from the start, and it is fine if it takes time before they can deliver; but I do ask for an account of the growth curve they will trace. Where results are not rising as hoped, that turns into pressure. This too is obvious to anyone for whom it is obvious, but for someone who has never been anywhere results were asked for severely — not in the sense of impossible quotas, but in the sense of results being set out plainly as numbers — I think it is a point that easily feels hard.
Who does well here
Saying it may be something of an anticlimax, but I think someone "not underhanded, attentive to those around them, and able to keep at it" has a high chance of doing well. It is not really a question of which skills you hold.
Underhanded people are out of the question; the fit with us is as bad as it gets. "Underhanded" sounds harsh; a milder word would be "fudging". Because we hold to being fair and being open, people who fudge do not settle in. Fudging is something people are not very self-aware about — a good deal of it is morally wrong but goes unchallenged, so it gets done, and then becomes habit. Flicking cigarette ends into the street, that sort of thing. Anyone who does that kind of fudging without discomfort is not welcome, whatever their ability at the work.
"Attentive to those around them" can be restated as "able to read what the people around you need and respond appropriately". This is something you can train outside work, in ordinary life — speaking to someone who looks unwell, for instance. The habit of reading what those around you need is enormously useful at work too, in building the ground for judging where value lies. We place particular weight on starting from the market's problems and turning them into action. Being attentive is no guarantee you can move in ways that lead straight to results, but at the very least, aligning on where the value lies will go more smoothly than it otherwise would.
Being able to keep at it matters too. Not keeping at it in the sense of repeating simple tasks, but in the sense of piling up trial and error, course corrections included, until output with value comes out. Work here asks you to clear many hurdles to produce one valuable result. In the early stage especially, before you have the feel of it, you may be sent back to rework something several times. Even then, a certain backbone — or plain openness — is needed to take feedback positively and carry things through to done. Some people resist and push back when something they submitted thinking "that's it" is rejected, or lose their motivation (the more someone prides themselves on the experience they have accumulated, the stronger that tendency, I think), and then the team's performance does not rise. Constructive argument should happen as much as you like, but regardless of how the person concerned sees it, situations do arise where experienced members simply cut something loose.
With the team still very small, if it came to choosing between "someone inexperienced who meets the points above" and, say, "someone experienced and technically very strong but not attentive", I would take the former.
What is good about Quartile
Anyone reading this far will probably be thinking "hmm, sounds hard", but I do think it is a good place to work for someone who can doggedly keep turning the cycle of acting so as to create value, walls and all. Where the aptitude is there and someone keeps at it, results always follow, and once someone has reached the point of running under their own power we let them work fairly freely.
- reasonably good pay (5.5 million yen a year at 25, for instance — it depends on the person)
- no overtime
- fully flexible hours
- remote is fine (conditions apply)
- English conversation lessons (we use English often)
As things stand this is not a workplace with a cheerful, boisterous atmosphere (I hope it becomes one some day), but because nothing here gets fudged in any sense, I think anyone who can produce results here will pick up business skills that hold good for the rest of their career.
And here you can be directly involved in building a business, small though it is. The experience lets you take on something of a manager's perspective, so for anyone who wants to start something of their own in future I think it makes for an interesting place to be.
We are hiring
If reading this has left you thinking it might suit you, I would very much like to meet and talk. It may even be that you join us, do great things, and become the reason Odoo spreads across the Japanese market all at once. Taking a run at stirring up Japan's ERP market a little from a team this small — doesn't that sound exciting?
Photo by Daniele Levis Pelusi on Unsplash
A tiny IT services firm's struggles with hiring