Developers are a huge part of organizational success. Way back in 2013, Stephen O’Grady said that developers are “kingmakers” – so this idea is not new.

As a society, we’re increasingly connected – to each other, and to the businesses we choose. Those connections, and those businesses, run on software. We’ve moved to hitting a website or using an app to do business instead of picking up the phone – and even if we call a company, the person we’re talking to is definitely using software on our behalf.

Pikachu, I choose YOU.

We said that we’re more connected to the businesses we choose – and we do have significantly more choice about which businesses we use. The business’s software is part of how we make that choice – if it’s engaging and easy to understand and use, then working with the business as a customer is easier. If working with a company is easier, we’re more likely to go back. If, on the other hand, the website or app doesn’t work, or it’s confusing, we’re more likely to use one of the many alternatives that the internet allows for. Basically…

Customer service is characterized, facilitated, and proven by a company’s software.

Software driving a business’s success is also not a new idea – in fact, it’s the core concept behind the ideas of digital transformation and digital disruption. If we accept that it’s true, the next thing to consider is how to make software successful.

Software’s success is determined by how well it’s designed, built, and maintained. Great software can’t be built by mediocre developers using mediocre architecture, running on and designed for mediocre platforms. So…that means that businesses really need to know, “how do we enable our people to create amazing and engaging software?”

Software drives a business’s success – and software’s success is driven by how well it’s designed, built, and maintained.

How to Enable Developers – Technology

Enabling via Architecture

What do developers need to be successful? Well…they need several things, but first they need to understand the rules of the software they’re building: what is it intended to do? How does it communicate with other software? What APIs, services are available? Where is data permanently stored? What languages can I write it in?

These questions are all architecture. The answers should be clear and consistent, and they should allow for flexibility in implementation. They should also allow for development speed and developer familiarity – usually by using modern, standard technology with lots of community support.

Open source technology is usually the best for enabling happy developers. The communities around open source development are strong, and they’re full of skilled, passionate people who love the technology they’re contributing to – and they contribute to technology that they would love to use. Spring (Java framework), NodeJS (JavaScript run time environment), Ruby (general purpose, object-oriented programming language, like C++ and Java), MongoDB (document database), and Kafka (pub/sub messaging) are all examples of great open source architecture ingredients that developers actually like to use.

Enabling via Tools

Developers need to know what tools are at their disposal to develop, test, and run their software. They also need those tools to be kept up to date – via updates, or via new tools that accomplish what they need better, faster, or less painfully.

They need an IDE they understand – and enjoy using (we like IntelliJ, but nerd tools are something like holy flame wars, so…you do you. Laine quite happily made entire web pages in Notepad++ as a teenager, soooo…). Think about your office, or the primary tool you use to do your job – that’s an IDE for a developer. It needs to be comfortable.

They need code repositories (Git-based, Bitbucket is great), and security scanning (Sonarqube, and a dependency scanner), and test automation, ideally built in as early in the process of development as possible. They need fast build tools so they aren’t forced to stop everything and wait in order to even see if a change works (Maven, or Gradle), and automation where and how it makes sense, for builds, or deployment, or…whatever (Jenkins, or Ansible).

They need a good platform on which to run their software, ideally one that gives them the ability to self-serve…well, servers, so they don’t have to wait a week or a month or even a day to move forward once their code is ready (OpenShift).

Enabling Developers – Culture

Enabling via Processes

Confusing release processes, slow purchase processes, unclear approval processes for free tools – these are all processes that choke innovation, and worse, choke a developer’s ability to even execute. To enable developers, a business actually wants them to have some freedom to stretch out – to use their skills, and to discover new skills.

Independent of IT processes, there are also HR processes – like rules that dictate many hours must be worked, or rules that don’t “count” any work done from anywhere other than on site. IT is an art, not a formula – IT brains are constantly designing and adapting and connecting information – and then refining those designs, adaptations, and connections. Expecting, and behaving as though, X developers = Y lines of code, and Y lines of code = Z business priorities delivered causes pain and actually slows developers down.

IT is an art, not a formula.

So…there are bad processes that, if stopped or lessened or sometimes just explained will enable developers. There are also good processes – giving them a comfortable means to communicate with each other (Slack! <3), or encouraging easy ways to learn and grow and try things without repercussions.

Enabling via Support

Application developers need support – people backing them up and fighting for them, and supporting the tools they need to do their jobs in the least painful way possible. They need Architects setting architecture standards, and making sure that people talk to each other and agree about how all of the software into, out of, and within a company will interact. They need Platform Architects (sometimes called Enterprise Architects or Infrastructure Architects) setting up their platforms and making sure their apps run, and giving them access to get clear, fast feedback about their applications from those platforms.

They need people who will cut through any cultural red tape to get them the information and tools and good processes that they need. They need HR managers who support their career and their personal and professional growth. They need technical leadership who teach and advocate – new architecture patterns, how to actually use new tools, what works and definitely does NOT work between teams and in other companies. They need people explaining how to use the tools provided and giving them permission to adapt the “how” in such a way that the tool is not onerous.

They also need each other – people who are native speakers of their language, who are trying to accomplish roughly the same things in the same ways with the same barriers.

Teams Drive Organizational Success

Developers drive organizational success, but they need teams around them – supporting them, and fighting for the processes and tools that will help them be successful.

A healthy ecosystem is vitally important to developer success.

So…it isn’t actually just developers who drive organizational success – it’s teams. Teams centered around development, and enabling that development, but…definitely teams.

Successful businesses have successful software. Successful software is made by enabled developers. However, the truth of the matter is that because we are all so connected, no one exists in a vacuum. Developers need architects, and infrastructure people, and leadership (HR and technical, along with vision setters and vision communicators), and cutters of red tape, and purchasers of tools, and each other to truly be successful.