Tag Archives: Career

Tips for first time book author

I wanted to share the tips while they are fresh on my mind. I’ve been working closely with Packt Publishing. My first book is scheduled for December. A nice Christmas present for myself 🙂

Be a Contributor first. This lets you contribute a chapter before you attempt to write the whole darn book. Even 1 chapter, which should be around 20 – 25 pages, is not a small undertaking. Writing a chapter is much harder than writing a series of blogs. I know a few friends who have tried that and could not pass 1-2 chapters. Yes, they have been blogging for years! By being a contributor, you also get to experience the book publication process. Speaking of process….

Work with a close friend who have published before. The entire process of publication is more complex and longer than you may assume. Working with a good buddy who have gone through the process and have established working relationship with the editor mean you can focus on the content instead of the process. I used the word friend, not acquaintance. It has to be a person you know well, both in personal and professional capacity. You can avoid a lot of pains with a coach 🙂

Certainly, you may skip the points above. I did that (which kind of explains the unnecessary pains I went through). If you do, keep it short. Aim for 100 pages for your first book. The other reason for 100 page is you can always add later. My book started with 100 and ended up at 200, and eventually became 250 after the publisher formatted it. How I wish it was 100 page only! BTW, a publisher may ask you to write for at least 200 pages. That’s not a hard and fast rule.

Once you are ready to be the main author, try to do it alone. Working with multiple authors can have its complication. I know a friend whose book is delayed because a co-author was busy for an extended time. If you need multiple authors, make sure the outline is solid and finalized first. A book has to be very structured and precise, so differences in opinion can occur as there are many details to iron out. It is also hard to have consistent writing style.

Write around 50 pages before you approach a publisher. If you are using that 100-page target, you are half way done! At least complete the first 2 chapters, so you have something to show. A publisher will certainly appreciate real content when assessing the viability of your book proposal to them. It lets them judge better and faster.

Use the publisher template early. This avoids reformatting, and let you visualize what it will look like early. If you are writing for Packt, I can pass you the template. The template helps you to be mindful of keywords and texts that appear on screen. They also have guidelines on quotes and tables. I spent a lot of time on this because I did not use the template.

Give it time. Believe me, you may get sick of reading your own book! After you finish a chapter, leave it for at least 1 week. Come back to read it with a fresher perspective. Do this a few times. You should also read multiple chapters to see if they flow well, avoid any repeated content and ensure the entire structure is completely logical. I call this the process of stabilization. Some may just call it “Soaking It”.

Be clear on the Primary audience and Secondary audience. Virtualization touches a lot of things in IT, so there are many roles that you can target. In my case, the primary audience is VMware engineers, architects and administrators. They may work in VMware, partners or customers. As you know well, a VMware professional deals with many different roles in his/her organization. Do not be afraid to target different Secondary audience in different chapter.

Get reviewer early. But know them well. By knowing the reviewer knowledge and perspective, you can better understand the feedback. A feedback is always contextual, written from the reviewer view point. Know the context, and you can better decide whether you want to include it or not. Choose the wrong reviewers, and you get wrong reviews.

If you are writing about a product (e.g. vSphere), avoid working with versions that are not released yet. Minor details can change, even after a long period of beta. In my case, I have a lot of screenshots and metrics. Reviewing every screenshot and metric to see if there is any change was time consuming.

If English is not your first language, reduce the theory part, and focus on the hands-on part. English is my second language, and those chapters where I focus on the concept were harder to write. I kept rewriting and reshuffling the contents. There were occasion where I shifted an entire sub-chapter!

Decide the writing style. For my case, in my region a lot of readers don’t speak English well. I remember how I myself struggled with basic English when I first learned it. So I’m keeping it simple and conversational. In addition, infrastructure is also a dry topic in my opinion, so I want a light language. I also want to build relationships with readers via my blogs, Facebook and LinkedIn, so the language is very casual and personal. I want you to feel as if I’m talking to you as a friend. I deliberately do not want a written English.

