In the Beginning…

As I stated in the post titled Writing a Technical Book, “I am often asked for more information about writing a technical book.” In a follow-up post titled, One Way to Write a Technical Book, I state, [here] “I share details of my approach to writing a technical book.”

People reading these posts have asked questions about my process – how I go about doing the writing that will eventually become a book. I answered this question in part during an interview for Malathi Mahadevan’s (@sqlmal | Curious About Data blog) book titled Data Professionals at Work (which is a book that explores the habits of a handful of folks in the SQL Server Community). In this post I share the beginnings of writing, for me…


In the beginning of the writing process, I begin.

A tautology? Maybe. It may be circular as well, but there are differences between the tautological and circular. Climbing back up the rabbit hole:

(click to enlarge)

This is the beginning of a book.

Will you see this chapter in print? Maybe. Will it read as it now reads? No. It will most likely be rewritten – more than once. Sometimes the edits are themselves circular in that it is edited to read one way and then edited to read as originally written.

Writing is funny like that.

Does that bother you? Does repetitious doing and then undoing – digging a hole and then filling it in – get under your skin? Does the inefficiency of it all drive you up the wall? If yes, writing may not be for you.

If writing is not for you, are you less of a technologist? Professional? Person? Goodness no! It’s just one thing that’s not your thing.

Know Why You’re Writing

In One Way to Write a Technical Book, I state, “I write because I love to write.” For me, that’s a powerful and pregnant statement. It means I cannot be plied with money or promises of fame (or clicks or page views). It means I write for me.

I find writing for me freeing. I believe being free results in me writing better; I know it results in me writing more. More is not always better except when it is better and writing more is better than writing less. One may will always edit.

I think why you write is the most important aspect of writing.

One Last Thing

If you find yourself thinking, “Someone should write more about / document this topic in plainer language / with better / more complete / real-world examples,” maybe that someone is you.


If you want to write, begin writing.

Don’t worry about the rest, not now. Just start. Start a blog. Start a manuscript. Start a channel. Put something out there.

In the beginning, begin.

T-SQL Tuesday #111 – What is Your “Why?”

I enjoy math. I noticed a pattern learning math, perhaps you experienced something similar. I found arithmetic an exercise in memory. I have a good memory (well, I had a good memory…) so memorizing a bunch of rules was no big deal. 

When I learned algebra, arithmetic made more sense. In addition to the memorized rules, I saw why the rules existed. I understood the rules better as a result.

This pattern held all through my math education. I understood algebra better once I learned geometry. I understood geometry better once I learned trigonometry. I understood trigonometry better once I learned single-variable calculus.

An Axiom (for me)

I notice a similar pattern applies to my career (or careers, as the case may be). I’ve served in many roles: 

  • Farm laborer
  • Musician
  • Stockyard laborer
  • Truck driver
  • Service technician
  • Soldier (part-time in the Virginia Army National Guard)
  • Electrician
  • Electrical engineer
  • Electronics technician
  • Manufacturing automation integrator
  • Software developer
  • Author
  • Data professional
  • Entrepreneur

The similar pattern manifests itself in this manner: I’ve enjoyed the position – and more success in the position – when I had a reason to do the work; some reason other than a paycheck. In some cases, I had multiple “why’s” beyond remuneration. For example, I join the Virginia Army National Guard to learn electronics and serve my country – to especially protect everyone’s right to free speech guaranteed by the First Amendment. I may not agree with what people say, but I was (and still am) willing to fight and die to preserve the right of US citizens to say whatever they want. 

As a result, I enjoyed serving in the National Guard (for the most part). I learned more. I learned better, I think, because I enjoyed serving.


Entrepreneurship can be challenging. I believe one needs a “why” – or perhaps several “why’s” to remain an entrepreneur. The “why” cannot simply be money. Money isn’t inconsequential, mind you, but I believe the best “why’s” are less tangible.

Passion plays a major role for me. When business isn’t going well or when business is going too well, a couple intangible “why’s” – passions for both entrepreneurship and the kind of work I am blessed to do – inspire me to keep a steady hand on the tiller.

Also, entrepreneurship affords more and different ways to serve people. Am I saying one must be an entrepreneur to serve others? Nope. Flexibility with time, though, facilitates opportunities that may not otherwise be possible, or as possible.

What is Your “Why?”

That’s the question this month: Why do you do what you do?

I look forward to your replies.

The Rules

T-SQL Tuesday has the following rules:

  1. Publish your contribution on Tuesday, 12 Feb 2019 between 00:00 UTC to 23:59 UTC.
  2. Include the T-SQL Tuesday Logo and have it link to this post.
  3. Please comment below with a link to your post.
  4. Tweet about your post using #tsql2sday.
  5. If you’d like to host in the future, Steve Jones.


On or about 19 Feb 2019, I will publish a roundup post. (Until then, that’s a broken link…)



“Do I Need a Biml Framework, Andy?”

No. No, you do not need a Biml Framework.

In the same way that I do not need a vehicle powered by an internal combustion engine, you do not need a Biml framework.

