An Engineer’s Bill of Rights and ResponsibilitiesBy Charity Majors | Last modified on August 18, 2022
Power has a way of flowing towards people managers over time, no matter how many times you repeat “management is not a promotion, it’s a career change.” It’s natural, like water flowing downhill. Managers are privy to performance reviews and other personal information that they need to do their jobs, and they tend to be more practiced communicators.
Managers facilitate a lot of decision-making and routing of people and data and things, and it’s very easy to slip into making all decisions rather than empowering people to make them. Sometimes you want to just hand out assignments and order everyone to do as told (er, just me?).
But if you let all the power drift over to the engineering managers, pretty soon it doesn’t look so great to be an engineer. Now you have people becoming managers for all the wrong reasons, or everyone saying they want to be a manager, or engineers tuning out and turning in their homework (or quitting). We all want autonomy and impact, we all crave a seat at the table. You need to work harder to save those seats for non-managers.
In the spirit of the enumerated rights and responsibilities of our musty Constitution, here are some of the commitments we make to our engineers at Honeycomb—and some of the expectations we have for engineering roles.
Engineer’s Bill of Rights
- You should be free to go heads down and focus, and trust that your manager will tap you when you are needed (or would want to be included).
- We will invest in you as a leader, just like we invest in managers. Everybody will have opportunities to develop their leadership and interpersonal skills.
- Technical decisions must remain the provenance of engineers, not managers.
- You deserve to know how well you are performing, and to hear it early and often if you aren’t meeting expectations.
- On-call should not substantially impact your life, sleep, or health (other than carrying your devices around). If it does, we will fix it.
- Your code reviews should be turned around in 24 hours or less, under ordinary circumstances.
- You should have a career path that challenges you and contributes to your personal life goals, with the coaching and support you need to get there.
- You should substantially choose your own work, in consultation with your manager and based on our business goals. This is not a democracy, but you will have a voice in our planning process.
- You should be able to do your work whether in or out of the office. When you’re working remotely, your team will loop you in and have your back.
- Make forward progress on your projects every week. Be transparent.
- Make forward progress on your career every quarter. Push your limits.
- Build a relationship of trust and mutual vulnerability with your manager and team, and invest in those relationships.
- Know where you stand: how well are you performing? How quickly are you growing?
- Develop your technical judgment and leadership skills. Own and be accountable for engineering outcomes. Ask for help when you need it, give help when asked.
- Give feedback early and often, receive feedback gracefully. Practice both saying no and hearing no. Let people retract and try again if it doesn’t come out quite right.
- Own your time and actively manage your calendar. Spend your attention tokens mindfully.
What about managers?
Managers, of course, also have a bill of rights and responsibilities—we’ll be sharing an article in the coming weeks on their side of the equation as well.
If you’re looking for more reading material in the meantime, Ben Darfler wrote a post not long ago about the engineering levels at Honeycomb. It’s definitely worth a read!
How Do We Cultivate the End User Community Within Cloud-Native Projects?
The open source community talks a lot about the problem of aligning incentives. If you’re not familiar with the discourse, most of this conversation so...
How We Define SRE Work, as a Team
The SRE team is now four engineers and a manager, and we are involved in all sorts of things across the organization, across all sorts...
Deploys Are the ✨WRONG✨ Way to Change User Experience
I'm no stranger to ranting about deploys. But there's one thing I haven't sufficiently ranted about yet, which is this: Deploying software is a terrible,...