For screenshot, keep the width below 800 pixels. Otherwise, the text will be too small on iPad or 13″ laptop. The length is less of an issue due to the book format. I had to retake quite a number of screenshots.

If you are quoting, ask for permission. Include the exact quotation, and why you’re using it. Assure the owner that you will provide proper acknowledgement.

Hope you find the tips useful. Feel free to add or correct in the comments section below.

The Chef and his cooking – Story of VMware Admin

I see a lot of VMware Admin/Engineers/Architect at end-user environment do not extend his/her influence beyond architecture. I think that’s a lost opportunity because Operations and Architecture are like Yin and Yang. Or Mobius strip.

I shared the idea that as the creator of the platform, we have to have interest on how it’s operated. It was an impromptu presentation at our VMUG Singapore back in mid 2014, hence no slide.

I used analogy about restaurant.

The restaurant business provides a good analogy to our Infra-as-a-Service business. We (Virtualisation Architect/Engineer/Admin) are the Chef. In that end-user environment where you work, you are the expert in producing what your customers want. You architect and design a solid platform, where your customers can confidently run their VMs. If there is an issue, you often get involved, restoring their confidence in your creation. You are seen as the VMware guy, or the virtualization expert. Yes, you may engage VMware PSO or SI, but they are not working for the company. You are the employee. As far as your customers concern, the buck stops at you.

You do not sell hardware nor software. You charge your customers per VM. In fact, to ensure that your customers order the right kind of VM, you need to charge per vCPU, per vRAM and per vDisk. The chargeback model is something that I very rarely see we discuss. We tend to stay in technical discussion. We need to realise we are no longer just a System Builder. We are Service Provider. By not extending our circle of influence into how App Team should pay for our service, we created the issue we have today (Oversized VM, dormant VM, VM sprawl). We need to “step out from the kitchen” from time to time. We need to be like Chef who step out to the dining area, building relationship with his customers, explaining the reason behind his cooking.

As the Architect/Engineer, we are the best person to determine how much it should be charged. We build this thing. We know the costs, and we know the capacity. Not convinced? Put it this way, would you rather someone else determine how much your creation is worth?

We all know that IT exists because of Business. It starts with the Business. Some of the issues we have are caused by unsuitable chargeback model and incorrect Service Tiering. The VM in Tier 1 (mission critical) platform cannot cost the same with the VM in Tier 3 (non prod). I’d make sure there is distinct difference in quality between Tier 1, Tier 2 and Tier 3, so it’s easy for business to choose. Need a good example? Review this.

Using the restaurant analogy, say you cook fried rice. It’s your dish. You need to determine the price of the fried rice. You also need to be able to justify why you have normal fried rice and special fried rice, and why the special one costs a lot more for the same amount.

To me, the Chargeback model and the Service Tiering serve as Key Drivers to our Architecture. I will not consider my architecture complete unless I include these 2 in my design. We are architecting to meet the business requirements, which are “defined” in the chargeback model (e.g. the business wants a $100 VM per month, not a $100K VM per month), and service tiering (e.g. the business wants 99.999% and 3% CPU Contention).

As shared, I see a chance for us to STEP UP and STEP OUT.

Step out of the kitchen and network with your customers (the App team). Educate and fix the problem at the source. Step up from pure IT architecture to business architecture. Architect your pricing strategy and service tiering.

The good thing about pricing is…. your benchmark is already set.

Azure, AWS, Google, and many SP have to a certain set the benchmark. Your private cloud cannot be too far from it. Too low and you will likely make a loss (it’s almost impossible to beat their efficiency). Too high and you will get a complain. Another source of benchmark is physical.

If you are pricing your VDI, the cost of a PC sets your benchmark. You can be higher, but not by a huge gap. A PC costs $800 with Windows + 3 year warranty + 17” monitor. Add your IT Desktop cost, and you meet your benchmark

Hope the above provides clarity. I’m keen to hear your thought.