Job-Hunting Advice For International Students

And now for something a little different (not Salesforce).

I've worked a lot with international students and, upon helping a few at a career fair last night, realized I'd like to formally publish the advice I often give international students about job-hunting.

It seems that colleges and universities are able to perform superhuman feats of service welcoming international students, helping them succeed socially and academically, making sure they know what they can and can't do for work, and steering them toward job-search resources (plus making them aware of timelines and deadlines).

But there are a few "mental barriers" I think often remain.

Many people have helped me get through my "but I don't know what I'm doing..." mental barriers, so I hope I can "pay it forward" somehow.

---

I'd say most mental barriers unique to international students can be summarized as:

"I'm afraid of being judged for my handicaps, and history shows that I have good reason for that!"

And all the solutions I suggest can be summarized as:

"Jump ahead of the company and guide their staff.  Talk about your handicap - making clear not only what it is but what it isn't (so their imaginations don't run wild) - and present a solution to the problems it poses BEFORE they have time to make their own guesses.

"You're right that by the time they've assumed, it's often too late to change their minds.  But you're wrong if you think you can't change their minds at all.  You just have to be one step ahead of them.

"It's easy to presume a company's staff make all hiring judgment calls on their own just because they are in a position of authority to do so, but that's a myth.  They know what expertise they don't have.  You will be amazed how open-minded and grateful hiring officials are about being told how to handle your handicap."

"It's hard, and it will take a lot of practice to get good at, but investing the time in getting good at 'making your own handicaps look like strengths' will drastically change your job-hunting life forever.  It is the foundation on which everything else you're going to get training and practice for as you job-hunt (networking, cold-calls, resumes, cover letters, interviews) will become more successful."

---

I suppose I haven't yet said anything that isn't true for domestic students, too ... but what I think is unique about international-student-specific mental barriers is that they ALL seem to be variations on this theme.  So, below are 6 specific complaints of this type that I frequently hear international students worry about and the 6 specific 'So make it sound like a good thing' advice I give them.

========

CONCERN #1:

"Every company I'm applying to for after-college work says they don't want to talk to people who aren't US citizens or permanent residents because they don't have any money to sponsor people for work visas."

ADVICE:
You're right that they're judging you as soon as they see your immigration status - so the best you can do to 'jump ahead' of that is in your cover letter / resume.  Some companies legitimately don't want to work with F-1 students, but in my experience, most companies simply don't know the difference.  Here's something you can throw in as a footnote to your cover letter / resume if you're explicitly getting shut down by companies with, 'No sponsorships!':

'Over the summers and for [12 / 12-27 (if STEM)] months after graduation, I am authorized to do work in America that gives me real-world experience extending my academic training in [list majors] at no cost to your company.  Hiring a current or recently-graduated international student is different than sponsorship (which pertains to long-term work visas) and does not require any complicated legal filings or fees.  My work for your company would only be constrained by duration and subject area - hiring me can be structured as an internship, a temporary position, or even a direct hire.  Please ask me if you have any questions!'

Or, here's one that's concise and a little less bold, if it's true of you:

'I am an international student from [country] who intends to establish a career in my home country.  My visa allows me to perform [major]-related work during the course of my studies and up to [one / two and a half (STEM)] year[s] after graduation.'

CONCERN #2:

"Everyone I want to work for says they don't offer internships."

ADVICE:

Stop saying the word 'internship.'  There's no requirement that your work has to be an 'internship.'

You've probably heard that word a lot because 'internship' means short-term work that is structured to help the person performing it gain specific skills in a field.  Obviously, this kind of position naturally suits the limitations on the kind of work you can perform as an international student, so everyone talks about internships a lot.

But you can gain relevant skills at a job even if the job isn't specifically structured around a skill-building goal.

You can also work jobs that are a 'temporary' position or a 'direct hire,' as long as you stay within the duration, subject-matter, and hours/week requirements of your F-1 visa status.  So broaden your job search beyond internships.

