07 June 2010

Enabling GNUPG (PGP) with Apple OS X mail.app

(Postnote 2011-03-05: Don't waste your time on the below.  Just go directly to gpgtools mail, read the instructions, and get on with it.  It's been updated to work with OS X 10.6 and Mail 4.4.  Just tested it, works great.)

I am so not an expert on PGP, GNUPG (GNU Privacy Guard) or OS X's mail.app.  But what I can do is explain how I got the basics of PGP working with Mac mail and some resources that helped.

If you don't know anything about PGP or want more detail, see "Learn More" section at the end of this post.

The following worked for Mac OS X 10.6.3 and mail.app 4.2.

1. Install GNU's Privacy Guard (gnupg).

You need to have Macports installed.  Install it if you don't have it.

sudo port install gnupg

2. Generate your encryption key.

gpg --gen-key

Here are the options I used:

1. Option 2: DSA and Elgamal
2. Keysize: 3072 (that was the biggest keyvalue offered)
3. 0, key does not expire
4. Key identification
Real name: Jeff Blogs
email address: jeffblogs@dodgymail.com
No comment
5. Passphrase "something memorable yet complicated and long, don't share it with anyone, and don't forget it"


Your ~/.gnupg directory of configuration and databases gets set up.

3. Install the magic mail.app bundle

The bundle contains a version of GPGMail that works with OS X 10.6.3.

Exit mail.app.

mkdir ~/Library/Mail/Bundles  # if it doesn't exist already - mine didn't

Be thankful for clever, helpful and giving people and Download the bundle.

Extract from zip download and deposit GPGMail.mailbundle into ~/Library/Mail/Bundles

From the command line as the user you run mail with (not root!):

defaults write com.apple.mail EnableBundles -bool true
defaults write com.apple.mail BundleCompatibilityVersion 3


Start mail.app.

You should now have a PGP option in your mail menu (Message->PGP).

Mail.app menu with new PGP option

You should also see a PGP toolbar when you create a new email:

New PGP toolbar appears when composing a new email

(This step was the silver bullet from macrumors.com forum with an updated GPGMail from Lukas Pitschl - thank you!)

4. Create your public key.

From command line:

gpg --armor --output "Jeff Blogs.asc" --export jeffblogs@dodgymail.com

You'll need to send people your public key if you want them to send encrypted email back to you.

5. Add other people's public keys

gpg --import "Ronald McDonald.asc"

At this point you should now be able to send and receive PGP encrypted emails and mail.app will be reasonably supportive of you.

I found regularly restarting mail.app is useful when fiddling with gpg at the command line.

6. Set yourself up with a verified key service.  This will decrease warnings from mail and GNUPG.

Set yourself up with pgp.com.

Use the name and email address you used to generate your key in step 2 above.

Add the verified key service key:
gpg --import keyserver1.pgp.comGlobalDirectoryKey.asc

Let GNUPG know about the pgp.com key server.  Edit ~/.gnupg/gpg.conf and uncomment "keyserver ldap://keyserver.pgp.com" line.

