Whitney Sorenson

Whitney Sorenson
Whitney is HubSpot's Chief Architect.

Recent Posts

What Does It Mean to Be a “Good” Engineer?

At HubSpot, we first defined and published our company values in 2013 with the Culture Code. Last year we published our Product Values to be more transparent, internally and externally, about what we value as a product and engineering organization. But one thing that’s become clear as we’ve grown (both in terms of size, scope, and global reach) is that candidates and employees alike want more clarity on what behaviors support those values on a daily basis. 

There’s a lot of noise out there about the importance of holding onto the fabled “10x engineer,” who exhibits superhuman levels of productivity (and subhuman levels of empathy). But we want to combat the notion that there’s only one way to be an effective engineer, and that traits like proactivity, kindness, and teamwork don’t contribute to making an impact.

Our values are only as real as the degree to which they are personified in the code we ship, the individuals we hire and promote, and the leaders we value and reward, so the more context we can provide for people on the front line about the behaviors that are meaningful to our team, the more likely it is that we bring our values to life every day in the work we do on behalf of our customers.

The initial internal draft for this post riffed off an old post by Ben Horowitz on good and bad product managers. While useful and illustrative in its contrast, it reinforced the idea that there are “good” engineers and “bad” engineers and that those are either badges of honor (in the case of good engineers) or shame (in the case of bad engineers). 


HubSpot’s Engineering Values

As our team has grown, we’ve reached a point where tribal knowledge just doesn’t get transmitted as easily as it used to. For much of this tribal knowledge — like why half our infrastructure team recently Photoshopped lasers onto their eyes in their Slack pictures — it’s not a big deal if not everyone's in on the joke. But when it comes to our team’s values — the very principles that shape how we work, and why — well, we want everyone to be on the inside.

At our engineering leadership offsite last month, we realized that as we scale, we need to share our engineering values — our most important tribal knowledge of all — more plainly, more publicly, and more often. While much of our value system gets transmitted by osmosis during everyday interactions between people and teams, we recognized that it was time for more explicit reinforcement and articulation. If we aren’t deliberate about exposing new hires to these principles early and consistently, as time goes on, we risk eventually diluting (and possibly losing) these important and hard-won values altogether — values that have shaped the team and the company that we are today. 


Principles for good engineering leadership

In our recent post about how we do engineering leadership here at HubSpot, we shared our philosophy about what engineering leaders should focus on. 

We encourage our engineering leaders to be primarily product-focused (and, to a somewhat lesser degree, people-focused) rather than spending most of their time driving a process or managing people. This kind of leadership stands in stark contrast to the kinds of leaders who primarily care about administering and health-checking teams, or are on the hook for making sure their employees did the things they were supposed to do. 


Why our engineering leaders focus on product over process

Who was the best manager you ever had?
Even though all of us have different people in mind, those people probably have a lot in common. Maybe he really cared about you as a person. Maybe she was a brilliant visionary who always knew how to push you to be better. Maybe their leadership styles were different but I’d wager that their philosophies were the same.

Inheriting Code: Why You Should Keep Code Teardowns to Yourself

We all dream of a perfect, unencumbered world, working with a pristine code base or starting a project from scratch. In reality, I’ve started enough projects to know that I can build myself into a corner just as well as anyone else can, and that things always get messy unless you spend an incredible amount of time refactoring. I’d like to offer some advice about taking over someone else's code based on my experience: Keep your code teardowns to yourself. I learned this the hard way.


Modern Java at HubSpot

HubSpot’s core technology stack has been through a lot of change and iteration. What started as a simple content system based off a C# framework has evolved into a broad application platform. Today, our tech stack is made up of hundreds of services and dozens of full-fledged products. We’ve experimented with a lot of languages and frameworks along the way: We’ve built services in Go, Scala, node.js, and Ruby, and launched major product initiatives in Python and Java.


Subscribe for updates

    New Call-to-action