'Cold-call' relevant staff at companies you'd like to work with asking them if they ever have, or can create, 'short-term work' - rather than asking 'if they have internships' available.  You'll find that many of them who 'don't have interships' are open to 'having short-term help.'

Open yourself up to working with temp agencies (just make sure they understand your duration / subject / hours-per-week limits so they don't suggest inappropriate placements).

And here's a nice little phrase you can add to cold-call letters or your resume to ensure they don't make any assumptions about whether or not you're easy to hire:

'I am an international student from [country] looking for hands-on experience in America before embarking upon a career in my home country.  My visa allows me to perform [major]-related work during the course of my studies and up to [one / two and a half] year[s] after graduation.'

CONCERN #3:

"I have to get a job in my major, but I've never worked in my major - I worked in foodservice / RA / etc. on campus."

ADVICE:

If your old jobs aren't relevant to the one you want, give them just enough resume space to show that they existed.  They show you've been able to hold down a job and work hard, but don't waste space.

Create a space on your resume called 'Projects' or 'Projects and Research' or 'Projects and Field Work' - etc.

Include a 1-sentence description of a research paper you did.  Describe a class trip by what you did on it, e.g. 'Investigated the pH of lake sediment along Lake Superior boat docks.'  Etc.

The #1 thing to remember to be successful at this is to NEVER let the fact that everyone in the class had to do something, or the fact that the professor walked you through how to do something, stop you from mentioning it.  Your resume is about advertising YOU, and you really have done these things!

Include even things you couldn't repeat without guidance.  You're young.  If a company needs you to be able to do such work independently, they'll let you know at the interview stage.  But don't be afraid to list something you've done in class just because you felt like it was 'no big deal.'



CONCERN #4:

"I'm already handicapped in so many ways.  Why would anyone read my resume or my cover letter?"

ADVICE:

Because you took the time to write a great one.

Different companies put different values on the resume and cover letter, but here's a secret:  those who actually read every applicant's cover letter REALLY love cover letters and get a whole lot of generic ones they hate.

If you use your cover letter (and any free-text areas in the application form) to show that you actually bothered to read the job description (use the job description's words!), you will be in the top 50% of cover letters.

If you also follow up the company's own words with descriptions of why you are the candidate who can solve those needs, you will be in the top 5% of cover letters - including Americans applying to the same job.

Most people get too busy applying for every job they see to tell the story of why they personally fit the job in question.  Take the time and you will be at the top of the stack, despite your visa status, employment background, lack of experience with American customs, etc.

CONCERN #5:

"I'm already handicapped in so many ways.  How am I going to keep my nerves together in an interview when I fear people are looking for a reason to reject me?"

ADVICE:

Find your fears.  Google 'common interview questions' and pick 5 that look terrifying.  Or make up a few of your own about fears that linger despite perhaps having addressed them in your cover letter - e.g. your immigration status work restrictions.

Develop 'elevator-speech'-length answers to them (15-30 seconds).

Stand in front of the mirror and ask yourself the scary question, and practice delivering your answer at least 10 times (focusing on comfort and body language).

It doesn't matter if these aren't the questions you get asked.  They're the questions that brought you fear, and now they don't.  It's like lifting weights in the gym and then being asked to help a friend move a refrigerator.  The skill of 'calmly making yourself sound good in response to a question you were afraid to be asked' will be transferable when you are sitting in an interview.

CONCERN #6:

"I have to find a job in my field, which means I'm applying to jobs where they expect a lot of knowledge in my field.  What if they ask me some sort of obscure question I don't know the answer to?"

ADVICE:

Similar answer to the 'how am I going to keep my nerves together in an interview?' but with one addition:

Google to find 2-5 common interview questions in your field where you know enough about the subject to understand what is being asked, but doubt your abilities to give a top-notch answer to the exact phrasing.

Think about how you would explain what these questions are asking to your grandmother or to a 10-year-old.  Now bring it down to 15-30 seconds.

Now mirror-practice answering the question in a way that draws upon that 'for a 10-year-old' brief explanation of the issue at hand.

Phrase your answer something like this:

'I haven't had the opportunity to work with [______], but I know that it is a [_____] used for [______], and that when working with [_____]s, it is important to make sure that issues of [______, ______, and ______] are addressed because otherwise, [____, ____, and/or _____] could happen.'

Again, this 'mirror-practice' is transferable to unexpected questions.  You will now be experienced at analyzing a question beyond your expertise for what you DO know about its subject-matter and explaining how your general knowledge enables you to solve the company's problems, given time to further train on the specifics.

If you secure an interview, you might want to repeat this drill with 2 new questions from the internet that pertain to the job description at hand.

========

GOOD LUCK!!!!!!

:-) :-) :-)

