Choosing a partner to take care of development is not simply a matter of who displays the most talent, it is also about who you can see yourself building a long-term relationship with.
It is rare these days to visit the website of startups, both large and small, and not see a "We're Hiring" button, or some variation thereof. Developers are in short supply, and good developers are even scarcer. Startups aren't only competing with each other in picking from a shallow pool of talent, they're competing too with traditional businesses who are rapidly trying to adapt to an increasingly connected, and online, world. How consumers shop, where they shop, and how businesses are able to interact with them, have all changed.
No, not changed.
They're in a state of flux, and things don't look like they'll be settling anytime soon. In many ways this is great news for developers, since it gives them more leverage, and allows them to be more selective of what opportunities they consider.
For startups and traditional businesses, it means putting in more effort to attract good developers, or opting for a small in-house team, and outsourcing the big tasks. Outsourcing has many benefits for startups, but it is not without risks. Choosing a partner to take care of development is not simply a matter of who displays the most talent, it is also about who you can see yourself building a long-term relationship with.
Talent in any organisation waxes and wanes, and you would want a partner who can manage this without it affecting your startup. What this means is that you need to assess your partner on more than what they are able to deliver now. And while having a partner whose values and culture align with your own is nice, it is less important than having a partner whose values and culture are appealing to developers. Their ability to attract and retain talent is directly impacted by this, along with the own involvement and visibility within the developer community.
Highlighted below are examples of values and community involvement that you would want to see in your partner, but it just as important that you yourself are exposed to them. Doing so not only brings you into contact with highly skilled developers, it allows you to understand and support developers better within your organisation, whether in-house or outsourced.
We judge people, and companies, on the stories they tell (and sell), so having a partner who comfortably shares their own story on a company blog is to be commended; as long as the story told is real. There is a world of difference between carefully crafted ad copy and unvarnished honesty, with the latter more obvious when your partner allows their own developers to tell their stories.
Company culture is a very important consideration for anybody, not just developers, though the requirements of what represents a desirable company culture are quite different for developers. Company culture is not about perks, benefits and corny value statements, but about behaviours and skills that are valued and encouraged. Think of how an exotic plant thrives when nurtured and placed in the right environment; that is what you want to see in skilled developers. You nurture, you create the right environment, and they thrive (naturally, if your developers are happy and thrive, your business too should thrive).
Coding and development is a largely collaborative process, not only within large companies and large projects, but also during the early learning stage. Many developers start out being self-taught: while still at school, while studying at college/university, even later in life ahead of a career change. No matter how great a learner you are, at some or other stage you are going to turn to other, more experienced developers for their input; either to help you solve a problem, or just to comment on your current project.
This collaborative aspect has helped create a multitude of open-source projects, mostly supported and advanced by developers in their free time. Companies that understand hacker culture (or developer culture, if you prefer) will fully understand the purpose of open-source and they will actively encourage it, not only among their developers, but within the organisation too. Netguru is not only active on Github, but they also have several open-source projects that their team of developers regularly contribute to.
There is no creativity, no innovation, and no chance discoveries without failure, so the one thing your partner should not be micro-managing is performance. Of course, we're not suggesting that they (and you) accept sloppy work and bug riddled code, but they should be supportive of an environment that accepts that mistakes will be made. That's why they should have a QA team.
Developers should be encouraged to always deliver the best product, but they should feel comfortable, and have the freedom, to try out new ideas and make mistakes along the way. Ahead of the Facebook IPO, Mark Zuckerberg wrote in the company's S1 filing:
Hackers try to build the best services over the long term by quickly releasing and learning from smaller iterations rather than trying to get everything right all at once.
And even though some 18-months later Facebook appeared to have started testing new products and updates more thoroughly, it doesn't suggest they've completely turned their back on move fast and break things.
Rear Admiral Grace Hopper was a US Naval office, and more importantly, an early computer programmer. She developed the first compiler, and was responsible for several colorful quotes. One of these quotes is as applicable today as it was back when she first said it:
Photo by izquotes.com.
One of the standout features of many startups is disruptiveness; a strong desire to do things differently. And you can't be disruptive if your internal processes still follow the way things have always been done. Without putting your business at risk, be bold with your experiments. This means not only should you be encouraging your developers to try out new ideas, but that you yourself should be willing to do things differently.
Your partner or developer should be even bolder with their experimentation. The rate at which technology evolves has risen sharply, not only in terms of hardware, but also in terms of programming languages and techniques. Are they constantly exploring new developments, and adopting those that benefit their team and their customers, and that drive innovation?
Even in workplaces that actively promote experimentation with an eye on innovation, it is possible that great ideas are being missed, or not shared at all. To reignite the excitement and (healthy) competitiveness found at hackathons and Startup Weekends, many companies have started organising their own internal events. Ribot started with a 2-day event aimed at improving internal systems and generating new ideas. This has proved so successful that it has evolved into an annual 7-day event. Red Nova Labs did something similar, under the banner Launchpad, in 2011, the same year SEP started their own internal Startup Weekend, which continues to this day. More recently, Coca-Cola, under the mentorship of Up Global, held their own Startup Weekend.
One wouldn't normally associate Coca-Cola with startups, but like any organisation, they do recognise the importance of innovation, along with the relationship building and skills transfer that happen during events such as this.
Having a partner or developer who shuts down their business for an entire week might not inspire too much confidence in you, unless you truly embrace disruptiveness as a path to innovation. However, it does not have to be a full week; Startup Weekend's are exactly that - a weekend event, stretching out over 54-hours from a Friday evening through to the Sunday night.
The points above, and the ones that follow, all make for great stories to tell. But they should be humble in their approach; they shouldn’t be crowing about personal achievements, but simply highlighting the culture and values found within their organisation. When Zuckerberg wrote about hacker culture in the S1 filing, he wasn’t only telling Wall Street analysts that Facebook did things differently, he was also telling developers around the world that even though Facebook was about to be listed, its roots hadn’t withered and died.
The concept of users' groups is as old as mainframe computers, with SHARE, founded in 1955, the oldest active user group. These are not merely social groups, but instead they aim to promote opportunities, and skills development, through shared experience.
Smaller groups revolve around regular meetings (sometimes with industry related speakers), social events, technical support, and an exchange of ideas and best practices. Larger groups, meanwhile, offer the same, but are also known to arrange conferences, Code Camps and BarCamps. Aside from the social events, the focus is always primarily on developers, code and the industry as a whole.
Although the promotion of commercial products and companies is generally discouraged, support and sponsorship are always encouraged. Partners who are committed to developers (and hacker culture) are usually actively involved in user groups, providing local groups with a meeting space, snacks and refreshments, and even encouraging their own developers to speak at events.
Nothing stops you from becoming involved too, offering similar support. Even if you don’t have any in-house developers who could speak at events, startups still have a wealth of knowledge and experience they could pass on to developers. And you never know what you yourself might learn in the process, so make sure your support extends to attending meetings, especially the larger conferences.
Although the term hackathon has been with us since at least 1999, it is only in recent years that hackathons have exploded in popularity among both developers and companies. Hackathons have evolved to now focusing on specific subjects:
Exposing your company to skilled developers, and learning from them in the process, is again a matter of sponsoring hackathons, or offering some form of support. You can take it a step further by even organising your own hackathon or workshop, related either to your industry, or an open-source project you've been working on. Your level of involvement comes down to what your company can reasonably manage, as the last thing you want is a PR nightmare stemming from a poorly organised event.
With an unlimited budget, and not much else to do, you could easily attend a tech conference every week of the year and still not get to them all. As with user groups and hackathons, tech conferences come in all sizes and cover every foreseeable topic. And as with user groups and hackathons, company sponsorship, support and involvement is always welcome.
Depending on the conference you become involved in, the cost in terms of time and money can be significant, but so too is the amount of exposure you receive. If you have never done this before, start small with local conferences, particularly those that focus on your industry. As you become more comfortable, and as your company grows, so too can your involvement.
Lest you forget, networking can be just as beneficial for your company as big branded exposure. A high-level representative of your company should try to attend the larger conferences that you aren't able to sponsor.
The value in being more involved in your community and your industry is not only in greater visibility to skilled developers. One also get’s to evaluate the skills of developers, not only in terms of hard skills, but soft skills too - what leadership qualities do they exhibit, are they strong team players, and how supportive are they of each other?
Companies normally sponsor and participate in events and conferences in order to attract the attention of industry experts and consumers, but for many startups the purpose is to identify skilled developers, and organisations that fully support developers and hacker culture. It is worth remembering that for many developers it isn't the perks and the benefits, or the prestige attached to a company name that attracts them. It is knowing that the company understands developers, fully supports them, and encourages a developer-friendly environment.
The company culture needs to be appealing above all else, to you and to developers.