Connecting geographically distributed consultants

[Re-hash of a posting I made to the PSVillage forum]

Verilab is a multi-site, two-continent, three-country firm (UK, Germany, Texas), with consulting teams scattered across clients from the US West to East Coasts, to umpteen places in Europe, and with growing presence in Asia, the Far East, and South America. The challenge is helping my team to remember that they are a team, that they are my team (i.e. that they are Verilab as opposed to <whatever client they may be in>), to let them benefit from being that team, and to do all of that across space and time (zones).

To help keep us all together, we've tried (and still use) a number of tools and techniques, including:

1. Company-wide email lists. This is the oldest mechanism. We used to have several of them - some technical, some business, some serious, and some for Friday afternoon nonsense. But we realized that volume is important for lists, and too many lists each with too little volume would die. So we merged them into one until such time as the volume gets too much. This works well, but needed a lot of care and nurturing to begin with. Some shy individuals still hide in the shadows too much.
2. Company wiki (we use Twiki). This has lots of potential but hasn't yet worked as well as I'd hoped. We have a ton of stuff on there, but lots of "entropy food". There is a core of material that is useful, but a lot that is old and hairy. Overall, it's worth having, but probably needs more personal attention.
3. Internal blogs. Some success. This seems to be a very personal thing. Some people love to tell other people what they're up to - and some don't. This is a horse I'm still flogging, because I think it's A Good Thing.
4. External blogs. More success. My ideal would be that there would be *only* external blogs, but then there's almost no chance of getting the quiet shy people to speak up. Also, see point below about Yammer versus Twitter.
5. Yammer. A surprising recent success. We messed with Twitter, but that's externally visible. One of my guys found Yammer and we gave it a go. All of a sudden, people are ... well, yammering back and forth across the Atlantic. The odd one-liner of status, occasional yells for help, and even the beginnings of technical discussions that then move onto some of the more appropriate forums (like our mailing list). My aim was that it provide the same sort of impromptu conversation that
   co-located people get by standing up and yelling over their cubicle wall. Seems to be achieving some of that. The fact that Twitter (public) got very little uptake while Yammer (internal only) took off was noteworthy. As with all of this stuff, the human issues are more important than the technical ones, and obviously feeling safe that your conversation was only among "family" was an important human issue. Recommended if you want to try something out.

We've also dabbled with the usual meeting-enhancing suspects, including:

• GotoMeeting - works fine, does what it says on the tin
• Skype - ditto. We use this a lot for one-to-one, and occasional video conferences. Multi-cast video would be cool.
• Shared Google Apps presentations. Just tried this last week and it worked great. Much Cheaper than GotoMeeting, and if all you were using that for is PowerPointing, Google may be worth a look.

We've had at least one such meeting where the attendee list was:

• Group A - Austin, TX office
• Group B - Munich, Germany office
• Attendee C - at home in Edinburgh, Scotland
• Attendee D - in his car in Texas
• Attendee E - in Bristol, UK airport waiting for his flight

Worked surprisingly well.

Overall, the degree of technical collaboration we've achieved is, I think, superb. I see detailed technical inquiries flashing back and forth and being answered with a speed that the official support channels of the tools we use just can't match. And ramp-up time on any given skill is dramatically reduced for any engineer who wants to yell for assistance on a new area. This has huge positive benefits for our clients too. It's rare that any single engineer can know every answer to every question instantly. But in Verilab, our clients can get access, through any one consultant, to the much larger "verification hive brain".

And all meetings must now be carried out in Esperanto

Psst. Would you like to hear a secret? It could help you and me make lots of money. Maybe we'll be famous too. Either way, it's a really cool secret. Want to hear it? I have a condition though, before I tell you.

I need you to agree not to go off and exploit the secret without me. I've put quite a bit of work into figuring it out, so I want you to work with me, not against me. Of course if it turns out that you already knew the secret - maybe I'm only imagining that it's cool and new - then the condition doesn't hold. But if I'm really letting you in on a proper secret, I need you to agree to work with me, not against me. Sound fair?

