<aside> <img src="https://prod-files-secure.s3.us-west-2.amazonaws.com/a8021bab-ef98-451f-aa13-d2f09e396ef7/79041f43-2293-4b2f-b0f9-4c86bc0a79c9/Trade_off_icon.png" alt="https://prod-files-secure.s3.us-west-2.amazonaws.com/a8021bab-ef98-451f-aa13-d2f09e396ef7/79041f43-2293-4b2f-b0f9-4c86bc0a79c9/Trade_off_icon.png" width="40px" /> Even over statement
Our principles are described using the “even over statement”. An “even over statement” is a phrase containing two positive things, where the former is prioritized over the latter.
A good thing even over another good thing
It is tempting to phrase even overs as “a good thing even over a bad thing”, for example empathy even over arrogance, but that reduces its usefulness as there is no real trade-off. An even over should be just as valid when reversed
(taken from : https://medium.com/the-ready/even-overs-the-prioritization-tool-that-brings-your-strategy-to-life-e4f28f2949ac)
</aside>
Building a strong team starts as soon as the hiring phase. Hiring well requires that we identify the right needs and set up the best hiring process that matches these needs. We take very few risks and make sure everyone involved in the hiring process keeps the same bar.
We believe that helping each other and helping other teams will benefit the team and the company in the end. Being able to help requires that we make ourselves available and provide the right level of support according to the topic emergency.
Anyone can challenge a decision, a way of working, or anything already installed in the team or at Shipup in general. Whatever their seniority, experience, background, or responsibilities are, speaking up should be a habit and can only be unlocked when members trust each other.
Things should work but things need to be maintained, will have to evolve and support the growth of the product. It’s about caring for the next devs who will work on top of your work and caring for your future self as well :)
We want to create a robust organization that is not dependent on anyone and where any new member can ramp up very easily and quickly.
Related practices: Not working alone on features, sharing knowledge in emissaries, pair programming, workgroup initiatives, technical representative role, favoring T-shaped roles over specialists, on-call, wiring & success engineer rotations, extensive documentation
Let’s close all the topics we open. The last miles can be the hardest ones but skipping them will lead to different kinds of issues like knowledge being not enough distributed/missing documentation or some cognitive overload (is it finished or not?).
Technology is to serve some needs. Identify needs/problems first, then the right technology. Choosing shiny and trendy technology is the cherry on top of the cake, not the cake itself.
Some examples: Keeping a monolith and using microservices only where we need them.
