How To AMP Your Engineers: Ideas For Energizing Your Best

The following is a guest post from Yoav Shapira.  Yoav is on the management team at HubSpot and runs our platform initiative.

At HubSpot, our small internet marketing software company, a major factor in our plans for world domination is our engineering team.  We want our developers, designers, product managers, and QA engineers to all be as empowered as possible, so they can produce their best work.

This is very common, naturally.  What company wouldn’t want that?  But in my experience, most companies and management teams go about this empowerment in intuitive, but wrong, ways.

The result is the usual mix of complaints: slow product development, low quality, unproductive developers, and unhappy customers.

To me, the key to this puzzle comes from two researchers, Daniel Pink and Simon Sinek.  Their research spans psychology, organizational behavior, and behavioral economics, and it answers this question pretty well.  The main finding is that we need to stop using the old “carrots” like cash bonuses.  Instead we should use approaches that increase intrinsic motivations for these creative 21st-century tasks like software product development.

Daniel Pink speaks about AMP: Autonomy, Mastery, and Purpose.

Autonomy, the dictionary tells us, can be understood as “The capacity to make an informed, uncoerced decision.”  Mastery is about expert skills, in-depth understanding of technologies and ideas, and continued study and practice.  Purpose is about having a shared vision throughout the organization, at every level, of why we’re here as a company, and why we’re doing what we’re doing, in service of something larger than ourselves.

Simon Sinek touches on many of the same topics.  He positions it as three concentric cirlces: the “What?” circle, the “How?” circle inside that, and the “Why?” circle inside the “How?”.  If it sounds a bit strange, watch his TED conference presentation below.

In fact, you should probably watch both of these presentations now, or after you read this blog post.  You really should.  Both are short, both are great, and both apply to your company, I promise 😉

What I wanted to share today is not theoretical, but how we are trying to apply some of the above findings to our work at HubSpot.

(1) Product development teams run like small startups.  

Each team has a product manager, who can be a classically-trained product manager or an experienced developer.  More than half our teams today are led by an experienced engineer.  Each team has a small number, 2-4 typically, of additional engineers.

Each team also has a Customer In Residence (CIR), a member of our Customer Success team who speaks to customers all day long, every single day.  Finally, We also augment the team with specialist skills, like QA engineering or design, as needed for their specific projects.

Each team owns an area of the product.  And when I say they own it, I mean they really own it.  They not only decide what to do in that area, in what priority, and how to build it, but also what metrics are the important ones for that product area, how to track those, and what the goals should be for themselves for those metrics.  We think of the product managers as mini-CEOs of their own startup — because they basically are.

This helps establish autonomy.  Real autonomy, where they can make their own decisions, drive their own metrics, experiment as they see fit, and be accountable for the consequences.

(2) Purpose: A sounding Board for advice and coordination.

Just like our company has a Board of Directors for advice and feedback and tracking progress, our management team serves as a Board for the different product teams.  We have a monthly Board meeting where each team presents its progress on the metrics they track, analysis thereof, and plans for the next month or two.  We have an open and candid discussion about what’s going on, but the team decides what to do next.

(Image from The Equity Kicker.)

Also like a company Board, specific Board members work closely with the teams, each one as an advisor, and each one helping only 1-2 selected teams so they are focused.  We help them look at the metrics, keep the big picture and company vision in mind, identify opportunities for coordination with other teams, and otherwise help answer any questions they might have.

This Board helps keep a consistent message on our purpose and vision: why are we here?  Why are we doing what we’re doing?  What’s the greater good?

We also do other recurring activities, like a periodic all-hands company meeting (followed by a party typically), an extensive internal wiki with transparent updates from everyone in the company, starting with the CEO and going to the newest employees, a weekly internal newsletter, and more, all intended to remind us of our purpose.

(3) Opportunities for mastery are everywhere.

As Daniel Pink tells us, it’s important for creative professionals, including software engineers, to get better at our craft.  Besides the actual improvements to our work products, this also gives us a good warm feeling of continuous improvement, learning, and satisfaction.

There are a variety of ways to accomplish this goal, although really this is a life-long quest, not a binary “yes / no” badge.

Things like tuition reimbursement, for example, are pretty common and we love them.  But even there, your company can differentiate itself with a creative policy.  For example, ours is roughly “no paperwork, no manager’s approval, you will get reimbursed, but you have to list your name, your course with link to materials if possible, and your grade, on our internal wiki visible to all employees.”

A less common thing companies do, unfortunately, but one I think they should do more, is encourage employees to contribute to open-source projects.  These can be open-source projects we use at work, things we like personally, things we created at work and now made available to the world, or some other combination.

At HubSpot, we actually go a step further and look for open-source contributors as part of our recruiting process.  We find a high correlation between intellectual curiosity, a professional drive to be a better software engineer, and contribution to open-source projects.  It’s not a requirement of course, but we really like it when we find those folks.

Sometimes you get an open-source project that on its face has nothing to do with your product: Git by a Bus, recently written and open-sourced by HubSpot engineer Edmund Jorgensen, is a good example.  It’s a tool to analyze source code repositories for unique knowledge held in developers’ brains 😉  But even that tool, which has nothing to do with our product, is a valuable engineering management utility.

Finally, we invented a little bit of our own custom opportunity for mastery, in the form of HubSpot Fellows.  This is a program anyone here can apply to.  It’s jointly led by our CEO, Brian Halligan, and a Harvard Business School professor, Andrew McAfee, we recruited for this role.  There are classes roughly every week during the academic semesters, and they cover a diverse range of topics that the management team finds relevant to our business, and/or topics requested by students in the class.

All of these things together, combined with explicit encouragement from management to engage in these activities and improve oneself, lead to an enhanced sense of mastery over time in our engineers.  Or at least, so they tell us 😉

(4) Make it personal with a mentor

As readers of this blog likely know, many engineers can be shy or timid.  They often want the above autonomy, mastery, and purpose, but are unsure about how to ask for it, how to voice complaints, or even what they really want.

I found that having a more experienced mentor you can go to from day one with any question really helps with this.  We pair people up before they join the company, even, with a more experienced engineer.  It doesn’t have to be an older engineer, just someone who’s been here for a while and knows the system well.

We tell our new employees about autonomy, mastery, and purpose (informally usually), and encourage them to speak with their mentors / buddies any time they have a question on any topic.  I hope they specifically push their mentors on these topics in particular.

The mentorship is a stable, long-lasting relationship, hopefully.  It spans projects, team changes, and more.

(5) As with everything else, know that you’re imperfect.

We know we’re not going to get this all right in the near future.  There is plenty of room for improvement, and plenty of opportunities for us to make mistakes.  The good thing is we recognize that, and we try not to be arrogant.  We ask for feedback from everyone all the time, and (gasp!) we often listen and act on it.

Many of the programs above did not exist when we started the company.  They have evolved over time in response to feedback, both quantitative and qualitative, from employees primarily, but also from advisors and other “friends and family of HubSpot” people.

We’d love to have your feedback, so we can improve our programs even more.  What do you do to encourage autonomy, mastery, and purpose on your engineering team?

By the way, if you or someone you know is an awesome developer, you might want to check out what HubSpot is doing to win the battle for technology talent in Boston [there’s a $10,000 bonus involved].

Looking for other startup fanatics?  Request access to the OnStartups LinkedIn Group.  130,000+ members and growing daily.

Oh, and by the way, you should follow me on twitter: @dharmesh.