The “Perfect Company”

On “Culture”

I saw a good quote, and can’t find the attribution for it, because I can’t find the original, but the gist was.

If you have to tell people how great your culture is, your culture isn’t that great.

I loved this quote, because it really gets to the heart of my thinking on “culture”, as applied to tech companies.

If all you do is talk the talk, but never walk the walk, then your culture won’t travel outside the confines of people’s imagination. If your culture is strongly tied to a few people in the office, the bus factor of all those fun parties, team get-togethers, and table tennis games is very low. If those people decide to move on to greener pastures, then all of a sudden you’re left with no “culture” and no parties.

Now really, all this “culture” talk is a bit shallow, because company/team culture isn’t about the parties, the games, and the fun things you get to do once every few months as a bonding exercise. The culture is every part of your job that isn’t the specific thing you were hired for. If you sit in lots of meetings all day, that’s culture. If you have no meetings, that’s culture. If you have a continuous stream of deadlines, rushed work, and requirement changes, that’s culture. If you work with a team of people who look just like you, that’s culture. If you have a flexible set of working hours, that’s culture. If you can work remotely, that’s culture.

If you enjoy your working environment, that’s culture.

If you measure culture by the length of the bar tab at the Christmas party, that might not be a job I stick around for, especially if that’s something communicated regularly when the culture conversation happens, especially to interviewees.

Honestly, I’d like to see a bigger push for diverse hiring, and a focus on inclusivity at the heart of the “Perfect Company”. I’d like to see a serious conversation surrounding hiring externally vs promoting from within. I’m a firm believer that everyone can be taught to be a talented manager, but without a conscious effort in continuous training and improvement, I’ve also seen people hired as developers, put into managerial positions, and flounder wildly because they haven’t been given the knowledge, or lack the experience, to be a good leader.

Finally, we can only be the best people we can be if our job offers some flexibility in time and location. If culture is driven by people who believe that physical proximity is the “one true path” to collaboration and learning, then that’s probably not a job I’ll feel most comfortable in.

On Software

I’d like to see a commitment to testing, documentation, and simplicity as far as possible. I don’t want to spend my first day(s) at a company hopelessly lost as I flounder around pages on a potentially outdated internal wiki page, trying to figure out why the instructions to build the project from the README file don’t work. I understand that not everyone can have 100% test coverage in a fast paced, ever changing product, but I want to see effort being put in to make sure that we’re not flying blind and ignoring failing tests because the tests themselves aren’t being updated.

I am aware that the JavaScript community, (that which I call home), is currently going through something being described as either JavaScript, or tooling fatigue, due to the large amount of tooling being released to help people write, process, and serve their JavaScript in the most efficient way possible. However, I think at the end of it all, the question about tooling I always ask, is:

How would doing this affect the way I need to explain this to someone else?

That usually means that while I can take advantage of some cool tooling, I know that the bit that people interact with is often the bit they want to be consistent. In build tooling, this usually means I, (at the very least), wrap my task runner commands in npm scripts, (although I most often don’t use a separate task runner, but I also don’t work on particularly complex projects).

This small decision means that I can jump to any project I need to work on, and I don’t have the moment where I wonder what task runner I‘m using, or what it’s API is. I can usually kick off with `npm install`, `npm test`, and `npm start`, and be done with it. That’s very specific to my JS/Node.JS ecosystem, I know, but really just thinking about what you’re exposing to the end user, and having documentation that describes your build process, can be hugely beneficial, either if you make the bit of software open source, or you leave, or any other reason that means someone other than you needs to run your code.

At the heart of my thoughts on this bit of process, is broadly, keep it as simple as you’d be comfortable documenting, then write that documentation. Once you’ve jumped over the hurdle of writing the initial documentation, swapping out webpack for rollup becomes not that big a deal, because if it all goes well, no-one needs to care about the underlying mechanism, just that the appropriate task outputs what the developer wants it to.

Some Nice Ideas

In this perfect company, I’d like to share some of my values with the values espoused, (and acted on), by the company.

For example, I really like being able to do my work in the open. Working on Open Source software has been something I’ve been privileged enough to do, and by default, anything I’m not developing specifically for a client, should be published with an open, free, license. I think we’re only as good as the sum of our parts, and a large chunk of my JavaScript-ing, and the tooling around it, has been enabled because someone else was able to write and publish their software freely, and continues to maintain it, update it, and do all those things, very often for free. That’s a really powerful impetus for me to both try and contribute to open source projects, and to share things I’m working on, in case they can help someone else.

I think the “Perfect Company” should appreciate and understand that it’s building on top of an existing community of people, and should seek to be a good community member. Whether that is through hosting, sponsoring, or amplifying initiatives and events that teach people from marginalised groups, contributing financially to those whose work we are building on, or even contributing their time and expertise to non-profits and charities.

The “Perfect Company” would understand that it’s employees were people, not drones. Salaries shouldn’t be a measure of how well someone negotiated, but a reflection of how well they do what they do. I wrote about it a little before, but flexibility in time and location is a big part of displaying how much trust people have in their employees, and how much they are valued. How requests for time off are handled is another matter too. I see a lot of people talking about “unlimited” holidays being brilliant, but I think a better policy is a “minimum” holiday budget. This shows me that the company cares about how close an employee may be to burnout, or when someone may just want to take some time off. Having to think about how many days you have left before doing that, and worrying that you may spend them too quickly, is a lot more stress than we really need. The last thing I want to do is to have to force myself to go to work. I did that for a few years, before I worked in tech, and it is unpleasant, and I wouldn’t recommend it.

The “Perfect Company” would promote learning and self improvement, with trips to conferences, workshops and training events covered as standard. For me, the “Perfect Company” would appreciate that I want to improve and grow as a public speaker, and do their best to help me with that goal. I’m not really sure what that entails outside of financial matters, but I’d love to hear your suggestions on other ways companies can encourage potential speakers.