I like to think I qualify to talk about the topic, given my background as a fairly serious developer (kernel protocols, device drivers, distributed systems) in the early years of my career and taking pride almost exclusively in the technical swagger of my work. And surrounded by people only like me, just more senior and “high profile” in that profile, all of whom thought similarly. Eventually, I made career choices based on some learnings along the way.

Fast forward to a few years ago, when I was managing a team of Product Managers and one of them asked me a tricky question: “why should the engineer do it?”. His predicament came from the fact that we had a fairly broad set of responsibilities spanning both inbound and outbound product management and given the enterprise context, there would always be ad-hoc asks of us (a demo, a POC, a Gartner/Analyst demo scenario, etc.). That meant that the engineering team would have to accommodate this despite their sprint commitments and the engineering managers (EM) planned for it. So far so good. The real problem my PM had was not in convincing the EM, but in getting cooperation from the engineer whose work got disturbed. The PM’s point was “I get why I should do this — for “business” reasons, but why should the engineer do it? How should I convince him/her?”. The engineer did eventually deliver, coz “duty”, but I wrote the question down on my white board and it took me a few weeks to finally solve it. And the answer is simple:

“the engineer should do it because he is not going to remain the same engineer forever and must understand where his work sits in the world”.

The reason the ad-hoc assignment’s purpose made sense to the PMs and not the engineer, is because you have to first see the “why” of the assignment before you see the “what” of it. And for good or for bad, all engineering pedagogy (at least in the US and India, places I’m familiar with) followed by engineering team culture in companies convinces us all to think engineering is the “bottomline” where the “real” work happens. Take pride in its richness. Turns out, over time, you’d realise, the real bottomline (aka money aka business aka market dynamics) is the bottomline.

Not the complexity of the code, not the tech, not the brandname of the company, not the school you went to — it is the market that drives the need to use engineering a certain way to build something specific and then someone else takes it back to the marketplace. Try and recall that bad product you use (or are made to use) — “how did they even ship this?!” category — and you’ll see how much business talent it would have taken for that to reach you. And the number of brilliant engineering innovations that never saw the light of the day explain the same idea.

Business problems are not only extremely hard, but are also non-determinstic, unlike engineering — while engineering management has its own challenges, the outcomes are by and large predictable for their deliverables

And so, you owe it to yourself to understand why you’re doing what you’re doing — if others aren’t doing that for you (odds are, nobody is), you do it for yourself. Most likely, your manager/their-manager/their-manager and architects project a feeling that they are the entire ecosystem. Only they’re not.

Take time out to talk to people who are NOT AT ALL like you. A product manager, a salesman, a marketer: they did not “go to the other side” like you’re made to believe — they’re on your side. Listen to what the CEO is saying in an All hands and pester people to explain to you what s/he talked about and see if you’re convinced. If not, do some reading — see what your competitors do.

There’s some things you cannot unsee and understanding business impact is one of them. You can suddenly understand a lot of things: layoffs, for instance — how bizarre is it for that “dream company” to suddenly become so poor overnight that they cannot pay salaries to some people — thing is, it was long coming if you take the business context into consideration. You can similarly explain new hiring, new offices, attractive job offers, acquisitions, etc.. In today’s hyper-fast world, you cannot afford to not know this.

It is not just the raw engineering talent that matters, it is the need for it that does.

Once you get this, your own career perspective will change dramatically. You may continue being an engineer, but you’ll be management’s favourite, since you “get” them. You’d eventually become a better architect or manager, since you’d appreciate optimizing for outcomes. Or you might want to switch lanes: become a PM, go get an MBA, join a startup, start a startup. Or just make new friends you’ll admire.

If nothing else, you’ll see where your code sits in the market. You’ll understand if you’re working on Flash or HTML5: whatever Steve Jobs is explaining in this video, applies to where you apply precious career time.

Hope this helps you think beyond your immediate circle. I wish you the best!

PS: I’m currently building a startup based on my own learnings like above, to enable people to have intentional careers and for companies to enable so, with

• A Career Planner to plan long/short term career plans
• A Work Journal to keep track of progress
• A Mentoring module to get advice from someone you respect
• If you like it, you can even engage your manager to help enable these plans

Get access at yugahq.com or ping me at kiran@yugahq.com to learn more.