4 ms·

So how can you make a technological decision if you do not have hands-on experience with the technology (at least a year of deep immersion)? It sounds like the

So how can you make a technological decision if you do not have hands-on experience with the technology (at least a year of deep immersion)? It sounds like the most important decision (whats to build) are at the hand of the least knowledgeable person.

Swizec 8y ago
You listen to your experts. Get their opinions. Ask for their logic and their evidence and their conclusions. Then you decide.
- streetcat1 8y ago
  Right. So why do you decide and not the expert decide? So the expert can be smart enough to come with a solution but cannot "decide". My point here is that once you become the manager, you should constrain yourself to the functionality (input/output spec), but you cannot decide on technical issues if you are not keeping up with the technology.
  - eksemplar 8y ago
    Because the technical truth is only part of the equation. The right decision almost always boils down to a combination of experts, finances, end users, over all strategy, corporate culture and realism. The variables variate in importance, but the one thing you can be consistently sure of, is that experts over value theirs. On top of that, decision making is only a small part of management. The majority of it is spend on politics, motivation and issues/conflict resolution.
eksemplar 8y ago
Because decisions are rarely down to just one field of expertise, and technical experts are often some of the least knowledgeable about fields that aren’t theirs. Like if you build a new application for handling internal e-commerce. The programmer will know how to build it, the service designer will know how to create the ux, the lean consultant will know how to build the best work-flow, the financial expert will know what functionality is required, the project manager will know how to get things build in the right order and how to manage benefits, the hr-consultant and the lean consultant and the service designer will know how to get it implemented, the data scientists will know what kind of data model their like to do BI. And so on. The right decision is to listen to all those inputs, and implement them in a way that’s both realistic, possible within the budget and making sure the final product actually fits in within the organisation. That doesn’t mean you won’t delegate. I don’t really care if it’s build with graphql or not, as long as building it with graphql doesn’t increase production time by an unreasonable amount of time compared to other options and graphql is part of what our company in general uses. Because the best flashy new tech is useless if only 1 out of your 100 programmers know it.

Swizec 8y ago

You listen to your experts. Get their opinions. Ask for their logic and their evidence and their conclusions. Then you decide.

streetcat1 8y ago
Right. So why do you decide and not the expert decide? So the expert can be smart enough to come with a solution but cannot "decide". My point here is that once you become the manager, you should constrain yourself to the functionality (input/output spec), but you cannot decide on technical issues if you are not keeping up with the technology.
- eksemplar 8y ago
  Because the technical truth is only part of the equation. The right decision almost always boils down to a combination of experts, finances, end users, over all strategy, corporate culture and realism. The variables variate in importance, but the one thing you can be consistently sure of, is that experts over value theirs. On top of that, decision making is only a small part of management. The majority of it is spend on politics, motivation and issues/conflict resolution.

eksemplar 8y ago

Because decisions are rarely down to just one field of expertise, and technical experts are often some of the least knowledgeable about fields that aren’t theirs. Like if you build a new application for handling internal e-commerce. The programmer will know how to build it, the service designer will know how to create the ux, the lean consultant will know how to build the best work-flow, the financial expert will know what functionality is required, the project manager will know how to get things build in the right order and how to manage benefits, the hr-consultant and the lean consultant and the service designer will know how to get it implemented, the data scientists will know what kind of data model their like to do BI. And so on. The right decision is to listen to all those inputs, and implement them in a way that’s both realistic, possible within the budget and making sure the final product actually fits in within the organisation. That doesn’t mean you won’t delegate. I don’t really care if it’s build with graphql or not, as long as building it with graphql doesn’t increase production time by an unreasonable amount of time compared to other options and graphql is part of what our company in general uses. Because the best flashy new tech is useless if only 1 out of your 100 programmers know it.