You see, I live about 5 miles from Farmville Virginia. I could walk to town each time my family needs groceries. I could pack as many groceries as I can carry into a backpack and walk the 5 miles back home. There are several benefits to this, not the least of which is the exercise that I would get walking to the store and then walking back – carrying a load of groceries, even!

“Is walking to the grocery store efficient, Andy?” Well, if you’re going get all persnickety about it… I suppose not. But think of all the money I would save on vehicle maintenance and fuel – plus the benefits of exercise!

Does this reasoning sound silly to you? It does to me (and I wrote it). Let’s add a dose of reality, shall we?

The Art of Data Integration Architecture, Part 1

Like many sciences, data integration is part art and part science. The art part is just good judgment. My lovely bride, Christy, has an awesome saying about good judgment: “Good judgment comes from experience, and experience comes from bad judgment.” With that in mind, I share the following in the hope that it saves you some… experience:

Don’t Use Biml…

If you are building a data integration solution that loads data from one source to one destination, do not use a Biml Framework. Heck, don’t even use Biml for this. Build this solution manually in SSIS or T-SQL or some combination thereof. It’s quicker, easier, and less-frustrating to construct a loader manually.

Use Biml…

If you are building a data integration solution that loads data from a couple dozen sources to a collection of destination tables, use Biml but do not use a Biml Framework. It takes about 40 hours to become proficient in Biml. To learn Biml (or anything, really), you first need a real-world problem to solve. Next, you need the gumption to try and solve that problem using a tool you have not yet used to solve a real-world problem.

Why wait until you need to build a couple dozen SSIS packages? It takes me about 2 hours to build and test an SSIS package that incrementally loads data. The math works:

24 x 2 = 48

If I take the time to learn Biml, which will take about 40 hours, I can complete two dozen loaders in less time than it would have taken me to build those SSIS packages manually. Plus I’ve learned something. More on this in a bit…

Use a Biml Framework…

After you’ve invested the initial 40 hours in learning Biml… If you are building a data integration solution that loads data from one or more sources to a collection of destination tables, use a Biml Framework. Once your framework is built, you can decide when it makes sense to use your automation and when it makes sense to build loaders manually.

I wrote about a Biml Framework here.
You can download an early example of a Biml Framework here.


Perhaps you’re looking at all the innovation and automation happening around you and thinking, “This is just some passing fad. The djin will be put back in the bottle soon and we’ll return to the days of carving our own integrated circuit chips out of wood.” Ok, maybe you’re not thinking precisely that. But I hope and pray you get my drift.

If the announcements of the latest Microsoft conference have taught you anything, they should have taught you that automation is following the arrow of time. Automation is on the increase in both volume and complexity. One benefit of having lived over half a century (and doing technology for most of that time) is perspective:

I promise you, the djin no longer fits in the bottle.

If I’m scaring you, good.

I’m not arguing the merits of automation.
I am arguing the facts of automation.

I am not attempting to assess the potential good – or potential harm – of automation. I am stating that it’s here to stay – and grow.

If you want to live and work in a field where you can master a craft and simply do the same thing until you retire, technology is not the field for you. Technology is the field for you if you enjoy learning and growing.

“How much time should I spend learning new stuff, Andy?” Experience informs me the answer is “about 25% of your time should be spent learning and growing.”


My brother and friend Kevin Hazzard (DevJourney | LinkedIn | (awesome and fascinating) DataDriven interview) refers to “numbers” as “nummers.” There are a nummer of reasons I like this mispronunciation… perhaps I will explain another time. I bring up nummers here because – as my friend and brother Aaron Lowe used to tell me (before he passed away earlier in 2018 – I miss him…):

Math is hard.

I once delivered a solution that contained several hundred SSIS packages using Biml. The unit-of-measure for my estimate, based on the nummers I shared earlier (2 hours per package based on an incremental load SSIS design pattern) was “months.”

I delivered the solution in days using Biml.

It’s possible your employer isn’t good at math.
It’s possible your employer is more interested in providing you a job than in making a profit by remaining competitive (I love it when politicians speak of providing jobs… don’t get me started…).

The nummers argue that one day things may will change for your employer. If When that day arrives, things may will also change for you.

(Did I mention that I hope I am scaring you?)

So… Learn!

At the time of this writing, it is not possible for others to take your knowledge away from you. I pray that day never comes, but more than half-century of existence has trained me to not by surprised by anything.

So… learn!

Learn as much as you can. Consider knowledge a hedge against future changes. Add knowledge of the new and shiny to your experience. I don’t care how old or how young you are, start today.

I share this in the same spirit of you wanting me to get more exercise by walking to town to buy groceries, except that I am right about this and you were… less efficient. 😉

Start at SQL Server Central. It’s free.

Well, you have to give them your email address.

I understand that bothers some folks, but I encourage you to carefully weigh the benefits of sharing your email address with an entity that provides this much free education against falling behind in technology trends, application, and education. It’s totally your call, but you may find yourself in possession of the cleanest Inbox Zero of anyone who is uninformed and increasingly less-employable…

The Stairways are awesome.

Head over to edX. Many courses there are free. If you want, you can pay for certificates that you can post on LinkedIn. But – please – go get the knowledge.


