How we work
Processes
We like process at BiteSite. A lot of what we do centers around processes that we can all agree work well and if they don't we tweak them. When working with our processes, here are some philosophies we adhere to.
Flexibility
Coming soon.
Changing Process and Introducing New Processes
When it comes to introducing changes to our processes, or introducing entirely new processes, whether it comes from staff or client suggestions, we always take the same approach: small experiments that introduce as little disruption as possible and take as little effort as possible to get off the ground. It's basically the MVP or Minimum Viable Product approach.
The idea is to think of the easiest-to-implement version of the new idea, test it out, and tweak. If it's a bad idea, it'll slowly fade. If it's a good idea, it'll slowly grow.
We approach most (if not all) new ideas as something to try out and see where it goes.
Day to Day Work
We like to welcome all types of people with diverse backgrounds when it comes to our staff, our clients, and anybody else we work with. Everybody has their own working style that we respect, but here are a few guiding principles that help us perform as well as we do.
Too much communication is good
Coming soon.
Be mindful of other people's situation
A lot of times we put our priorities above others which is natural. If you have a deadline you need to meet and it depends on others getting their work done - you're going to be stressed. But before you set the internal expectation that someone you depend on is going to drop everything they're doing to solve your problem, remember that your deadline is not necessarily theirs.
As such, when requesting something from someone else, be mindful that they had other work, other priorities, and other things to deal with. Be courteous to their situation. One thing that can help is to schedule something in the future: don't ask for their help now, but ask "Would you have time in the next couple of days to help me out."
Parallelism
Good software, like a lot of work, involves many parties doing what they do best to produce a great result. When you have multiple people working together whether it's a team of 2 or a team of 50, you inherently run into situations where you are waiting on other people.
To help with this, we always encourage our staff to increase parallel work as much as possible. That means if you're trying to decide between two things to work on in the day and you have time to do both, you prioritize the thing that will allow others to continue their work. That way they can work while you work on the second thing - in parallel.
Concretely, this manifests itself into things like Pull Requests and code reviews and testing. If you're working on something that doesn't really require anybody's input yet, perhaps it's better to review someone's code first so they can make any necessary changes while you work on your other work.