Engineering culture deck for Kasten, a cloud-native startup in the enterprise space. Apart from broader company culture, this deck touches on the things that are the most relevant to engineering teams.

1. Kasten Engineering Culture Deckv0.1
This deck, just like the company, will always be a work in progress. It is
also incomplete without the general Culture Deck. Feedback welcome
and appreciated!

2. Culture is a
shared outlook

3. “Culture is Strategy”
- Jim Collins

4. Enables us to outcompete others
Helps build a great team
A Great Engineering Culture:

5. KISS: Keep it Simple, Stupid
- US Navy, 1960
• “Make things as simple as possible, but not simpler.”
• Applies to everything we do, not just engineering
• Easier to build, extend, maintain, debug
• Faster for new team members to become productive
• We should not apply premature optimizations either

6. Think Long Term
• Keep technical debt in check
• Be very conscious if ever indebting ourselves and figure out a plan to pay it off
• All technical debt is not created equal. We need to keep it manageable
• Encourage Continuous Refactoring and Improvements
• Helps reduce complexity that might have crept in
• Helps pay off accumulated technical debt
• Build infrastructure to make this low risk and low effort
• Design for an extensible architecture

7. Thinking Long Term: Code Quality
• Good code quality and uniformity goes a long way
• Helps new people come up to speed faster
• Helps people work with non-familiar portions of the code base too
• It is therefore OK to be pedantic with code quality expectations
• Keeping to the same codestyle is just the start
• This should be enforced automatically and not via manual reviews
• Reuse common design patterns wherever possible too
• Code Quality starts w/ Code Reviews
• We review everything
• We keep code reviews small to increase SNR and reduce reviewer burden

8. Thinking Long Term: Code Reviews
• Code Quality starts w/ Code Reviews
• We review everything. Even trivial changes.
• Helps share common patterns, share knowledge, increase visibility, catch issues early.
• We keep code reviews small to increase SNR and reduce reviewer burden
• Prevents this oft-quoted tweet

9. Thinking Long Term: Automation
• Automation will be the critical tool for agility
• Testing must be completely automated
• No way to ship rapidly without this
• Deployments must be completely automated via our CI/CD pipelines
• Too high risk without that

10. Ship Quickly
• This is critical to both our success and our customer’s success
• Our goal: Customer ship every two weeks!
• But we do not believe in “Move Fast and Break Things”
• And we are not believers in death marches either
• As touched upon in earlier slides, we will:
• Invest heavily in automation in general
• Invest heavily in automated tests to get high coverage
• Invest heavily in anything else that reduces ship friction

11. Ownership
• We have a collective responsibility for our product
• If you see a problem and can fix it, do so. Don’t wait for permission or
approval
• Even if you cannot fix it, it is your responsibility to raise the issue
• Like many things, this applies to things outside engineering too
• That said, ownership for self comes first
• You own your code
• When developing, think about whether it will get you paged at 2 AM

12. Maximize Collaboration, Minimize Interruption
• For better or worse, open offices are here to stay.
• While we are very collaborative, need to minimize random interrupts
• Minimal noise on the floor. Will electronic communication work?
• Keep your cell phone on silent/buzzer mode
• Take calls in rooms or in the hallway
• We strongly prefer async communication methods
• Slack Channel >> Slack 1:1 >> Email >> Phone >> In-Person
• If you see headphones on someone, they don’t want to be interrupted

13. Document, Share, Document
• Anything non-trivial must be captured
• We will provide the tools to make this easy (JIRA, Confluence, Add-on tools)
• Non-trivial discussions should almost always be open
• Do it in public spaces (e.g., Wiki page, Slack channel, mailing list vs. 1:1
conversations, personal email, etc.)
• Always err on the side of over-sharing (generally there is no such thing and
your team members will love you for keeping them in the loop)

14. Don’t use 💩 metrics
• Never measure productivity or performance via easy-to-game metrics
• Examples include # commits, # bug fixes, Lines-of-Code written, etc.
• Will always be counterproductive

15. Invest in People
• Not just about promotion but instead about overall career growth
• Folks should, over team, have an increase in one more more of:
• Technical complexity of problems handled
• Depth in various technical stacks
• Related non-technical skills (communication, leadership, networking, etc.)
• At the end, everyone should see significant “market value” increase
• Commit to helping people get to the next step in their career
• Ideally within our company but, if not always possible, even outside
• If a team member is exemplary, our networks and doors are open for
whatever is next

16. Promote From Within
• Invest in and grow leaders and managers from within our group
• Look for people already punching above their weight class
• It might not always be possible but we need to strive to always
promote from within

17. Credits: This Deck Stands on the Shoulder of Giants
And many other great organizations and people that we have been
fortunate to learn from