We are problem solvers, sadly some of us don’t get it yet…

Thoughts on why startups can accomplish so much with few people, while big companies fail to do so.

Whether you’re Mr. big-manager or a cog, I’m assuming you’re familiar with at least one of these sayings:

• “We have a motivation problem”
• “we have an inspiration problem”
• “we have a focus problem”
• “we have a leadership problem”
• “it wasn’t in the spec”
• “QA/UX/Product/DEV/Ugly-naked-guy isn’t doing their job!“

On and on and on it goes…

The above are contributors to the fact that we aren’t proud of our products, sometimes we’re even ashamed… (ssshhhhhh don’t tell anyone), they “turn off” people, no one cares, or takes positive initiative, and when no one takes initiative, you need to do something in order to make sure things keep moving, so we create procedures and roles to make sure things are advancing (=bureaucracy), if your solution to a problem is “we need more rules and managers”, alarm bells and red lights should be ringing and flashing all over the place.

This is frustrating, harming, and clear signs of atrophy, this is not good! These are symptoms of deeper issues, I’ll try to dive into.

I acknowledge the fact that giving people more ownership and responsibility, reduces control, I’m 100% fine with this trade off, I prefer thinking, creating, initiating people over control.

I don’t believe control is sustainable, or scales well, It’s hard for me to imagine a good outcome if you optimize your organization for control.

To best understand my thoughts below, assume that Problem=Challenge.

We all solve problems using different tools and skills, but for some reason we allow our tools to define us. “I’m a developer”, No you’re not! You solve problems with code/software. “I’m a designer”, Wrong! You solve problems using visuals, color, movement, and design mindset. Same goes for writers, analysts, HR (people problems are the worst!), each have their set of tools and approaches for finding solutions. But the fact we know how to solve problems using methods from a certain domain, shouldn’t stop us from solving other problems which seem to be out of our responsibility (Domain ≠ Responsibility).

In order to ship a feature a lot has to happen, develop the thing, design it, write copy, test it, review it, make sure we can measure it, and more. The fact you did your part, “Design is ready”, or “Code is done”, doesn’t mean the product/feature is out. Since we’re trying to ship, not complete the code. This means we haven’t reached our goal yet, hence your work isn’t done. Now start looking for other things that need to be solved for this to ship, and move them forward.

We MUST internalize that we’re 100% guaranteed to face unexpected problems. it’s up to the team to solve them, and it’s what we do, we solve issues, but we have to look further than our discipline’s domain, not only below our nose. Understanding this will be a huge step forward, on a personal and organizational level.

The reason startups accomplish huge things with few people, is that everyone is solving problems beyond their role, it’s not about roles, and titles, or other imaginary boundaries.

It’s about solving all the problems that need to be solved for the product to ship, as fast as possible, and no matter what!

Had the privilege of working in teams that operated this way, and it was an absolute pleasure, I’m trying to figure out how to recreate this in every team.

It’s more than knowing what you have to accomplish, you need to think about what we’re trying to achieve as a team, the Why, the How and the What.

For this to happen you have to be engaged in your work, or it’ll be mediocre (=One or more of the following — Shit, slow, frustrating, uninspiring, and worst of all BORING!!!).

Breaking news — It’s your responsibility to make sure you’re engaged, few of us are lucky enough to have someone else do it for us. It’s up to you to figure out why you’re doing what you’re doing. In great teams, you’re expected to do this, and called out for not being engaged (in a positive manner).

I believe that changing your mindset to that of problem solving will be a leap forward, you’ll become valuable, and appreciated, and once this happens it’ll trigger a wonderful chain of events. You’ll have possibilities and options, you’ll be able to dream.

A problem solver is a person that makes things run smoother, she’s a developer who sees a design issue, and makes sure it’s addressed. He’s a designer that catches logical flaws, and discusses them with the developer.

Becoming a problem solver is hard, making it a habit is way harder, but you’ve gotta start somewhere.

My goal is to create an environment of initiative, not an hectic workplace, when I say PUSH I don’t mean work like crazy, I mean work smart, in a calm and sustainable pace. Avoid burnout! This isn’t a sprint! (pun intended).

They are many ways to achieve this, explore, adapt to your needs, and character, but make sure you’re initiating!

That’s your reality check — If you’re not initiating, examine your actions. Ask for feedback, talk to people, have a mentor, do whatever you can to solve this!

My thoughts and ideas on this subject are half-baked, I’m aiming to improve my understanding and solutions to the problem of lack of initiative, or how to create amazing teams. Would be happy to hear your thoughts, advice, and how you solve these problems yourself or in your teams. Thank you!