Hey, it’s Alvin!
One day, back when I was still a junior software developer, I found myself at a meeting table. My boss (let’s call him, “Bob”) was up at the front of the conference room, laying out a plan for the team. He found a new client who owned a restaurant and promised them we’d build an entire software system for them.
We were to build a mobile app that allowed customers to order food. The orders would be sent to the kitchen management app for the cooks. While another app would allow servers to manage tables and bills, and process payments on point-of-sale machines. Back then, this was leading edge restaurant management technology.
Bob assigned the entire mobile app part to me. Up to then, I only had about 6 months experience developing simple web pages and about one year of backend development. I knew nothing about building a native mobile app, which I discovered required a completely different design approach.
Bob also insisted on a Windows-based app even though Android was a far more popular mobile operating system back then. The bigger problem was that developing a native Windows app back in the day required a computer with a version of Windows the company didn’t even have yet.
Not to worry, we had four months to get it all done.
Scratch that, we had TWO months to get it done. You see, the client asked to see something in four months, but Bob insisted we’re better than that—he told the client we could do it in two months instead.
No, he didn’t consult the team before doing that.
Keep in mind, we’re not talking about two full months of coding. My Windows computer wasn’t ready until two weeks in. And the testers needed two weeks of testing before the software could roll out. What I really had was…
four weeks to build a fully functional, professional looking mobile native app from scratch
… with tools I never used before
… to make a solution…
For pretty menus with photos of foods to be synchronized from a central server,
For patrons to add items to their order, and
For customers to submit their order to be sent to the kitchen
I didn’t know where to begin with any of that.
And I wasn’t going to get any help. Of the six people on the team, I was just one of two developers. The other (senior) developer was way too busy with all the other stuff I mentioned.
It would be like asking someone with no construction experience to build a fully functional, move-in ready 3000 square foot two-storey house in two months.
Don’t worry, I ordered your tools from the hardware store. You’ll get them in two weeks.
To this day, I contend Bob’s demands were unreasonable. But I was so inexperienced, I didn’t know how to push back. And the rest of the team didn’t have the courage to push back.
Or they felt it was pointless because Bob had a lot of power in the organization and his approach was authoritarian. You did what you were told by the deadline you were given. No debates. No discussions. And there were times he would threaten to cancel an entire project and layoff the team if the team didn’t comply.
Bob used to be a software developer, but he hadn’t coded for over 20 years. By the time I worked for him, it was like he had no technical experience at all. His favourite expression was, “it’s not rocket science,” routinely underestimating the effort needed to build new features. Because a job looks easier when you’re not the one doing it.
That’s the fundamental problem with a non-technical boss running a technical team: they don’t understand what the team needs to succeed. But part of that role IS to get the resources the team needs to do their jobs well.
Of course, the boss probably can’t give everything the team asks for; you have to spend wisely. So, the boss has to be able to prioritize the team’s asks—whether it’s equipment, people, or just time. And the best way to know the importance of an ask is to have had recent experience doing the job.
If the technical team doesn’t get what they need to get the job done because the boss doesn’t understand their needs or underestimates effort, then the project is doomed to fail. There are many projects that fail for that reason.
If you find yourself in a similar situation with this kind of boss, you can just do the best you can and whatever happens, happens. You’re probably better off looking for another job no matter what. Because if your boss can’t support you, you won’t grow in your role. You might also pick up bad habits cutting corners to meet deadlines. It’s all bad for you and your career.
With more work experience, I would try to break down the project into tasks. Then, I’d set the tasks to a project timeline and discuss the numbers with my boss to see if we can work together to determine what we can reasonably accomplish. Of course, this still depends on cooperation from your boss.
This is why I try to avoid these situations all together. It means researching a company and asking questions during job interviews to figure out what it will be like to work with my future boss(es). This post is getting too long, though, so that’ll be a topic for another day.
We can all learn from Bob’s mistakes, too.
If you’re planning on running a tech company with no tech experience…
Be prepared to spend much more time, money, and effort than you think you’ll need.
Communicate with your team to understand why things are done the way they are, so you can learn and grow into your role.
Understand what your team needs to balance their needs with those of your business and your clients.
Almost every software developer I ever met wants to do a good job because it feels satisfying to create a quality product that makes our clients and users happy. They’re not trying to waste your time or screw you over. So, assume good intentions. Trust your people. Because if you don’t, you’ll almost certainly fail.
I hope you enjoyed this dive Below the Surface of non-technical bosses running tech teams. Reply to belowthesurfacetop@gmail.com if you have questions or comments. Have you ever had a boss who didn’t understand your work? What was that like? Let me know. I’d love to hear from you.
Thank you for reading. Have a wonderful day. And I’ll see you in the next one.
“Bob” reminds me of most business development people I’ve had to do contend with.
Both on overselling the work I’m meant to be delivering and on overselling the solution they are trying to get my client to buy.
A classic example of misaligned incentives.
> with a non-technical boss running a technical team: they don’t understand what the team needs to succeed. But part of that role IS to get the resources the team needs to do their jobs well.
It can be just as bad when it's the customers.
Thankfully, customers usually care more about the goal than the methods of achieving the goals.