That's why a blog series about how we look at the profession at Blis Digital. As an ode to all developers who are busy making valuable things for their users every day. To the people who come up with solutions 'from scratch' to complicated problems that no one in the world has ever tackled before and for which there are therefore no examples available.
This is part 3: about building strong teams and keeping your tools sharp.
The right mix of skills
“Can't I just hire a few developers from you?” I still get that question regularly. And the answer is always no.
Because a successful development team consists of much more than just programmers. You need a mix of technical, creative, and business skills. And that goes beyond just knowledge - it's about the right one mindset.
Take technique. Of course, a developer must be able to program. But a modern developer also needs to understand cloud infrastructure. From AI tools that can accelerate work. And from low-code platforms that are increasingly playing a role in enterprise software. It requires people who embrace new technology and understand when the tried and tested approach works better.
Creativity is just as important. Software development is solving problems. That means: being able to think outside the box. See patterns. Balancing different solutions. And sometimes start all over again when a chosen path turns out to be a dead end.
And then there's entrepreneurship. Developers need to understand what it's really about: adding value for the end user. That means thinking along about functionality, suggesting alternatives if something is about to become too complex or too expensive, and, above all, understanding that software is not a goal but a tool.
Not every person has all these traits equally. You can't demand that from someone either. And that's why “a development team” is completely different from “a bunch of developers in a room”.
Team roles
In any case, one team member is not the other. They are just people in that regard. Because, of course, we translate the skills we need into roles with specific responsibilities: a solution architect who creates and monitors the technical design. A business analyst who translates requirements into concrete functionality. UX specialists who ensure that the software not only works, but also works well.
Developers to write the code, cloud engineers to ensure that everything runs smoothly in the cloud, and data engineers for the links with other systems. Testers who ensure that everything not only works, but also keeps working and that it meets the requirements. Project and service managers who keep things on track by continuously interacting with the customer.
But it doesn't work to stick to that too tightly. After all, the strength of a development team lies in flexibility and joint responsibility. In practice, this means that roles, expertise, skills and responsibilities are not strictly separated. For example, developers not only write code, but also contribute to Infrastructure-as-Code to make DevOps run properly. Testers work with developers to identify possible problems early in the process. Cloud engineers contribute ideas about architectural choices that go beyond their direct role. Everyone in the team actively contributes to the success of the project, but of course it must be clear who is ultimately responsible for what.
For most organizations, it is impossible (and unnecessary) to have all the necessary expertise in-house full-time. For us as an agency, part of the added value we offer lies in being able to use that expertise flexibly where and when necessary. But to be able to make quality software within budgets and other restrictions, it's not enough to shuffle around with people. To do this, you need to build teams of people who, regardless of their role and specific expertise, have the goal and vision of the project in mind.
Working with a development agency like ours is therefore not a matter of 'extra hands'. It is a strategic choice to use capacity and expertise flexibly, with responsibility as the connecting factor.
Keep the tools sharp
A team can only work with good tools. That's why we continuously invest in keeping our knowledge and tools up to date. We follow new developments with our “technology radar” and we experiment a lot with new tools and techniques. Some disappoint, sometimes there is a real revolution in between.
Take AI-assisted development, for example. We saw the potential of this early on, but also the pitfalls. By experimenting with it a lot, we now know exactly where it works and what doesn't. That saves our customers a lot of learning money. By the way, the same goes for cloud technology and low-code, where we combine the best components into robust solutions and develop our own tooling if necessary (see, for example, our Power Pages Dev Kit).
We keep our knowledge up to date by routinely evaluating and improving. What worked well? What could be better? And above all: what do we learn from this for future projects? That costs time and money, and it requires our people to sometimes come to the office at night for a knowledge session, but it pays off in better software. And pizza eases the pain.
It's about the right match
Ultimately, it's about connecting the right people to the right project with the right tools. That sounds logical, but it is an art in itself. It requires experience, knowledge of people and a good dose of reality.
Because not every project requires the latest technology. Not every team needs all the expertise. And not every customer benefits from the same approach. By being honest about that - and sometimes saying “no” to projects that don't suit us - we build long-term relationships.
And, dare I add, we can also recruit and retain better people than other companies. Because in my experience, software makers are people who love a good salary and a nice car, but who are mainly looking for ways to have a positive impact, tackle challenging problems and continuously develop. This includes continuously looking for better ways to build software.
In the next part of this series, we'll look at how we shape those relationships. Because a good team with good tools is one thing, but cooperation with the customer ultimately determines the success of a project.
You can also read the two previous blogs in this series here:
.jpg)
