In the last six years I have been lucky enough in IT to be fairly successful and advance my career. Lately I’ve been reflecting on what I did right, and what I might change. In looking to the future and where my path is going, I find I have to look into the past and better understand how I got here. While there was no definitive five year plan, I think there were three pillars that served me faithfully to enable growth and advancement. Continue reading “My Three Pillars”
There are two deployment models in Azure, the older being the Service Management model, aka classic mode. The newer model is Azure Resource Manager (ARM). For reasons that extend beyond this post, Microsoft is moving away from the classic mode and adopting ARM wherever possible. Up until a few months ago, the two models had not yet reached feature parity and so classic was still required for some deployments. At this point the two models are at feature parity, and in fact ARM has pulled ahead. That gap is only going to widen as Microsoft continues to pour investment into ARM and leave classic to die on the vine.
If you are looking into migrating your Azure classic virtual machines to ARM, you might be wondering what your options are. There are several potential solutions, Microsoft supported and otherwise. Each has a set of limitations and gotchas, and in this post I intend to review them and provide a guide for using Azure Site Recovery to get the job done. Continue reading “Options for Azure Migrations”
One of the things that I found most surprising about working in technology, and consulting in particular, is the sheer amount of writing we have to do. When I think about it, on a daily basis I am writing emails, IMs, text messages, documentation, memos, blog entries, or even newsletter articles. You would think that working in technology would be all plugging in cables, configuring software, and running scripts. But instead each day is full of reading and writing. That’s why it is so critical to be mindful of what you write and how you write it. In short, you need to Write it Right.
Writing it Right means adhering to some fundamentals of writing, which include making sure your spelling and grammar are correct. That goes for any writing whether it is an IM, email, or formal document. Obviously, some spelling and grammar errors in chat and text are inevitable, and the medium expects a certain level of informality and brevity. In more formal mediums, such as email and documentation, there really is no excuse for misspelled words or incorrect grammar. The tools to prevent such errors are built right into the products we use to write! It may sound silly, but clients and coworkers can and will judge you by the quality of your writing, so make it easy on yourself and utilize the tools in Word and Outlook to prevent common errors.
Writing it Right also means being aware of the context and content of what you are writing. The language and style you use in an email to a coworker will probably be a little different than what you would use for client communication. Depending on the document type the content should have a sliding level of formality going from the most informal (text/IM) to the most formal (Statement of Work/Final Documentation). Just as you would not put legal verbiage in to a text message or tweet, you also should not put a humorous pun into an SOW. Clients and customer expect professionalism in communication, and may share or forward anything you write to other persons in their organization. When sending an email, think to yourself “Would I want everyone in the client’s company to read this?”. If the answer is “no”, then it’s probably best to reword or skip it. Don’t forget that anything you release out into wild is subject to sharing and legal discovery.
Writing it Right means writing less and being more concise. It also means creating templates and forms to replace manual creation of documents. This is important to create consistency in solution delivery and speed up the process of generating documentation. Writing it Right also means have a back catalog of documentation available. There are many times that I have been able to shorten delivery times or avoid common pitfalls by referring back to documentation on a previous project. Clients also appreciate solid documentation, especially if someone takes over the environment and never received knowledge transfer from the previous custodian. Having an excellent document to refer to can be a lifesaver for them, and a great advertisement for you. When the project is over and you are long gone, the only thing a client has to refer back to is the documentation they were left with. Their impression of the project and its execution is largely informed by the final documentation left behind. Every communication and document that you write is an advertisement for yourself and your competency. Don’t miss a chance to leave a lasting, positive impression.