In the early days of a startup, especially a tech one, it isn’t rare for pretty much everyone on the team to have some sort of engineering background. You know the story, girls and guys get together and make an app. Then one of them is chosen as the CEO (usually the one who talks the most and owns a nice pair of shoes). Something like that happened here at Koofr as well.
Being tech-savvy is great at the beginning, since everyone is doing everything. But as the story unfolds, CEO starts to fade away from code, servers and hacking to focus on customers, sales, UX, management and whatnot. And as it turns out, the less details you know about the technologies being used inside your product, better you can be at your job.
I’m not saying you should immediately forget everything you know about MongoDB, Python and Java, but rather start employing the good old “Ignorance is bliss.” when appropriate.
I’m sure many of you will not agree with me, but I’m more and more convinced. Since I’ve stopped desiring to know about every piece of technology and software used by our developers, I’ve become much better at managing the team. I had to come to this conclusion myself, and thinking about it, even if someone would have explained it to me 2 years ago, I probably wouldn’t have listened.
And these are the most common excuses that we use, to keep nosing into developer’s work:
I can’t sell if I don’t know everything
That’s wrong on so many levels, but mostly, because you’re not actually selling the technologies are you?
You’re selling your vision, your story, your solution to the problem.
It’s actually much easier to receive and acknowledge feedback from customers, when you’re not biased with the limitations of your database. If the market wants something changed, it’s your job to discover that and someone elses job to go and make the right technical adjustments.
I can’t help users if I don’t know everything
Your users probably shouldn’t need to be programmers to use your product (unless you’re building a framework or an API or something like that). So if they don’t need to understand the internals to use your product, why should you?
Solving their problems usually means fixing UX or explaining something in your FAQ. That’s it. And when the questions get really technical, I’m sure you have a ticketing system to pass it down the pipeline anyway.
I can’t assign tasks if I don’t know everything
This is the one that bothered me the most. Turns out, I was just trying to micromanage. Yes, I should be assigning tasks, but someone else (CTO) should take care of the details. Instead of trying to learn about correlation between increased index size and reduced write speed, you should be out getting customers.
I can’t help them fix stuff if I don’t know everything
That’s right, you can’t. And you shouldn’t. Trust me, I’ve tried it once. They’re still angry at me after one year, for having to work around my hacks.
So as you see, there really isn’t a good reason for you still going through every line of code or having access to every server in the company.
Don’t get me wrong, I’m not saying you should be completely ignorant and oblivious to the inner workings of what you’re selling. You should still have a good overview and at least so much knowledge, that you don’t look foolish in front of investors. But focus on what others on your team expect from you and that is not fixing the code.
After two years, I would recommend everyone in a similar position, to take a step back, trust your team (that’s why you‘ve hired the best anyway) and don’t question every technical decision. If everyone is aware of their responsibilities and the choices they have to make and defend, work will run smoother. Don’t worry, engineers will make the magic happen for you. You just get the money for their salaries.
If you enjoyed this or share similar thoughts, please share it and press “recommend” below. You will have my eternal gratitude.
