Who is your Chief Engineer?

I really like Scott Bellware's post about a chief engineer to drive the development of software within your organization, which is based on the definition of the same role at Toyota (which, incidentally, is referenced quite often when talking about lean software development.) I also like the though that such chief engineers need to be grown and cultivated within an organization with a culture of change already in place. This is very similar to what Mary Poppendieck calls master developers in her book Lean Software Development. These people are responsible for representing the customer as domain experts and oversee the design and development of software since they know about the technology and still use it! 

In another post, Scott rewords the chief engineer's responsibility within a context of acceptance testing:

A Chief Engineer in a software product development organization can write acceptance tests without the burden of elaborate end-user testing tools. He can use the common tools of the trade. He understands the imperatives of using tests as documentation and uses usability-focused test authorship, and sets standards for authorship that his organization cultivates and follows.

If I'm reading between the lines correctly, it sounds like the chief engineer might not be writing code anymore, but can sure write tests to insure that the software is implemented in a way that its behaviors pass the tests that he wrote. I like that very much. I've read in so many places and truly believe that great managers and leaders still code. They have to have their hands wet and dirty. Writing acceptance tests, or BDD and other kinds of tests is a great way to do that while at the same time making sure that they are not in the way of the developers. Talk about having your feet in both the customer's world and in your own world at the same time! I don't think this concept exists any other way in software development.

Now, how do we get a chief engineer if we are a one man show like myself? I guess it is up to me to cultivate myself into one. But that can take years! I guess the only solution, in the meantime, is to surround myself with customers and use all the tools that we have so that I can understand them as best I can. BDD, DDD, acceptance tests, etc... Eventually, either I'll become a chief engineer in that domain or I'll end up cultivating another one, which will mean that the business that I haven't started growing yet will be making money (crossing my fingers!)

Thanks Scott for the great post!