If you want to dive deeper, sign up for Biml Academy or SSIS Academy or Fundamentals of Azure Data Factory! I’m still building the material so the costs for subscribing to the academies are low.


It Costs Precisely $0.00USD to be Nice

Be nice. We all have bad days. I know I do. It seems like I get interrupted about 1,000 times more when I’m busy than when I’m not busy. Why is that? Is it some vast universal conspiracy to rob me of productive work? Is it all in my head?

I am not sure.

One thing I am sure of, though, is that it ultimately comes down to me. I read this years ago and it stuck:

If the Comic Sans font bothers you, please reread the message.

I Am Here to Help™

I get a bunch of messages from recruiters. Many of them via LinkedIn. Most of the communication follows a similar pattern:

  1. I receive a Connection Request from someone with “recruiter” or “personnel” or “people” in their title.
  2. I accept. Why? I like people. I’m just that kind of guy.
  3. I get a message – usually within 24 hours – that reads in part something like the following: “I came across your profile searching for someone to fill a position for a ______. I think you may be a good fit for the position. If you are not interested, please share with any qualified individual in your network.” This is sometimes followed by a promise of referral recompense, though I’ve never – not once, to date – ever been compensated for recommending someone.


Back in my Linchpin People days,  I actually did a little recruiting. I’m not entirely sure, but I think I made more money per hour doing recruiting than I have ever made – period. I mean, I didn’t do it for the money (and I don’t recommend people for referral compensation, I was just pointing that out…). I was actually trying to help a friend, or customer, or both out of a jam.

In short, IT recruiting pays well. So I understand why recruiters behave they way they sometimes do.

There was a time when I would have done almost anything to have recruiters reaching out to me almost daily. It wasn’t that long ago, actually – just a couple decades. I remember begging recruiters to just give me a chance! I knew I could do the work. I could learn anything and I have a strong work ethic. I knew I would succeed. But…

I Lacked Experience

‘nough said.

Lately, Though…

Most recruiters who contact me these days do so via LinkedIn following the communications pattern I shared earlier.

I don’t mind. I used to mind, but I no longer do.

“Why Don’t You Mind, Andy?”

I’m glad you asked! That’s an excellent question.

There are actually several reasons. Please allow me to share one of them. Last year Enterprise Data & Analytics was hired to help a team deliver medical-related data integration with SQL Server Integration Services (SSIS). The customer succeeded with our help and all was well with the world. But there was this one twist that bears mentioning:

We were hired by a company for which I worked years ago.
And my boss used to report to me.

“It’s a good thing you weren’t a jerk to that person, huh, Andy?”

Almost. That sentence has an extra five words in it. There at the end.

Don’t get me wrong. It is good I wasn’t a jerk to that person. It’s better that I wasn’t a jerk to anyone – well, almost anyone – at that place of business. Why?

Because you never know.

Back to the Recruiters…

So… here we are communicating with people whose specialty and experience currently lies with hiring IT professionals… and you decided it’s a good idea to “teach them a thing or two?”

Really? One question: Have you thought that one through?

Are you never going to need to change jobs again? Ever?
Are you going to leave the IT field when you do?
If so, is it possible – even remotely – that you might encounter even one of the recruiters with whom you interact on LinkedIn?

One Way to Respond

How do I respond? I have this note saved as a text file. It takes about 15 seconds to find, open, copy, paste, and edit:

Be Nice


I am a Product Manager (No, I’m Not… But I Can Explain)

I was about to click the Publish button for this post about my new role as a product manager when my friend and brother, Scott, called. I mentioned it and Scott said, “You’re not just a product manager. You’re a problem-solver.”

Scott is correct. Hence the parentheses in the title of this post.

“Is This The Best Use of Your Time?”

A friend used to ask me this question all the time. It’s a fantastic question. The question made me pause and think. Pausing and thinking is mostly good most of the time. When is pausing and thinking not good?

When it delays action you desperately need to take; action you are uniquely positioned to take.

Evolution of a Response

For a couple years my response to this question was to answer, “No,” and then I would feel silly for considering the thing I had wanted to do. But then a funny thing began to happen: I increasingly felt cornered by “the best use of my time.”


Let’s pause right here and consider a different perspective. I was being selfish. I wanted to do what I wanted to do, the consequences be damned.


This is an accurate description right up until the point where I didn’t do what I wanted to do – what I felt desperately needed to be done – to help people attempting DevOps with SSIS. Instead I stuffed the ideas back down inside, put my head down, and went back to doing what was a good use of my time.

Was I in any position to make this determination?
Was I qualified to make this call?

Yes. Yes I was.

Coming Out of the Corner

Over time, my response evolved. I stopped feeling silly about wanting to solve DevOps for SSIS and started feeling silly for placing myself into a position which offered more obstacles than opportunities.

The short version of a long story is: I extricated myself from that corner.

Before I did anything else – I am not making this up, I can produce witnesses – I started writing SSIS Catalog Compare. I started coding within minutes of announcing my decision.

I did not know what I was doing.
I am still learning.
I feel like I only recently worked my way up to being a n00b C# developer.
I didn’t know anything about designing a software product. I know more now but (still) not enough.
I didn’t know anything about marketing a software product.
I didn’t know anything about managing a software product.

