Flexibility is the greatest perk

comments 2
Growth
Photo by Avi Richards on Unsplash.

Where we are

Given that technology talent is in significant demand, and given that salaries can only go so high before they fail to become a meaningful differentiator, companies need to find new ways to attract and retain staff.

As a manager of engineers, aside from making sure that I am paying market rate, I’ve found that the most impactful workplace perk that I can give staff is flexibility over the time and location of their work.

Typically this means:

  • The ability for my staff to work from home (or elsewhere) when they need, either for productivity reasons or for any other life reason.
  • No strict start and end of the day, since we’re not a factory.

This perk costs you pretty much nothing, but the effect on employee happiness can be something quite special.

It can give someone the ability to do all of their children’s school runs. It can save thousands on peak time public transport costs. It can allow someone to care better for a dependent in need. It can take the pressure off of a partner working full-time with no flexibility of their own. It can allow someone to visit their family for two weeks whilst also getting their work done remotely and not using any vacation time.

Doubling your salary will not allow you to buy these freedoms.

We’ve come a long way from free Coke

Ten years ago, a Google-esque perks list that included foosball, free snacks and drinks and a quirky office on top of interesting work will have been unique enough to attract staff away from duller corporate environments.

However, I would argue that these benefits have become a hygiene factor for most technology companies. My cynical side could point out that companies that try to make their office “cool”, whilst still being in the cultural and technological dark ages, have a lot to fix before worrying about where to optimally place their Kegerator.

A positive shift happening in our industry is a move towards increased trust and flexibility in the full-time contract between the employer and the employee.

In my experience, senior staff couldn’t give a damn about how good your table tennis table is. They want to do meaningful work, for a decent wage, but most importantly, they want to be trusted, autonomous, and be able to manage their time like an adult.

This means working from home when they feel that it makes them more productive, leaving early each day so that they can do the school run, and having a flexible vacation policy so that they don’t have to sacrifice time off this year so they can carry over enough days into the following year to go and see their family for a meaningful amount of time in another continent.

I am a fervent supporter of this flexibility for all of my employees. It makes a vast difference, especially with the cost and unreliability of transport.

Age as a catalyst of change

In the early stages of my career, most of my time and energy was channeled into my work and self-development. I worked obsessively hard on my Ph.D. and in my first few years of work. I certainly do not regret this. There is a time and a place for blinkered laser-focus, but it is certainly not all of the time.

The most important thing in life to my current self isn’t my job. (Sorry folks.) It’s everything else as well. It’s my family, dog, friends, mental and physical health, my hobbies, and also my job. I want to bring my best state of mind to all of those aspects of my brief existence without one being detrimental to the other.

If my job is leaving me so tired and time poor that I don’t want to cook and enjoy a nice meal as a family, or it makes me unable to read or watch a movie without falling asleep, nor leaves me with the creative energy to engage in my hobbies, then what’s the point of doing it in the first place? I could easily get a different job. Work should support and enable lives, rather than claim them.

Given that we don’t need to clock in and clock out of a building to operate machinery to build software, I want the flexibility to be able to manage my time as appropriate, work from my nice desk at home to birdsong when it is most beneficial for my productivity and my home life, and generally feel like an autonomous, trusted adult. If you give me that, interesting work and a decent salary, I’ll give you my best.

I’ve managed to arrive at this position over the years, but I appreciate that not everybody else in the technology world has, for a variety of reasons. Sometimes workplaces simply do not allow it and require bums to be on seats between 8:30 AM and 5:30 PM regardless of the tendency of employees to converge towards sinecure to pad the time, or sometimes there are hurdles of internal, anxious social workplace pressure to conform.

“I must be in the office early! What will they think of me if I am not?”

But why not?

If you are a manager and your workplace does not offer this kind of flexibility, then do not immediately lose hope. You could make it happen. You can look to pitch it to your own manager as an experiment. You could light the fire that begins to spread.

It obviously helps if you and your team are already performing well in the first place, but I have the feeling that if you’re actively researching how to introduce more flexibility, then you’re a few steps ahead of most managers out there.

So, assuming that your team performs well, and assuming that offering more flexibility is something that both you and your staff will benefit from, pitch the following to your own manager:

  • That you are going to allow more flexibility in working hours and office presence from this point onwards. You may want to define this more formally, or just let it unfold naturally. If your team isn’t used to this, then I’d recommend starting with perhaps 1 or 2 days maximum working from home a week, and defining some core office hours, such as 10 AM to 3 PM for those physically present in the office.
  • That you will run flexible working as a trial for a fixed period of time. 90 days is a good timeframe to start with, as that can coincide with a decent amount of work being done that you can collectively measure.
  • That, as a reminder, you are ultimately responsible for your team’s performance. You will grant and revoke more or less flexibility if it is or isn’t working out for individuals on your terms, based on the productivity and team harmony that you see, rather than what outside observers may think.
  • That it will be done privately and without wider announcement. In order to cause as little disruption – and potentially jealousy – in other areas of the company, the trial will be done in stealth and not publicized. After all, if increased flexibility is beneficial to employee happiness and productivity, then the quality of work and interactions with the team should remain at least as good as it was before.
  • That you’ll all report back after the trial. Collect the opinions of the team and of those that regularly work with them. Did any aspect of the team’s work suffer as a result of this increased flexibility, or did morale and productivity improve? Did those that interact frequently with the team find them harder to get hold of, or did it not matter?