Now, let me be clear. I will not be offended one bit if you don't want to hear the secret. I'll say that again. No Hard Feelings. Really. Some people don't like secrets. That's OK. And if you're one of those people, fine. We can even still work together. But not on the secret.

So, what do you think? I give you the secret. In return, you give me an assurance that you won't use it without me. Are you in? 

If you said "yes", you and I have just made a form of "Non-Compete Agreement", something that the worthy Joel Spolsky says is, in the context of employment contracts, "completely outrageous". His remedy reflects the fact that, whether he likes it or not, Spolsky is as good a salesman as he is an engineer (which is, incidentally and as far as I can judge, very). His remedy is to point out to engineers-under-pressure-to-sign-a-non-compete that they may have a bargaining chip. He suggests:

"If the employer absolutely, positively insists that you promise not to go work for a competitor when you leave your job, you can tell them: "fine. You don't want me to work for a year after I leave, that's fine, but if I'm going to be 'on the beach', I want you to keep paying me my salary for one year after I leave, until I can legally get a job that you approve of."

And you know what; providing that is proposed in the same "no hard feelings if you don't accept" spirit that my original "you must not use my secret against me", it's a reasonable tactic (although not one I'd recommend). The potential employer can weigh the costs and benefits, just as the potential employee can. And both can decide according to their own sets of individual priorities.

But suppose they - both employer and employee - were forbidden from doing that weighing. Suppose Someone Else decided that under no circumstances is a non-compete permitted unless the employer continues to pay salary after the person has gone. What that Someone Else would be doing is effectively imposing a form of minimum wage. They'd be forcing the employer to pay above a certain mininimum OR NOT AT ALL. That Someone Else would have taken the ability of the potential employee to try to work a deal and turned it into an Unalianable Right. And I've already argued how careful we have to be with those.

So, does such a Someone Else exist. Well, yes it seems they do. And, unfortunately, it's the German government again. Here is the clause - something identical being legally required in Germany - covering non-competition in a new draft employee contract I just reviewed for a business partner in Munich:

"During the non-compete period the Employee shall receive a compensation which amounts for every year of the prohibition to half of the contractual benefits last received by the Employee."

Remember, there is no negotiating on this. The Employer has only two options if he feels he must protect the secret: he can either have the non-compete and pay money to the Employee after they leave; or he can simply not give the Employee access to the secret at all. There is NO MIDDLE GROUND. Even if they both agree, the Employee and Employer cannot make that agreement the basis of employment. (Well perhaps they could; but it would be unenforceable).

So, with a simple swipe of a pen, some bureaucrat has added another nail to the coffin of German engineering employment. Because with that pen, said bureaucrat has made Indian, Chinese, Roumanian, you name it employees more attractive (to the extent that those governments have a more laissez-faire approach) by making German employees less attractive.

They may as well have said that all meetings in Germany must be carried out in Esperanto.

Much Ado About Methodologies

ACT 1 Scene 1

It's an an early morning in Verilab Austin. Tommy's office. He's just picked up Davie Robinson who is visiting from the UK Verilab team. Davie's now working in the conference room with JL, while Tommy goes over his email. As he works his way through the list, a sequence of visitors arrive, either physically or via new emails or IMs:

