Ten months since I joined Quartile
I'm Kakurai, and I joined mid-career in March 2021.
In my interview beforehand it was put to me plainly: "Actually, one person is leaving at the end of this month, so for now it will be just me and you — are you all right with that?" Slightly rattled, but thinking "ooh, that sounds fun", I joined with nothing to lose, and ten months have passed, with a fair amount happening along the way.
With working from home encouraged and more companies pushing on with IT, attention on Odoo — one of the ERP systems — has grown too, and as one of Odoo's official partners Quartile gets a good many enquiries. There are enquiries from customers considering Odoo for the first time, and upgrade work for customers who have used it for years, which adds up to this: there is work but not enough hands, so there are cases where we keep customers waiting, or turn them down. Which is why we are enthusiastically looking for people to work alongside us. (Incidentally — if "short of hands" made you think "≒ isn't that a sweatshop?", please do read to the end. Quartile's business model actually has mechanisms that make that unlikely, and make it easy to work healthily.)
So, in looking for people: what sort of person do we want to come? Hence this page.
I joined from a standing start of "this is the first time I have ever seen this Odoo thing", and although getting up to speed was a struggle at first, ten months on I enjoy working at Quartile. So, entirely on my own judgement, here are a few qualities that make me think "someone like this would do well here!".
- people brimming with curiosity, who want to look things up and try them straight away
- people who can enjoy survival, who want to feel themselves growing
- people who like being rational, and like thinking about what the real value to the customer is
I have written up each of them below — so if you thought "hang on, is this me?", do come and work with us!! We look forward to your application.
People brimming with curiosity, who want to look things up and try them straight away!
Ideally you can deliver the service while holding a broad view
First, a rough sketch of the scope of the work.
Consultant and engineer both. If you insisted on splitting it into the usual job titles, it would come out roughly as:
- business improvement consultant
- ERP system consultant
- project manager
- system engineer (Python, JavaScript, SQL, HTML, CSS and so on)
- server engineer
- sales and marketing
- hiring and development
Not that every single person does all of it, but you take on what you are good at, have a go at what you cannot yet do, and cover for one another as a team. Everyone builds up enough of a baseline that conversations work internally and roles can be covered for to some degree.
As an engineer, the scope is probably what would be called full-stack.
Consultant and engineer — what does that actually look like?
For reference, I made the chart below, going on my own impressions.
For instance, I am the K-san on the radar chart in the image below (as in the initial…).
Up to my previous job I had worked as a consultant implementing and maintaining ERP systems, so even now my work leans comparatively towards consulting. As a share of working hours, my sense is that around 70% goes on the consultant side: hearing out requests, defining requirements, project management, and investigating and answering enquiries.
The remaining 30% is the engineer side instead: functional testing of modules that have been built, server work such as updating code (basic Linux and Git commands), checking data in the database (simple SQL), and so on.
Y-san's area looks narrow at first glance, but that is because they are currently at the stage of getting to grips with Odoo while putting their Python skills to use.
If you like learning new things and enjoy widening what you can do, do get in touch
So: the work calls for a lot of skills, and you end up absorbing them one after another.
If you are the sort who, day to day, looks something up or tries it out the moment it catches your interest or puzzles you, and who enjoys the range of what you can do widening, then I think this will suit you.
People who can enjoy survival, who want to feel themselves growing
(To put it bluntly: if what you are after is a job where the skills you already have earn you a reasonable salary, this is not it.)
I think "can you enjoy a startup" can be restated as "can you enjoy survival".
No boat! No net! No lighter, no knife either?!
⇒ How do you solve it with what is on this island? Would making one raise everyone's efficiency? How would you get to another island to fetch one? And so on. Once you have recognised there is a problem, what is needed is the stance of not stopping there, but asking "right, so what shall we do?" and trying things, one after another.
Food, water, somewhere to sleep, and a distress signal too?!
⇒ Skills do help, so you also need the drive that says "if what I have now falls short, I will go and pick up whatever is needed!"
Wanting to make use of the skills you have now is, of course, entirely good — but with a stance of "this is all I can do", the chances to show what you are worth at a startup with few people are quite limited. A crew member on a big ship has the work divided up and is asked to carry out their own part reliably; this is not that.
There's so much to do! I'll burst, I can't do it?!
⇒ It cannot be helped that the pile feels mountainous, but you set priorities and solve what is in front of you one at a time, try things and review as you go, and improve what can be improved. It is that plodding challenge, repeated.
Rather than setting out to build a luxury liner from the off: if you can look at a plank you can sit on and something to stand in for an oar and think "improve from here and I could probably build a boat that gets to the next island", then you are our sort of person.
"Shall I just dangle a line off a stick and wait?" — will that do?!
⇒ Forming a hypothesis and doing something to test it is excellent. But vaguely starting with whatever happened to catch your eye leaves nothing to test.
The basics: think about the purpose first, communicate as needed where something is unclear, and keep repeating the hypothesis-and-test cycle.
It is certainly close to survival conditions, but this is not a desert island, so make good use of your colleagues. As a basic of the work: check the goal and the deadline first, align on the purpose and the shape of the plan, and realign each time things drift from it. Get that cycle turning — hypothesis and test, combined with keeping people reported to, informed and consulted — and you should be able to move things forward with the help of those around you.
People who like being rational, and like thinking about what the real value to the customer is
(Delivering value to a customer, and solving their business or system problems, sometimes means not going along with how the customer feels.)
Quartile as a company started from taking our founder Tashiro's "provide more flexible, more cost-effective business management system services" as its founding purpose.
That founding purpose was part of what made me think "nice" before I joined, and having worked here ten months I still find that "this and that really do hang together properly for the sake of that purpose". Below I have picked out some specifics of how we actually work, in the hope that some of it comes across.
Our founding purpose is "to provide more flexible, more cost-effective business management system services"
…as our blog also says.
(Do have a look at this one too → We have decided not to write the customary Japanese email opener)
The price of an implementation is stated plainly on our website
Plenty of companies claim to deliver cost-effective services, but for a company that does system development, saying anything about price in advance is in fact extremely hard.
There are all sorts of reasons. For one, at the stage before development begins you cannot really say that customers often hold clear requests of their own; and even where things have been pinned down as far as the requirements level, it happens all the time that only once it has been built and put to use does anyone notice the real request lay elsewhere.
Given that, how can we "deliver a cost-effective system" to a customer, and let them invest in it with confidence and some view of what lies ahead? Our current service is what came out of thinking that through.
We contract directly with the customer who will be the user
(We do not take subcontracted work unless the circumstances are quite exceptional.) Being able to talk to the customer directly makes communication more efficient — hearing out their requests, taking feedback on what was built — and it also saves the cost of a third party's margin.
(That does mean more capability is called for as a consultant and as a project manager, so as the knowledge and skills asked of you go up, the work itself gets harder. It is correspondingly more rewarding, and there are more moments where you feel yourself growing.)
We do not build every request a customer makes
When a customer asks for something like "we want to add this here", we ask about the background, the purpose and the use, and if we are not convinced, we do not build it. Unnecessary customisation becomes debt against future maintenance costs.
Take the layout of the various printed forms: we often hear "this is how it is in the current (or previous) system". But does matching that layout produce any business value? If "the system is changing, so please get used to it" will do, then weighing development cost, maintenance cost, the cost of keeping it working through future upgrades and so on, we frequently put a proposal to the customer that we not build it.
Building whatever the customer asks for is, in the sense that we would be paid for the development hours, the tastier business. That we do not is because we started from "provide more flexible, more cost-effective business management system services". Rather than simply realising "what the customer wants to do", we want our value to lie in proposing what will "contribute to making the customer's work more efficient".
Development is agile, and billed time-and-materials (the customer is charged according to the time actually spent)
(Which is to say, not the approach of asking the budget, fixing a deadline, and then developing.)
The advantage of this is that by turning the cycle of building, having the customer look at and touch the screens, and taking their feedback in small, fast loops, the development gap can be kept as small as possible.
There is an advantage for the developing side too: no working to force things into a deadline fixed in advance, no rework after a huge build, and generally less of what makes a project slide into a death march. Given that we honestly cannot claim to have enough hands, it is no exaggeration to call this the best thing about our company.
(The four main features of a death march: (1) the deadline is too short, (2) too few engineers, (3) too little budget, (4) frequent changes to requirements and specifications. Reference: wikipedia/デスマーチ)
As a rule we do not work overtime. Where it cannot be avoided, we balance it within the same month by leaving early
These days I generally get in a little before 10 and leave somewhere around 19:00 to 19:30.
Even saying we do not work overtime, cases do come up where something urgently needs following up, so balancing it within the month strikes me as rational and good (part of the background being that working out overtime pay takes administrative effort nobody wants to spend). Since overtime is not paid, nobody wants to put in pointless hours either, and tens of hours of overtime a month never becomes the norm, which is healthy.
Incidentally, my hobby is games and I play something for a few hours every day. Right now I am hooked on Pokémon Legends: Arceus. Rowlet is my favourite.
…That said, asked whether I do nothing whatever work-related in my own time, the fact is that early on I did put a fair amount of time into the catching-up I needed. Hunting out introductory videos on GitHub and Docker, or watching Odoo's official videos while poking at a demo environment on my own iPad. Whether you simply like looking into new technology and features and trying them out may be what matters.
Meetings with customers are all online, from the first one onwards
We had COVID covered before the pandemic made online meetings the recommendation.
For the first six months or so after joining I think communication comes more easily if you can get into the Fukuoka office where possible, but we do have people who have worked remotely from the start.
We fill in timesheets in 15-minute units
As above, we run on billing customers time-and-materials (charging according to the time actually spent), so in meetings to hear a customer's requests and in the development itself alike, we record how many minutes each piece of work took, in 15-minute units. That is what we invoice the customer each month.
Which means there is no time to sit around vacantly. That is, I think, fairly demanding.
But while that pressure is there, in exchange — see the time-and-materials part above — there is none of having to build features nobody can say are needed or not, against a deadline impossible by any reading, with staffing short by any reading. So there is no need to work while feeling the whole thing is unreasonable, and you can stay mentally healthy.
If any of this resonates, do get in touch…!
This is a personal view formed from brushing up against various industries and jobs (part-time work and job-hunting included), but there do seem to be a fair number of cases that end up as "the corporate philosophy is glorious, but in practice, well…". Working while uneasy — "can sales really sell this product or service to a customer with their head held high?", "this feature is definitely going to stop being needed and cause trouble later" — would not, I think, be much fun.
These are my own values, but when someone asks "so what work do you do?", I want work I can answer with a smile. Even while you are new, and your work is not yet something to hold your head high about, being able to think "my work is doing somebody some good" connects, I believe, to whether you can work with energy, work happily, and in the end live happily.
In summary
Thank you for reading this far.
It has run long, but as someone who joined mid-career, struggled with getting up to speed at first, and now enjoys the work, I have set out the sort of person who — personal opinion — would probably enjoy working at Quartile. To sum up:
- people brimming with curiosity, who want to look things up and try them straight away
- people who can enjoy survival, who want to feel themselves growing
- people who like being rational, and like thinking about what the real value to the customer is
That is the lot. It is only natural that what I find enjoyable and what somebody else finds enjoyable differ, so in the end I suppose it comes down to fit. I would be glad if you came away thinking "I see — I might rather like working at a company like that".
We are currently looking for people to work alongside us. We look forward to your application.
Photo by pixabay
We're hiring! This is the sort of person who would enjoy working at Quartile