Remove bureaucracy, Embrace remote working

We don't want to be the norm

We have been embracing a dynamic working environment ever since there was only 4 of us, working in a small apartment. We refer to everything that prevents our developers from being productive and living the life they want as bureaucracy. It is dogmatic, I know, but the attitude keeps us alerted, always looking for ways to improve the environment and eliminate boredom.

The latest issue we try to tackle transparently and systematically is a remote working policy for staff. It is not like remote working is new at Cogini or in Vietnam. . Young and reckless, we believed in a culture step-change, affecting staff and businesses, as work increasingly became something we do, rather than a place that we go. The benefits from this decision are various, ranging from improved staff engagement, talent attraction, boosted productivity and a better work/life balances for employees.

The challenge we face after more than a year applying remote working into professional workplace is the growing mismatch in expectation and communication between board of management and employees. Working under pressure, there were urges to abandon remote working, bring things to a tighter control. But that is just a sight a weak management and we know we can be better than that. What we need, in this particular situation, wasn't tighter management and more processes. We need a clear understanding between staff and management on what, why and how of remote working. We made this guideline to express the concern we are having, practices we are doing and nonetheless, set the ground for further improvement.

---

The Guideline

Is remote working suitable for you?

Newbie developers, or competent developers who are phoning it in, are absolutely not going to have the moxie necessary to get things done remotely. It isn't all about technical skills though. Those who are sanctioned to work remotely by management are the employees with an appropriate skill set such as punctuality and good time management and organizational skills. Under any circumstances, you will be asked to to move back to the office if your colleagues or direct manager feel like the productivity and project progress is compromised because of your absence.

Stay connected, Stay motivated

Remote workers often suffer feelings of isolation. Some feel that they miss out on informal organizational discussion and have a poorer understanding of the office and project context. Try to bring yourself to on-site events whenever possible. If you are within the city, come to the office at least once a week. Try to combine it with some formal activities such as Project Review Meetings, TechTalks or Retrospective Meetings to make your time and communication worthy.

Because remote workers are not actually physically in the workplace, and therefore 'seen to be at work', there is a crucial need to make yourself accessible during your working hours and let people know what you are up to. Define a time frame as your 'office hours' and commit to be accessible during that. Update your status whether it is a general one or project specific for every day that you work remotely.

Despite that, remote workers do have to be able to motivate themselves to work independently and with less supervision. If you find this difficult and miss the direction you have previously received from face-to-face contact, remove working is going to be rough.

Don't write angry

When you work in the same room as people, misunderstandings can be quickly cleared up. In contrast, remote workers tend to spend most of their time communicating via the written word that can be easily misinterpreted from afar. If you are worked up about something - angry, confused, frustrated, etc - try not to vent your frustration in writing. Instead take a moment to voice or video chat with your team to discuss the situation. Make sure your work place is fully equipped and quiet enough for Skype calls.

Build your own office

Whether you are working from home or heading to your favorite coffee shop, you need to put some real thought into your work environment. Of course remote working offers better control over the working environment and you shouldn't lose a chance on getting nice furniture, natural light and bunch of other gadgets to make the station comfortable and convenient. But there are some benefits of working in an office that people often fail to notice and therefore can't reproduce for their remote working station.

• Right working environment to eliminate sources of distraction (TV, Game consoles, Kitchen, etc..)
• The office routine separates your work life from your personal life. 

When you fail to give your body proper breaks, it gets tired pretty quick and drags your productivity down. Many fuse their personal time with working time. Soon they find themselves exhausted and productivity is dropped. And even though they are in the illusion that they are working for longer hours, they in fact just get tired sooner. Well defined working schedule and working station give you physical and mental breaks, which is essential for the next productive working day.

The journey to an ideal billing option

General speaking, there are two types of billing we are using for our contract work: fixed price and Time and Materials (T&M). Fixed price contract is just like it sounds. Meanwhile a T&M project is similar to being an hourly employee, payment is made based on a set rate for the actual hours that you worked. Each of which has its own pros and cons and articles about that can be found at mostly every corner of the internet, as it turns out that this is a norm in consulting work in other industries too. What got my attention recently is how my ideal billing type has been changing through out the years.

