I'm a dev and I understand the frustration of multiple resource load and the bandwidth burden it imposes but also as an entrepreneur and business owner, I see the need for metrics when making a sales pitch.
> Your job is to show why both parties’ incentives are actually aligned, not opposed.
This!
It's your job to do just that because of your vantage point i.e. you're able to see everything more broadly than anyone else. Understanding that all the stakeholders in your organization are doing something important that allows everyone to have a place to come to work to tomorrow is critical for you as the engineer.
You've heard of "be a multiplier, not an adder", right? My contention is that many good developers can be multipliers across very large portions of an engineering organization when given the chance. Dysfunction does seem to be the natural state of any business, and engineering groups are no exception; technical and social resources capable of and empowered to tackle cross-cutting concerns are that chance I'm describing and provide self-evident benefits over the long term. You're right, that sometimes it happens informally. I am asserting that institutionalizing it makes teams faster, less risky, and happier.
I also happen to think that I'd be good at it, because it's kind of what I already do, and I wish it was more common because that'd be great. Heaven forfend. I mean, you can try to pull the well-actually-it's-labor-that's-bad thing by trying to turn it into my mindset is wrong rather than let's talk about executive and managerial allocation of resources and whether we do a good job of it across the board, but the thing speaks for itself.
And you're right, that post is braggy. It's also marketing: from this thread I've gotten two emails inquiring as to the state of my pipeline and if I'd have time for a chat. It can be both self-marketing and a reasonable observation of reality. (Email's in my profile.)
Decide and communicate the metrics that matter for your business, then constantly educate and remind engineers of how they can help to reach those goals. Increases the number of good ideas from people with the best context and reduces the bridges-to-nowhere.
I think it is important for you to think about how/to whom you want to sell your product. Do you want to have a bottom up approach where you sell to the engineers touching the code everyday? Or do you want to sell to the CXO of an organization?
If you want to sell to engineers, I think your page is fantastic. It is solving a problem that engineers face regularly - error/performance related analytics. But I don't think it really appeals to the business side. Most business folks do not know how to translate those pieces of analytics to business performance.
Well said. I work on engineering stuff but I spend a huge amount of time encouraging people to understand the other parts of the business and their needs.
Certainly those sorts of goals shouldn't be how engineers are judged (or worry that they'll be judged), and they should have their own KPIs. However, it's very beneficial for them to be included in the overall goals, as it can increase both their sense of purposes (why are their individual KPIs important?) and their sense of being a team (we're all working together to grow the userbase, not just the sales guys).
I think it's simple. If you're business requires scaling at this level you need to have really good engineers and they need to have a lot of say in how things are done. I've worked with a number of "product" people from myspace, and they were definitely not doing 1 of these two, maybe both.
Oh, I see. Totally agree. Knowing what users actually need and knowing how to sell it to them is the most valuable thing in an early stage company. Way more valuable than engineering talent.
The reality is that both engineers and sales have their own respective forms of myopia. Engineers often bias towards elegant code and architecture, salespeople bias towards whatever the last sales lead said on the phone. Both have some value, but neither one will unlock a massively scalable market. To do so you need some vision beyond what the sales lead is saying on the phone or what is easy to design elegantly. Not just that, but you also need rapid iteration and not to fall so in love with your early thinking that you can't effectively capture new insight along the way.
I disagree. Engineers have a habit of over engineering. Businesses have a habit of introducing too much process, too many meetings, too many layers between the end user and the engineer building.
A lot can be done most of the time to help devs optimize to deliver quickly. However, most businesses get stuck in their ways, struggle to give sufficient autonomy, and... sometimes get burned by giving too much to a dev when they aren't yet ready for it.
In short, getting efficiency "right" is a balancing act, and each "story" could be unique which makes it difficult to balance well consistently.
In my experience, don't get too caught up with estimates. Devs do need goals (even artificial ones) to help focus effort and prevent too much "bad" distraction (sometimes distraction is exactly what they need though--stepping away from the problem for some amount of time can help them look at it differently).
Give estimates. Motivate with goals. Build a real team environment where delivering is contagious. Its actually much harder to do than say, and I'd guess many devs have never experienced this before.
Exactly. That's why I have a line of other engineers waiting for me to teach/show them how to sell the product they built.
Being a hybrid between a software engineer and marketer does give me a perspective that few here get to see.
The more engineers get involved in the business side, the more they see both problems and opportunities that remain hidden if you just give them specs, no matter how good those specs are.
Attribution is critical. A salesperson who lands a big deal can claim it's their exclusive work. An engineer who is one of a dozen people working on a feature that customers like does not have a similarly clear number they can point to as value added.
That works in sales, where one salesperson runs the whole engagement and can clearly claim responsibility for the revenue and thus be directly compensated with a proportion of it.
But in engineering you need people to be thinking big picture, thinking collaboratively, taking risks, doing long term development, cleaning up technical debt. If you overly tie compensation to product revenue, you risk incentivizing your entire engineering staff toward short-term bolt-on-the-feature thinking.
This item stands out as one of the most important aspects that is either unknown or ignored in companies. The amount of information a person has access to drastically alters their ability to make informed decisions.
"Exposure to the business and to business metrics. Engineers are encouraged to interact with the rest of the business and build relationships with non-engineers. In contrast, traditional companies often make it impossible for developers to interact with the rest of the business."
As an engineer I understand this completely. We are already discussing internally how we can improve our site and documentation. Our goal is to create a vibrant community and getting all the sales fluff out of the way is something I support!
Agreed. In fact, the better that engineers understand the customers and end-users the better-off the company probably is. That is a good, healthy practice.
But having engineers actually trying to do sales to make up for revenue shortfall . . . not so much :-)
I think you're over-inflating the value of people fetching specs back and forth between a pool of customers and design / engineering.
If you're a software or hardware company, ultimately the people who design and build the software / hardware have to design and build the thing, everything else is ancillary to those tasks.
The context to my post are the reliability issues that def. can be instrumented and fixed.
Business and pricing model not so much unless the engineer is willing to add the Sales prefix to their engineer role ;)
But even the pricing model - measure and compare the costs, competitors, and value derived (ok, commodity now vs 5yrs ago) and work with people pitching prices.
That’s still designing, analyzing, measuring systems - prices instead of code - definition of engineering.
One of the realities of 'software eating the world' is managing client driven requests with finite engineering resource.
Forcing sales to prioritise their requests amongst themselves (fight it out) periodically is generally good practice that all product teams should employ although doing this on global scale across multiple regions and products with same pool of engineers can be challenging.
> Your job is to show why both parties’ incentives are actually aligned, not opposed.
This!
It's your job to do just that because of your vantage point i.e. you're able to see everything more broadly than anyone else. Understanding that all the stakeholders in your organization are doing something important that allows everyone to have a place to come to work to tomorrow is critical for you as the engineer.
reply