We interrupt your regularly scheduled programming to bring you this short email back-and-forth I had with Aart de Geus last year during SNUG (Aart is co-CEO of Synopsys for anyone not familiar with the name). It happened just after his keynote where he spoke about something he called systemic collaboration. I remember it being quite interesting and thinking that in people terms, systemic collaboration seemed synonymous with cross-functional teams, a key characteristic in agile development. I asked the question in that direction… he was kind enough to respond. I’d be interested to hear what people think.
From: Neil Johnson [mailto:firstname.lastname@example.org]
Sent: Tuesday, March 27, 2012 12:44 AM
To: <aart de geus>
Subject: SNUG keynote
Aart, I’m at SNUG this week and enjoyed your keynote this morning.
This is my 6th snug (5 time presenter and first time tech committee) and you always do a great job of kicking things off.
This year, I was particularly interested in hearing you talk about systemic collaboration. With very few 1-dimensional problems left in semiconductor development, seems collaboration is absolutely necessary to enable real progress… whereas unilateral decision making for the benefit of one feature/team/function is usually offset by a corresponding negative impact to another for no net benefit.
My apologies for the long-winded buildup but this ends with a question about systemic collaboration…
…seems that from a tool perspective, Synopsys is doing it’s best to enable collaboration (especially in the area of physical design where knowledge from 1 tool is available to enable decision making/exploration in another). On the flip side, however, and countering the ideal of an integrated tool suite is an organizational structure that dominates most semiconductor firms. experts are almost always split into functional teams and go through long development cycles independent of each other. That type of silo based orgstructure leads to what’s better described as systemic disfunction than systemic collaboration imho. Examples are functional design and verification… designers write the design, verifiers build a testbench and it’s only after several months that the 2 actually come together to run sims (i.e. demonstrate progress). If either has made bad assumption, it doesn’t show up until well into development. Worse is the divide between hardware and software. These 2 areas often report to different executives and compete with each other for budget and resources (i.e. work in an environment that encourages conflict rather than collaboration). Seems that while modeling tools/emulations platforms/co-simulation tools and similar technology continues to improve, collaboration is limited to spec reviews meaning the teamwork required to harness that new technology is all but absent in many organizations.
My question finally… how far can Synopsys and other EDA vendors expect to go with tools geared toward creating a systemic collaboration while organizations structure themselves in ways that so effectively repel collaboration?
fyi… the reason your systemic collaboration hits home for me is because my interest for some time now has been agile development and how we hardware developers can learn from the agile software movement. imo, agile teams practice systemic collaboration in ways we can never hope to achieve but that was only possible through fundamental changes to they approach development. I could be way off, but I see there being a glass ceiling limiting the potential of even great tools that enable close collaboration between functional teams in hardware development until there are major changes to how we structure teams (you can lead a horse to water, but you can’t make it drink).
I’d be interested to hear your thoughts on any of that.
thanks again for the great keynote. And if you’ve actually made it to the end of this email… thanks for reading (or if you’re shaking your head right now, sorry for wasting you time!)
From: Aart de Geus <…>
To: Neil Johnson <email@example.com>
CC: Kathy Schmidt <…>
Subject: RE: SNUG keynote
Thanks for being an active participant in SNUG through the tech committee!
Thanks also for your thoughtful comments and question. There is no simple answer, but here are some perspectives:
1) Organizations are first and foremost structured for efficiency. Whereas the term “silo” tends to highlight the negative, a silo is also an area of focus around a theme and aimed at getting maximum push and emphasis on its objectives. We have a number of business units (Implementation, verification, IP, etc) that at times we refer to as silos, but are fundamentally are as of deep expertise. Even within these areas, there is more hierarchy (each product). Within implementation, we have gradually gotten the products to be more and more “systemically aware” and the amount of physical understanding that is embedded inside of our synthesizer is quite astounding.
2) Silos, or let me call them “focused organizations”, invariably come about historically. The boundaries tend to be determined by very practical reasons. For example: design and manufacturing are separated effectively through libraries, rules, PDKs, etc. This is very efficient: you follow the rules and you will get good yield. That is until the boundary conditions become too narrow, and the issues become more “systemic” requiring understanding or actions on both side of the fence. This is the same for HW and SW. There too, segregation has worked incredibly well, until people started to optimize HW for some SW needs, and vice versa. At Synopsys we have examples in both of these categories with products straddling the fence: Yield explorer between implementation and manufacturing and virtual prototyping between verification and systems (software).
3) Organizations have to evolve to focus on the areas of biggest change and challenge. Invariably this starts with taskforces, etc, in order to work “accross the fence” without disrupting too much an otherwise efficient organization. Over time, though, if the impact or necessity warrants it, one restructures the organization. This tends to bring to the forefront a whole set of “old silo” issues that can then be fixed but, of course, starts creating a new set of issues. Let me call this “evolution”. And… as Darvin predicted 150(?) years ago, the most adaptive organisms survive best.
Simply put, leadership implies focusing on the continual organizational adaptation to the changing needs and opportunities. Systemic thinking is my attempt at keeping a bit of an overview on the strategy behind that.
All the best,
Why post this now? Well… this morning my memory was jogged by a related yet unrelated conversation around how EDA companies and their customers can benefit from practicing agile development. I’ve always thought EDA companies with their positioning and influence are very well situated to give agile hardware development a nudge in the right direction. I guess my question for Aart was a trial balloon of sorts to get a feel for what shows up on the radar for the folks that help run the show :).