When I was younger, having my first full-time internship, I was always fond of fixed-price projects. Why? It had always given me much less blocker doing thing that way. A project back then wasn't much different from a school assignment. The project requirements were given to me sometimes in a nicely formatted spec, sometimes a Redmine ticket or sometimes just a mockup. The only thing I needed to care was to finish the requirements in time. No one told me whether the project went through four rounds of development and lost us a bunch of money nor did I care about. I got my work done, and that was it. The simplicity made me happy.

Given that I am an untidy person, T&M projects, on the other hand, weren't that fun. I had to keep track of my time, and as I jumped between tasks and my Chinese classes, the little chore turned into a burden. The question "did I turn on/off my timer" kept running through my mind just about when I need some concentration. And even when I managed to get my task done, I needed to mind the time I spent on the task as well. Usually, I missed the estimate made by my PM. Even though this was expected (yo, I was an intern) and we "deal" with it by billing 50-75% of my time only, it still somehow left me a guilty feeling. Needless to say, in the early years of my career, fixed bid was the preferred option.

Further down the road, I gradually took more managerial work and the amount hasn't stopped increasing so far. The fixed bid that I used to love started to haunt me back. I soon learned that fixed bid contract is all about fortune telling and my team efficiency.

In order to make a reliable fixed bid without massively increasing the estimate, I have started to develop weird hypothesis about what would happen during the development process and truly wish for the ability to tell future like Nicolas Cage in Next. Ok, I accelerated thing a bit here. In practice, I make THREE versions of quote, each for ideal, normal and worst case scenarios. This all sounded insane at the first time I was asked to perform by my boss. Soon, though, I realize that engineers are optimistic and idealize most of the misty parts during estimating (hence worst case scenarios quote for the rescue). Yet, there are parts that are hard to predict anyhow, like the learning curve of a newbie, time to set up dev and prod environments for non-standard products, and deployment time. No matter how you look at it, it is definitely more work, boring work : (

And with all of that burden, I am not even making the estimate for myself, I am making it for my team. Which requires thorough understanding about the team and trust that they will do it in the right manner. If we are efficient at doing the work, we make money, or else an even or a lost. Efficiency of a person inevitably relies on one's emotion, the amount of work and morale. That complicated nature making the effort to jell a team just as challenging, if not more, as telling the future.


T&M billing option now proves to be useful for me, as an PM. I can really focus on getting the job done, rest assure that I will be paid for what I have done. Try stepping into customer's shoes, I also find T&M is more valuable for them, given that the consultant they are working with is ethical and trust-worthy. Terralien illustrate the point beautifully using the house building metaphor.

a fixed price agreement will almost always cost more and give you less than you need.

It has been pretty fun looking at the past and noting it down here. I am not sure how would my point of view change in the next few years but unarguably, this is one of the challenges whose answers define the shape of the company and set it apart from other norms. So I am pretty eagerly looking for next challenges here : )

Get started in Cogini Team

TEAMWORK GROUND RULES

There are three things that are important in general:

Ask: If a task is not clear, or more information is needed, please ask as soon

as possible. Asking is always ok. Doing the wrong thing (or doing nothing)

because you didn't ask is not ok.

Debrief: It's not "done" until you reported it done. This is often just a

one-sentence email to me or to the client, sometimes a "100%" mark in the task

list, or a ticket closed. It is done, completed or fixed only when whoever

needed it done knows about it.

Warn: If a deadline you know is important will likely be missed, warn me soon,

as the situation is evolving, and then we can usually figure something out. If

I have to learn at the moment of the deadline that it was missed, that's not

ok. If you are working on multiple projects with multiple project managers, or

if you're a freelancer, also warn me if your workload is above what you can

actually do, instead of not doing certain tasks.

Last but not least PRODUCTION SYSTEMS

When systems are in production, you need to be careful about what you do. 

It's easy to get in a habit during development of making bugs and fixing them,

but in production they can have real impact. So we need to have a review

and testing process for all releases to production. Test everything, even

simple typo fixes, as they can sometimes make a page give a parse error.  

In general, any bugs having to do with money can cause serious problems. 

And simply having the production site down for a few hours can result in

thousands of dollars of lost revenue.