How to Lead High-Impact, Cross-Functional Projects

How to Lead High-Impact, Cross-Functional Projects

Hardik Gandhi   January 11, 2018

Even When You’re Not the Boss

This past summer I managed the largest acquisition campaign in my company’s history. I work at HubSpot, a marketing software company that popularized lead-gen campaigns and the whole idea of “inbound marketing,” so this is no small feat (we’ve run massive campaigns over the years).

The campaign, Four Days of Facebook, drove 10x the number of average leads of a typical acquisition campaign and 6x the lifetime value of projected customers.

But I didn’t do it alone. This campaign involved 11 teams and 33 people who directly contributed to the work.

Cross-functional campaigns like this can be big, complicated, and challenging which is why they so often take a boss or recognized leader to make them happen. So I wanted to share my experience as a “non-boss.” I hope it encourages other individual contributors out there to get their co-workers in other departments excited about working on high-impact, cross-functional projects.

Pre-planning: create alignment

You won’t have all the answers on day one, but make sure every conversation you’re having at this stage focuses on one thing: impact. You’ll be asking a lot of people to work hard on something outside of their normal day-to-day, make it clear that your asks will translate into business results.

• Meet with senior leaders of each team before you ask for their employees commitment on helping. Again, make it clear that you won’t be wasting anyone’s time, you’re out to generate big results.
• Have a kickoff meeting with the team who will be responsible for delivering the work. At a high-level, you want to let everyone know that you have senior leadership buy-in and the project will be worth their time. On a more tactical level, you’ll also want to get people up-to-speed on the tools you’ll be using to manage the project.
• Go the extra mile to develop a team culture for your team. You know how developers name their projects crazy-sounding names? It’s surprisingly effective! Give your temporary team a name that makes people feel like they’re a part of something, set up an email alias, and create a Slack channel. Get people excited!

Throughout the pre-planning stage, keep your vision front and center. For Four Days of Facebook we were partnering with Facebook, a fact I repeated constantly.

If people are excited and engaged with your vision, they’ll put up with the inevitable bumps as you achieve lift-off.

During: maintain momentum

The Progress Principle is the idea that humans love the satisfaction of wins, even if they’re small. It’s your best friend as you seek to keep multiple teams and dozens of people aligned and moving in the right direction–constantly show (and celebrate) forward progress.

• Display it: I put together a registration goal waterfall chart that was updated everyday to show progress. It’s motivating to close-in on and cross that goal line.
• Never shut up about it: I linked to information about this campaign in my email signature, Slack rooms, wherever I had the attention of my co-workers. And that information was short, sweet, and up-to-date.
• Be a good partner: You’re not technically the manager of the people on a cross-functional team, but you should implement some management best practices: give people autonomy, figure out how they like to work and what kind of support they need from you.
• Ask for feedback: I asked questions constantly– Is this system or process working for you? Can I set up these reports in an easier way? At one point during this campaign I asked the senior manager of a few folks working on the project if she had thoughts on how I could run it better, she told me she would love to see weekly updates sent to her and other senior managers. I was avoiding this as I didn’t want to clutter inboxes, but it ended up being one of my best tools for building internal momentum around the campaign.

Don’t overlook the fundamentals of good project management. A framework like DARCI makes roles & responsibilities super easy so you the project lead can just say, “This meeting is for people who are Responsible and Accountable only, we’ll be covering deadlines for next week”, or “This meeting is for people that need to be Informed, it’ll be a milestone check-in.”

Find a project management framework, and stick to it.

Wrapping up: close-the-loop

I run 4–5 acquisition campaigns at HubSpot every quarter and running a campaign of this size and impact was a complete rush and I can’t wait to do it again. But before jumping into the next big project, it’s important to do a clean wrap-up, I want people to be excited to work with me and my team again in the future.

• Say thank you: Do it publicly via a company announcement or email, and privately. I wrote handwritten notes to every person who contributed to this campaign.
• Share results soon: Share the quantitative results, but don’t miss Twitter comments from attendees, feedback from partners, or the accolades of your co-workers. This is your chance to make it clear that you promised impact and delivered it.
• Look for improvement opportunities: Because no matter how successful your campaign was, there are opportunities to do better — Were any deadlines missed? Why? Did any team members not work well together? Can this be addressed?

