After many years as an editor, I’m finally working, rather apprehensively, on my first “lean publication”. This is a book that attempts to describe the importance of Database Lifecycle Management techniques in improving the quality of all database processes involved in the design, governance, development, delivery and ongoing operation of a database. Much like a lean software project, the idea is to deliver content to readers in shorter cycles, and then refine it iteratively based on reader engagement and feedback.
The alternative traditional editorial process can seem inexplicably slow. It is a process of carefully molding and shaping the author’s initial efforts. In much the same way that a book or film editor would do, the technical editor strives to help the author crystallize their ideas, to find the real ‘story’ of the article and therefore the correct narrative structure. This process can range from gentle guidance to radical surgery, as required.
In any event, the fear of the 3-star review is strong in any editor, and only when we have a fully rounded piece is it released to the wider world. I hope that Simple-Talk stands as testament to this proven method of delivering high quality, readable articles and books, with which people can engage.
So where is the possible value in a lean publication and by implication lean editorial process? One can understand the desire to give the traditional processes a shot in the arm, as well as the attraction of encouraging early reader engagement. However, hard experience tells me that one can’t use “lean” as an excuse to rush out content in a half-baked state, and then ‘fix’ it iteratively, based on the reader feedback and engagement that you assume optimistically will come flooding in. It won’t. I’ve tried to read a few such lean books and if its narrative is muddled, then its ideas are lost, along with any prospect of reader engagement.
A “lean” chapter, I believe, can and must initially be stripped back to the point that it clearly expresses only what we believe is its two or three most important ideas. The metaphorical back stories and full character arcs that make the content complete can come later, as long as the first “release” tries to tackle what we believe are the most important challenges and problems that people face with a given database process, and states clearly its ideas for their solutions.
Perhaps the lean publication process needs to encourage an atmosphere akin to a bustling university, where lecturers experiment with many different ways to explain core ideas to students, and get their feedback, before finally having the confidence to construct their ‘master work’.
This is harder than it sounds. It probably requires a whole new way of planning out the initial content, such that it exposes “just enough” information to explain the central ideas. It requires bravery to expose these ideas early, outside the safe, incubating atmosphere of the editorial process. It means that they won’t always be the right ideas.
No editor likes ‘hard’ or ‘brave’. However, the promise of real reader-engagement in the content development process is one that few red-blooded editors can resist.
This post is was inspired by my ongoing work on a “leanpub” book that attempts to describe the importance of Database Lifecycle Management techniques in improving the quality of all database processes involved in the design, governance, development, delivery and ongoing operation of SQL Server databases.