4 ms·

Can you give an example of what you mean by input from non stakeholders?

varjag 6y ago
Depends on the org structure. In the one I was, architects were siloed off from the projects in a parallel sub-unit in the department, making it a bit of an ivory tower. They would issue design and scope decrees without facing any schedule pressures themselves. It took me a while to realize that most of my managing peers were quietly* ignoring them, delegating the actual decisions to the team. (*) As in, amend them to a workable design through a few status updates rather than making a stand-off in the initial meeting.
- mtberatwork 6y ago
  A situation like this can backfire quickly though. If the project fails or a setback occurs, the architects can quickly say that the engineers weren't following the original design and specifications.
  - varjag 6y ago
    Sure, but here lies the importance of my point: you get to be responsible either way, but at least you get to make your own call. If you turn that around and fail to deliver "because architects overdesigned it" everyone is going to give 0 f*cks - it's still your fault.
    - mtberatwork 6y ago
      Yup, a tough call to make for sure and certainly grey areas with no clear path. When things fail, folks are quick to pass the buck and it's best to have as much recourse in your back pocket as possible. Don't give yourself a bigger mountain to climb so to speak.
      - varjag 6y ago
        Yes, this is situational. As mentioned it was a recurring pattern so a dysfunction peculiar to that particular org. What happens is that many non-coding architects (sorry folks, not all of you but plenty enough) are essentially junior developers with little experience who negotiated themselves into these positions. Which is not that a big deal if they feel themselves part of the team and are grounded in the situation and open minded about debate. But unrestrained they build Daedalus wings and in the end it's you who get to do the falling. You as a manager with engineering background have better comprehension of your team, with its strengths and weaknesses. You navigate the project leveraging the former and avoiding the latter, and if third party (neither the customer requirements nor your team) starts meddling it's not going to end well.
- teddyh 6y ago
  The Magician of the Ivory Tower brought his latest invention for the master programmer to examine. The magician wheeled a large black box into the master’s office while the master waited in silence. “This is an integrated, distributed, general‐purpose workstation,” began the magician, “ergonomically designed with a proprietary operating system, sixth generation languages, and multiple state‐of‐the‐art user interfaces. It took my assistants several hundred man years to construct. Is it not amazing?” The master raised his eyebrows slightly. “It is indeed amazing,” he said. “Corporate Headquarters has commanded,” continued the magician, “that everyone use this workstation as a platform for new programs. Do you agree to this?” “Certainly,” replied the master, “I will have it transported to the data center immediately!” And the magician returned to his tower, well pleased. Several days later, a novice wandered into the office of the master programmer and said, “I cannot find the listing for my new program. Do you know where it might be?” “Yes,” replied the master, “the listings are stacked on the platform in the data center.” — The Tao of Programming, chapter 7.3 (Geoffrey James, 1987)

Depends on the org structure. In the one I was, architects were siloed off from the projects in a parallel sub-unit in the department, making it a bit of an ivory tower. They would issue design and scope decrees without facing any schedule pressures themselves. It took me a while to realize that most of my managing peers were quietly* ignoring them, delegating the actual decisions to the team. (*) As in, amend them to a workable design through a few status updates rather than making a stand-off in the initial meeting.

mtberatwork 6y ago
A situation like this can backfire quickly though. If the project fails or a setback occurs, the architects can quickly say that the engineers weren't following the original design and specifications.
- varjag 6y ago
  Sure, but here lies the importance of my point: you get to be responsible either way, but at least you get to make your own call. If you turn that around and fail to deliver "because architects overdesigned it" everyone is going to give 0 f*cks - it's still your fault.
  - mtberatwork 6y ago
    Yup, a tough call to make for sure and certainly grey areas with no clear path. When things fail, folks are quick to pass the buck and it's best to have as much recourse in your back pocket as possible. Don't give yourself a bigger mountain to climb so to speak.
    - varjag 6y ago
      Yes, this is situational. As mentioned it was a recurring pattern so a dysfunction peculiar to that particular org. What happens is that many non-coding architects (sorry folks, not all of you but plenty enough) are essentially junior developers with little experience who negotiated themselves into these positions. Which is not that a big deal if they feel themselves part of the team and are grounded in the situation and open minded about debate. But unrestrained they build Daedalus wings and in the end it's you who get to do the falling. You as a manager with engineering background have better comprehension of your team, with its strengths and weaknesses. You navigate the project leveraging the former and avoiding the latter, and if third party (neither the customer requirements nor your team) starts meddling it's not going to end well.
teddyh 6y ago
The Magician of the Ivory Tower brought his latest invention for the master programmer to examine. The magician wheeled a large black box into the master’s office while the master waited in silence. “This is an integrated, distributed, general‐purpose workstation,” began the magician, “ergonomically designed with a proprietary operating system, sixth generation languages, and multiple state‐of‐the‐art user interfaces. It took my assistants several hundred man years to construct. Is it not amazing?” The master raised his eyebrows slightly. “It is indeed amazing,” he said. “Corporate Headquarters has commanded,” continued the magician, “that everyone use this workstation as a platform for new programs. Do you agree to this?” “Certainly,” replied the master, “I will have it transported to the data center immediately!” And the magician returned to his tower, well pleased. Several days later, a novice wandered into the office of the master programmer and said, “I cannot find the listing for my new program. Do you know where it might be?” “Yes,” replied the master, “the listings are stacked on the platform in the data center.” — The Tao of Programming, chapter 7.3 (Geoffrey James, 1987)