Engineering Team Management Skills

Scaling from 50 to 100 employees almost killed our company. Until we discovered a simple org structure that unlocked $100M+ in annual revenue. In my 10+ years of experience as a founder, one of the biggest challenges I faced in scaling was bridging the organizational gap between startup and enterprise. We hit that wall at around 100~ employees. What worked beautifully with a small team suddenly became our biggest obstacle to growth. The problem was our functional org structure: Engineers reporting to engineering, product to product, business to business. This created a complex dependency web: • Planning took weeks • No clear ownership  • Business threw Jira tickets over the fence and prayed for them to get completed • Engineers didn’t understand priorities and worked on problems that didn’t align with customer needs That was when I studied Amazon's Single-Threaded Owner (STO) model, in which dedicated GMs run independent business units with their own cross-functional teams and manage P&L It looked great for Amazon's scale but felt impossible for growing companies like ours. These 2 critical barriers made it impractical for our scale: 1. Engineering Squad Requirements: True STO demands complete engineering teams (including managers) reporting to a single owner. At our size, we couldn't justify full engineering squads for each business unit. To make it work, we would have to quadruple our engineering headcount. 2. P&L Owner Complexity: STO leaders need unicorn-level skills: deep business acumen and P&L management experience. Not only are these leaders rare and expensive, but requiring all these skills in one person would have limited our talent pool and slowed our ability to launch new initiatives. What we needed was a model that captured STO's focus and accountability but worked for our size and growth needs. That's when we created Mission-Aligned Teams (MATs), a hybrid model that changed our execution (for good) Key principles: • Each team owns a specific mission (e.g., improving customer service, optimizing payment flow) • Teams are cross-functional and self-sufficient,  • Leaders can be anyone (engineer, PM, marketer) who's good at execution • People still report functionally for career development • Leaders focus on execution, not people management The results exceeded our highest expectations: New MAT leads launched new products, each generating $5-10M in revenue within a year with under 10 person teams. Planning became streamlined. Ownership became clear. But it's NOT for everyone (like STO wasn’t for us) If you're under 50 people, the overhead probably isn't worth it. If you're Amazon-scale, pure STO might be better. MAT works best in the messy middle: when you're too big for everyone to be in one room but too small for a full enterprise structure. image courtesy of Manu Cornet ------ If you liked this, follow me Henry Shi as I share insights from my journey of building and scaling a  $1B/year business.

As Duarte grew, I’d hear feedback that decisions were made too slowly, which confused me. In reality, we didn’t have a system to recognize when the team was asking for a decision. We thought they were just informing us, so decisions would languish. We weren’t ignoring them, failing to act, or even making incorrect decisions... We just didn’t realize a decision needed to be made in the first place. It dawned on the exec team that the lack of clarity during the conversation is what slows teams down. Leaders and teams can share the same language for decision-making. Much of it is about shaping recommendations that actually lead to the right type of action and making the urgency clear. Here’s the shift that changed everything… We started mapping every decision against two factors: urgency and risk. Low risk, low urgency: Decide without me. Your team runs with it. Low risk, high urgency: Inform on progress. They update you, but keep driving. High risk, low urgency: Propose for approval. They bring a recommendation, and you decide together. High risk, high urgency: Escalate immediately. You're in it together, right now. Once my team understood which quadrant a decision lived in, they knew exactly how to approach me. And I knew exactly what my role was. The framework gave us a shared language. People can’t act on ideas if they don’t understand how decisions are made. Leaders should define how recommendations move from idea to approval to action. That transparency keeps progress from stalling. Remember: One of the biggest threats to your company isn't a lack of good ideas. It's a lack of clarity. #Leadership #ExecutiveLeadership #OrganizationalCulture #DecisionMaking

