What’s the best way to give developers space?

August 13, 2013 | 1 comment

Like all my new posts and articles, this piece originally appeared on werd.io.

Software developers are not technicians. Whereas technicians are employed to do practical work involving technical equipment, the development process is more akin to writing. Paul Graham was absolutely right when he pointed out that:

[...] Of all the different types of people I’ve known, hackers and painters are among the most alike.

What hackers and painters have in common is that they’re both makers. Along with composers, architects, and writers, what hackers and painters are trying to do is make good things. They’re not doing research per se, though if in the course of trying to make good things they discover some new technique, so much the better.

Making requires concentration, creativity and skills. In turn, those things require the right environment, talent and practice. All three can be cultivated.

As a CTO (and, in effect, product manager), part of my role is to protect the team I work with and ensure that they have the right environment to do their creative work. Depending on the startup, the resources and the context, how well this works is a mixed bag.

Most developers I know work with great big headphones on. This isn’t an accident; think of all those scenes in The Social Network where someone can’t be interrupted because they’re “in the zone”. It’s a great big social signal that says, “I’m working”. Completely understandable: regaining your concentration after an interruption can take a very long time.

More than a set of kick-ass headphones, though, a productive environment needs to be cultivated. Here, asynchronous communication becomes important – developers tend to prefer communicating by email because they can do it in a natural break, without replying right this second. Similarly, meetings need to be scheduled carefully. Non-developers sometimes have trouble with this, and perhaps see it as an anti-social trait. It’s not: you’ve got to leave people alone to work. If you’re looking for a frenetic pace and for something to always be going on, I’d hazard to say that a software company shouldn’t be your first port of call.

(The flipside of this is that developers have to remember to send those emails and be communicative. Nobody likes a black hole in their team.)

I’ve been thinking a lot about this lately, and would love to hear your thoughts:

If you’re a developer, what do you do to maintain your concentration?

If you’re a CTO or a product manager, what do you do to help ensure that your team has the creative space to do their work?

If you’re a non-technical manager, how do you prefer to interact with your technical teams?

#productivity #productmanagement #development

Software factories vs software universities

April 29, 2013 | Leave a comment

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.

The product management cycle

June 28, 2010 | 2 comments

Monday: “The plan is A! We’ll market it at A!”

Tuesday: “Actually, I was thinking B. A is stupid. Who would want to do that?”

Wednesday: “Goddamnit, we need to be working towards C. Why does no-one see that?”

Thursday: “Maybe A was right …”

Friday: “This team sucks.”

Hint: pick a direction and run. And make sure – just as your tech team does – that your management team has measurable metrics for success.