It’s easy to get stuck in a rut of executing one marketing campaign after the next, and it’s scary to think about leading a big cross-functional project that could potentially fail publicly.

But so often the answer to higher impact is better collaboration. Learning how to lead across teams 10x’ed the impact I was having at my company, I hope it does the same for you.

JavaScript — Shorthand Variable Assignment

JavaScript — Shorthand Variable Assignment

Hardik Gandhi   January 10, 2018

A three minute introduction into shorthand variable assignment

This article will take a (very) quick look at shorthand variable assignment in JavaScript.

Assigning Variables to Other Variables

As you’re probably aware, you can assign values to variables separately, like this:

var a = 1;
var b = 1;
var c = 1;

However, if all variables are being assigned equal values, you can shorthand and assign the variables like this:

var a = b = c = 1;

The assignment operator = in JavaScript has right-to-left associativity. This means that it works from the right of the line, to the left of the line. In this example, here is the order of operation:

• 1 — First, c is set to 1.
• 2 — Next, b is set equal to c which is already equal to 1. Therefor, b is set to 1.
• 3 — Finally, a is set equal to b which is already equal to 1. Therefor, a is set to 1.

As you can now see, the shorthand above results in a, b, and c all being set to 1.

However, this is not a recommended way to assign variables. That’s because in the shorthand variable assignment shown above, we actually never end up declaring variables b or c. Because of this, b and c wont be locally scoped to the current block of code. Both variables b and c will instead be globally scoped and end up polluting the global namespace.

Using Commas When Assigning Variables

Lets look at a new example. Consider the following variable declarations and assignments:

var d = 2;
var e = 3;
var f = 4;

We can shorthand this code using commas:

var d = 2, e = 3, f = 4;

As you see, we are separating each variable assignment with a comma which allows us to assign different values to each variable.

For ease of reading, most coders who prefer using the comma method will structure their variable assignments like this:

var d = 2, 
    e = 3, 
    f = 4;

Best of all, in the shorthand variable assignment shown above, we are declaring all three variables: d, e, and f. Because of this, all variables will be locally scoped and we’re able to avoid any scoping problems.

---

Want to Learn More Shorthands?

Check out my other articles on shorthand coding techniques in JavaScript:

• JavaScript — The Conditional (Ternary) Operator Explained
• JavaScript — Short Circuit Conditionals
• JavaScript — Short Circuit Evaluation

Closing Notes:

Thanks for reading! If you’re ready to finally learn Web Development, check out: The Ultimate Guide to Learning Full Stack Web Development in 6 months.

If you’re working towards becoming a better JavaScript Developer, check out: Ace Your Javascript Interview — Learn Algorithms + Data Structures.

Why people shouldn’t learn to code

Why people shouldn’t learn to code

Hardik Gandhi   January 10, 2018

As a scholar, I like arguing against myself. Thesis, anti-thesis, synthesis: the Hegelian dialectic can be one of the more productive and entertaining paths to truth.

And so, in this post, I attack the central thesis of my research: that the ability to program a computer, and the computational thinking that can come with it, is a power that must be democratized.

Why do I believe this? I believe that a severe concentration of power nearly always leads to injustice, and justice is one of my core values. That only 20 million people write the software that shapes the digital experiences of the 7.5 billion people on Earth is concentration of power second only to global income inequality. My research aims to lower the barriers to acquiring the power to code, which I hope will more evenly distribute this power, which in turn will reduce injustice.

Agree with me? Great! But that’s no fun. And it leaves this position open to attack, with no sense of how robust it actually is. My position might even be wrong.

So let’s consider three anti-theses to my thesis.

Ability is an arms race

