“Sharing My Practice” Discussion with CPSquare: Intro

Written by Sean Murphy. Posted in Community of Practice, EDA, Rules of Thumb

In May of this year I was invited to take part in a month long group discussion on CPSquare where my consulting practice was the focus. This is the introductory statement I posted to explain a little bit about my background and what I do.

Intro

I worked in Electronic Design Automation on board, chip, and system design in the 80′s and 90′s. This gave me an appreciation of the value domain specific visual languages for representing geometric, physical, logical, electrical, and temporal properties and relationships. Since I had studiously avoided electronics and anything related to hardware in my education I had to concentrate on the poorly understood problems of data management and applying computers to the design of computers.

I also learned that electronic systems design required a team of experts from different disciplines collaborating to create something new. A chip design team needs to reach a working consensus on a range of problems in different domains. One paradox over the roughly two decades I worked in system design was that solving a problem in one domain moved the constraint to another one, so that you a group that was critical for one or two generations has to let others take the lead as new challenges dominate.

When I was getting ready to apply to colleges I had a long conversation with a friend’s father who worked as a fighter aircraft designer at McDonnell Douglas. He was an expert in materials and mechanical design. He said that one of the challenges his organization faced was that aircraft survivability from the 1940′s through the 60′s had been driven by airframe and engine design as combat took place at close range using machine guns. As Gatling guns gave way to missiles there were many fewer combat engagements within visual range: avionics and electronic counter-measures, which had become important starting in the second half of the World War 2, now came to dominate the equations governing survivability. The challenge was that the organization was dominated by folks with a clear understanding of airframe design and they needed to learn how to incorporate guidance from many new disciplines.

I think this challenge of integrating not only the evolution of  knowledge in a particular domain but fostering effective communication and collaboration among experts in different domains was what led me originally to CPSquare. I was working at Cisco in a hardware design best practices effort and I read an article by Etienne Wenger on cultivating communities of practice in the Harvard Business Review. It was eye opening.

These days I work primarily with teams of two to five engineers or scientists who are experts in a field and are challenged with explaining the benefits of their services or software so that they can get their startup off the ground. I spend some time trying to understand the details of the technology but for the most part try and draw a box around it and understand the inputs, outputs, timeframe, and costs that a prospective customer will need to appreciate before deciding to engage.

The incorporation of a new technology into a business process often changes existing political boundaries, frequently obsoletes old assumptions, establishes new processes and ways of working together, and requires shared experimentation between the customer and startup for shared learning.

I am happy to answer any questions folks may have on challenges I face or issues that I wrestle with. I have learned a lot from my participation in CPSquare events over the years and am happy to take part in this exercise.

For more background on my current practice and some of the things that have influenced me please take a look at some of these blog posts:

Trackback from your site.

Comments (1)

Leave a comment

Quick Links

Bootstrappers Breakfast Link Find related content Startup Stages Clients In the News