Craft construction and factory construction are different ways to achieve the same goal. If you want a table, you can craft one by selecting lumber and using a wide variety of carpentry skills to shape and sand and varnish a table. Or you can select an item from a table production factory. Personal craft is great. Robots are great too. At enterprise scale, you probably want to see more automation and less craft though.
Writing a program is craft. The factory for software is called a Development Process or an SDLC (Software Development Lifecycle). There’s different styles, with more or less rigorous process and procedure, just as physical goods production factories have different systems of automation. The developers who work in an SDLC are still employing their craft skills, but they do so within the framework of the factory: they create software after a funnel of prioritization has brought features and designs and plans to clarity and they aren’t done until that software is tested, documented, translated, and in customer hands. The craft is now the kernel of a larger machine with inputs and outputs that are in themselves machines.
Selling something is a craft, like making a table or writing a program. You might do it well or poorly. It might be a thing you could repeat elsewhere, or maybe not. It’s a craft project. Selling a guitar for instance: that might mean finding a local buyer, arranging a test play, haggling a price. Or maybe you’ve got a room full of Gear Acquisition Syndrome results and you’re posting stuff on Reverb.com every week, but every sale is different. Some go smoothly, some fall through. There are also craftspeople doing enterprise software sales, and their deals are best thought of as a craft project. A sales person has worked with the client organization to determine need, fit product to need, ensure commensurate value, set a fair price, negotiate a contract, get the bill paid on reasonable terms, and ensure support so that a renewal can happen. The tasks and motions are sort of the same as in a full Go-To-Market (GTM) factory… it’s like yeah, we’re making tables alright. The problem is, repeatable throughput is limited. If metrics like “deals per account manager per quarter” or “days from hire to first sale” are not strong, maybe this team needs a more rigorous and disciplined GTM.
Going to Market on the other hand is like running a factory for selling. It’s repeatedly executing a complex process with supporting systems, checks and balances, management feedback, contributor visibility, and more. It’s engineering, but for sales. In engineering SDLCs, the input machine is usage analytics, tickets, field engineers, executives, engineering managers, architects, product managers, drawings, documents. The input machine for GTM is marketing: demand generation, white papers, customer references, analyst relations, SDRs, events, conferences, webinars. Software production wants a prioritized queue of qualified features to build and bugs to fix. Software sales wants a prioritized queue of prospects with a clear need, defined project, identified budget, and a desire to act. The queue is then processed with ruthless prioritization. Sometimes an engineer introduces a contact to an account manager and is surprised to find that the potential deal isn’t pursued. This is the same thing that happened when the account manager suggested a feature that didn’t get built. Input was not above the quarter’s priority line. The output of an engineering SDLC is quality software that produces happy customers and is easy to maintain. The output of a GTM is quality customers that reference your product and happily renew it.
In engineering or sales, the rigor of process is critical to produce the scalable outcome, but individual contributors must recognize that need and embrace it before the organization can grow.
Monkeynoodle.Org 