If your one-on-ones are primarily status updates, you're missing a massive opportunity to build trust, develop talent, and drive real results. After working with countless leadership teams across industries, I've found that the most effective managers approach 1:1s with a fundamentally different mindset... They see these meetings as investments in people, not project tracking sessions. Great 1:1s focus on these three elements: 1. Support: Create space for authentic conversations about challenges, both professional and personal. When people feel safe discussing real obstacles, you can actually help remove them. Questions to try: "What's currently making your job harder than it needs to be?" "Where could you use more support from me?" 2. Growth: Use 1:1s to understand aspirations and build development paths. People who see a future with your team invest more deeply in the present. Questions to explore: "What skills would you like to develop in the next six months?" "What parts of your role energize you most?" 3. Alignment: Help team members connect their daily work to larger purpose and meaning. People work harder when they understand the "why" behind tasks. Questions that create alignment: "How clear is the connection between your work and our team's priorities?" "What part of our mission resonates most with you personally?" By focusing less on immediate work outputs and more on the human doing the work, you'll actually see better performance, retention, and results. Check out my newsletter for more insights here: https://lnkd.in/ei_uQjju #executiverecruiter #eliterecruiter #jobmarket2025 #profoliosai #resume #jobstrategy #leadershipdevelopment #teammanagement

Delegation isn't just about freeing up your time. It's about helping your team grow. The best leaders understand this. They know that: 🎯 Every task is a teaching moment 🎯 Every project builds confidence 🎯 Every handoff grows capability But here's the key: it must be done right. Let me share some frameworks to delegate effectively: 1. The Control Spectrum There's a spectrum from "complete control"  to "full autonomy." → Tell: You decide and inform → Sell: You decide but explain why → Consult: You get input but decide → Agree: Decide together → Advise: They decide with your guidance → Inquire: They own it, you stay informed → Delegate: Full ownership transfer 2. The RACI Blueprint Smart delegation isn't just about "who does what."  It's about clarity in four key areas: → Responsible: Who does the work → Accountable: Who owns the outcome → Consulted: Who provides input → Informed: Who needs updates 3. The Leadership Truth Real delegation is about moving from: → Doing the work → To managing the work → To developing other leaders This is how you scale yourself and your impact. 4. The Game-Changing Habits → Be clear about expectations → Match people to tasks based on potential → Provide context, not just instructions → Set checkpoints without micromanaging → Stay available without hovering → Recognize effort and coach for growth The real power of delegation? It's not about having less on your plate. It's about putting more on others' resumes. Start with opportunities, not just tasks. Because true leadership isn't measured by what you accomplish alone. It's measured by who you help grow. ♻️Find this helpful? Repost for your network. Follow Amy Gibson for practical leadership tips.

The quickest way to create project charters: [after creating 25+ charters in the last 3 years] I view the project initiation as a compass, not just a formality. Then, I begin with the end in mind. This method: -Aligns stakeholders -Sets clear objectives -Maps out project boundaries -Identifies potential risks -Establishes authority and accountability Here's each step of my charter creation: 1. Objective Define the core purpose: -Why is this project essential? -What business problem does it address? -Articulate the expected outcome: -Desired end state after project completion -Key performance indicators to measure 2. Scope Detail out project boundaries: -Inclusions: What's part of the project? -Exclusions: What's out of scope? Establish the deliverables: -Tangible outputs -Milestones to reach -Stakeholders Identify key players: -Who will benefit from this project? -Who has influence over its outcome? 3. Outline roles and responsibilities: -Who’s doing what? -Who holds which authority? 4. Risks & Assumptions Highlight potential pitfalls: -What might derail the project? -Assumptions made and their validation Plan for contingencies: -Risk mitigation strategies -Backup plans 5. Resources Allocate essentials: -Budgetary constraints -Required tools and technology -Team members and their skillsets 6. Timeline Breakdown of project lifecycle: -Start and end dates -Major phase completion dates -Dependencies between tasks 7. Communication Define the communication plan: -Who gets updated and when? -Preferred communication channels 8. Approval Establish authority: -Who signs off on project decisions? -Acceptance criteria for deliverables Outline the revision process: -Feedback loop -Change request protocol 9. Documentation & Archiving Detail out the documentation process: -Where are project files stored? -How to access historical data Establish a post-project review plan: -Lessons learned -Feedback collection -Continuous improvement Follow this charter framework to kick-start your projects with clarity and purpose. What are your project charter best practices?  Leave a reply in the comment section.

