DEV Community

loading...

Discussion on: What should I know to be a software architect?

Collapse
stereoplegic profile image
Mike Bybee • Edited

Much of being a software architect (and especially CTO) is the ability to slap nontechnical stakeholders (up to and including your own CEO) back to reality, in a way they they respect you for. I can give an example from my time with a startup whose CEO had ADHD (and ultimately was a cheapskate and a BS artist, which is why I'm not around to build the product), and lost a major client by flying off the rails with ideas unrelated to what we were doing.

Basically, we were trying to stir up interest from potential corporate customers in running product pilots. He got an exec from a major big box electronics retailer (yes, that one) on a pitch call by himself, after I had already told him he should get me involved to keep the discussion technologically grounded in reality (rather than the all-too-typical sales routine of making promises on which we couldn't deliver without significant additional work and eaten costs). His pitch went swimmingly, but then the exec asked him what our 5 year plan was re: market saturation, expanding into new verticals, etc. This is where he went off the aforementioned rails, throwing out ideas which had absolutely nothing to do with our current core product and no conceivable (or attractive) way to integrate them: VR, facial recognition, and other buzzwords.

When he told me, I reiterated that this was why I should have been involved. The answer was easy: Since we would already need to integrate with the APIs of customers' existing systems from other vendors, we could study their strengths and weaknesses while doing so and eventually offer competing products more tightly integrated with the core product.

Forem Open with the Forem app