I continue to learn. Here’s the latest thing I’ve learned:

I am not afraid.

I am not afraid of not knowing. Frank Herbert got it right (in Dune): Fear is the mind-killer. The only way to learn is by using my mind – the same mind battling fear of not knowing.

Was the question about the bet use of my time well-intentioned? Absolutely. My friend was watching out for me, he had my back. I learned from the experience and walked away more mature and with broader perspective. I learned. I grew. I would not be where I am now had I not.

I am a Problem-Solver

Scott reminded me I am a problem-solver. I always have been a problem-solver. Lord willing, I will continue to be a problem-solver.

Becoming a software product manager was required in order to solve a problem.


One Way to Write a Technical Book

In my previous post titled Writing a Technical Book, I discussed phases of the process of writing a technical book. In this post I share details of my approach to writing a technical book.


To summarize, the steps for writing a technical book are:

    1. Idea
    1. Proposal
    1. Contract
    1. Writing
    1. Editing
    1. Typesetting
  1. Publication

How I Write Technical Books

First, a disclaimer. I want to be very clear: This is but one way to write a technical book. This is not the only way and there are likely better ways to write a technical book. This works for me; your mileage may vary.

I choose to list the problems I am trying to solve and my responses.


Publishing is a business. Books are commodities in the publishing world. Like every other commodity on the planet, books are treated as goods to be sold, deliverables to be delivered. While the publisher desires a well-written book, they want a book above all else.

Impedance Mismatches

The process of writing a technical book is fraught with impedance mismatches – the misalignment of the goals between the author and publisher.

One example: the author may see the book as their magnum opus.
The publisher desires a good book, well-written. But most of all, the publisher wants to publish something. That’s how they get paid.

At the intersection of magnum opus and getting paid lies the AreYouDoneYet? call / email. This is usually an (or several) unpleasant communication(s) for all involved. The publisher likely feels fiscal pressure to ship. The author feels deadline pressure. As I said, not pleasant.

I know plenty of single-book authors who tell me, “I will never again publish a book through a publisher.” Without fail, each one lists an AreYouDoneYet? experience as their reason or part of their reason. I feel you. I really do. I don’t like those calls either.  Many solve this problem by self-publishing.

One Solution: Write First

How do I solve AreYouDoneYet? I change the order of the process and write the first draft, first – and then submitting the book proposal.

If you don’t like the AreYouDoneYet? communications, get done first. If you believe self-publication is the route to go – and I write this as someone who has self-published – then you will need to write the book before you can publish it. Go ahead and write the first draft.

Just ship.

It is not uncommon to experience difficulties writing such as writer’s block or finding adequate time to write. If you are writing about software that is scheduled to be released, the release schedule may slip. In fact, you should count on experiencing these difficulties and allow for them in your writing schedule, whether you are writing for a publisher or self-publishing.

I am not sharing this with you to discourage you. Quite the opposite, in fact! I want you to enter the writing process with both eyes wide open. I want to be unequivocal about these facts:

  • Writing is hard work.
  • Writing requires discipline.
  • Writing takes time.

If you read the writing of others and think, “I could do a better job,” odds are you are correct (especially if you’ve read my writing). I am not a good writer. Prolific does not equal good. But – and this is an important but – you have to write to write better than me.


“Why do you write, Andy?” In my humble opinion, why you want to write is the most important question you need to answer. This question needs to be thoroughly settled in your mind before you apply keystrokes to document editor.

My answer? “I write because I love to write.” I think it stems from the joy I derive from learning and a desire to pass that joy to others. Trite? Perhaps. But altogether true. I enjoy writing. I write stuff no one else reads, even. I journal. I do not care if a single soul reads this blog post. Does that mean I don’t care about writing?

Nope. I rewrite for you.

So I rewrite. I do that here, even. I edit posts before publishing them. I often read a post later, cringe, and rewrite some sentence, paragraph, or entire section. Often, I add material or links for clarification. More often, I delete stuff (especially commas and parentheses and run-on sentences and sentences that begin with conjunctions and ellipses…).

Robert Graves said, “There is no such thing as good writing, only good rewriting.” He’s right. In his book titled “On Writing,” Stephen King shares awesome tidbits about the craft. I found King’s On Writing and Steven Pressfield’s The War of Art and Do The Work inspiring and informative. Note: those links are to my Amazon Associates account. If you would rather not use an Amazon Associates link, please click one the following links: On Writing, The War of Art, Do The Work. These are books worth reading. I wish I’d read them before I started writing.

I want you to experience the joy I derive from learning. I know some of you experience that joy because you tell me.

The coolest thing about writing, for me, is helping someone learn something.

Another word of advice:

If you are going to be a writer, please learn to write.

Learning to write will actually solve most of the AreYouDoneYet? problem.
Don’t believe me? Start writing a book today. Follow my advice and write first. You’re going to have to write the book for the book to get written, right? Even if you self-publish, you will need to write eventually.

Why not start writing today?


