Scaling Your Team with Problem-Solving Frameworks, Not Superstars

What is a problem-solving framework?

A problem-solving framework is a checklist of questions that help you break down a problem and figure out how to solve it. It's like a step-by-step guide to understanding the issue, brainstorming solutions, picking the best one, and then implementing that solution.

As software engineers, our day-to-day tasks are mostly problem-solving. Given a problem, we find the solution. We gather a lot of skills and practice, and time after time, we become proficient with it. We automatically follow some frameworks but don't realize it.

One of the challenges of an organization is not to depend on the key person, that person who has gathered a lot of knowledge and practice. He can resolve the problem easily; he's a superhero, a firefighter. But if he leaves the company, all of that is lost.

Documentation won't help much; it will be outdated and no one will look at it.

IMO, I think we should focus on building the process, not the key person.

A well-defined process can help the newcomer go through a checklist with only the basic, fundamental knowledge about the system. In case of an emergency, a team member without experience can try the process for the first time, it works for them and if anything is missing from their perspective they can add it to the process.

To be more specific, we call the process a framework. The framework is opinionated by the creator. A place where we can see how the top performers work, extract their methodologies, turn them into a process, and make the excellent a standard for everyone.

Example: Framework to Investigate a Bug

If we have a bug report that something went wrong in the last 3 months, what should we do?

1. Understand the problem, and read the problem statement at least twice to ensure the reported issue is correct

2. If the resolver lacks knowledge, find the help page, find the document, or consult another team member to understand how it works

3. Define the clear expectation

4. Dig into the log, understand why the system doesn't work as expected

5. Dig into the code, read it, and find the wrong logic

6. If the code looks right, maybe it has changed during the last 3 months but gets reverted. Let's check the git logs.

7. Find the ticket related to the code changes to find out what we expected at that time

8. Find the Slack message around that day to discover what is the decision making that didn't write to the ticket properly.

Framework to Implement a New Feature

1. Understand the requirement, and read the problem statement at least twice to ensure the reported issue is correct

2. Define the acceptance criteria

3. Look at the design (if any) twice, and notice all the details missing in the requirement

4. Ask the ticket creator all the questions to clarify the requirement until you make sure all the detail is covered

5. Now work on the code base, and the system design to find the solution

6. Write a solution for preview, maybe a list of bullet points, a diagram, or a document on how you resolve the problem

7. Consult the team members, get an agreement on the proposed solution

8. Go to coding, write the test first if your team follows TDD

9. Submit PR, ask your team for review

10. Resolve feedback, the rest is your normal deployment process...

So, where do we go from here?

Implementing problem-solving frameworks isn't just about following a checklist – it's about fostering a culture of shared knowledge and continuous improvement.

Picture this: a team where every member, regardless of experience level, can confidently tackle complex issues. A workplace where knowledge isn't siloed but flows freely, captured in living, breathing frameworks that evolve with each challenge overcome.

This isn't just a pipe dream – it's a reality we can build, one framework at a time.

Here's my challenge to you:

1. Start small: Pick one recurring problem in your team. It could be bug investigation, feature implementation, or even code review.

2. Document your process: Next time you tackle this problem, jot down each step you take. Be specific – what worked? What didn't?

3. Refine and share: Discuss your nascent framework with your team. Gather their insights, refine the steps, and create a shared resource.

4. Iterate and improve: As your team uses the framework, encourage feedback. Let it evolve based on real-world application.

Remember, the goal isn't perfection – it's progress. By taking these steps, you're not just solving today's problems; you're building a foundation for tackling tomorrow's challenges.

I'd love to hear about your experiences. Have you used problem-solving frameworks in your work? What hurdles did you face? What unexpected benefits did you discover? Drop your thoughts in the comments below – let's learn from each other and elevate our craft together.