[justjico]

For anyone interested in learning more about strategy, I highly recommend Richard Rumelt’s book “Good strategy, bad strategy”. This link provides a good summary of the book: https://www.mckinsey.com/business-functions/strategy-and-cor...

I often see the word “Strategy” thrown around, often referring to meaningless corporate speak or fluff. In fact, it’s a whole field of study, and I feel many engineers will love it if they gave it a chance.

In order to develop a strategy you must have a challenge or hard problem to solve. Then you define a cohesive set of actions or policies backed by an argument to solve the challenge. Strategy should define the “how” to solve the problem by clearly articulating the hard choices you have to make.

“Increase customer value”, or revenue or profits, those are not strategies. Being the best, or “leading”. Those are goals or wishes. Defining how to achieve that, given a whole set of constraints, that’s the heart of strategy. And engineers are generally great at solving those type of complex puzzles.

The solution is not one that may involve code or even engineering in general, but rather, a clear understanding of the problem, its constraints, and the argument for choosing some specific set of trade-offs.

[usrbinbash]

>The solution is not one that may involve code or even engineering in general, but rather, a clear understanding of the problem, its constraints

Problem is: The only way to really understand a problem in engineering, is trying to engineer a solution for it.

[justjico]

Agreed. But the problem itself may not really be an engineering problem, and therefore a potential solution may exist outside.

I agree though, particularly in tech, the tendency is for great leaders to be deeply knowledgeable on engineering details because that is a requirement for a good strategy.

Nonetheless, in a broader sense, defining success for a business can create a solution space that extends well beyond engineering.

[usrbinbash]

If it is not an engineering problem, then engineers should not be bothered with it, simple as that. Not because we cannot do it, but because we can do things others cannot. And these things take time and focus to do well. And without them, all the talking and planning and strategizing and wearing suits, becomes pointless, because there is no product to sell.

I am a coder. It is not my responsibility to sell our product, convince someone to see a demo, or do "market research" into what features we require.

"division of labour" exists for a reason. If I am supposed to be doing the job of the guys in suits&ties, in addition to be able to write, read and test code, then I have to ask the question why we should pay these guys in the first place.

[clarge1120]

Thanks for the link. I will check it out. I too see the word "strategy" thrown around without being well defined, and it should be clearly defined, especially for engineers who want to move into decision-making.

Strategy is "the plan to win". An engineer's work is to execute the plan. It's like coaching the team vs playing the game. Engineers are the players, and the job of the player is to score the next goal. Executives (or Managers) are the coaches. The job of coaches is to win the game (and the season). These are not opposing goals, they are complimentary. Unfortunately, in the technology field, players and coaches are oftentimes at odds as though they have opposing goals.

The article makes a case for engineers who want to get into management, but haven't found a way to make that happen. Not every engineer wants to manage, even if that management is of technology rather than managing people. But for those engineers (players) who want to get into management (coaching) the case the article makes is this: players who want to coach must think like coaches.