[Davie pops his head through Tommy's office doorway]

Davie: So, when did we standardize on the VMM?

Tommy: When did we what?

Davie: The VMM. You said we standardized on it.

[JL arrives next to Davie]

JL: Why did you say we've standardized on the VMM?

Tommy: [suspicious] Who says I said we standardized on it?

Davie and JL: [together - pointing to a press release] That did!

Email from Gordon (Verilab UK): Seems we've standardized on the VMM

JL: Did you see Gordon's email?

Tommy: Hang on I'm ....

Email from Mark (Verilab Germany): I'm using OVM at the moment. Am I supposed to stop?

Tommy: %*&!$....
[Exeunt JL and Davie. Backing away, slowly]


Here's the reason for the consternation:

http://synopsys.mediaroom.com/index.php?s=43&item=605

You see, the trouble with press releases, as any political press secretary will tell you, is the devil's in the details but the message is in the large. You have to keep an eye on them both. Here's the core of our quote:

"We have found that VMM can act as a key component in such a deployment [of an effective methodology]..."

And that does indeed reflect the reality of our day to day work. The VMM really can, and in fact does, add significant value to chip teams. We have deployed, are deploying, and will continue to deploy the VMM at clients where it is appropriate. Now as is normal with press releases, that phrase and others went through various revisions, back and forth between us and the final editor.  But in the end, the meaning stayed intact. Now look at the bigger context:

"Leading European Design Consulting Firms Standardize on VMM Verification Methodology"

Unfortunately that can obviously be interpreted as:

"Leading European Design Consulting Firms Standardize EXCLUSIVELY on VMM Verification Methodology"

And of course in Verilab's case, that isn't correct. Here's why.

Verilab tries to plough a scrupulously objective furrow in EDA when it comes to tool vendors. Our primary allegiance is, rather, to our clients. And while we consider Cadence and Mentor and Synopsys (see how they're in mere alphabetical order) among several others to be our good friends and partners, we are exclusive to none of them. And by "objective", we don't mean we'll say the same amount of nice things about each vendor. If vendor A's offerings were consistently inferior to vendor B's for a given client, we'd tell the client (and, if they were open to our advice, the vendor). And if A was consistently worse than B for everyone else; well we may well tell everyone. That's our job. And it's why our clients like us. We're not just contractors, we're consultants. We've seen more chip flows, across more tool suites, in more clients and more countries than most any other team on the planet. And we have no hidden tool agenda. If a spade needs calling a spade, we'll do it. So if the amount of nice (or nasty) things we say about each vendor happens to be the same for each, that's because that's how we call it. And in fact, that *is* in general how we call it. Our view is, consistently, that choice of tool vendor is not, from a technical point of view, the decisive factor in verification capability. Verification is fundamentally a problem of Peopleware; not, per se, Software, or Toolware.

So there you have it. Verilab absolutely believes that the VMM can be a key component in the deployment of an effective verification methodology. But it is not the only such key component and it is not the only approach used by Verilab.


It is, as Shakespeare said, my bad. None of this was the fault of anyone at Synopsys.

The Dangers of Gratuitous Unalienability

Suppose there was a bill passed tomorrow, creating a law that made the minimum hourly pay rate for engineers in the US $10,000/hr. As of tomorrow, paying a US engineer anything less than that minimum rate would become illegal.

Would you care?

Well, if you're a US engineer, I hope your answer is, "Hell, yes I'd care. What a stupid law". And, contrariwise, if you're an engineer anywhere else, you could be forgiven for rubbing your hands in glee at the thought of all that formerly US work coming your way.

But suppose, now, that the same law was created, but with an "Only If You Want To" exception. In other words, suppose the law said that your clients could pay you no less than $10,000/hr, unless you and your client made a prior arrangement for a lower rate. Let's call that prior arrangement an ... oh, I dunno ... how about "a contract".

Now would you care?

In this case, I imagine the answer is a puzzled, "But surely that's no different from no law at all?" And you'd be correct. By allowing you to give away, or abandon the "right" to a $10,000/hr rate, the damage created (in the form of making you unemployable) of the original law is undone. In other words, the damage created by the original law arose out of the fact that the original law took a simple pre-existing right to a $10,000/hr rate (hey, I'm free to quote that to you today if I want) and forced it onto you and your intended clients or employers in the form of an obligation. The damage arose because laws tend to make some rights unalienable - that is, you cannot choose not to have the right in the question.

Ah but if only this was just a wee story. And of course, it's not. As well as operations in Austin, TX; Bristol, England; and Edinburgh, Scotland; Verilab also has an office in Munich. And the German bureaucrats are very, very good at this kind of thing. Take, for example, the recently announced German "Nursing Care Leave Act" (Pflegezeitgesetz “PflegeZG”) which came into force earlier this month and which my friendly neighbourhood legal advisors in DLA Piper sent my way. Germany regularly comes up with little gems like this, adding more and more "rights" to employees. As a result, the poor Germans, saddled as they are with an increasing burden of unalienability, find themselves increasingly uncompetitive in the world market.

Of course, work goes on in Germany. Verilab has had an office there for over five years now, and we're looking to hire, as always, superb engineers. But we, and everyone else, would be hiring even more superb engineers if the burden of gratuitous unalienability was lightened. nicht die Spur einer Chance.

Verification Planning

David Robinson, another Verilab dude, has started a blog over here. Coincidentally, David also just uploaded his recent DAC presentation, made in association with Springsoft. The document is simply the PowerPoint slides, so it'll be of primary use to anyone who attended one of David's sessions and wants the slides as a reminder. Verilab does however provide intensive consulting on requirements-based verification, so if you'd like to discuss that in more detail, give us a call. Our emails take the usual canonical form: firstname dot lastname at verilab dot com.

What does business need from "The Government"

That - specifically about EDA, but it applies more widely - was the thorny issue tackled by some brave souls at one of the numerous panels at DAC last week. It's good I wasn't on that panel. My answer to the question tends to be a more or less (usually less) polite version of "To have them get out of my face and let me get on with running a business." In particular, the visa issue they discussed is always a raw nerve for me. It's not just that I myself am an immigrant. It's the fact that my US clients, owned by US shareholders, with lots of US employees, paying US taxes, are crying out for good technical people to make more money for those shareholders, employ more of those US folks, and pay more US taxes, but can't find enough of them because the immigration policies of their own of-the-people-by-the-people-for-the-people government are:

1. Blocking foreign talent who want to come here from doing that and, as a result
2. Scaring the local talent away from engineering (because they think all the jobs are going to India)

The first point is particularly frustrating. Put it this way. There is very little question as to whether the amount of VLSI engineering being done by Indian, Chinese and other "foreigners" is going to increase. It is. The only question is, where are they going to be doing it: India or China, on the one hand; or, on the other hand, here. And as current policy stands, it's not going to be here.


It reminds me of a survey in which I participated earlier this year. Somewhere in "The Economist", I'm on a list of people to whom they send such surveys from time to time. As a reward for participating, they'll send me books and let me see the results. This one was on how immigration rules were affecting business in the US. And they appear to have published the results more widely than usual. I'm not sure how long these links will stay live, but here's the press release:

http://graphics.eiu.com/upload/eb/EIU_immigration_PR.pdf

and here is a graphical version:

http://tinyurl.com/3e3bum

Personally I think they're being overly hard on the Americans. I mean, the UK isn't exactly open-armed to the world either. And Europe as a whole - not exactly the land of immigration opportunity, is it? (Just say "van der Elst Visa" and stand back.) No, the real criticism I'd have to reserve for those who although clearly understanding the principles of "Life, Liberty and the Pursuit of Happiness" choose to ignore them; those for whom the terms jus soli and jus sanguinis should be mere Olde Worlde artefacts, never to be used in anger, but instead are baked right into the zeitgeist. The real criticism is reserved for any nation which, despite being:

"...conceived in Liberty, and dedicated to the proposition that all men are created equal",

despite knowing that - to misquote Lincoln:

"They that can give up essential liberty to purchase a little temporary [job security], deserve neither liberty nor [job security]."

and despite having stapled to a big bloody statue the words:

"Give me your tired, your poor, Your huddled masses yearning to breathe free."

still choose a policy that is the modern equivalent of the common ownership of the means of production.

Did I mention this was a raw nerve for me?

Cadence, bla, Mentor, bla, acquisition, yada ...

So now we, 60 and climbing EDA bloggers, have something to blogstorm about. JL's on it already, scooping me by five minutes. And John, at his Semi-Blog, is even gathering comments. Daniel Payne, over at Chip Design Mag, has a take too, and none too complimentary.


Daniel's general sense of underwhelmedness is understandable. But he misses one semi-important verification issue when he says, of a merger, "it really wouldn’t bring the EDA industry anything new". One thing it could do is reduce the number of SystemVerilog methodologies out there, from three to two. The three being the VMM, and let's call them: OVM_m (Mentor's OVM) and OVM_c (Cadence's OVM).