If the trial goes well, you can probably extend it indefinitely. If your manager is supportive, you could use it as a vehicle to start the conversation with the wider company about flexible working, which could bring meaningful change for everybody.

Flexible working will prevent your staff from leaving. Get them off of the rails. You won’t regret it.

Management bugs: 18 months later

comments 2
Growth
Photo by michael podger on Unsplash.

Nearly a year ago, I wrote an article on an initiative called “management bugs” that I had introduced into our Engineering department at Brandwatch. If you’re not familiar with the concept, then I go into a fair amount of detail in the previous article.

However, in summary:

  • The management of the engineering department have their own JIRA backlog that staff can raise “bugs” into if something isn’t working quite right.
  • Anyone can raise bugs, regardless of role or tenure, and anyone can view or comment on them.
  • There is a designated person (me) who receives, triages and dishes out bugs to the relevant people in order to solve the issues.
  • Typically the bugs become part of the agenda at our management meetings, and are taken away as actions.
  • Once resolved, a summary is written of the outcome and emailed around to the department mailing list.

This week, I was invited to give a talk about the management bugs initiative at The Lead Developer Meetup which was hosted at Intercom’s office in London. In my talk, I introduced the concept and walked through some of the things that had changed in our department as a result.

In preparation for the talk, I revisited the management bugs scheme by reviewing all of the bugs that had been raised and closed. We’ve been running the scheme since summer 2017.

Here’s what I learned:

  • In 18 months, we’ve completed 48 management bugs, with 5 currently in progress. So that’s a new bug every week and a bit. Although, it has to be said that the average number of bugs is skewed by a deluge coming in at the beginning of the initiative, and it has lessened with time, hopefully because we’re getting things fixed!
  • An overwhelming majority of bugs were opened by non-managers. This is great, as it shows that our staff feel empowered to raise their concerns openly with their names attached.
  • The typical length of time that a bug was open for ranged from 5 minutes to 1 year! Some issues were extremely simple to solve, and some were not even necessarily solvable.

I sifted through the bugs to get some examples of issues of different sizes.

Here are some examples of small, quickly solved issues:

  • What do the VPs do? As a VP, this one hit slightly close to home! However, it was a good example of us failing to regularly share the location of our career tracks document, which details the roles and responsibilities for the individual contributor and management tracks.
  • New starters aren’t getting introduced! And indeed, they weren’t. We now make sure that every new member of staff has an introduction sent to the department from their manager detailing their name, what they’re working on, a picture of what they look like, and any self-declared interests and facts to help break the ice.
  • Is there a budget for books and courses? Well, yes, there was, but we had never really documented it. So we did.
  • New staff outside the UK aren’t getting dialed into induction meetings. Oops! That doesn’t happen any more, and all calendar invites now have proper video call links.
  • New roles aren’t being advertised internally. Often opportunities would arise in teams and the outside world would know more than our internal staff who might be interested in working on something new. We make sure that we publicize roles internally now also.

How about some of the medium sized issues?

  • Why aren’t we getting faster as we’re getting bigger? That classic debate. It had a whole bunch of fascinating input from people in a variety of roles in the department. I wrote up a fairly in-depth summary about productivity per head decreasing as you grow, including mention of the Mythical Man Month, speed of decision-making, and the Innovator’s Dilemma, and how we could keep this in mind as we go forward.
  • Why do we not advertise roles as part-time? Well, after a bunch of discussions, we now do, and we have part-time staff that we have hired into our department. So that was a success.
  • When are we going to rewrite the frontend? We’re not, but this did help instigate further discussion about architectural and technical debt work that we needed to tackle, and we now have a permanent stream of work to address it.

Lastly, what about some of the issues that took a very long time to resolve?

  • What is our technical vision for the department? Tricky to define, as it cross-cuts so many different skill sets and areas, such as what our cloud strategy is (we run both cloud and hardware for different parts of the system), how we migrate towards Kubernetes everywhere, whether or not we should standardize the storage and deployment technologies in all teams, and so on. We made a fair bit of progress, but then we went through a merger, so this is all up for further debate again…
  • Why don’t we sign up for StackOverflow for teams? We made the decision very quickly that we’d like to, and we ran a trial that was very well received. It just took a long time to secure the budget. Sometimes it isn’t always the consensus that takes the time.

All in all, I’ve been really happy with our management bugs initiative. I hope that it has made everyone empowered to make change, regardless of their seniority or tenure in the department. It’s also allowed myself and others to get involved in discussions with individuals that we otherwise would rarely talk to.

The challenge that I set the audience of the meetup was that they should go away and do something similar in their own Engineering department. Will you?