As a client project manager, I consistently found that offshore software development teams from major providers like Infosys, Accenture, IBM, and others delivered software that failed 1/3rd of our UAT tests after the provider's independent dedicated QA teams passed it. And when we got a fix back, it failed at the same rate, meaning some features cycled through Dev/QA/UAT ten times before they worked. I got to know some of the onshore technical leaders from these companies well enough for them to tell me confidentially that we were getting such poor quality because the offshore teams were full of junior developers who didn't know what they were doing and didn't use any modern software engineering practices like Test Driven Development. And their dedicated QA teams couldn't prevent these quality issues because they were full of junior testers who didn't know what they were doing, didn't automate tests and were ordered to test and pass everything quickly to avoid falling behind schedule. So, poor quality development and QA practices were built into the system development process, and independent QA teams didn't fix it. Independent dedicated QA teams are an outdated and costly approach to quality. It's like a car factory that consistently produces defect-ridden vehicles only to disassemble and fix them later. Instead of testing and fixing features at the end, we should build quality into the process from the start. Modern engineering teams do this by working in cross-functional teams. Teams that use test-driven development approaches to define testable requirements and continuously review, test, and integrate their work. This allows them to catch and address issues early, resulting in faster, more efficient, and higher-quality development. In modern engineering teams, QA specialists are quality champions. Their expertise strengthens the team’s ability to build robust systems, ensuring quality is integral to how the product is built from the outset. The old model, where testing is done after development, belongs in the past. Today, quality is everyone’s responsibility—not through role dilution but through shared accountability, collaboration, and modern engineering practices.

I've watched so many hours wasted because nobody talked about the basics upfront. A few years ago, I made the mistake of assuming everyone had the same idea of what "done" meant. By the time we found out, we had done three iterations, with much frustration on all sides. That's when I saw the value of using team charters. It’s like a relationship contract for your work team. You sit down together and hash out the stuff that usually stays unspoken: What are we actually trying to accomplish here?  How do we like to communicate?  What drives us crazy?  What does good work look like to us? The beauty of that isn't in the document itself. It’s more in the conversations you have creating it.  Suddenly everyone's speaking the same language. One of the best parts?  When someone new joins, they get the playbook.  Instead of trying to decode unwritten rules for six months. And the charter isn't set in stone. We update it when things change. Since none of us are perfect at team communication, we need tools like charters to help us get aligned. When was the last time your team had an honest conversation about how you want to work together?

In today’s rapidly evolving global economy, one truth remains constant: skilled workers are the backbone of progress. Whether it's a technician maintaining the integrity of a factory line, a software developer writing secure code, or a health technician ensuring patient safety, skilled workers translate vision into reality. Yet, despite their importance, the conversation around them is often overshadowed by flashy innovation headlines or executive-level discourse. Why Skilled Workers Matter More Than Ever As automation and AI become more integrated into our daily workflows, the demand isn’t just for workers—but for highly capable, adaptable professionals who can bridge the gap between technology and execution. Countries that invest in vocational education and workforce development—like Germany and Singapore—continue to outperform in manufacturing, infrastructure, and advanced services. It's not just about creating jobs; it's about future-proofing industries. What Organizations Should Do Invest in Upskilling – The half-life of skills is shrinking. A one-time training model no longer works. Ongoing learning must be embedded into organizational culture. Too often, skilled roles are seen as “lesser” than white-collar jobs. This mindset is not only outdated, it’s harmful. Recognition and respect lead to retention. There’s a disconnect between what’s taught and what’s needed. Stronger partnerships between industry and education can realign training with real-world demand. If you're a leader, ask yourself: Are you investing in the people who build, maintain, and improve your core operations? If you’re in HR or talent development, are skilled workers represented in your strategy? And if you're in a skilled profession—know this: the economy doesn't move without you. Let’s stop calling them the “middle” and start recognizing them as central. #emotionalintelligence #jobseekers #hiring #business #management #training

