Working for a good tech startup is fun. There's a lot of energy, a certain amount of chaos, a huge amount of work produced and a general atmosphere of people enjoying themselves at work. It's something a lot of companies struggle to hold on to as they grow, and it's common to hear headcount, the need for process or growing regulatory burden cited as reasons.

I'd like to challenge that.

Here is my patented Triangle of Fun In Software Development:

You need all three things, because they interact closely with each other:

  • Innovation - building new software, creatively solving problems. Spending time working on new products rather than maintenance or firefighting. Innovating by using new technology leads to...
  • Exploration - learning how new technology works. Trying out different design patterns. Collaborating with a cross-functional team and the business to understand these new ideas leads to...
  • Ownership - working together to help create a solution rather than being told what to do. Having the ability to suggest changes and propose solutions. Being able to influence the outcome of a project leads to...
  • Innovation - and so onward.

I won't bother with the Triangle of Sadness but it's pretty much the antonyms of the above. Stagnation of spending most of the time maintaining and firefighting leads to a by-rote development style using the same old frameworks and designs day-in, day-out, and eventually to teams which have neither much of worth to contribute nor avenue to do so.

The important thing is that none of these have anything to do with size of organisation, development process or the need to comply with external regulations. If anything, a mature Agile process should be helping by locking in the "ownership" angle of that triangle. (As I keep repeating, if your Agile process isn't doing that then it's not a very good one.)

So how do you get that "startup feeling" if you're either losing it or never had it in the first place? I can't offer a one size fits all solution, but there are some important questions to ask:

  • Is your development team able to contribute meaningfully to the design and execution of the software they build? Is requirements gathering a two-way conversation rather than a one-way dictation?
  • Do you choose your technology stack and architecture based on the needs of each project, or do you just continue with whatever you did last time?
  • When hiring new development staff, do you aim for skills that might be useful in future, or just people who can work with the existing stack and nothing more?
  • Does your development team get to work closely with designers, testers and representatives from the rest of the business? If so, are they treated as peers rather than subordinates?
  • Are maintenance and firefighting requests reviewed for business value, or do you try to do everything? Is there an upper limit on the amount of time dedicated to these tasks?
  • Does maintenance and firefighting have its own dedicated team, or do you interrupt developers from other tasks? Are people rotated into and out of the team on a regular basis to avoid them getting stuck in maintenance forever?

The more astute will notice that startups often get the above wrong, or only get it right by accident. That doesn't mean you don't have to think about them in a larger, more mature company. A 25-person company with less than two years' worth of software estate can get away without any sensible way to manage firefighting because there's so little of it compared to an established firm. Collaboration between developers and the business tends to happen naturally when they only sit a desk apart. There is no "whatever we did last time" to consider.

The flip side to this: that's what makes it easy for a startup to lose track of why it's fun to work for. Making your 100/500/10,000 person company a fun place for developers to work requires doing things that you simply don't have to care about at the 5-25 person scale, and a lot of the challenge in growth is identifying those things ready for the point at which you need to start doing them.

The key is that your team always has ownership, innovation and exploration. They're what makes working for a startup fun, and there's no reason why a big company can't have those values too.