Hello potential Bitovian!
I'm writing this blog post to organize my thoughts on working at Bitovi. I'm going to attempt to:
- Answer the most common questions I get during the recruiting process
- Help you determine if Bitovi is the right fit for you
I am extremely biased. Bitovi is largely a result of my ideals about what a consulting company can be tempered a bit by cold hard reality of needing to generate a profit.
Our stated vision is:
Through innovation and process refinement, we will discover the secrets to technology delivery and share them with our clients, ourselves, and the community.
Our mission is:
Empower technology delivery for everyone using:
- Innovative technology
- User-centric design
- People focused process
What this means ... is that we want to be the best at delivering amazing software. We want to share our ideas and methodologies with the world.
Now the best can mean a lot of different things. In business, this usually means delivering value at a given price. We acknowledge this reality, and strive to be the best, not by cutting corners, keeping salaries low, etc, but putting everything we can toward increasing the value we can produce given a unit of time.
How are we attempting to increase value? We'll it might help to understand a bit of Bitovi's backstory...
Prior to starting Bitovi, Brian and I worked for an extremely large (>300,000 employees) consulting firm in their research and development group. We saw a few problems in "big box" consulting:
- Commoditizing employees.
- Promoting competition instead of cooperation.
- Few opportunities for technical improvement (training) within the organization.
- An emphasis on sales over technical accomplishments.
- An emphasis on sales over quality results.
We wanted to create a different model. The idea is that through cooperation, training, and deep technical experience, we will be be able to produce better results faster.
Have we achieved this yet? A bit. We have a long way to go. If solving this puzzle excites you, Bitovi might be the right place to check out.
Some examples of how we are different:
- We have full time open-source developers able to help you solve problems, talk architecture, etc.
- We actively encourage people to do open source work. We will support you taking time away from a client to build something.
- We treat people like humans and try to find them clients and work that supports their skill set and/or interests.
- We let people start their own "profit and loss" mini organization where they have tons of creative freedom.
We work across industries and for the world's biggest companies and for startups. We work on lengthy projects (>2 years) and shorter ones (3 months). We typically find ourselves in one of the following roles:
- We are providing thought leadership and training to a large team. We aren't developing actively, but doing lot of code reviews, architecture discussions, etc.
- We are embedded with a client's team. We are actively developing, but we are also training and building a team of the client's engineers.
- We are doing all the development. Sometimes a client just wants us to do everything. We're cool with that too.
If you are on client work, you are making sure the client gets a successful product ... by any means necessary (except longer hours). Generally speaking, you are doing the common agile workflow tasks and writing code. Some clients have their own methodology, but most will have some sort of standup, sprint planning, etc. We have a checklist to make sure that best practices are followed across all our projects. You are building features, fixing tech-debt, writing tests, etc.
Our goal is a successful project. Success means users are happy with the product, the business is happy with the product, etc. It doesn't necessarily mean the client is always happy with us. They should be love us by the end, respect us the whole time.
Critically, it means that we treat everything as our responsibility and that no problem is out of bounds for us to try to fix.
If you are a developer, but there is not a clearly defined mission, roadmap and goals for the project, you need to fix that. We are not pigeonholed by our titles. We think creatively about how to transform businesses for the better no matter our role. If something is wrong, we fix it - ideally in fun and clever ways.
Some brief examples:
- If you are unable to meet with a busy decision maker to make your case, how can you solve this problem? A tactic we've tried is to offer driving them to work. They can answer questions on their commute.
- If tech debt is increasing a problem, but the client lacks the will to address it, create a meteor (representing tech debt) and earth (representing the app) on the whiteboard. Every sprint, redraw the meteor closer to earth. This is a fun way to keep this problem in focus.
While we want to be as smart as possible, we don't want to work more hours. Ideally, I would like everyone at Bitovi to work an intense 8 hours, a day filled with creativity, efficiency, some fun, and then end their day. It's impossible to be clever if you are overworked.
Yes! Everyone hired gets 2 weeks of technical and soft-skills training with me (Justin Meyer). We also do another company wide training every year. Finally, we have another hour or 2 of training approximately every 6 weeks.
We also encourage people to attend conferences and especially speak at them!
Bitovi is all about technical excellence and open source. We believe that any specific tool matters very little to the success of a project. For most project, the features of CanJS, Angular, React, or Vue has never been the source of success or failure. It's how well a team knows those tools that matters. There's few teams that someone can hire that:
- know their tools better than we do.
- will recruit and train people on those tools better than we do.
For this reason, we prefer our own tools. However, using our own tools is not a requirement. We will use the tools that best fit the job.
We try to do open source in such a way that our libraries can be useful across different frameworks. For example:
- Ylem is a combination of CanJS's observables and ReactJS
- CanJS's custom events can be exported to work with VueJS or jQuery.
- CanJS's data layer is designed to be integrated with other frameworks.
Our hope is that when using other technologies, we can create libraries and tools that are useful across the web.
The open source team consists of about three semi-permanent developers in addition to folks who are between client projects. Starting a year ago, we changed how we manage the open source team. Currently it works as follows:
- The goal is to make existing users of our technology love our product. We measure this with Net Promoter Score and other sources of information.
- There are three 2-week sprints within a 6-week Epoch.
- Every epoch, we perform user testing. Based on user testing, we create proposals that go in a survey to all of our users.
- Based on what our users voted on, we prioritize the next Epoch's tasks.