-K

========

P.S.  1 MORE CONCERN:

"I think xenophobia / prejudice is hindering my job search."

ADVICE:

Yikes.  I'm really sorry.  That is terrible.

For the most part, I'm in over my head on that one.

But I do have one suggestion, and yes, it comes from the mind of someone who's never had had to deal with it, but...

Even if you want to just walk away, think about firing back your rejection reason at the people doing the hiring and ask them if they could clarify what specifically they think would put you in a stronger position to overcome that disadvantage in the future.

If you don't get a satisfactory answer and still think prejudice is an issue, tell the the HR department coordinating the job search about what was said to you and ask them if they have any clarification about what the company might be looking for, so that you can better prepare yourself for similar positions in the future.

(HR probably won't actually have a good answer.  You're mostly just playing stupid and, by 'asking for useful information,' letting HR know what their employees are saying to candidates that might be against corporate policy or the law.)

Example:

I worked with someone who wanted a customer-facing technology position, but whose only American jobs had been a summer internship and graduate-student-worker positions.

Multiple times, he was told that the company was 'looking for someone with more U.S. experience.'

He came away with an icky feeling that most of those meant, 'We don't want someone who's not only relatively new to the field, but also has brown skin and an accent, to be a major liaison with our customers.'

My only question was, 'But what if there's even one of them who doesn't really mean that?  Who would consider hiring you in a year?  Don't you want to know exactly what they want to see you've been doing for that year so you can think about spending your next year doing it?  It sounds like there's a lot of prejudice in your field, but maybe asking this question over and over can help you better prepare yourself for a job at the nonprejudiced companies.  And in the meantime, subtly tattle to HR on the prejudiced ones.  Oh, and also, I'm really sorry you keep running into this.'

The Singleton Pattern And "Commonly Used Data"

If you hadn't noticed, Salesforce stored-procedure & trigger programming is basically using Java wrapped around crippled SQL. Which means it's a good idea to be up on your object-oriented design patterns.

