Creating a Company Culture That Balances Helpfulness and Productivity
Vice President, Product & Engineering at Amilla
The Problem With Overly Helpful Teammates
I've worked at three companies and have been a part of more than 20 teams in my career. I noticed that there's one thing that never changes: there are always a couple of seniors who spend most of their day helping others. These are subject matter experts with lots of experience, so people always knock on their doors with all sorts of questions and requests.
We have a few senior developers who used to say "yes" to every request that came their way. They're great developers who are fantastic team players, but they couldn't put a limit on their helpfulness. At the end of the day, most of their own tasks remained unfinished because of all the distractions.
I'm sure that one or two colleagues popped into your mind when reading this. Don't you wish they could unblock their colleagues, but still focus on their own assignments? They were hired for a reason— and it wasn't helping everyone else all day.
Creating a Culture of Helpfulness Without Being Disruptive
If seniority translated to helping juniors with their tasks, leaving less time for their own, we'd never get anything complex done. I was faced with this conundrum when I came across the famous story about John F. Kennedy visiting NASA. He was walking around and asking employees what their job was. At one point he came across a janitor who responded, “I’m helping put a man on the moon.” Because he was working towards the same goal as everybody else. He was contributing to the same goal, regardless of his job. This inspired me to come up with an idea to help create a balanced helpfulness culture at my company.
The 30-Minute Rule of Thumb
Everyone at Amilia has 30 minutes each day to help a colleague outside of their team. This applies to everyone in the company. However, they stop after 30 minutes and consider if they'll be done in a few minutes. If not, they need to postpone additional help for the next day or defer to someone else. For example, a support agent might approach a senior developer with requests like:
- Will you help me understand how complex it would be to do [X]?
- Will you help me figure out if that’s an intended behavior?
- Will you help me erase that transaction I made by mistake?
- Do you have an idea of how we could solve the following customer problem?
The rule extends to matters outside of just “dev work.” It’s about helping in general. You want help doing some research? You want a second opinion on an email? You need help moving boxes around? Irrespective of your role, if a person needs help, there's no reason why you wouldn't spend half an hour helping them.
Setting a Time Limit
30 minutes is an arbitrary number I came up with the first time I pitched this idea. It proved to be effective and has stuck for the past five years. It's important that there's a limit, after which you focus on your own assignments. This serves two purposes:
- Increasing helpfulness: The 30-minute rule can have a huge impact in companies where people tend to work in silos. It breaks the mentality of "this is not my job" and fosters an environment where people are mindful that they're working towards the same goal . Ultimately, a solid collaboration culture will help everyone succeed.
- Decreasing disruptiveness: Establishing boundaries is vital. Every individual has a specific role and set of responsibilities, and if they spend too much time helping left and right, their unavailability impedes their main team's collective goal. Saying "no" has to be accepted without offense, because there's always the next day.
When I introduced this rule, it was mistakenly seen by a few as an opportunity to go around certain processes. I noticed that people were approaching developers and asking them for quick feature changes without going through the appropriate motions. So I had to clarify the rule and put emphasis on the fact that it's not a way to bypass processes. It's just a way to get help from someone.
We haven't had any issues since explaining the dos and don'ts. I also published an internal document that underlines what the rule is and what it isn't. As long as you specify the limits in a well-articulated manner, I’m confident that there won’t be any problems.
I saw great results in regards to the evolution of our company. Every time we had consultants come in to evaluate our culture by interviewing employees, the most prominent feedback we always get is that everyone feels surrounded by helpful people. This also translates to kindness, which is often the second item that comes up about our culture. There's no toxicity or isolation. It fosters a very positive work atmosphere.
Also, the rule was successful in its core mission, which is ensuring that our seniors can actually focus on their tasks. Five years ago this wasn't the case; the improvement in focus and productivity was undeniable.
Balancing Helpfulness and Productivity
- The 30-minute rule doesn't care whether something fits within your job description. It encourages you to look at the bigger picture, beyond just your backlog, and work collectively with your colleagues towards a collective goal.
- It's important to set a time limit for helping others. If given the freedom to do so, people in seniority positions risk spending most of their time helping their peers instead of doing what they were hired for.
- The rule isn't an opportunity to abuse the availability of developers. Make sure to specify it’s meant to ask for help rather than a way to skip processes and assign tasks.
Be notified about next articles from Alexis Philippe
Vice President, Product & Engineering at Amilla
Connect and Learn with the Best Eng Leaders
We will send you a weekly newsletter with new mentors, circles, peer groups, content, webinars,bounties and free events.