Do you remember grammar and language arts classes in grade school? I do. I made straight D’s in these classes until my senior year in high school. I had a fantastic teacher my senior year at Nottoway Senior High School. His name was Barrow Cyrus. Mr. C. taught with passion. I’m sure other teachers had passion; I noticed Mr. C’s passion. Years later I would see the movie Dead Poet’s Society and be reminded of him. I made a B in Mr. Cyrus’ class. I started enjoying reading. I began to think about writing.

Remember those dumb outlining exercises? I hated those. First you have to plan how you’re going to write. You have to think first, then plan, and then write. Even back then, I enjoyed writing, but I wanted to get to the fun part and Just Write.

Those dumb outlines will save you many a headache, many hours rewriting, and might just help you avoid one or more AreYouDoneYet? communications. Please trust me: I’m right about this.

Does your outline have to be in standard outline format? Nope. It just needs to exist before you write the body of material.

In Practice

Start writing by creating a document for each chapter. Provide a title. Optionally, write an “In this chapter…” section. Don’t write more body text, not yet.

Add section headers and optionally include an “In this section…” sentence or two. You may add subheadings.

Please resist the urge to start writing in earnest on the topic until you’ve created an outline for each chapter you intend to write.

Does this mean you will not add chapters later? Goodness no! You will add and remove and consolidate chapters as you write. Start here. Write an outline.

On Advances

An advance is a pre-payment for writing. It’s essentially a loan against future royalties. An advance is seen as a way to compensate authors during the writing process, since writing takes time away from other paying endeavors.

I no longer accept advances on writing.

Why? I find it depressing to receive the first royalty statement from the publisher stating something akin to, “You earned $100 in royalties. You now owe us only $400 of the $500 we advanced you.” I’d rather receive a check for $100.

In worst cases, and advance can be weaponized against an author in an AreYouDoneYet? communication. I have a strict rule regarding ultimatums that applies to everything in life, not just writing.

Andy’s Ultimatum Rule states: You can deliver an ultimatum to Andy once.

I almost always capitulate when delivered an ultimatum. The other party gets their way. They have deployed a nuclear option, however; whether they realize it or not. My top priority from that point forward is departure.

It’s probably time I shared some potentially discouraging truth with you about writing…

You Are Not Going to Make Money Writing

Now that’s not entirely accurate. Odds are, someone reading this post will, in fact, make money writing. I have. So why’d I write that? I wrote that because you should not begin writing if you are only in it for the cashola. If even part of the reason you want to write is to make money from writing, stop now and save yourself some frustration.

I earn less – considerably less – than minimum wage writing.

“Are you telling me there’s no money in writing, Andy?”

Yes. Yes I am telling there is no money in writing. But

You can earn more money as a published consultant. If you want to look at this as a silver lining, please understand there’s a cloud attached.

My first book project was Professional SQL Server 2005 Integration Services (Wrox, 2006). That particular book sold more copies than all my other books combined. I made money off that book. The year that book was released, my salary tripled. Why? That’s an excellent question to explore.

Often, CIO’s and CEO’s do not follow the technology crafts. They don’t know who’s good from who’s not-so-good at tech. They listen to friends in the business for advice about who to hire. They hire larger firms that have been around longer because, they reason, those firms must be doing things correctly to have survived and grown.

You and I know the biggest and oldest are not always the best. We understand technology and know how to discern between who’s up-and-coming and those riding past success – or even firms that have better salespeople – or firms that flat-out lie. Some CIO’s and CEO’s cannot separate the wheat from the chaff. Many can (they didn’t get where they are for no reason!) but not all.

If you and I are bidding for the same work and I am published and you are not, I am probably going to win the work because the customer is going to reason, “Andy must know what he is doing because he’s written a book about the technology.” They would be correct insofar as I know enough to write about it. Does that mean I am going to do a better job for them, though? Maybe. But you may not get a chance to show them you can do better work than me because I can drop a physical book on their desk and you cannot.

Is that unfair?
Yes. Yes, that’s wholly and completely unfair.
It’s also reality.

So I lied. You will make money from writing, just not from the act of writing all by itself.

Consider not accepting advances.

If you accept an advance, I recommend you save the money as if you hadn’t received an advance. That way, should you find yourself in an AreYouDoneYet? discussion and an ultimatum regarding the advance is made, you preserve the option of responding akin to, “Will you take a personal check?”

If you accept an advance, please, please pay very close attention to the section in the contract about how the advance is distributed and collected. I’ve heard horror stories about authors actually owing the publisher money when books don’t sell as expected.


Maybe reading this post has discouraged you. If so, I am glad. Do I like hurting people’s feelings? I promise you that I do not. If you are discouraged it’s likely because you opened this post thinking some things that are simply inaccurate about writing technical books. If I’ve disabused you of false notions, I feel I’ve done you a favor.

“I’ll Just Self-Publish”

Self-publishing is a way to avoid AreYouDoneYet? communications.
Self-publishing is a way to avoid contracts and advances and all the associated headaches.
Self-publishing is a way to add work to managing the book and, thereby, the book’s value – especially the long tail. (That link is to an excellent blog post by none other than THE Seth Godin. If you’re thinking of self-publishing, you need to read Seth Godin!)