One of those that I just used to avoid copying the same SOQL query into a 5th trigger-handler's source code is the Singleton pattern.
(I'll be going back and fixing the 4 older trigger-handlers. Yes, I let it get that bad before I had time to fix it.)

---

Quick refresher for newer programmers: in object-oriented programming, a "class" is a "cookie cutter" and an "object" is each individual cookie you cut. So, a "car cookie cutter" would say, "Make sure that every car has a number of wheels, a number of doors, a make, a model, a paint color, and a unique serial number. It also needs to be driveable." A "car object" would be the "the 4-wheel 4-door red Ford Taurus with serial #XYZABC12345" - these are the values stored in its "class-level" variables. Like all cars, it would be driveable (this is a "method" that's part of the definition of all "cars" and it comes with this particular car just because it's a car).

When you're defining Apex triggers, you typically don't actually do object-oriented programming with classes. Typically, you define & use "static" methods for the "car cookie cutter" and directly invoke the "drive()" method. Which is a little hard to imagine as a metaphor - driving the car factory instead of the car - so sorry about that. But just trust that, well, if it's not a method that actually needs a particular car to exist, such methods can be defined and used and that's probably what you're actually used to doing as an Apex trigger programmer.

---

But ... sometimes it IS useful to manufacture a particular car!

And, more specifically, if what you'd like to do is put a single car in a museum and call it "best car ever made" and have all of your code just copy its color and number of doors, you want a Singleton. The reason to do this "copy whatever's in the museum" pattern is that this keeps you from having to hard-code values like "silver" or "4-door." If you ever change your mind about these details, you just change the car in the museum.

Think of a "Singleton" class as the museum itself. It's not open to the public - all you can do is ask the guard, "What color is the car that's in there right now?" You don't even get to know whether they really have a car in there or not. You just know that the sign on the front door says you can ask the guard what color the car is, how many doors it has, etc.

(There's an extension on the "Singleton" programming pattern where, for efficiency, the museum doesn't even exist until the first visitor asks a tourist-info-kiosk for directions to it - at which point the city quickly scrambles to build a museum complete with "4-wheel 2-door silver Ford Taurus" inside before she gets there. Designing the museum this way is called "lazy instantiation." In my code below, I took this pattern a bit further for rare questions & named it "lazy data fetch" in my comments. Think of it like not bothering to paint the car until the first time someone asks the guard what color it is.)

---

So here's my code for accessing "commonly used info" like "the default Account ID for new Contacts," "the default Owner for records," "the Record Type ID of a given object & record-type-name," etc.

To call the "Singleton" code and ask it "the Record Type ID of a given object & record-type-name," I just write:

Id rtID = UtilityDefaultInfoOftenNeeded.getInstance().getRecordTypeId('Admissions', 'Opportunity');

The call to "getInstance()" asks for directions to the "useful settings" museum (at which point the city scrambles to build one, complete with answers to questions I can ask the guard, if it's not built yet) and gives my code directions to that museum.

For legibility if I'm asking the guard at the door lots of questions, I might instead write:

UtilityDefaultInfoOftenNeeded useful = UtilityDefaultInfoOftenNeeded.getInstance();
Id rtID = useful.getRecordTypeId('Admissions', 'Opportunity');
// (etc.)

Note that I don't say "new UtilityDefaultInfoOftenNeeded()." I made the "constructor" private on purpose to prevent that. Instead, I say "UtilityDefaultInfoOftenNeeded.getInstance()."

In fact, the inability to use "new ..." is really what makes it a "Singleton." You're not allowed to demand that a new "best car ever" or "default settings" museum be built. You can only ask for directions to it via a "public static" method like "getInstance()" and trust that one single museum will exist by the time "getInstance()" returns directions to the museum.

---

Here's how "UtilityDefaultInfoOftenNeeded" is written (as a "lazy-instantiation singleton"):

public class UtilityDefaultInfoOftenNeeded {
    
    // Please note that many values returned by the "getter" methods of this class could return null,
    // so be sure to check returned values for "== null" if that is important to your code calling these methods.
    
    private static UtilityDefaultInfoOftenNeeded instance = null;
    
    private Id defaultAccountId; // Fallback "Account" for new "Contact" records where not specified
    private Id defaultOwnerID; // Fallback record owner ID for records in the database
    private Id defaultLeadNurturerID; // The User ID of the "default" "Lead Nurturer" staff member

    private Map rtIDs = new Map(); // For holding data from the "Record Type" object


   
    // Private constructor - this is a Singleton class
    private UtilityDefaultInfoOftenNeeded() {
        // In this constructor, we do any computationally expensive or limit-worrisome computations
        // that should be done as soon as the object is instantiated (rather than when the data
        // is requested through a public object-level "getter" method).
        // Checking for "null" is not necessary because this is a constructor - all variables are null so far.
        // We will not populate every object-level variable in this constructor.
        // Some object-level variables' values are rarely needed and more expensive to compute, so we will "lazy data fetch"
        // them in their getter methods.
            if (Schema.getGlobalDescribe().keySet().contains('default_settings__c')) {
                // Set default Contact Account ID, Owner ID, and Lead Nurturer User ID
                // First, grab the "Default Settings" custom setting:
                Default_Settings__c cs = Default_Settings__c.getInstance();
                System.debug('Default Settings custom setting consists of:  ' + cs);
                // Next, initialize Default IDs from this setting:
                defaultAccountId = String.isBlank(cs.Account_ID__c) ? null : cs.Account_ID__c;
                defaultOwnerID = String.isBlank(cs.Owner_ID__c) ? null : cs.Owner_ID__c;
                defaultLeadNurturerID = String.isBlank(cs.Lead_Nurturer_User_ID__c) ? null : cs.Lead_Nurturer_User_ID__c;
            }
    }
    
    // There should be just 1 public method in this class that is STATIC:  "getInstance()."
    public static UtilityDefaultInfoOftenNeeded getInstance() {
        // Lazy instantiation
        if (instance == null) instance = new UtilityDefaultInfoOftenNeeded();
        return instance;
    }
    
    // These three methods may return null Id-typed values, so be sure to check the return value before using.
    // (Developer note - no need to "lazy-data-fetch" these values, as they "lazy-fetched" upon instantiation in the constructor.)
    public Id getDefaultAccountId() {return defaultAccountId;}
    public Id getDefaultOwnerID() {return defaultOwnerID;}
    public Id getDefaultLeadNurturerID() {return defaultLeadNurturerID;}
    
    // This method may return a null Id-typed value, so be sure to check the return value before using.
    public Id getRecordTypeId(String devName, String sObjName) {
        if (rtIDs.isEmpty()) {
            // Lazy data fetch of entire "RecordType" table into this object's "rtIDs" private variable
            for (RecordType rt : [SELECT Id, DeveloperName, SObjectType FROM RecordType]) {
                rtIDs.put((rt.DeveloperName + ';' + rt.SObjectType), rt.Id);
            }
        }
        // Grab the relevant ID and return it (or "null" if not found)
        Id idToReturn = null;
        if (rtIDs.containsKey(devName + ';' + sObjName)) {idToReturn = rtIDs.get(devName + ';' + sObjName);}
        return idToReturn;
    }
    
}

(If you see "string string" end tags at the end of this code, ignore them - my code formatter is inserting them.)

---

And here's its test class:

@isTest
private class UtilityDefaultInfoOftenNeededTest {

    static testMethod void testInfoOftenNeeded () {
        
        // Set up default custom settings (these are data in a table, so they don't exist in seeAllData=false test classes & need to be made in the test)
        DefaultTestDataAccountFactory.makeAndSetADefaultTestingAccount();
        DefaultTestDataOwnerFactory.makeAndSetADefaultTestingOwner();
        DefaultTestDataLeadNurturerFactory.makeAndSetADefaultTestingLeadNurturer();

        UtilityDefaultInfoOftenNeeded useful = UtilityDefaultInfoOftenNeeded.getInstance();
        
        Test.startTest();
        Test.stopTest();
        
        System.assertEquals(TRUE, useful.getDefaultAccountId() != null, 'getDefaultAccountId() is null.');
        System.assertEquals(TRUE, useful.getDefaultOwnerID() != null, 'getDefaultOwnerID() is null.');
        System.assertEquals(TRUE, useful.getDefaultLeadNurturerID() != null, 'getDefaultLeadNurturerID() is null.');
        System.assertEquals([SELECT Id, DeveloperName, SObjectType FROM RecordType WHERE DeveloperName = 'Admissions' AND SObjectType = 'Opportunity'].Id, useful.getRecordTypeId('Admissions', 'Opportunity'), 'getRecordTypeId(...) is null.');
    }
    
}

Certified Salesforce Admin

Woohoo - this blog saved my employer $200 and pushed me to get certified! I entered a "blog or do trailhead for a free cert voucher" drawing, took the test without any special studying, and guessed well enough to pass! (We don't use Chatter, Communities, Cases, etc. so there was a LOT of guessing to do.) Fortunately, at least 1/3 of the questions were data-architecture type questions that made intuitive sense rather than requiring memorization. You'll want to have done some sort of formal studying being an admin (I took ADM201 when I started this job), but it wasn't nearly as bad as I thought it'd be. The voucher was the difference between waiting until I was "ready" and taking the test "just to see what was on it" (as a woman in a developer community encouraged), so yay.

Mid-Dormancy Updates

The good news is that I'm more used to Apex+SOQL than PL/SQL+SQL now. I can't say the same of SQL vs. SOQL (SOQL still drives me bonkers), but I'm not floundering enough to have to write down my daily frustrations any more. In fact, I'd say I'm starting to bang out Apex triggers rather often!

I've also had the chance to work on some other really cool projects. When I went to Dreamforce, I vacationed at the home of a hobby-acquaintance who happens to be part of San Francisco's tech boom crowd. Between hanging out in the Dreamforce dev zone and spending time with him and his friends, I got inspired to get my hands dirtier with not-purely-database Salesforce programming.

• With a friend's help, I developed a Python (Pandas & OAuth & Flask) web application and hosted it on Heroku.com. It facilitates a colleague's daily updates/inserts of external data into Salesforce using Name+Email as a matching key. (Name+Email for matching is not natively supported by Salesforce data loaders.)
  
  My colleague provides my tool a .CSV file of names, email addresses, and data to be uploaded into Salesforce.
  
  The web application downloads a list of names+email addresses+IDs from Salesforce, joins the two lists, and returns the user's .CSV file to them in a form that is ready to "upsert" into Salesforce using standard data-loading tools.
• With another friend's help, I wrote my first significant amount of JavaScript/JQuery. Our Web-To-Salesforce form handler wasn't doing a very good job, so I switched us out to another provider. Our forms now do a great deal of "onSubmit" pre-processing to alter the DOM before it goes off to the form handler.
  
  A lot of cloud form-handler providers don't let you choose your own field names, for example. They make you use names like "form143_field281." To avoid changing things like "first_name" to an obscure name/id like that in our HTML and keep our forms more portable should we have to switch form handlers again, I copy the relevant fields into hidden fields at the last minute using this JavaScript.
  
  There were also certain "to-Salesforce" behaviors that couldn't really be taken care of in the JavaScript or the form handler's connector, so I got to do plenty of Apex trigger programming as well.

Oh, and finally, I finished my software degree with straight A's. Booyah - time to check in about a raise!

It's been a fun period of blog "dormancy" - happy new year to all.

Universities: To Break Down Silos, Implement SalesForce Starting With Your Smallest, Simplest Use Case - Not Your Highest-Revenue Use Case

If there's one thing I'm passionate about after 9 months in SalesForce, it's the idea that when implementing SalesForce at a university or in a university department, it's best to start small and "natively like SalesForce."

Don't start with your "sales" departments that already have highly established databases and processes, like the Admissions department. Despite SalesForce's name having "sales" in it.

---

1st, start with a dean + dean's secretary who want to digitize their Rolodex. Observe their struggles and refine your user training manuals to take them into account. Write all the Reports they need.

2nd, move on to an associate dean who wants to digitize their Rolodex. Train them in with your training manuals. Write all the Reports they need.

Observe the conflicts that come up from suddenly being able to "step on each other's toes."

Refine the data model (and report organization model) if you need to, so that people can tell what data is "theirs." Think about whether that data model will be scalable to 20 or 40 different "clumps" of users who want to mark records as "records they are working with.

Make some governance ("don't edit this field unless...") manuals and pass them around to all new users. Update your training manuals (including adding sections on "how to tell whether you are working with someone," "how to tell who else is working with someone," etc. and pass them around to all new users; make sure they read the new parts.

3rd, add another user with a Rolodex.

Again, observe and improve your reports, data model, governance manuals, & training manuals - and re-train all existing users.

---

Now, 4th, you're ready to try taking a group of 1-4 staff with a very simple "events" model and adding them to SalesForce (perhaps using the "Campaign" object). Teach them not only what you taught the other groups, but also to set up an event (new Campaign), say that a Contact is coming to an event (add a Campaign Membership), and update whether they came to the event (update a CampaignMembership's status field). Write all the Reports they need.

Again, observe and improve your data model, governance manuals, & training manuals.

Now try letting this 4th group - the one with events - send out a mass email about to everyone that "they are working with" (or some subset thereof). Note how you show them to make sure they ONLY send it to people that THEY are working with. WRITE THIS DOWN! This is the foundation of your "how to send mass mailings with SalesForce" training manual that you're going to write.

Use the "mass mailing" training manual you just wrote to train someone else from the 4th group if there is one. See if the training manual teaches them everything you wanted them to know. Refine and publish & make sure everyone from this group is using it (plus the governance & other training manuals). And write any Reports they need in light of now starting to send mass mailings.

5th, add another group of 1-4 staff with a very simple "events" model (as simple as the 4th group).

Observe the conflicts that come up from suddenly being able to "step on each other's toes" with respect to events management.

Refine the data model if you need to, so that people can tell what data is "theirs." Think about whether that data model will be scalable to 20 or 40 different "clumps" of users who want to mark records as "records they are working with.

Again, update your reports & training & governance manuals until all 5 groups (including 2 groups with "events") are working seamlessly in the same SalesForce instance ("org").

Repeat one more time w/ a 6th group - again, a small group with a very simple "events" model.

---

If you've gotten this far, and you've developed a successful way to document and project-manage these 6 rollouts, updates of training end users, etc. CONGRATULATIONS! You are NOW on track to start thinking about how to move past "Rolodex & simple events" departments.

---

But you're not all the way to a big, organized department like Admissions yet!

7th, try doing a department that already had its "Rolodex" in a relational database with "Person," "Company," and "Event" tables that are structured exactly the way SalesForce's "Contact," "Account," and "Campaign" tables are structured and doesn't have any additional tables beyond that. (That is, 1 person can work at 1 company at any given time. A company can have lots of people working at it. People, not companies, attend events. A person can attend lots of events over time. An event can have lots of people attending it.) It's okay if they have more fields on their "Person" & "Company" tables than your average business card would have previously made you add to Contact/Account/Campaign. This is going to be Round 1 of seeing what it's like to move people with an established database into SalesForce - people who are used to seeing and filtering by a higher level of detail!

Get them up and running with the appropriate modifications to data model, training/governance manuals, Reports, etc. and back-updating all other users of the system. Migrate their data from their old database and have them cut over to using SalesForce instead. Keep working with them until they're happy and there isn't anything they used to be able to do but now can't. DO NOT MOVE ON until they're 100% as productive as they were in their old database! And remember that they, in particular, are not used to having to "share" edit-permissions on their People/Companies with other sub-departments, so expect a LOT of governance updates with all existing users. It's going to be a while until they're happy. Convince your superiors to be okay with that - that they will waste less time doing "measuring twice and cutting once" than moving on until all 7 departments (especially this 7th) are using the same database in perfect harmony.

8th - do Step 7 again. Only now you have two "semi-mature" subdepartments in the same database. How do you need to change your data model to tell whose "extra fields" on Contact/Account are whose? Change all your reports/governance/training manuals and fill everybody in again.

Don't move on until every single current user (including this "8th" sub-department) is happy, no matter how slow your progress feels.

Bringing something like your Admissions department into SalesForce - especially if you need to keep your data synced to a central student/employee database - is going to be like building a house (or an addition to a house). You are working your way up from "building a birdhouse" through "building a shed" through "building a stand-alone garage" to "building an addition onto a house." The project management habits, documentation, etc. that you are gaining along the way are going to be vital when it comes time to build that home-addition.

Yes, you are spending a lot of money on SalesForce for very little revenue increase, if any, but a failed implementation for a high-revenue department isn't going to be any more profitable, either.

If the reason your university wants SalesForce is to get everybody having "intelligence" on everybody else's activities so that you can "work smarter across silos," you need to start small and work your way up - and let rollouts be done when they're done, not when you thought they'd be done.

---

If everything is chugging along nicely after you have 3 "Rolodex" subdepartments," 3 "Events" subdepartments, & 2 "Cut Over From Their Own Simple Database" subdepartments all playing nicely with each other, PAT YOURSELF ON THE BACK!

Ask people how they and the university as a whole have become more productive since moving from siloed data stores to a shared data store. Take notes. (If they haven't, this might be a good time to get everybody back to their old systems and pull the plug on SalesForce. It's expensive to keep going. At least you only have to tear down a birdhouse and a shed, though.)

If net productivity is up, ask them what they had to sacrifice in terms of productivity to get these overall productivity gains. Take notes.

Share your notes with decision-makers and decide whether it's better for the university to build more birdhouses/sheds (other similar departments), which you can do quickly, or to keep working upward toward building that house (more likely home-addition). It just might be the case that SalesForce is the system of your "small departments," whereas big organized departments keep using their status-quo systems and people call/email them to find out what's going on in those systems. You're still ahead of where you used to be in the cross-silo visibility arena, and perhaps getting every last birdhouse/shed-size subdepartment into the same SalesForce org is what would bring your university the most benefit.

---

If your university decides to go for "building the house," remember that you still haven't even built a garage yet.

You haven't dealt with departments with quirky event structures or departments with lots of events.

You haven't dealt with departments that sell people things.
Tip: Don't start with the "admissions" department. Yes, it sells educations, but "degree" is a weird product that a customer has to inquire about, then prove they're good enough to buy, then finally buy. That's a complicated sales model. Building a "garage" is integrating a sales department that sells things anyone can buy as soon as they express interest (such as a department that offers fee-based seminars).

And if you can find more than 1 "garage"-level subdepartment to implement at your university to work with, all the better. I always advocate for seeing how similar departments step on each other's toes and resolving issues that arise before moving up to the next level of complexity.

---

When you finally do decide to integrate a department with strong ties to an existing central database, you are going to be so experienced at bringing users more complicated than the last into your org without messing up existing users!

Pat yourself on the back. If your goal is to break down database silos, you will be much farther along than if you had started by setting up a complex system for a complex department, only to find out that adding anybody else to the SalesForce org brings your whole house of cards tumbling down.

---

In my 9 months, the most impressive/"creative"/revenue-increasing higher education projects with SalesForce I've seen involve getting Rolodex/Spreadsheet systems into a proper relational database for the first time ever - NOT reinventing the wheel for super-complicated departments that are already "getting by."

For example, Algonquin's Saudi Arabia "Student Information System" isn't an integration with their main Student Information System. According to Q&A during their presentation at the SalesForce Higher Education Summit 2015, it was the first digitization of a homegrown SIS that previously lived in a bunch of spreadsheets. I'd actually call that a "garage"-level project, but they have some really skilled programmers in their IT department.

And yes, St. Norbert's is probably the standard-setter for the "Admissions-office-first" model, so if you're on that train, call them. But it's not a train ticket I recommend buying if you're just now considering SalesForce.

It seems to me that for schools with an eventual goal of integrating lots of tiny Rolodex/Excel/Access-based sub-departments into the same database, the "start small & work up" approach is best.

If you're a university that has followed this model, please contact me - I'd love to talk further! Also, you should totally present at SalesForce Higher Ed conferences - hope to watch you on YouTube one day!

Really, 2015? Women At Technology Meetings Don't Code?

*sigh* Because it's not like women code or anything...

This is like the time I saw conflicting lunch meetings of the ASME & the SWE (mechanical engineers & women engineers) on campus where I work - in fact, I think the job recruiters were coming to the ASME meeting, and at the same time, it was the first SWE event of the year (or its wrap-up). Yet no one bothered to reschedule one meeting or the other.

And now DreamForce, of all places. A tech conference where the CEO of the sponsoring company is doing a keynote about women's "career advancement."

Yet women in a highly-paid but highly-sexist-and-gender-gapped career (programming) have to miss what the male presenters are saying about advancing their careers to go to the 1 & only keynote in their career track?

*sigh* Did no one think this through?

I've seen other sessions rescheduled - I think a reschedule is seriously in order for this one, DreamForce. (But not so other "underrepresented dual identities" conflict so insultingly instead!)

Dormant Blog, Sorry!

The more I get used to SalesForce, the less I have to gripe...I mean write...about.

Plus, I haven't been in the thick of algorithm design and programming for a few months.

So...thanks to everyone who started reading my blog, and sorry it's been dead lately...I will be back if I get confused and ranty again!