Mohamed Y. KHALID’s Post

Non-technical founders always have this problem: If you are looking to assemble your own technical team, Although you are not technical, it’s possible for you to be the founder and head of a technical product. 3 things to know before assembling your own technical team: 1. You need to bring in a strong technical presence, or maybe learn to be one yourself. This is definitely needed. You need someone who is mature enough to assemble the best talents for you if you don’t have the time and resources to do that yourself. Your job is now left to just find that presence, and sort of, everything will add up so easily. 2. Get people who are product-driven and experienced in product development. Product-driven, meaning they care more about the product being complete and working well than they care about using the latest technology. They are also mature in product development in the sense that they don’t get you into unnecessary technical debt, for example. 3. Lastly, get someone who doesn’t crack under pressure. What I mean by that is: -You will have stakeholders -You will have product and feature requests -Customer feedback You need someone on the technical side to go; no, this is not possible. No, this is going to branch out the product so much. Someone who can make the right decisions on where to move technically when under pressure. How you build your product is as important as how you market it.

Ever found yourself stuck between detailed specs and the challenge of ensuring every aspect gets covered during development? Complex features often translate into lengthy specs. Despite our best efforts, there is always a chance that crucial details slip through the cracks, leading to misaligned expectations down the road. Engineers, eager to dive into solutions, might overlook nuances in their haste to deliver. Here is an interesting idea: instead of bombarding the team with lengthy specs, why not leverage the power of video? By breaking down specs into bite-sized clips, each spanning 2-3 minutes, we empower our developers to focus on what matters most. They can cherry-pick the areas they need clarification on, fostering a deeper understanding and reducing the risk of missed requirements. While we can't always control what happens, we can certainly control how we respond to it. ✨ So, why not give this approach a shot for your next feature? I would love to hear your thoughts and experiences!

We all enjoy highly effective engineering teams. A few things can create them -> 1. Self-organizing 2. Foster trust 3. Recognize individual strengths 4. Have an environment where everyone feels valued 5. Members can contribute their unique talents But wait... Even in "flat" teams, we can encounter the "ego-developer"—those who, as Jocko Willink puts it, are "tortured geniuses" (not the musician kind). But that's okay—because there is room for growth! Here is the Alternative - Switch the mindset -> highly skilled developers understand collaboration. They value diverse perspectives, mentor teammates, and heighten everyone's skills. When the team improves, the software is delivered faster, less error-prone, and more maintainable. Remember: "If you want to go fast, go alone – if you want to go far, go together." Embrace the Unusual Developer mindset and build a high-performing. So, what makes your team great?

No matter how important an objective is for your company, you can’t suddenly assign a thousand engineers to work on it using systems built for 10 engineers and still expect results. In recent years, we've seen tech companies often invest 30% or more of their engineers in platform teams, intending to allow product engineers to move faster. I find this trend interesting and a clear indicator of where our industry is heading. However, simply increasing the number of engineers in platform teams won’t automatically solve the scaling challenges. You still have to build the right tools, processes, and culture that enable those teams to drive efficiency and innovation across the organization. Without a holistic approach and a product mindset applied to platform engineering, companies are essentially throwing money into a black hole, hoping for results that may never come. My experience at Thinkific shows that when we align platform investments with company priorities, create specialized teams, and build a strong platform engineering culture rooted in high agency, extreme ownership and continuous improvement, incredible things happen. You enable faster shipping, fewer bugs and outages, and most importantly, a resilient, scalable infrastructure that adapts as your business evolves. Start early and treat platform investments as an ongoing priority. This will set your teams up for long-term success, allowing them to focus on delivering value rather than battling technical debt and inefficiencies.

𝗖𝗼𝗻𝗾𝘂𝗲𝗿𝗶𝗻𝗴 𝗧𝗲𝗰𝗵𝗻𝗶𝗰𝗮𝗹 𝗗𝗲𝗯𝘁! Are you feeling the drag of technical debt slowing down your team's progress? It's time to break free from the shackles of outdated systems and processes! 💡 "Struggling to add a new window? Let's face it, technical debt shouldn't be the reason why even the simplest tasks take forever." It's easy to get bogged down by the blame game, but that won't solve anything. Instead, let's focus on empowering our teams to tackle technical debt head-on and pave the way for smoother, faster, and more cost-effective development. 💪 "Stop pointing fingers and start empowering your team to slay the technical debt monster!" By prioritizing debt reduction and embracing modern development practices, we not only improve efficiency but also create a culture of innovation and agility. 🔔 𝗥𝗲𝗽𝗼𝘀𝘁 ♻️ and share the wealth of knowledge with your fellow product warriors. Follow Rahul Rawat for more product management insights and resources. Let's build amazing products together! 💪🚀 #technicaldebt #productmanagement

