“The only thing we have is one another. The only competitive advantage we have is the culture and values of the company." Howard Schultz said it about Starbucks and we unreservedly agree. Here at Vinta we care a lot about having an ever-improving environment to work on. Check our guidelines so you can also go forward and create your own!
- Who we are
- Things we will not tolerate
- Why estimates aren't worth it
- Why we believe in open source
- What inspires us
Vinta is a software consultancy focused on web projects. We like to work with Python and JavaScript tools, but we have an open mind to experiment and play with other languages and tools. Django and React are our specialties and we love working with APIs.
- Programmers, not processes nor code, are the most important thing in software engineering.
- The client should be always aware of what is happening, be it good or bad.
- There is no such a thing as the best language or an only way to do things. Each project is unique, and requires its own tools.
- Code should be clean and tested so programmers feel happy and confident to work on.
- Refactoring is a recurrent need and should be regarded as any feature in the backlog.
- Because of the above, automated tests are a must. As long as you write them, choose whatever process you like the most.
- Code should be deployed early and often.
- Simple beats complex.
- However complex it is, there is always a simple way to explain it so everyone can understand.
- Community is one of the most important features of a programming language, keep this in mind when choosing one.
- Open source is tremendous. Make the most of it and remember to give it back whenever possible.
- To keep a welcoming, safe, and healthy workplace so we all exchange experiences.
- To fight for mutual respect among everyone in the company regardless of gender, political position, sexual orientation, religious choice and race, so we all see one another as equals.
- To aid anyone to approve talks and attend conferences, so we all share what we’ve come to learn.
- To encourage open source contributions, so both we all and those we don't know grow together.
- To provide technical courses for everyone, either in-person or online, so we all see no barriers to learning more.
- To buy any technical book wanted/needed, so we all keep reading even outside the company.
- To offer as much coffee and tea as people wish, so we all work in our best.
- A humble attitude to recognize failures, and the will to improve when they happen.
- Tolerance towards failure and sustained improvement.
- Open mindedness for learning and self-improvement.
- Any kind of racism.
- Any kind of sexism.
- Any kind of prejudice.
To us going #noestimates was a decision made early on. Mostly because we believe estimating is bad for both sides (the contractor and the client). To better exemplify that, here is how people think a fixed bid project works:
Project estimate -> internal development of the estimated features -> delivery to the client
This sounds good in theory, but none of those parts happen as smoothly as they are supposed to. Psychology tells us that we are way less analytical than we think when it comes to making predictions. We tend to overestimate our abilities to deliver and to see everything in hindsight as ‘perfectly predictable’. That might be ok for short estimations, but when we are talking about projects that last more than 3 months and many layers of complexity, it becomes quite hard to accurately deliver a working schedule.
Every programmer knows that when you are developing a feature, lots of things can happen. It usually takes some time to study how to fill requirements, bugs might take longer than expected to be corrected and integrations are never as smooth as predicted. Some people say, as you can check here and here, that these problems can be corrected with a better risk management or an improved estimation method. But even with those corrections we believe that in environments with more uncertainty, these methods are not enough to tackle the whole issue. Anything from the client changing his mind, the customers validating the feature out, or even a new and urgent feature popping up are not only possible to happen, but absolutely common to do so. And these are only some of the different turns that might come up.
When Vinta talk about no estimates, we charge and agree on contracts based on hours worked, not features delivered. That means a project is never finished until the client is satisfied. Although scary at first, there are a lot of benefits that come from it:
- We don’t need to estimate, since we saw it’s difficult and error prone, and that’s a big relief.
- Everything takes the time it should take to be done, that means more testing, more studying and more time invested in quality, which leads to better code and increased maintainability.
- The client doesn’t need to waste time thinking/predicting every single need she/he might have. Also, she/he is forced to stay engaged to the project and receives more deliveries according to what she/he wanted, instead of waiting a long period of time to see something that isn’t exactly right.
We are community people, open source contributions are wonderful and everyone is encouraged to do some. Since a lot of our coding uses open-source tools, maintaining our own open-source projects seems reasonable. So we encourage people to contribute as projects demands. We find that is one way to leave our company's mark in the community as well is to always fork using Vinta's Github account.
For us, it's very important to acknowledge where our ideas came from. First, because we don't want to take credit from things that we didn't do and Second, because it helps to emphasize that everyone is free to learn, copy, and improve on what we are doing. Most of our references come from books we read, Startups and bright people from the developer’s community that have inspired us.
-
Rework - Rework is our Bible here, we believe Basecamp has it spot-on regarding where we want to be as a company. It taught us to question growth and see it as a tool to increase value delivered to the customer, not as a necessity. Here, we’ve also learned that meetings are toxic, and much more. Ultimately, it gave us the faith that we can create a company different from the status-quo and still be successful and relevant.
-
The Lean Startup and The Four Steps to the Epiphany - We are not a Startup, but it doesn't stop us from thinking like one. We use the lean build-measure-learn cycle on everything we do. We are always revisiting our processes and iterating them. For us the key take is: validation. Be it something we want to experiment outside the company or inside with our employees, nothing is set in stone, everything needs to be validated.
-
Two Scoops of Django - “Write code that you are proud of”. It is Vinta’s main statement. In this direction: Two Scoops of Django, from our friends PyDanny and Audrey Greenfield, helps us a lot to fuel our discussions regarding our Django Code.
-
Real-Life Responsive Web Design - The way our web projects interact with users fascinates us. We focus on making users awesome with our deliveries, and the fact that we can do that with small alterations in how they use our software is great . Smashing Magazine sets great example by continuously introducing new discussions regarding user interaction and HTML/CSS good practices.
These books taught us something that lives on in our culture. Sometimes bringing us things we haven’t ever heard of, and other times just by asserting things we already had stumbled upon in our practice and use frequently in our day-to-day.
Alongside the books we read, we also devoted a lot of time to research other playbooks and how other companies choose to open their methodologies and culture for the world to see. Their approach and playbooks vary widely, but the important thing is everyone is contributing to raising the level of process discussion worldwide and choosing openness instead of secrecy.
-
Y Combinator - One of the few, if not the only, playbook from an investment company that we could find. They focus on sharing the knowledge they acquired from helping several startups succeed. Its chapters are well decoupled from each other and can bring valuable lessons
-
Basecamp - We've also quoted Basecamp's printed book last section, but their playbook is also worth noting and has a lot to teach. They have found a nice workaround to the problem of letting some subjects open and stir the discussion without compromising some more sensible data.
-
Valve - Valve shares with us a very distinct way of looking at management and how we share information inside the company. Their playbook has a cheerful approach and acknowledges that these changes are not always a bed of roses, but you can ponder the trade-offs and make either side work.
-
Google - Thought it's organized more like a standalone site than properly a playbook, Google's Rework gives us quite a lot of insight in researches that they've done and how that affects their processes. This level of openness that shares even knowledge is one of the reasons Google is a reference in our field.
-
Thoughtbot - Thoughtbot's playbook is structured to cover all the phases of their production process. Dividing it by phase makes it easier for people to go exactly where they want. Although focusing less on the internal operations of the company, their takes on sales, hiring, and apprenticeship are well worth the reading.
-
Luminary Labs - Before this playbook existed, Sara Holoubek did an excellent job advocating lengthy about how companies could go above the minimum line of benefits and start behaving more humanely. Recently they compiled not only their practices but also practices from multiple other companies. They are divided into sections that explain the importance of each benefit while listing many different ways that an interested company might implement them. It's a must read if you are interested in what benefits companies could offer.
-
Facebook - Playbooks can also be a great tool for inspire people and align people with principles that you want for your company. Facebook's playbook does a very good job at that, focusing on the magnitude of tasks developed there and inspiring feelings of grandeur about changing the way people communicate. It doesn't talk much about internal practices, but it's a very good example of an inspirational playbook.
-
Atlassian - Atlassian did an outstanding visual job on their playbook. Almost every part of the process, what they call "plays", is documented and has a video explaining how it works. The playbook is also full of templated documents that anyone can download and a set of tips to be read before testing the practices yourself. Although way more difficult to interact and generate a discussion than a typical, open-source playbook, Atlassian's compilation shows there is always a benefit if you can include more people in the conversation with different ways to show the same content.
-
Wemake - Wemake has several definitions of their playbook, they chose to bring a lot of necessary technical clarifications to a more open discussion, such as "the definition of done", "creating issues", "closing issues" and so on. Another interesting thing they do is set Dealbreakers: criteria that define what types of clients they won't work with. We realize not all companies can do it, and need to work with anything just to keep the head above the water, but we also believe more companies should be doing something like this.