📌 How to do Prioritization as a Product Manager. Product Managers face a problem of plenty. You have so many things to do, many problems, many solutions, and many suggestions, but are always limited by time, bandwidth, and resources. Now you need to obsessively prioritize and filter ideas before you put them in the roadmap. But how do you prioritize? The simplest yet most powerful framework that most PMs rely on is the Impact v/s Effort Framework. The impact is determined by: - Potential revenue estimate, - Customer value, - Alignment with company goals, - Demand from the market, or - Any other relevant metrics that align with product goals. Impact estimation is mostly the responsibility of the product manager. The effort is determined by: - Development complexity, - Engineering efforts, - The time required & cost, - Operations complexity, etc. Effort estimation is mostly done by the delivery teams like engineers, design, ops, etc. This is a collaborative exercise. The next step is to visualize this through an impact v/s effort matrix. Provided that the estimations are done correctly, the low efforts & high impact items are picked at the earliest, & other things are prioritized in a logical order. 📌 3 Tips to take your prioritization game to the next level: 1. Consider tradeoffs at every step: Some high efforts ideas could be of high strategic importance, similarly some low-impact ideas could be critical for customer experience. Understand the situation from all angles. 2. Look out for red flags: All ideas look high impact, or the backlog is completely filled with low effort low impact ideas. This indicates either the PM is not competent at impact estimation or is not considering enough ideas during product discovery before deciding on the best one. 3. Validate high-effort ideas by first converting them into low efforts experiments. For example: Rather than converting your whole website into all Indian languages, try to convert the most popular pages into 3 popular languages, observe the results and then decide to roll back or go all in. 📌 Other frameworks for prioritization: There will be times when you'll need more detailed frameworks to prioritize, some of the other helpful frameworks are: 1. KANO: Puts customer satisfaction at the center and distinguishes between basic expectations, performance attributes, and delighters. 2. MOSCOW: categorizes requirements into four priority levels: Must have, Should have, Could have, and Won't have. 3. RICE: adds to more dimensions of Reach and Confidence to make Impact v/s Effort more reliable and exhaustive. ✨ Prioritization is a supercritical and useful skill for product managers, during their work, stakeholder management, and also during interviews. Do you think this would be helpful for you? I share helpful insights for product managers almost every day, consider connecting here 👉🏽 Ankit Shukla to not miss out. #productmanagement #prioritization

As Product Managers it’s so easy to loose trust if features on the roadmap are not prioritised correctly. Here are 5 prioritization frameworks and when to actually use them: 1. RICE (Reach, Impact, Confidence, Effort) ✅ Use when: You have multiple ideas/features and want to prioritize based on expected impact. 📌 Best for: Growth experiments, new features, MVP ideas 💡Tip: Confidence % is often biased calibrate with data! 2. MoSCoW (Must have, Should have, Could have, Won’t have) ✅ Use when: You’re working with tight deadlines and multiple stakeholders. 📌 Best for: Sprint planning, product launches 💡Tip: Don’t let every stakeholder label everything as “Must have.” 3. Kano Model ✅ Use when: You want to balance delight with functionality. 📌 Best for: Customer-facing products 💡Tip: A feature that delights today might be expected tomorrow. 4. ICE (Impact, Confidence, Ease) ✅ Use when: You want a quicker version of RICE for fast decision-making. 📌 Best for: Rapid prototyping, early-stage prioritization 💡Tip: Use ICE when you don’t have a ton of data but still need to move. 5. Value vs. Effort Matrix ✅ Use when: You want to visualize trade-offs with stakeholders. 📌 Best for: Roadmap discussions, stakeholder alignment 💡Tip: Plot features on a 2×2: * Quick Wins (High value, low effort) * Strategic Bets (High value, high effort) * Time Wasters (Low value, high effort) * Fillers (Low value, low effort) So which one should you pick? Use RICE when you’re in a data-driven company. Use MoSCoW when time is tight and alignment is tough. Use ICE when you need speed > accuracy. Use Kano when delight matters. Use the Value/Effort Matrix when people keep asking, “Why this first?” 📌 Save this for your next prioritization war. 💬 Tried any of these at work? Drop your go-to framework in comments! #productmanager #job #PMjobs #learning #frameworks