I was talking to someone recently who works in a product company. He told me about the transition the company is undergoing. They were building a product in EdTech for many years. The company was steadily growing for many years, but in the COVID years, the growth exploded. Of course, once the world started recovering from all the stress and lockdowns, the amount of people sitting at home and making use of newly found time to learn something started to go down too. The growth rate declined.
Unfortunately for everyone in the company, the board of directors decided to hire a new team of managers. The reason was that the company was no longer a startup but was operating like one, so the new management would need to put in place all the right processes and hopefully recover the lost growth rate. It took just one wrong person at a wrong place to completely halt any innovation in the company. Something that took days to do now takes months, because every change requires approval of six managers. It’s a death sentence, in my opinion, if they did not change this approach.
The Value of Wearing Multiple Hats
In a small company, there are no clear boundaries of what you can do. Imagine a small flower shop hiring a florist. Since the shop is small, the florist does a multitude of things (I’m making this up because I have no idea how flower shops work) — purchasing, answering client calls, handling deliveries, managing social media, and many other things. If you work in the large department store that has a flower stand, all you have to do is prepare the flower bouquets and put them on a stand, maybe also consult people to help them choose what they need. Everything else is handled by other people.
Same way, in a small tech team, everyone wears multiple hats. A business analyst writes code and designs the database from time to time. A QA engineer does a bit of project management. The product owner tests features occasionally. Developers handle some DevOps tasks. It’s inevitable for these roles to overlap in many cases. If you’re a developer building a new feature in our team, you can go and add the fields you need to the database (of course you have to be senior enough to make this decision and consult with at least one other person, but you still can).
But when we try to hire people from large companies, we sometimes see that people know very little outside their main role. There are developers who never wrote a line of SQL code because that was done by DBAs. There are QA engineers who can’t organize themselves or write test cases because they are used to just logging into the system, picking up the first ticket that is available, and just going through the steps described. Heck, we once hired a QA lead who couldn’t do any actual testing because she was working as a lead from day one — she managed people without being able to actually do the work.
The Problem with “Shallow” Employees
In a small team, you can’t be shallow. Maybe you can get away with it for a small time, but this will be brought to light sooner rather than later. What does it mean to be shallow? I’m still trying to nail down the actual description, because that’s what we are trying to screen new candidates for, but here are a few examples. Here’s how to know if someone is like that:
- Asks no questions about the job or task at hand.
- Cares about how to do less work versus bringing more value to others.
- Uses a lot of buzzwords but not actually doing anything related.
- Actions do not match words.
This is far from a full list, and I think the “asking questions” part is the most important one. Again and again, no matter the role, I can see that this really makes a difference. No matter the role, no matter if it’s an early-stage hiring interview or the person is six months into the job, the number of questions asked tells what the end result will be.
It’s the same thing in communication outside of work. Imagine you’re meeting with a friend. You sit in a nice café in summer, and you want to ask for advice. You tell your story and ask your question. If you get a ton of follow-up questions, wouldn’t it make you feel your friend deeply cares and wants to know as much as possible before advising you on something? Questions would make a difference.
I know it’s not a perfect way to know if someone is shallow or not. I think nothing will tell you for sure until you work with someone for a while. Too many questions may get quite annoying. Some people try to fake it by just generating a ton of nonsensical questions. But still, this is at least something.
Big Teams Have Their Place Too
There are a lot of things we have that wouldn’t be possible without big companies and big teams working together. We wouldn’t have anything complex without them. Apple is a huge corporation that creates complex hardware devices and software we use every day. Most of the SaaS products we use daily are created by large companies — Amazon, Netflix, Instagram, and many others. So by no means am I saying we need to go back to the Stone Age or anarchy and work only in small teams.
What I’m saying is I see this difference in people who work in small teams and companies versus those who work in big companies. And I think it’s because the company is huge, it’s easier for shallow people to pretend they work, pretend they are efficient, obey the rules and clear boundaries, and get away with it.
I’m thinking about this because our company is growing. At some point, we’ll reach the mark of 100 people, which would be a lot for us. And I’m trying to understand how to keep our team human, connected, and efficient.
One of the ways I see is splitting into a few small and independent teams where each team has its own leaders. I’ve seen this with ad agencies a while ago — never worked in one, but I had friends in a few of them. For ad agencies, creativity is vital — you can’t survive if the ads you produce do not deliver the wow effect a client and audience expects. And the way they do it is by having small independent agencies and small independent teams within each agency. Maybe this is a formula tech teams need to use as well. Maybe someone already does this, I just don’t know about it.
It’s just I don’t want to become this big inert entity where everything needs to get through multiple layers of management approval before it gets done. You probably know a few places like that, this is quite common.
Originally published on Medium.com
