Product companies and startups have it so easy!
Everyone involved knows what the mission is, they know what they are building next, all their developers work on the same code base and can easily collaborate and reuse each other's code.
Product agencies instead deal with multiple projects at the same time, different teams, multiple code bases, multiple IP owners and constant shift in the specifications. The development process can become especially difficult.
In such a company, for instance, it's often very hard to advocate code reuse at an organizational level because developers tend to push back with arguments like:
It would not take me long to implement that.
I can't reuse it because I want to learn how to do it.
Every project is different so I have to recreate it.
I can copy-paste that from another code base and change it a little.
Some of these are valid arguments in an agency, especially one that chooses its projects based on what it can learn from them.
However, I've noticed that a couple other factors keep developers from reusing someone else's code:
- Ownership and responsibility: "If I didn't write it how can I guarantee it works well?"
- Trust: "He didn't write it well enough so that I can also use it/ I don't like his code base."
- The need to learn: "I want to learn to build that too!"
- No research: "The deadline is short and we have so much to do, so there is no time to research what packages or services to reuse."
- Laziness: "It would take too much effort to write it for reuse" (Laziness is one attribute great developers use to their advantage more often than not - except in this case, though).
Whichever the cause may be, it creates an environment that's constantly reinventing the wheel and wherein everyone thinks they know best.
That's not a suitable medium to build successful products in.
It's for this reason why I think product companies have it a lot easier. They have a well-defined team aiming towards a common goal and their mission never changes as it's focused on the product.
Nurturing a startup mentality in an agency is difficult (to say the least). It also takes time...like, a lot of time.
At Around25, me and my team have been working on this for over 4 years, slowly changing the way we think, work and interact in order to build a similar environment to a startup. Here's a few things we learned along the way and now greatly matter to us.
It's not always visible at first, but every company has one. Problem is, if you don't care (enough) about it then it's probably not a good one.
As my colleague Robert said during a trivia Q&A: "I can't say exactly what it is, but there is a culture in Around25 and that's the best thing about the company".
For us, building our own company culture started from the motivations behind the founding partners, their goals, ideas and passion for the work. This is impacted by every new member added to the team - they either adhere to/resonate with the company culture or not.
Yes, startup life is hectic and very much growth-oriented, but at the same time you can't have a startup culture without a few goals everyone understands and strives to achieve.
This is a bit more tricky to set in an agency and instead you usually see a mission statement that you understand nothing from and you simply can't follow.
A good take on this is to make smart goals with where you want to get to in a certain time frame and also encourage habit-forming activities to support those goals.
For me personally, one such habit is writing a new article each week (here's the last I published) or build one new reusable component every month. For the rest of my team, the goal can be different but the idea is that they follow the same go-the-extra-mile approach each day they step into the office.
In this respect, I can refer to my teammate Darius Cupsa who's an active contributor on our GitHub profile and just recently committed to running his own workshop. It's a 4-event series where he's teaching the basics of Ethereum blockchain building to developers in the local community of Cluj-Napoca. Even more, he also writes about it (here's part 1 of the workshop series).
And he's not the only one doing stuff that's not on their job description. Take Calin Tamas, for instance: a fullstack developer turned photographer turned writer on our blog with a monthly issue he curates.
These are just a few examples of what 'company culture' - as overused a term as this might be - means to us as a product development agency.
Every company tries to hire the best people and offers trainings so as to make them better at their job.
However, I feel I have to point this out (although it's been said time and time again): the ones who are truly great at what they do always want to learn more - moreover, they do it naturally. That's why I tried to make this a golden rule for our recruitment process.
Continuous learning is in our DNA as a company and it's one of the things that I think makes it a cool to be part of.
Our aim is to push every team member to be open to new challenges and learn the skills to deal with them as if they were the go-to person for that project.
Even though our projects may change from time to time, we do work in a team and we tend to build some functionalities again and again.
This is also due to something called Intelectual Property, but that doen't mean we can't find ways of building new components and services for reuse.
Since last year, we have taken a hard look at this problem and decided to do something about it.
To facilitate this, we started making a list of all components/packages/services we could reuse for other projects based on our previous experience and gave it to the entire team to modify.
Bit by bit, we are building these components from the ground up with a focus on convenience, reusability and allowing every developer in the company to test and make Pull Requests to improve them with new features or bug fixes.
An agency is not a startup, but that does not mean it can't be just as great. It's up to you and your team to stop for a moment, take a closer look at your agency and see how you can make an impact.
I'll keep you posted with what effect our journey towards code reuse has had on the way we work.
In the meantime, I'd say strive to become the impact you want to see at your workplace. If you have any insight or experience you'd like to share, please do! You can find us on Facebook and Twitter or contact us directly.