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.

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].

WOW. I haven't even finished reading this and I'm already compelled to comment. If you agree with this article then please check out: "Managing To Inspire" by Bob Sullo. (It's on Amazon... and no, I don't get a kickback for this...!)

Always interesting to see how HubSpot does it. We think we're going to adopt a Jedi/Padawan system once we start growing our company instead of calling them mentors.

Random idea: A bug/task management system for small-medium sized development teams would be awesome too. One where you get points for completing things, and level up. You could even use the experience points to get prizes, like making your team buy your lunch. Hope someone builds that really well soon...

I get it ... but everybody says that. Google and everybody else says that they run their groups like little startups, that everybody's empowered and that every engineer is like a VP of Engineering at a different (lamer) company.

Joel Spolsky came out a while ago and actually fessed up that Fog Creek, despite all the rah-rah talk, had changed from a place where everybody is empowered to a place where people would collect in little groups every day and basically bellyache about Joel. Joel (I guess) is going back to try to fix that up.

I'm not saying don't try, just that there is lots of room for self-delusion. If employees really wanted to be entrepreneurs, they'd go be entrepreneurs, rather than be employees, even startup employees. That's where it really breaks down. A product group can only be run like a startup so much because a big part of being a startup is cutting the cord to the mothership. If product groups really wanted to be startups, they'd be startups.

Fantastic, useful insight! Thoroughly enjoyed reading all of these articles. Will be placing a link on my blog - the more people who have access to this info, the better:). Thanks to all of you; great going!