I had a interesting conversation with the CTO of a processor company about how to keep development teams moving fast. And one thing he mentioned that I agree with is that development teams need at least 4-6 weeks of backlog. It keeps velocity high and development teams aren't waiting for work. "We see the magic happen when the team has four to six weeks of work out in front of them that's planned and understood by the team." It's not always the easiest thing to do, but if you value your engineering team, letting them peak ahead can help solve many issues before development of those features start.

From the "I don't think this is a great idea" department. Let's talk about the trend of a CPTO role. (Chief Product and Technology Officer). Technology executives in both engineering and product already have pretty broad responsibility. For product, accountabilities for a CPO might include: - Cultivating your product team - Being out in the market learning what customers need (finding whitespace) - Ensuring there's alignment internally around what needs to be built - Ensuring designers and developers have what they need to build it For your average CTO, accountabilities might include: - Cultivating your engineering team - Developing technology strategy - Ensuring what you're building is secure, scalable, and up to date with what technology available - Finding and managing relationships with integration partners In programming, we have the guiding idea of the Single Responsibility Principle: your abstractions should do one thing well, and only one thing. So, looking at these accountabilities through that lens, I think it's incredibly audacious for one executive to do all of these things well. What's also often missed in this consideration is healthy tension. A CTO and a CPO have to weigh tradeoffs together and make difficult product decisions, with product representing the perspective of the customer, and the CTO representing what's feasible technologically. With one executive weighing these tradeoffs, there's all kinds of opportunity for bias and slioed thinking. For these types of critical decisions, wouldn't it be better to have two executive team members hashing it out, and to have both perspectives represented on your leadership team? I'd always recommend to a client that they optimize for product first. After all, without solving a problem for a customer, you don't have a business. So if you're considering a CPTO seat, also consider the possibility of having a CTO or a VP of Engineering report into product. Or, if you don't have a CTO, partner with a fractional or agency to advise and hash out the difficult technical tradeoffs with your CPO (shoot me a message if you need help like this). The two (often somewhat polarized) perspectives are strategically important. Do you have a CPTO on your team? Let me know in the comments how it's working out. I'm always interested in these org chart considerations.

Want you dev team to move faster? DEFINE² the MVP¹ then ACCEPT the MVP. Then schedule time to redo the have together minimums. It'll take time for your team to trust you, but this is mandatory if you want to increase product velocity. Engineers have learned that when the business says MVP they want perfect results on hacked-together timelines. Engineers have learned that the business has no interest in fixing the hacks and workarounds that went into moving quickly to build that MVP. Engineers have learned that they'll get blamed for issues that come from running an MVP long term AND they'll get blamed for missing deadlines. Engineers have learned that the deadline pain happens once while the broken MVP pain is eternal. ¹ Minimum Viable Product ² Must be 100% objective, include a deadline, and be complete.

Hey, do you feel like your company is just shipping things, and you're curious why they are shipping it? Usually, there's some really valid reasons, but maybe you're disconnected from the context. Many times, however, it's unclear why we're shipping a feature and what validation was done. It takes ALL of us to help push our organizations to move quickly, but also FOCUS. Check out some advice my colleagues at Test Double came up with to help: https://lnkd.in/eJvgfYcD

Trying to do more with less? Reject the myth that more developers = faster delivery. It's one of the most misleading beliefs in our industry. Overstaffing can actually slow down your engineering team: ❌ More communication complexity ❌ Unnecessary or redundant features ❌ Complexity that adds little value to the end product (and costs more to maintain) You can achieve more with less through simpler processes, clearer communication, and fewer cross-team dependencies. Smaller teams = speed-to-value and agility. Do add effective product management. Without it, it’s common to find teams mired in inefficient processes that hinder productivity and innovation.