I'm speaking in front of 200 people tomorrow on the topic around software development for startups. There are hundreds of books written on this so I'll try to condense my learnings from most.
Even though we're a startup company at cenario, I stopped hiring software engineers, hell I tried to unlearn and relearn a few things in the journey as well.
Confusing I know - I still have to grapple around the entirety of it all but the honest truth is being a software engineer alone will get you easily fired or unvalued in a startup.
You need to fire yourself from that role and re-hire yourself as a product engineer. I've referenced this point multiple times in my previous articles and I really stand by this.
I don't think this necessarily applies for larger companies when they're hiring specialists and algo heavy engineers, however in a startup you need to think about the product, the marketing and most important the customer.
There is a significant disconnect in larger firms from the creator (developer) to the end user, all the way from hierarchy, to Project Managers, to Product Managers, to Marketers, to Execs etc - but in a startup, if you push code up... it's up.
So whats so special about being a product engineer that a software engineer can't do? A few things:
1. They carry a get shit done attitude
Sure some engineers carry that too, these statements aren't binary or exclusive but address the vast majority. When you look at github discussions or you look at conference events where people share their discoveries, it's all based around the engineer - not as much around the customer.
So yes, product engineers have a get shit done attitude, keeping in mind that they need to push good work out, but are quick on their feet to understand how much of debt some technical decisions will be vs others. This will be understood better over time, and even after a decade of programming, I can confirm that there is no right or wrong answer, its extremely situational based.
2. Business first, software second
You should toughen up and realise that building on the latest and greatest tech will not make you a better engineer. You almost NEVER have as much a good reputation for being the engineer for a bad startup as you may of a good startup, even though your code in the bad startup might be worthy of awards and your code in the good startup might be worthy of firing. It's inherent you see - good code isn't coincidentally in good companies, its because the companies made the smart decision of hiring mini-CTOs, people who understood that their customer mattered as much as their code.
This doesn't mean you give up all morals and build on PHP(I'M JOKING :p), but it kinda does. Not PHP but any language that is deemed unfit just because it's popular or not. You do a direct risk analysis on what will get me to my next goal ASAP. Whether that's faster iteration, more features or modularised code bases.
3. Customer first, business second
It should all come down to how you can make the life of the customer as easy as possible when you're solving the problem for them. Sometimes business requirements become business requirements and not customer requirements, and if you're just a software engineer by title, you will be doing what you're told to do because thats the limitation you have, at least the limitation I had a couple of years ago.
By stepping out of that box and understanding that if the business requirements step outside of the customer requirements, you get to voice your opinion and more importantly add the kicker to your "opinion" by justifying it with your technical abilities, techies are badass, we're the makers, so in the end if we have the knowledge around consumerism AS well as execution, it'll make us bulletproof.
So yes, if you're in a startup - don't work as a software engineer, work as a product engineer. Your impact will be 10X I kid you not.
People will take you ALOT more seriously, you'll climb the ranks faster, your code will matter a lot more, and the impact will be at scale. Your work matters and there should be no reason why more people shouldn't experience your genius code, the way you can make that happen is by being product focused and ensuring your customers are having the best time of their life.
As with any post, I'm always always looking to learn and become better at what I do, so I'd love to hear what you have to say, good or bad 🙌
If you liked this, definitely follow me on for the similar stuff:
twitter: twitter.com/@veebuv
linkedin: linkedin.com/in/vaibhavnamburi
instagram:_veebuv
Top comments (35)
I love this take, I really think that, for most of us, the way to improve our careers the most is to improve our "business" skills rather than our technical skills.
In a related vein, any chance you have read anything by Erik Dietrich? He has a lot of articles and a really good book about how software devs should be taking on more business responsibilities:
Developer Hegemony: The Crazy Idea that Software Developers Should Run Software Development
Definite strong points! I do believe some places won't appreciate business acumen as much as others, so it certainly isn't a vanilla ideology.
And no i actually didn't, so thank you so much for sharing that article, I just read it and it's pretty darn amazing. I couldn't agree more with that the author has to say!
I definitely agree with you in terms of how one must conduct themselves in a startup. The role(s) you outline are pretty much spot on IMHO. I think though, that 'titles' have less to do with the work one performs for a company than said roles. Frankly, it's a startup: you will likely be a janitor from time to time too even if your title is software engineer/ceo/product manager, etc.
Agreed, titles diminish very early on in a startup lol, you're going to be doing everything. This applies even when you work at a startup, and not necessarily run it. My team are incredible in that they always chime in on product feedback, give thoughts on what would be a great approach and what wouldn't be and that makes a world of a difference
Truly, awesome real time business strategy which incorporates customer satisfaction whereby all facets of business are interrelated including engineering objectives with feedback and continuous improvement in the delivery of the product/service to the customers....
Exactly! You nailed it!
Thanks for the affirmation as your recommendations/advice are of unequivocal value....
You summed up the original intention behind the Agile Manifesto from 2001. The reason engineers are far from the customer in big companies is not because the company is big, it's because the company is wrong.
A man after my own heart.
I have been plugging away for ages that soft skills and business savvy are equally as important in a development role if you want to be exceptional at your job. Good programming skills on their own will only ever get you so far.
I know and work with many exceptional engineers who have brains for problem-solving and their craft, but are totally out of their comfort zone and depth if they have to deviate from what they are used to doing. No soft skills, no communication ability and just technology acumen is not a winning combination in my mind.
Hahaha I've come to learn the hard way that in the end, it's all for the customer like you said. Its, unfortunately, the sad thing about "titles", it confines you to a role and makes you think, thinking otherwise is wrong.
Honestly, your comment is perfect in the way it is, there's nothing for me to add but to clap at kind, sir!
👏👏👏👏👏👏👏👏
So I came to this article miffed that you would advise people not to work as an engineer in a start-up. Glad that's not the case 😁 Do I feel click-baited? Maybe. Do I care? Not really! I like your thesis.
This is something I look for when interviewing with startups as well. It helps to ask the engineering team pointed questions to see how they approach their work. I find that if I'm going to be working closely with an engineer who obsesses over technical purity at an early-stage company... well, there are going to be problems!
Separately, I like the idea of firing oneself. I'm going to do that today.
Hahaha I'm sorry about the click baity article, i try my best to make the titles as such but then no one reads anything i write haha. So i try justify the title with some sortof sense (i hope)
" I find that if I'm going to be working closely with an engineer who obsesses over technical purity at an early-stage company...well, there are going to be problems!" This part is golden! You're on the money there, each start up is different ofcourse, but especially isolated to small company and start up, you do what you gotta do to make shit happen
hahaha all the best :D Let us know how it goes!
Point, however I don't necessarily think that leads to becoming an entrepreneur, then again that word is so abused you don't really know what it defines anyway.
It was more so an attitude that people should embrace where they realise its not JUST code but code AND business that makes a dev successful
I believe that if we plan to improve in our career in a startup.
We should focus on our ability to sell, lead and become a better communicator plus networking.
Which applies to either being an independent contributor or moving into management.
With this in place, it could greatly help a developer to pursue the road towards being a freelancer or an entrepreneur if he/she chooses.
Granted we're not a startup, we came to your conclusion a few years ago - mainly due to ours having been involved in developing products for startups AND being startup founders ourselves. We're also coming from Romania - an ecosystem that abounds in tech skills and tragically lacks business skills.
So you can imagine we're trying to bridge that gap and we start from recruitment and company culture (our CTO phrased this as 'growing a startup culture in an agency' here: around25.com/blog/startup-culture-...).
The results? We started to change as a company; currently, we're switching from outsourcing agency to a product development one and the transition is sure taking a lot of work. Especially when you realize hiring software engineers into product engineers means hiring only knowledge-thirsty individuals who never cease learning by themselves :)). It's not a small feat for sure.
Another thing we do is we try to create learning opportunities that involve product development and this is how taking part in our local Startup Weekend competition became a yearly tradition (as our CEO explained here around25.com/blog/rome-was-not-bui...).
Couldn't agree with your post more & hopefully our insights will serve others looking to change their approach.
Articles like this are a good wake-up call, but I'm sure the author would be saddened to see this become Dogma.
I've been recently reflecting on a startup that encountered ~2 lost years due to too much "move fast and break things": I just think teams just need rationale discussions about the trade-offs at every stage, and to come to a close-to-concensus. Easy to say, hard to do.
Hey @coolman!
You're not wrong in saying that sometimes building at velocity without discussing the repercussions can hurt and sometimes even kill a business (has happened to me)
I think if anything I'd like people to take away from this is to be more outcome driven than feature driven. This can translate to faster dev, focus on customers or move fast/break things. In the end, as we all know - in startup land pace is everything (unfortunately), pace to build until you hit PM fit and then pace to maintain what you've built
I've written about refactoring and rebuilding your code. And if it's necessary to do so, it needs to be done.
Again you're not wrong 😀 and I'm glad you raised this comment!