What I learned after studying some “Business Writing Skills”

Business writing skills credits @flickr

As I am growing in a leadership career, I am finding that I am reading and writing more business documents than code.

I studied for years on how to write code before writing it professionally. I never did that for business writing. Therefore, I decided that i should learn that. I picked a couple high rated udemy classes to get me going. The goal was to identify 5 things I can immediately apply to all important documents I or my teams write.

This article is about sharing those learnings from my perspective. I will talk about 5 key things that I am taking away from my quick education about business writing.

#1: Be clear:

Use clear english. Use the right words in the right way to make a clear point. It means using clear, small words that do the job.

  • Have a clear understanding of why you are writing. Why should anyone care? What do you want from your audience?
  • Use small sentences. It’s hard to maintain the flow in longer sentences and they are often unclear. They fail to communicate clearly.
  • Use Active voice i.e.  Subject predicate Object. Active voices are direct, more influential. They keep the reader engaged.
  • Use simple words. Don’t use complicated words when a simple one does the job. Don’t try to be smart. Try to make your reader feel smart.

#2: Structure is very important:

Think about how you will structure your data. What is the flow of your document? Is the most important information hidden or highlighted? Chances are there is too much information in your document causing ambiguity or reducing interest. Is written communication the best way to handle this topic?

#3: Have Empathy:

You are writing because you want your readers to do something. Potentially differently. In other words, you are writing to influence or make a point. It’s best to always assume

  • Your readers are busy so you have to make it easy for your readers to read your work.
  • It should be inclusive, avoid jargons if you have doubt that they won’t understand (consider audience, think if they are from diverse background, new to the org etc)
  • Have the most important information first (Objective, Action, TL;DR), followed by supporting facts and reasoning.
  • Clearly mention the intent if you are requesting someone to do something by a certain time.

#4: Polish your work:

  • The higher the stakes, the more time it needs polishing. It is important. No one likes to read just a blurb of text. Especially not busy people.

#5: Review, Review and Review:

  • Review that your document hits the point you are trying to make.
  • Review for grammar and spelling mistakes (I make them the most)
  • Review the audience set again before sending and check for inclusion/empathy
  • If stakes are high, consider a peer review
  • Let it bake. Put your document aside for a while, revisit it and you will find that you may have a new perspective.


I found these ~6 hours of investment incredibly helpful. Practice makes skill better, so I plan to practice by writing articles such as this. If you typically write to advocate some action. I strongly recommend some education behind business writing skills


It’s ok to throw away your code. You will write it even better next time.


Being a software developer is not easy. When I say it’s not easy, I do not only mean its technically challenging, but its also emotionally challenging.

We as a developer can get attached to our code. We write it while our mind thought of creative ways to solve complex problems. The solutions we have are like our brainchild. However we work in a world that is constantly changing. Change happens around us and its inevitable. You can do scrum, mocks, freeze the product specification but a change will always happen and it can happen to an extent that the code you have written for a problem would not be applicable anymore. As far as that product is concerned, you may as well trash that code.

Despite of all that, I am here to tell you that its okay. It’s okay to throw your code and write it again. Yes it requires time and it’s not always justified but every creative challenge you have solved while writing that code has made you a better developer already. It may not do the product any good anymore, but it has already done good to you.

Every time you discover a new or a better way to do something it makes the previous method obsolete. Developers would often create something and keep throwing away/updating their code until they are satisfied with its performance, neatness and efficiency. The earlier in your developing career you learn, that its okay to throw the code and write it again, the more happy you will be working as a developer.

I have had plenty of encounters where I had to throw away the code and write it again, but every time you come back to a problem after a while, you have a fresh point of view and possibly a different approach, which can be efficient and better than the previous approach. Even if its not efficient than the previous one, its definitely neat and organized than previous one. It’s because you have already solved the problem once.

Therefore my friends, if you find yourself in a situation where you probably have to trash your code – archive it, and if you happen to write it again, compare the archive with the newly written code. You will probably find that you have gotten better.

Share your thoughts in comments.

Developing with end users in the same room? Being proud about it and getting things done!


I am in general an aggressive (aggressive in getting my work done) software developer. I want to get things done as they come. I do not like a TODO items sitting around even though its small. This means working fast, taking quick decisions, using fail fast methods. It also includes continuous education to yourself from team members and web, educating team members, know the latest and greatest tools avail at your disposal and sometimes running an extra mile for team / organization.

I have had a privilege here at my job for being in the team that builds a continuously evolving website for almost half of the company. These people use this website as their day to day job. All the business that comes in, get entered in our system from this website.

That’s right. I work with my end users sitting 10 feet away from me.

We all know how its like to build a software and demo it to the client. This means often times there is criticizing, change in priority, new requests and more new requests. Sometimes on a good day, there is appreciation and respect.

With all this going on release after release, there can be a point where you can feel “This is what they ask for, that’s all they get”. Times when you know that the ask is not the best thing to do and there might be some other solution, but we keep mum because we are afraid of making the change. I have had these moments. You have had these moments. Everyone who dealt with a real end-user have had these moments. All these moments hinder motivation and our strive to innovation.

What we should (and our end users should) realize

  • They are not developers.
    • Developers tend to best understand another developers professional challenges. While something that appear challenging to end user might not be challenging for developers and what may not appear challenging to end users, might be challenging to developers.
  • Everyone is on the same side.
    • Everyone is working on a vision of a better product. Period. If you think this is not true in your case, then there are bigger problems.
  • Communication is the key.
    • Communicate, in your team, to end users and try and explain what you think is best and why. Paint the bigger picture. You may not always be right, but hey you may not always be wrong.

While it might not look that way, getting things done is sometimes hard in these circumstances. Here is what I try to do and recommend.

While it might not look that way, getting things done is sometimes hard in these circumstances. Here is what I try to do and recommend.

  • Have a vision of end product and work towards that
    • Without proper vision, nothing will go in one direction, Aim and develop.
  • Have a TODO list of what needs to be done. Every day.
    • goes without saying, organizing things is more productive
  • Think and design as much as possible before development.
    • You will always miss something. Its okay.
    • Update the design as things change.
  • Prototype key features / changes to my end users
    • Best way to avoid bad surprises at the time of demo and to keep everyone in the loop.
  • Share new ideas among team.
    • Brainstorming ideas with team members always helps, builds team.
  • Ask yourself, How can this be better?
    • Everything can be made better, its just the matter of how and when?
    • When you ask these things to yourself, the good software developer inside you will force you to do things the better way.
  • Take pride in your work
    • If you don’t take pride in your work, no one will.
  • Praise yourself and others on their hard work.
    • If you don’t praise yourself and your team, no one else will.

Obviously there can be more to it…

Do you work along side your end users? Be proud about it.

What do you do to make sure you are at your best everyday? Share in comments.