Shelf Life

Books have a shelf life. Publishers have relationships with book outlets – physical outlets like the ever-diminishing book box stores and with Amazon. In addition to these relationships, publishers also have marketing departments that create banner ads for books you and I see online. Publisher marketing departments also create email campaigns designed to attract buyers to books.

This increases book sales.
This takes time.


Please do the math. Is your goal to make money from writing? I’ve shared my thoughts on that matter already. I contend the value of writing lies in consulting after being published. I feel that way because that’s what I have experienced. John Grisham probably has a different perspective.

Once the writing is done – the work – and the book is published, it’s time to advertise. You want as many people as possible to learn about your book. You want them to want to buy your book. You want them to want to hire you as a consultant. And, as I said earlier, you want to win the horribly-unfair competition against those who are not published (or not yet published) for mind-share in the minds of CIO’s and CEO’s.

The math is simple: More is better.

It’s true that I can avoid the pitfalls I’ve listed (and many that I’ve not touched upon) by self-publishing. But, bottom line, you are most likely not going to be able to advertise as much or as well as a publisher. And if you are able to advertise as much or as well as a publisher, consider doubling – multiplying, really – the advertising of your book by combining your efforts with that of the publisher.

One last thought about the math: Is it better to earn 100% of the royalties by selling 100 copies of your self-published book or to earn 10% of the royalties for selling 1,000 copies of your publisher-published book?

If you read that and thought, “That’s the same!” you are wrong.

Please scroll up and reread the paragraph about my salary tripling. Also, please see the section about the amount of work done by publisher advertising departments. You need mind-share. That’s why you should write (unless you love writing like I do!). Even if you love writing, you still need mind-share. Mind-share pays the bills.


I wrote Building Custom Tasks for SQL Server Integration Services (clean link) from a 12-part blog series. I wrote the blog series in 2012. I copied the contents into Word, edited the material, built a more-relevant demo task, paid an artist $200 to design the cover (not this cover), and popped over to CreateSpace to ready the book for self-publication.

I even printed a test copy. I was that close to pushing the button on self-publishing in March 2017. And then my editor emailed and asked, “Andy, why didn’t you send me that manuscript?” It was a fair question and I gave an honest answer: “I didn’t think you’d be interested in publishing so small a book.”

Building Custom Tasks for SQL Server Integration Services comes it at 111 pages. I really didn’t think Apress would be interested. Apress was interested. The book was released in July 2017.

He was interested.

Everything is Negotiable

I negotiated a bunch or author copies for Building Custom Tasks for SQL Server Integration Services. A bunch.

I failed to consider – and negotiate – more copies for my co-authors of The Biml Book.

I failed.

I led that team initially, and co-led the team along with Scott Currie at the end of the process. I regret my failure to lead and apologize to the team for missing this detail.

Why did I negotiate a bunch of copies of Building Custom Tasks for SQL Server Integration Services? I wanted to be able to give copies of the book away at conferences and speaking engagements. I did and I have.

Key take-aways:

  • The number of author copies is negotiable.
  • The writing schedule is negotiable.
  • The advance (or lack thereof) is negotiable.
  • Editorial control is negotiable.
  • Ownership and the right to share some (or even all) of the content in other outlets such as blog posts and articles and whitepapers for which you may receive additional remuneration is negotiable.


If you are considering writing, I encourage you to write. I want you to enter the profession (and it is a profession), though, with both eyes wide open. I want you to know what to expect. I do not want you to think writing is easy because it’s hard work (even if you enjoy writing).

After publishing your first book, it’s normal – perhaps even a rite of passage – to look back and think, “I am never doing that again!” If you’ve published and feel that way, I promise you things get better with the second book and subsequent books. Why? Because your initial expectations were part of the problem.

The problems caused by your inaccurate expectations about writing have been solved.

Last August, a small subset of The Biml Book author team rewrote the book. It took about three weeks. One Amazon reviewer commented on the unity of voice, even. That didn’t happen by accident.

For me, the rewrite was the most difficult part of writing The Biml Book. When it was done I was ready to not think about Biml for a while. If you read that last sentence and know anything about me, you know that was a heavy emotion and a pretty big deal. I love Biml! But I needed a break.

Enterprise Data & Analytics started a gig right after the rewrite concluded. We were required to be onsite for the kickoff and the customer’s HQ was a few hours drive east of my home in Farmville. Since the project was just getting started, Kent Bradshaw and I were onsite 8 hours per day; no more, no less.

Being an early riser, I got up each morning a few hours before we were due at the work site and wrote. Of all the things to do, why did I write? After weeks of rewriting, why in the world did I write?

I wrote because I love writing.

I wrote Data Integration Lifecycle Management with SSIS in one week, writing a couple hours each morning and a couple hours each evening.

I spent several weeks rewriting the book, editing, removing, and adding content. But the 185 pages you can read today started as 110 pages in Word written that week.

You Gotta Figure Out Your Why

Simon Sinek wrote a couple really good books about vocation motivation:

Start With Why and Find Your Why are excellent books.