One critique of my thesis is that the ability to code is an arms race. No matter how easy we make it to learn to code, this greater ease will only amplify the abilities of those who already could. The privileged few who learn to code now will learn younger and faster. All of those talented new engineers that didn’t have jobs before still won’t get jobs at Google because everyone else will be that much more talented. No matter what we do, power will remain concentrated, because the underlying social structures that protect that power will remain unchanged.

This is an instance of Kentaro Toyama’s argument about technology as an amplifier rather than a catalyst of social change. The argument is that technology of any kind, whether a learning technology, a better pedagogy, a simpler programming language, or a better developer tool, will only intensify whatever social structures exist. It’s up to us to change our behavior, our values, and ultimately, our institutions, if we want to redistribute power. More effective learning will not.

Software is evil

Another critique of my thesis is that the software itself is a net loss for humanity. Communication technologies have eroded our relationships, democratization of publishing has eroded truth, platforms have eroded innovation, and automation has eroded our livelihood. There may be some good things that come from digitizing information and automating decisions, but on the whole, they take more than they give. We should therefore have less software, not more, and so we should have fewer people that can code, not more. Like nuclear weapons, we should use software sparingly, if it all.

This argument abounds in pop culture of today. As all dystopian sci-fi has for a century, Black Mirror is popularizing this position, portraying how even small changes in how we use software can lead to plausible and horrifying outcomes.

Software is dangerous

One of the critiques I’ve heard most is the idea that software is too powerful to be democratized. As in medicine, engineering, and law, some knowledge should be regulated, only accessible to people with appropriate training. The risk of allowing everyone have the ability to code is that we increase harm. And perhaps were already seeing the result of unregulated access to the ability to code: software fails, people die. In fact, I analyzed 30 years of software failures reported in the news, finding that about once per month, the news reports at least one death, injury, or threatened access to food or shelter due to software problems. Is all of this faulty software really worth this increasingly frequent harm?

Some countries such as Canada do regulate software engineering. These efforts are often poorly implemented and premature, but not necessarily wrong in principle. We don’t want a billion people to know a little bit about heart surgery. Why would we want a billion people to know a little bit about software development?

---

Now, to synthesis. How can we reconcile these conflicting stances?

All four of these arguments have a kernel of truth. The small number of developers in the world really do concentrate power, and that does lead to injustice like algorithmic bias, poor software accessibility for people with disabilities, and innovations that primarily serve the privileged classes that created them. And yet, software does cause harm and can be evil. It’s entirely possible that by helping more people learn to code, we’ll just end up with more people with brittle knowledge of how to create software, more bad software, and the same people in power.

The fatal flaw that puts these positions in conflict is that none of them make explicit who will learn to code and what they will do with that knowledge. I envision a world in which a vast majority of educated people understand enough about code not to become engineers, but to advocate for justice. Some of those people will become software engineers, but they will be different, more diverse people, who represent society, unlike the engineers we have now. This larger group won’t make any more software than we would have made otherwise (and therefore won’t cause any more harm or evil than we would have had otherwise). Rather, this new majority of computationally literate citizens will be a political force that demands justice.

This literacy could not be more pressing. For the next century, we will be heavily debating net neutrality, privacy, the regulation of automation. We will be trying to parent in the presence of social media. We will be trying to make objective journalism sustainable and desirable. We need every parent, politician, and person in power to understand what code is and what it isn’t. And we need the 20 plus million developers in the world to reflect everyone, so the software they create serves everyone.

The other fatal flaw in all of the positions above is that they don’t make clear what “learning to code” means. What does everyone need to understand about software to be in a position to advocate objectively? It’s not necessarily knowing a programming language. It might mean knowing what programming languages are and are not capable of. It might mean understanding the intersection between computing and policy. It might mean understanding how software is engineered and who engineers it, so everyone can comprehend what any particular policy proposal they’re voting on would actually mean in practice. Some of these ideas have made it into our curricular standards and assessments, but most have not. We need to understand what this knowledge is and invent ways of teaching it effectively.

Software is not going away. It will continue to be evil and dangerous. It will continue to bring joy and prosperity. But it will not bring social change, and it will not provide universal access to knowledge about computing. That’s up to us.