Product engineers are experts at identifying, understanding and solving problems. When you talk about the types of problems you tackle, and therefore the impact that you have, the conversation should not be solely limited to the work you do within a text editor or integrated development environment (IDE).
Yes, the code that you write and the systems that you build are major contributing factors to the success and growth of a business. But when you’re free to solve problems at an organizational level, empowered to shape and evolve culture and processes, your impact can grow exponentially.
Here are the five areas that we encourage product engineers to contribute to as they seek to maximize their impact.
Being a brand ambassador
We are proud of what we have built at Intercom. But we’re even prouder of engineers who build great products and then share that knowledge with the world. Intercom couldn’t exist without a myriad of other engineers who’ve solved problems and built tools that we use every single day.
That’s why engineers at Intercom are encouraged to share their knowledge with others and do it in ways that enrich the community. If we’ve solved a problem that others have struggled with, we’re encouraged to share our solutions. That’s why we’ve invested hundreds of hours into speaking, writing, open source contributions and community-focused events. These are great opportunities for building our own engineering culture and fostering innovation in the wider community.
Our engineering focused event, Building Intercom, at Vicar Street in Dublin, Ireland, November 2017
It’s important that engineers are given the support to feel comfortable doing this. It’s perfectly normal for an engineers weekly commit to be “prepare for talk” or “write first draft of blog post.” If we are taking on the task of giving a talk or writing a blog post we’re provided the relevant training and support to do it to the highest standard e.g. a public speaking coach or an editor from the Content team.
Interviewing
Getting involved in interviewing candidates is perhaps the most obvious and direct way a product engineer can help out with hiring. As your team grows, the two biggest challenges are ensuring the quality of candidates is high enough and that broader alignment is maintained. The interview process is when you get a chance to gauge both quality and alignment, or identify the risk of misalignment, so it is a crucial opportunity for any engineer to contribute to the long-term health of the engineering team.
“If the hiring process isn’t consistent or geared towards collecting the right data about candidates the compounding effect can turn negative”
Engineers starting out in the process should themselves be given time to acclimate to the culture of the team for a few months before shadowing an experienced interviewer for a period of time in order to ensure calibration of criteria. New interviewers should start off with sessions that involve less ambiguity like pairing or reviewing take home tests in order to become familiar with process. After you are comfortable with writing feedback and participating, you can begin to shadow more abstract and ambiguous sessions until you’re comfortable leading it. At this point you should continue running the session on your own for a period of time before starting to allow others to shadow you and then repeat the process for another session.
If the hiring process isn’t consistent or geared towards collecting the right data about candidates the compounding effect can turn negative, leading to a lack of diversity and misalignment within the team. One misaligned hire leads to another, pulling the team in yet more directions. That’s why it is so important for product engineers to have ownership of the definition of the interview process.
Onboarding
Onboarding is often treated as a one or two day interlude before we get to our “real” work. It’s focused on meeting a bunch of people, setting up our computer, walking through benefits and occasionally meeting an executive who talks about the vision and mission of the company. It’s fast, cheap and short. Current employees don’t “waste” their time, and new employees can focus on having lots of impact immediately.
“We can only attain the benefits [of hiring more people] if we set up new engineers for success”
While these steps are important and necessary, this type of onboarding is generic and shallow and leaves huge gaps. It doesn’t teach new hires the unspoken rules and expectations around the office. It doesn’t help people find their feet in a new and different environment. When high impact engineers are heavily invested in helping a new person become impactful themselves, it acts as a force multiplier and will pay dividends for the team and company. We can only attain those benefits if we set up new engineers for success and ensure they are aligned with the values and principles of the company they are joining.
Having another engineer that is dedicated to making sure a new hire has a seamless onboarding experience is a great way to do this. Usually at this time there are large knowledge gaps that need to be filled in order for a new hire to feel productive. Having engineers proactively answer new hires’ common questions (“How do I set up my developer environment?” “Who reviews my code?” “How do I watch the status of a build?”) you reduce the chance of a new hire falling at the first few hurdles.
Knowledge sharing
The world’s best products are built by teams, not singularly brilliant and lone engineers. A defining characteristic of a product engineer is that they spend the time to make sure that more junior or new engineers unfamiliar with the tech or processes we have not only understand what they are doing, but also why they are doing it.
“There’s no single point of failure even if a key contributor is lost”
In practice, this means a product engineer demonstrates technical leadership by creating the processes that other people can follow, thereby enabling delegation and multiplying their effectiveness, whether that’s through practical workshops or well-written documentation. At Intercom, alongside our engineering tours, we run regular ask-me-anything style sessions where an engineer will explain to engineering teams outside their own how a specific part of our system works. They multiply their effectiveness because they use their knowledge not just to do their work, but to make it possible that an army of people can do the work instead. It also means there’s no single point of failure even if a key contributor is lost.
Defining values
A shared set of values that all your team buys into will help maintain the elements of company culture you hold dear. As the engineering team at Intercom has grown, issues like those above have appeared and values and processes that worked when the organization consisted of 10 people began to break when it became 100, and the ones that work for 100 most likely won’t work when it becomes 500.
We approach evaluating how engineering is working at an organization level and refining our values in the same way we do the product that we build. We constantly look to collect feedback and refine our values. One of our biggest inputs into what to iterate on is the feedback provided by our engineers at all levels of tenure and seniority. A forum of volunteer engineers gather each quarter to identify issues and potential areas of improvement and create working groups to feed this back to senior leadership.
“Having an impact outside the code editor is about finding ways to shape your company’s culture as much as you build the product”
Defining and iterating on values bottom up as well as top down means our values are something engineers have a sense of ownership of. In this way, they are not just empty words, but something we all have the opportunity to shape.
And ultimately, having an impact outside the code editor is about finding ways to shape your company’s culture as much as you build the product. That way, your positive impact will be felt far and wide.
Comments