You need some reason to write. Really, you need motivation to accomplish anything in life. I don’t think money is a good-enough reason. You need something else – something beyond money.

My why? Love. I love writing.

Regardless of whether you write or not, find your motivation.


Writing a Technical Book

Writing a Technical BookI am often asked for more information about writing a technical book. As author or co-author of twelve books focused or touching on technology, I consider myself experienced – not an expert.

I’ve noticed “ah-ha” moments recently when sharing insights and advice, so I thought I’d write a post about it. I hope that’s ok. If you’re here, I reckon it is.

A Typical Workflow for Writing a Technical Book

“So just how does a technical book get written, Andy?” I’m glad you asked. The answer is, unsurprisingly, “It depends.” It depends on the publisher and author(s), but mostly on the publisher. It can also depend on the topic and competition (real or imagined).

Step 0 – Idea

Someone has to come up with an idea for a book. It can be either a publisher or author, but someone says, “There should be a book about that!” Publishers often seek authors these days. Every time I share this fact I get blank stares and looks that communicate, “What did you just say?” It’s true. These days publishers are looking for authors to write about technology topics.

Finding good writers is hard for publishers. The writing process is hard work and requires discipline and stubbornness from authors. I am not making any of this up.

Once the idea for writing a technical book is codified-enough, the next step is…

Step 1 – Proposal

Every publisher with whom I’ve worked has a book proposal process. Book proposal templates vary but share some important features, such as:

  • Title
  • Description
  • Author(s)
    • Author bio(s)
  • Target audience
    • Reader market size
  • Competing titles
  • Projected page count
  • Writing schedule
  • Remuneration details

Most of these items are self-explanatory. Some are negotiable. For example, you will be guessing (wildly) at the reader market size. You will also be guessing page count. And writing schedule.

Although it’s very important I choose to hold off sharing details about remuneration, for now.

When writing a technical book, there is often some give-and-take regarding the book proposal, followed by…

Step 2 – Contract

The book contract usually includes snippets from the proposal. At its heart, the contract is the work-for-remuneration document.

You should always read the contract carefully and strive to understand not only the language of what is written but the nuance of what is not written.

If you have any concerns, I recommend you consult a lawyer – especially if this is your very first experience with a writing contract.

The contract will always include the writing schedule and page count. Pro tip: delivering a first draft early that is longer than the proposed page count is not going to be an issue. (That last sentence is pregnant…)

As an author, you want to make sure you are comfortable with the contract when writing a technical book.

Step 3 – Writing

The author writes (or authors write) the first draft. For technical books, this includes screen shots and code snippets. Writing may also include quotes from others or other books.

Everything must either be original or attributed. No excuses.

There will be language regarding original / attributed content included in the contract, accompanied by language about penalties should the book contain non-original-and-unattributed content, i.e. plagiarized material.

Writing a technical book takes time to do well.

Step 4 – Editing

Editing involves at least a couple phases:

  1. Language editing – someone who is good at human language syntax, plow, and structure and understands technology well-enough to not bungle the author’s intent reads through the manuscript and notes places where better sentence structure, different words, and entire sections can be moved or changed to enhance idea-flow.
  2. Technical editing – someone, usually a technologist, who is willing to walk through the examples, samples, and demo code to verify it works and there are no missing steps.

Sometimes you can find a technologist who is good-enough with language to perform both functions – or a language editor willing to tackle the technology demos – but that’s rare.

Editing takes time to do well when writing a technical book.

Step 5 – Typesetting

Not all books are published physically, but all books pass through a typesetting phase. You may think, “Why, Andy?” That’s a fair question, especially for books published only in electronic formats (e-books).

Formatting the written word is important. There’s an entire science dedicated to fonts. What looks good on a paper page may not be as easy to read in a web browser or an e-reader like the Kindle. Publishers (and authors… well, good authors) want the reader to enjoy as little resistance to reading as possible. That’s not as easy as it sounds.

Books are more than just words. There are images and code to consider. Readers often complain about line-breaks in published code. In response, publishers go to great lengths to manage code line breaks and line continuation indicators. Again, this is not as easy as it sounds.

When writing a technical book, typesetting takes time to do well.

Step 6 – Publication

Once the idea for the book has been conceived, the proposal submitted and accepted, the contract agreed upon, the book has been written, has been edited, and the typesetting is complete; the book is ready to be published.

All authors understand this step: this is why they signed up to write a book in the first place!

There is no way to adequately and accurately communicate the emotions of opening a package and seeing your name printed on the cover of a book.


This post covers writing a technical book at a high-level. In my next post, I share tweaks to this process I have learned from experience.

Who is Exhibiting at the PASS Summit 2018? Enterprise Data & Analytics, That’s Who!

I am honored and excited to announce that Enterprise Data & Analytics will be an exhibitor at the PASS Summit 2018!

If you browse on over to the PASS Summit Sponsors page and scroll to the Exhibitors section, you’ll find us listed:

Honored and excited – that’s me!

