I’ve worked in startups for almost my entire career – sometimes my own, sometimes companies started by other people. I’m good at what I do, and I love it: I get to create tools that empower people to do things they previously couldn’t, or that were substantial obstacles. Usually that involves some kind of democratization; a righting of an inequality of access. I love creating these platforms, I love watching people use them, and I love evolving them in partnership with the people who use them.
I’ve become more aware that some of my friends in technology startups aren’t having the same experience. We all love technology, but while I find working on it liberating, they find it soul-destroying. They complain about disconnects with management, and that their opinions aren’t listened to. (It makes me feel lucky to work in the environment I do.)
I’m contacted by a lot of recruiters and IT consultants (spoiler: I don’t think I’ve ever used any of them), and over time I’ve become aware that the way in which they talk about technologists is another side of the same coin. They complain about – or often solutions that address – the same disconnects, but from a management perspective.
It’s a mistake to create a them-and-us divide, and it’s impossible to say “this is what developers need; this is what management needs”. Nonetheless, a little empathy goes a long way, and with very little thought about the requirements of the different positions, it’s easy to see why these disconnects occur, and mitigate them.
Great developers are experts in discrete logic. They sit and write logical expressions that represent a desired experience, and don’t just have to think about how that logic resolves, but also about every single thing that could possibly go wrong. It’s not a million miles away from being a lawyer, and computer programs aren’t a million miles away from contracts. Both need to be logically watertight even given contextual circumstances that the author hasn’t thought of; both need to be usable; making a complicated program/contract simple to understand and use is not a simple challenge. Both professions have a reputation for being difficult to get along with.
Finally and most importantly, writing both software and contracts is a creative act. If you want a high quality product, you don’t just do it by numbers. Great developers and great lawyers are artists who are constantly learning and building on their skills. (The distinction blurs even further with user experience developers, whose job is, in part, to translate discrete logic into an emotional response.) They are not simply back-room technicians, and their ideal workplace is something akin to a well-paid university, where they can learn, create and innovate in a nurturing environment.
Startup founders and managers are, in my experience, significantly more financially motivated than developers. (You need to pay everyone competitively, but founders want to sell, whereas developers are often happy finding new, interesting ways to make something work.) This is important. While, depending on their background, they may not have the same grounding in logic as a developer, this isn’t to diminish them: they’ve probably got lots of other skills that the developer might not have, not least an ability to market and sell, and hopefully, a strong sense of vision. (Indeed, if your founders don’t possess these properties, you’re probably in trouble.) Nonetheless, often their ideal workplace is more like a factory, where a decision is made and everybody falls in line.
It’s silly, in a way, because everyone should be – and should feel like they are – all working on the products and services they’re trying to create together. The problems lie in how these two perspectives collide. Inexperienced managers, particularly in smaller startups, micromanage. They want to know every little thing, and want approval on every decision, which in turn means that developers will need to explain the logical underpinning behind their decisions. Worse, they may have to explain why a proposed solution won’t work. Unless these situations are handled delicately, the former has a high chance of making the developer feel undervalued, while the latter may make the manager feel like his or her authority is being undermined.
This is one of the reasons that so much startup literature focuses on hiring correctly. It’s not that some people are wrong and shouldn’t be hired; it’s that you, as a manager, need to feel like you trust them to make the right decision. A hands-off approach (combined with both clear communication and discussion about goals) for a creative, skilled knowledge worker will empower them to make stronger decisions, and make better software. Your main jobs as a manager are hiring correctly and maintaining infrastructure and an environment where your employees can be productive.
Meanwhile, on the other side of the spectrum, a professional developer needs to understand that everyone is a part of the business, and keeping the company afloat is something everyone needs to be concerned with. It’s important to bear those management motivations in mind – they have a fiscal responsibility to the company and its employees – and not think of business considerations as somebody else’s problem.
Given the right environment, that shouldn’t be a problem. If a developer feels like they are trusted to be creative, and to make the right decisions to create software of a very high standard; if their skills are a correct fit for the job that needs to be done; and the environment is such that they can ask questions and provide feedback without fear, and comfortably get work done; if you promote a culture of empathy and try to make sure everybody is valued; then you’re already a long way down the road of reducing that friction and making sure that people love to make great software with you.
It’s a tall order. But nobody said running a startup would be easy.
