Delver, lessons learned
It’s been three years since I joined Delver. Three years, and three different positions in two companies (Delver and Sears Israel). There must be some lessons I can think of from this period, right?
- If you want to build a web search engine, you have to think big (and raise a lot of money). Note – lots of money does not guarantee success. This “advice” comes without any warranty. Try this at your own risk 🙂
- Do not try to replace Google as a main search engine (or a user’s homepage). This approach is probably doomed to fail. Instead, think creatively on how you can augment the Google experience.
- Dog-fooding is king. Lack of it (when building consumer products) is an alarming warning sound that should be shouted at every company meeting.
- An ideal Design Review is a meeting where you present the design, and everybody sits silently and nods (credits to Tal Kedar for this hard learned lesson).
- Sprint Retrospectives are great. They’re not always easy, and effectiveness sometimes slips in large groups, but they’re an essential component to a growing and learning organization.
- If three minutes pass and you still don’t understand what you’re doing at a meeting, find out. If you don’t find an answer that satisfies you, leave.
- Meetings should have an owner, who should come with a prepared agenda.
- Ownership is great. I encourage you to be a feature owner, domain owner, version owner, team owner. (Thanks Delver and Moti Karmona for pushing this idea to the limit)
- Feedback is vital. Don’t wait for it, create it.
- It’s your responsibility as a professional to get feedback on your performance, and act on it. Are you making your boss happy? Are you making your employees happy? Are you making the share-holders happy? What can you do to improve?
- It’s your responsibility as a product owner to get feedback on the product you’re building. Get this feedback fast, get it today, get it as often as possible. Developing features just because we think they’re cool is wrong. We are biased. We need to validate our assumptions and rinse out the false ones.
- Make sure you know the criteria for success. This applies to projects, positions, features.
- Expect that different people will have different (hidden, unaware) expectations. When in doubt, especially when working on large projects or with new people, make sure you are all synched in your expectations – if you’re not, it will hurt a lot more in the future.
- Communication is more important than code.
- Never start a data intensive project without planning for identification and fix of data corruptions. This will take longer than you expect, even if you take Hofstadter’s Law into account. Also, never get involved in a land war in Asia.
- Prefer to do full features, end to end, within the confines of one small team, instead of partitioning the design to different layers, implemented by different teams. It’s way too brittle.
- Human Resources really are useful (thanks Osnat Barak!)
- Management is hard. For me, it’s a tight balance between doing too much and doing too little. Thanks Shachar Zehavi for the chance to experience it.
- SSDs make developers happy and productive. So does freshly cut salad in the morning.
- The ability to effectively automate and remove little manual “pains” is precious.
- When a project’s internal milestones exceed their ETA by more than 30%, it’s a good time to wipe the plan clean and start again from scratch. People will tend to simply adjust the current ETAs, thus carrying over error.
- Hackathons/Code Dojos are fun! (and I haven’t even been to one yet)
- Think before you post/reply-to-all.
- You are responsible for your career. Nobody will build it for you.
I’d like to take this chance again to thank everyone I worked with at Delver. I learned from you all, and hope you also learned something from me as well. Till we meet again.
