Handbooks, customer calls, and company mission💡
Monday Ideas — Edition #135
🧑🏽💻 Packmind Tech Coach — code quality in the age of AI
A couple of weeks ago we teamed up with the guys at Packmind to discuss how code quality changes in the age of AI.
As AI tools like Copilot reshape software development, here’s how the best teams stay ahead:
✅ Define — Instantly turn team standards and decisions into actionable coding practices.
⚙️ Deploy — Seamlessly integrate your practices into every developer's IDE, like a linter on steroids.
🔍 Enforce — Ensure alignment and quality in both human and AI-generated code.
To do this, this week I am happy to promote Packmind Tech Coach, which I am a big fan of. Packmind bridges the gap with team-specific standards and real-time guidance—keeping your codebase clean and maintainable.
You can learn more about it below 👇
Back to this week’s ideas!
1) 🔭 Vision vs Mission
As a founder, I was always confused about the difference between vision and mission. Today, to understand their relationship, I believe it’s helpful to view them as part of a bigger hierarchy:
🔭 Vision — the ultimate, long-term aspiration
🏆 Mission — the current purpose and approach to contribute to the vision
🗺️ Strategy — how you plan to achieve the mission
🎯 Goals — specific, measurable milestones
A vision statement is like a North Star—a fixed point in the distance that guides your journey. It is far in the future, aspirational (and inspirational), and relatively stable over time.
It paints a picture of the world you want to contribute to. It’s not what your product does, but the impact you want it to have.
One of the best examples of vision-vs-mission relationships is 🚗 Tesla:
Vision — "The world needs / is going to transition to sustainable energy"
Mission — "To create the most compelling car company of the 21st century by driving the world's transition to electric vehicles"
The mission provides the what, and the vision supplies the why, which is broader and leaves room for evolving the mission in the future.
Counterintuitively, I believe it is easier in most situations to come up with the mission first. Missions are still broad, multi-year initiatives, and chances are you already have one in mind for your company. Then, to craft your vision, you may ask yourself a few questions:
Why do I want to achieve our mission?
What is our mission’s impact on the world?
Why does such impact matter?
I wrote more about vision, mission, and how to craft them, in this recent piece 👇
2) 📖 What goes in an Engineering Handbook?
A couple of months ago we ran a Mastermind session about Engineering Handbooks. One of the most debated topics was: what goes in there?
There is no one-size-fits-all structure, but these are sections you might consider:
🔭 Company vision & mission — this sets the tone for everything else. We discussed it in this recent piece.
🏦 Domain knowledge — if your business operates in a space that requires specific domain knowledge (e.g. finance), you may have a section that teaches the basics.
🌟 Engineering principles — they answer the "why" behind your engineering practices. It’s the set of your shared engineering beliefs, that guide how decisions should be made. More about them here.
🔄 Dev process — how do you build and ship software? This covers your SDLC, from planning to deployment.
🔧 Tech guidelines — your coding standards, design principles, and best practices. Aren’t these the same thing as the engineering principles? Not exactly: principles are cultural stances, e.g. “fix problems even when they are not yours”, guidelines are tactical rules, e.g. linting and naming conventions.
🤝 Team collaboration — How do engineers work together? This includes meeting structures, stakeholders, pairing, and everything around ceremonies.
🎒 Onboarding — how new engineers get up to speed. There might be specific docs about your first week, how to set up your dev environment, etc.
🌱 Career Growth — how team members can grow their careers. This includes career frameworks, reviews, promotion cycles, and HR stuff.
Again, you shouldn’t probably create all of this: for some companies, domain knowledge is irrelevant. For small teams, career growth is just a few lines. And so on. Consider this as a checklist that you can go through and take inspiration from.
All in all, your handbook's structure should serve your team's needs. It is more important for it to be clear and useful than to be comprehensive. So, don't be afraid to experiment : the best structure is the one that your team actually uses.
You can find our full piece about it here 👇
3) 📞 The Four Forces of Customer Calls
One of the most common advice for startups and product teams is to talk with customers, all the time. And that’s not just for founders or PMs — also engineers often benefit from joining these calls.
But what should you ask to customers, exactly? Last month we explored this with master interviewer Enzo Avigo, who told me about the four forces that influence a customer who is considering a new product:
➡️ Push — negative aspects of the current situation that motivate the customer to change. Learn everything you can about what’s driving your interviewee to do things differently.
⬅️ Pull — the perceived benefits of switching to the new solution. Enzo’s product, June, is about tracking metrics, but “an easier way to track user metrics” is not enough information. He wants to know which metrics the user is interested in. Does “easier” mean more third-party integrations? Reporting templates? Automatic enrichment? Always ask for more detail.
🗯️ Anxiety — worries that exert force on the customer’s eventual decision. These inspire questions about what the customer is concerned about. You might want to investigate what they’re still confused by or uncertain of. Find out how these anxieties delay the decision to pay for a new product or hasten the decision to leave an existing one.
🐌 Inertia — lastly, there are a wealth of potential questions surrounding the customer’s current habits. How attached are they to current routines and workflows? How does your app impact or change those practices? Can you get a step-by-step walkthrough of their rituals? These are all essential to understanding how well your product would fit into their existing patterns.
So, if you come away from a customer interview without any new ideas or inspiration, your questions likely weren’t precise enough. Go back and watch or listen to the call recording, writing down new versions of them that would have yielded better responses. And, while you’re at it, pay attention to non-verbal cues.
You can find Enzo’s full masterclass on interviewing customers below 👇
And that’s it for today! If you are finding this newsletter valuable, consider doing any of these:
1) 🔒 Subscribe to the full version — if you aren’t already, consider becoming a paid subscriber. 1500+ engineers and managers have joined already! Learn more about the benefits of the paid plan here.
2) 🍻 Read with your friends — Refactoring lives thanks to word of mouth. Share the article with your with someone who would like it, and get a free membership through the new referral program.
I wish you a great week! ☀️
Luca