A strategy shouldn’t dictate WHAT needs to be done, it should layout where the company needs to get to and achieve. So in this micro services example, it’d be more appropriate to have something like “increase team independence and throughput”, of which microservices is a _possible_ solution amongst many others.
In terms of roadmapping, I like to use the phrase “futures, not features” to remind folks of the proper content for them.
Sometimes a WHAT is important enough to because the strategy. It should be an architectural problem holding everything back though. For the most part strategy should sit back a level where lots of different whats all fit in, and sometimes a what is allowed to violate it for good reasons.
> What is the alternative? Assuming here there is such a thing as a correct engineering strategy, who should define it?
In companies where engineering strategy is done well, the person defining the strategy (a director or VP usually) knows the technology as well as or better than any of the people working for him - that is why he or she is in that position. And because of that, he or she probably has buy-in from rest of the people in the engineering organization.
> For deeper inspiration on how to draft crisp and actionable strategies, I recommend the book “Good Strategy, Bad Strategy.”
This piece of advice is good, but I don't see it applied. If you take the book's advice as useful (and I do), good strategy starts with diagnosis of a problem. The problem statements are much more important than the solution statements.
Set goals and let the people doing the work decide how to achieve these goals. once they have decided on a strategy then management should support them.
dchuk|6 years ago
In terms of roadmapping, I like to use the phrase “futures, not features” to remind folks of the proper content for them.
bluGill|6 years ago
richk449|6 years ago
In companies where engineering strategy is done well, the person defining the strategy (a director or VP usually) knows the technology as well as or better than any of the people working for him - that is why he or she is in that position. And because of that, he or she probably has buy-in from rest of the people in the engineering organization.
bpicolo|6 years ago
This piece of advice is good, but I don't see it applied. If you take the book's advice as useful (and I do), good strategy starts with diagnosis of a problem. The problem statements are much more important than the solution statements.
Ididntdothis|6 years ago