(You're restarting mail.app between these steps right?)

7. Learn more!

These were helpful to the above:
These might have been helpful if they weren't really long, complicated, out of date, didn't work and I didn't already have the basic idea of how PGP was supposed to work:
And of course GPGMail itself, which doesn't work with current versions of Snow Leopard and mail.app.

-----

2010-06-19 Postnote: The latest OS X upgrade to Mail 4.3 disabled gpgmail.  Two things to fix this:

1. Copy GPGMail.mailbundle from "~/Library/Mail/Bundles (Disabled)" to ~/Library/Mail/Bundles

2. Enter the GPGMail.mailbundle directory and add two new UUIDs to Info.plist in the "SupportedPluginCompatibilityUUIDs" section:


E71BD599-351A-42C5-9B63-EA5C47F7CE8E
B842F7D0-4D81-4DDF-A672-129CA5B32D57

And gpgmail is working again.

(As outlined by user Bytes_U on the Apple support forums.)

06 June 2010

Flapping Tell-tales: Over-Management of Products and Priorities

If you've ever sailed with a bit of curiosity, you've learned about tell-tales.  Essentially they're the little flapping ribbons on a sail that help you know whether you're sail is working efficiently or not.  If they're flapping about all different directions, you're sail isn't doing much for you.

Now imagine one sailing boat with one steering wheel, and 15 people tugging the wheel different directions trying to get the tell-tales to settle down and make efficient use of sail and wind to to move you toward your destination.  Some of these people jostling about the helm are bigger than others, can shove the others aside and can really yank the wheel one direction.  Some just stand there in the way thinking about other wheels they need to stand around later in the day.  Others ask nicely for a go at the wheel and nudge it a bit one way or the other (n.b.: not to worry, per Darwin we'll evolve out the namby-pamby collaborative team players soon enough).

The same thing can happen in an internet gambling business with lots of opinionated non-technical product and other manager types trying to control the priorities of a small team of technology developers.  There is a lot of "flapping" and the sailing, if you're moving at all, is not in the right direction.

The Tell-tales

Here are common tell-tales of organizational brokenness around product and prioritization:
  • Product managers are complaining that their "must have" "make or break" feature won't be delivered for months.  Sales execs are blaming missing targets on not having a good product to sell and instead are selling products that don't exist.  Instead of looking for work someplace where they can make sales and create new products, they plod along selling vapor and complaining about slow IT delivery.
    • It's also taking a lot of IT management to keep track of and prioritize a rapidly increasing backlog.  There are 30 people across the business spinning out one liner requirements into a backlog maintained by 4 managers being worked on by 3 developers.  
    • What's considered urgent one month in the backlog drops to no interest the next month.  Features, once delivered, hit the market "too late".  Product managers and sales execs are viewed by the technologists as being fickle, lacking follow-through and constantly changing their minds on what they want.  IT is blamed for not keeping up with changing market requirements.
    • You have no bench capacity to chase emergent opportunities.  These opportunities pass you by.
  • People comment that the "politics" in the company is increasing.  What uncomfortable behaviors are labeled as "political"?
    • Conflicting priorities: there are more people to "drive" the organization than there are people to do the work.  The people defining the priorities have an inability to agree a common set of priorities and stick to those priorities once they walk out of the "alignment" meeting. The software development manager receives multiple conflicting requests and priorities from two or more people and is then in the position of deciding between them.
    • Not sure who to follow: Lack of clear who-owns-what decision making structure.  Seemingly arbitrary and often passive-aggressive punishment for following the "wrong" person.  The "right" person is flavor of the month, then out the next month.
    • If people complain about a lack of strategy and clear priorities, they're criticized for not having the "mental agility" to work in "ambiguous situations" and requiring everything to be "black and white" and spelled out for them.
    • Managers are using persuasion, asking for "favors" and a "bit of extra work on the side".  What's worse is they're then enabled and applauded for working this way.
    • People are careful to maintain plausible deniability and other CYA behaviors reducing overall business efficiency.
    • No one is actively nurturing an environment of trust and indeed such activities are viewed as a waste of time.
  • You're on a conference call with 15 people and realize:
    • Of the 15 people, one is there to ask question, listen carefully, and assess what is going to make high quality decisions.  This is the big boss in the meeting.  Unfortunately, this one person tends to do most of the talking and when they're not talking, they're "listening" while reading and answering their boss' emails on their Blackberry.  This one person has the special ability to pay only marginal attention but then to hear certain keywords and then talk a lot about them.
    • One of the 15 people actually does the work being discussed.
    • One manager owns and directly manages the one worker.
    • Five people are trying to influence the one person who owns resources to do work for them, each one at the loss of the other four.  These are product, project, and programme managers.  One is the flavor-of-the-month alpha dog while four are rummaging for scraps and taking notes for ammunition against the alpha dog in the future.  They alternate between threatening the one worker's manager and sucking up to the worker.
    • Two of the people distrust someone working for them and want to attend the meeting as their employee doesn't communicate a useful meeting summary with them or doesn't appear to pay much attention or take notes.  The two people don't want the person working for them to embarrass the department or create more work with screw-ups.  They don't contribute much unless they think their employee is about to screw up or conducting damage control afterwards.
    • Two people whose motivational imperatives haven't been crushed out of existence yet occasionally pipe in with genuinely helpful "cross-pollination", "how to do that" advice.
    • Five people on the call think the worker should be grateful to have been brought to a "high level" meeting to receive so much wisdom.  The worker isn't one of the five.
    • There are at least four people who are in other groups, only vaguely associated with this project, have been invited to make sure they're "aligned", and really don't care much about what is being said.  They're probably paying no attention and answering email, but no one will include them in the conversation anyway because no one is particularly sure why they're there.  These people will often write "lack of communications" as a systemic corporate problem during annual HR surveys.
    • There are at least five "could you repeat that" requests during the call as people are caught out not paying attention.
What went wrong?

Fundamentally, the company has over-staffed Captains and purchased too few boats and crews.  Communications are inefficient and durable alignment is non-existant.  It's typically not the fault of the one worker involved (unless they aren't effective at the job they signed up for) - it's a leadership, organizational, and strategy failure.

Ok, so what went wrong?  These are the reasons I've come across:
  • If you're a senior person in the organization, you understand senior people.  You have less of an understanding of more junior staff proportional to how far you're removed from them.  You hire a more senior employee because you relate to them better.  This is ok (in fact, preferred) if the person you hire is going to build a team under them or at least have control over enabling budget/resources.  If you find yourself stepping across and obviating an employee, you've created a problem.
    • Don't hire people you aren't planning to empower
    • (Humanely!) remove people that are no longer empowered
  • General wisdom is that a senior person is more skilled, knows more, can get more done.  They can cover the more junior responsibilities if they need to.  
    • This should apply to senior employees, but often doesn't.  They either can't or don't want to operate at a junior level and are more interested in bizdev, strategy and commercials.  They didn't enter the business with strong domain knowledge nor seem interested in developing it (why were they hired again?).
    • Although the "hire senior emlpoyee" wisdom may apply in some business functions, it's often wildly wrong in technology.  The scope of knowledge in technology is enormous, changes rapidly, and can take a while to pick up.
    • Regardless, as a result the senior employee owner can't work at depth, so hires more junior product owners and/or other managers step in to fill the gap.
  • The product partitioning and ownership in the organizational strategy was wrong and the original strategy's advocates resist changing the strategy as they don't want to be seen having made a bad decision.
  • Not many execs with a non-tech upbringing understand IT.  They don't understand how products are created and how long it takes to build IT and product organizations.  They think increasing sales, project, product, and programme managers are needed to "keep the IT team focused" when deliveries are late and of low quality.  They stay with what they know rather than drilling into detail they can't or don't want to understand.
  • The product(s) involved are sold in different "flavors" to different categories of customers.  Each category will have it's own requirements and priorities.  There is a lack of overall priority and alignment between them.  The flavoring creates new late stage technical requirements.
Considerations

Some assumptions about the right way of to get your ship in order:
  • Don't have the software development manager making strategic business decisions by arbitrating priorities.  Great that the manager is a little bit commercially aware and is sensitive to business and customer needs.  However, the more time they're building this knowledge, they're not building software.  Enable them to focus on software construction.
  • Don't expect the product managers, often peers, to effectively communicate with each other and prioritize between each other.  They're typically measured on delivery of their product line, not playing nice with other product owners.  A consistent and simple approach to business cases and approval process will help.
  • Don't have product managers that have to beg, borrow, steal resources.  They shouldn't have to rely on persuasion to acquire core enabling resources as it leads to politics, distrust, confusion and all the related inefficiencies highlighted above.
  • Do assign one product manager to be the final decision maker accountable for overall product priorities.  
  • Do have the software development team align their backlog priorities to the senior product manager's decisions.
  • Do hire product managers that understand at least at a high level the underlying technology and can sensibly evaluate technical debt tradeoffs.  Hire product managers that are interested in how to most effectively use the technology and can appropriately prioritize non-functional technical requirements.
The Solution

Scale the number of people who want to own and drive product to people who can build those products. This balance is essential.  You don't want 15 people behind one helm on one tiny boat.

If you have a big software development team with several potentially unaligned product managers creating work and issuing priorities, use a resource allocation model so that each product manager has to justify and fund a set of resources for their product responsibilities within the software development team.  Preferably these are intact teams, like a scrum team.  Resource allocations should be based on business value and/or risk management.

Make sure the software development team and manager have their own internal set of resources that they can internally prioritize to take on overall architecture, integration, code reviews, refactoring, mentoring, tools, how to scale the code base and personnel, and other (mostly) non functional requirements.

What about maintaining bench capacity?  I have yet to work someplace where there is any bench capacity for very long - everyone is busy.  The danger with bench is the organization may degenerate into a beg-borrow-steal model to grab these resources.  Ideally try to keep some bench in the internal set of software development resources and balance technical debt versus emergent benefit.  It really is powerful in an organization to have a few highly competent innovation-minded resources available to jump on the new market opportunity that just popped up.

Periodically review the resource allocations.  Rebalance them  between project deliveries to match changing business requirements.  Also, commercial realities can change suddenly so you may need to re-allocate resources at short notice.  So long as quick changes happen as an exception and not a rule and the reasons for it are clear and consistent, no one is going to object.  Indeed it can be exciting and foster improved teamwork.

Identify and eliminate any point in the organization where product and team priorities, ownership and decision making is ambiguous or shared.

Consider carefully whether a project or programme manager should get between a product owner and the lead/manager of the software development team delivering to that product owner.  Why does this extra layer exist?  Who really understands what is in the backlog?  Sometimes this additional management layer is justified if the project/product is big, complicated and/or there are heavy customer-driven process/audit/document requirements.

Here are two basic rules of thumb on whether someone is needed in the management layer:
  • If a team member forwards email to a peer more frequently than answering it or dealing with it, remove them from the team.  If they forward it to someone working for them without adding value, are they delegating appropriately?
  • If a recurring meeting member has contributed nothing of value for more than a few meetings in a row, remove them from the meeting.  They can read the meeting minutes or have a hallway conversation to catch up.
Conclusion

Fundamentally, an organization will be more efficient if there is a good match between Captains, boats and crews.  It's not easy to get the balance right, and the need for all three will change frequently.

If you do have to error on one side or the other, error on the side of having more boats and crews.  Better to have a little bit of spare execution capacity that can be thrown at an emergent opportunity than to degenerate into politically charged, rudderless anarchy.