I see – and have lived – this virtuous cycle in the SQL Server and PASS communities:

  • A person discovers the Community and is overwhelmed at our openness and genuine willingness to help others. They realize they are not alone.
  • They learn more and become better at their jobs which, in turn, positively impacts their quality of life.
  • Some desire to give back to the community, so they develop a presentation and submit it to a User Group or SQL Saturday.
  • Some are selected to deliver their presentation.
  • Some presentations are well-received and increase the visibility of the presenter in the community.
  • As presentations are honed over time, some are used as a springboard to develop and deliver other presentations, further increasing the visibility of the presenter.
  • Some presenters achieve enough visibility to become a brand.
  • Some presenters are selected to present at larger events, like the PASS Summit.
  • Some presenters use their newfound greater visibility and brand awareness to join a consultancy practice or to become independent consultants.
  • The continued care and feeding of the brand of some consultants drives business growth.
  • The businesses of some consultants grows to the point where they can become sponsors and exhibitors at events such as User Groups, SQL Saturdays, and – eventually – the PASS Summit.

This cycle can be broken (or quashed) at any point by any number of actions, inactions, missteps, mistakes, and/or competitive overreach. In fact, I promise you will make mistakes and take missteps along the way (ask me how I know), but those mistakes and failures can tear you down or build you into more than you were – and the outcome is 100% your choice.

I advocate for the next generation of presenters. I want to see you engage, learn, share, grow, build their brands, and give back – just like I did.

Go get ’em!


PS – Need some help with your data? Contact us! We are here to help and by hiring Enterprise Data & Analytics you support some great communities!

On Working Remotely

I read a re-published article titled Working From Home Vs. Working At The Office: Who Gets More Done? by
Nate Hindman. The article was published on the Small Business blog of an insurer, The Hartford.

Of interest to me – a proponent of working remotely – was the comparison section, accompanying data, and the conclusion (which I share here):

Lister notes that when determining the efficacy of remote vs. in-office employees the culture of a team is as important as the work itself.

“If a team doesn’t know each other that well, it is far better to work face to face,” she says. In-person interaction “gives people the time to build social connections that make it easier to collaborate remotely and create that level of trust to be effective when they’re not in the same room.”

The salient points?

  1. Culture matters
  2. Rapport counts

Culture Matters

You can have the best people. They can be intelligent, talented individuals who know how to play nice with others. But if your culture is oppressive, their endeavors will fail.

Since I know and work with talented technologists I see this time and time again. Tip to employers:

If you want to keep top talent, you cannot pay them enough to put up with your crap. You have to stop the crap.

If you, as an employer, want to practice handing out participation trophies, you need to engage in a neighborhood sports league. People who are self-motivated enough to seek the knowledge they need – and wise enough to then apply that knowledge in creative, innovative ways – are demotivated by the recognition of “everyone as equal.”

But there’s a flip side: These same individuals are also not motivated by applause at the team meeting, Employee of the Month parking spots, or Starbucks gift cards.

I can hear you thinking, “So how do I motivate my top performers, Andy?”

I’m glad you asked,


That’s it. Training. Send them to training. They’ve self-identified as people who like to learn. Do you have a top shelf developer interested in cloud technology? Send her to Reinvent or Build. Save your Starbucks gift card money and allow someone else to park closer to the building. Send your top performers to more training.

I have been told thrice in the past six weeks about great people who left their last job or are about to leave their current job because their employer killed the training budget. Is training expensive? Yes. But not as expansive as finding a new employee – let alone a new top performer.

Employers, please do the math.

Rapport Counts

At Enterprise Data & Analytics, we often consult remotely, but we insist on starting projects face-to-face. Why? See the quote from the article above. Email is extremely subject to interpretation. People who don’t know me may misinterpret what I write in an email – unless they’ve had an opportunity to get to know me. there’s no substitute for building rapport. There’s no other way to build trust. Both trust and rapport are best built face-to-face.

A little-known fact: poor rapport with the customer team is the number one project killer. I and my team cannot be successful if we are unsuccessful at working with your team. Fortunately, I and my team are fun to work with! We are not prima donna’s, we learned because other people shared with us and one of the things we learned from the people who shared with us is: We should share with others. We love learning! I think that’s why we love sharing and helping others learn.

Customers are often shocked that I consult. I have a great team working with me but yep, I still show up and deliver. I think folks get the impression that someone who’s authored / co-authored a dozen books just isn’t accessible. Nothing could be further from the truth!

I help people every day!

In addition to public training with Brent Ozar Unlimited and SQLSkills, I deliver customized private training to companies on-demand.

I and my team deliver data integration solutions for customers, and we bring value when we do. (The post linked in the last sentence is worth the read. The short version is: Expensive developers are not as expensive as they appear.)

How may we serve you? Let us know!


  1. Be a dependable adult. This isn’t about age. It’s about maturity. Penny Trupe is a millennial and she’s a rocking consultant at Enterprise Data & Analytics.
  2. Share knowledge if you have it, seek out a mentor if you need to learn. (Pro tip: we all have something to share and something to learn.)
  3. Work hard and work smart. For more information, see Grant Cardone’s books The 10X Rule and Be Obsessed or Be Average. A tip o’ the hat to my Data Driven Podcast co-host and brother from another mother, Frank La Vigne (blog | @Tableteer), for turning me on to Grant.