No. Good ideas are a dime a dozen. Execution is what really matters. Anyone who came from nothing to be a billionaire has skills and generally a crazy work ethic.
Jeff Bezos is a billionaire because he figured out how to modernize and automate shipping, and then iterated on that relentlessly forever to constantly drive down costs. His automated warehouses are amazing. He was very hands-on in their creation.
The Walton family got rich because Walmart got so good at reducing costs in the supply chain that they single-handedly were responsible for lowering national inflation by more than a point. Thomas Edison didn’t invent the concept of using a wire to generate light by passing epectricity through it, but he became rich because he tirelessly searched for the perfect material when others gave up and assumed light bulbs just wouldn’t be very bright or last very long.
All of these people worked their asses off and directly achieved things that had eluded others.
The same goes for CEOs. There are corrupt CEOs, and CEOs with bad ideas, but I’ve never met a lazy one. The process to make it to CEO filters out people who care more about things like friends, family, recreation, and sleep.
Exceptions may exist. And billionaires who inherited their wealth don’t count here, although if they don’t continue the same practices that got them their inheritance in the first place they won’t have it for long.
I don’t think the Elon Musks of the world weren’t brilliant people and I certainly don’t think they didn’t work hard.
I first of all think the approach of questioning conventional wisdom and thinking BIG is seen as the default mode for a lot of executives. In reality, no matter how great your ideas are and how much sweat you put into making them happen, you still have to get lucky to succeed by bucking conventional wisdom.
I also think that what takes real leadership a lot of the time is being aware of how things can go wrong and not put your company in a position where. I think there are a lot of success stories that no one will ever write a book about because they involve companies that avoided getting too ambitious and running into a pitfall.
Yeah, that’s pretty much what I see. Except it’s a lot worse when you work for a startup company because all they care about is just signing the deal.
Like the project I’ve been on for the past 6 months. They signed the deal and then handed it to the new engagement manager they just hired (me). At this point I’m still finding my bearings in the company, but after a few weeks of “discovery” I realize “this client doesn’t know enough about what they want us to build for them to actually build ANYTHING for them!”
The problem with all the project management paradigms is that on some level, you ultimately need to a) know exactly what you are building and b) how much it’s going to cost. The rest is just trying to shift around risk and “unknowns”.
Without going into specifics, while Elon Musk “works” hard, it is questionable just how valuable his “work” is. There is an oft-repeated story about how when SpaceX was in the early days and trying to figure out friction stir welding (FSW), he moved his desk and a cot out onto the production floor and worked and slept out there to put pressure on the manufacturing engineers trying to make the FSW machine work. However, what isn’t mentioned is that he refused to bring in consultants on setting up FSW, insisting that his own engineers should figure it out for themselves, and later touting how ‘advanced’ SpaceX manufacturing was at being the first to use FSW in making tanks and other structures even though FSW had been in use for over a decade at that point and Boeing had used FSW for Delta II, Delta III, and Delta IV since 1999. There are similar stories about his involvement in production issues in Tesla, and in my limited personal experience with him he spews disconnected pieces of technical jargon without any specific reference to the issue at hand. Musk was smart to hire Tom Mueller as his head of propulsion (coming from TRW propulsion and having long worked on the TRW Low Cost Pintle Engine program from which the Merlin engine family evolved), as well as Gwynne Shotwell, which aside from her frequently repeating some of Elon’s more egregious pronouncements, is actually a competent CEO and leader of the company who clearly listens to engineers.
Elon Musk is full of himself, and largely full of shit. He’s certainly a bombastic asshole like Steve Jobs, but he is nowhere near as technical knowledgeable or responsible for the success of his companies as Steve Jobs was of Apple, Pixar, and NeXT Software.
That whole post is excellent. I especially agree with this part, and it’s why I finally threw in the towel after 10 years as a business analyst. I have the skills to excel in the job but I found that in every company I worked at (as a BA) I was forced to stay at arms length from the customer. It was entirely my job to understand and represent the customer, but I was never allowed to spend any time with them other than the meetings you describe.
It always started right from the beginning, too. Get a job with a company in a new business domain. I was expected to learn the system I’d be working on and learn how the customer uses it. However I was never allowed to sit with them, watch them, interview them, nothing. I asked my managers at several jobs how I was supposed to accomplish this and was told to run test cases, talk to the developers and talk to QA. Developers are great but they can only tell you how the system is designed and built, not how the users use it. QA and running test cases is the same thing. I never could learn how the users actually used the system, what kludges and workarounds they implemented to get around flaws in the system, what their pain points were, what they loved about the system, etc.
So then after a few projects where my requirements gathering was just meetings with managers or a few key users, and seeing how many wrong or missed requirements we ended up with… that was my entire job and it was very frustrating to feel like I’d done it poorly. I don’t mean that as personal as it sounds, but… well, kind of. Why hire a business analyst if you won’t let them do their job? It’s just one example of how companies tie your hands behind your back and still expect you to get the job done well, and I finally just lost patience with that no win situation.
Not only this, but the project management tools I used assume that everything gets done right the first time. That’s find for the nth implementation of something, but a new microprocessor, say, is always going to have some unit that doesn’t make timing, or gets too big for the package, or something requiring rework. Do PM tools allow you to loop? They didn’t 20 years ago.
As I used to put it, even implementing a bog-standard inventory control system for a warehouse amounts to a greenfield research and development project as we perform an archeological dig through the accumulated accidents of history of every single IT & human system it touches within your company and your vendors and your customers.
The Navy’s Program Evaluation and Review Technique is theoretically supposed to do this, allowing you to accommodate and plan for changes in individual tasks to maintain overall schedule. It sounds great in theory; I’ve never seen it applied in practice, nor have I worked for a project manager that would have the technical knowledge and spare time to implement it. Everybody just does Gantt charts and waterfall planning and when something gets delayed or extended out everything else slips out to the right.
Developers are notorious IMO for just taking stuff at face value and doing exactly what it says, even when what it says may not make sense. This goes double for offshore teams in places like India.
A lot of trouble could be avoided if developers were engaged in the actual project they’re working on, instead of making every effort to insulate themselves from actually understanding the business implications of what they’re working on in favor of focusing strictly on the technical side of stuff.
I mean, if I wrote requirements that accidentally called out the same colors for warnings twice, most developers I have dealt with wouldn’t question that- they’d just do it, even if it proved to be confusing and just an oversight on my part. And if I say something like “Did you notice that would be confusing?” they always get defensive and say something like “Yeah, but it was in the requirements like that.”, as if that absolves them of any responsibility to make a usable end product.
That’s not inconsistent with my experience as a project manager. Particularly in my last job. Even under the best of circumstances, there is going to be a bit of a game of telephone gathering requirements from the business, translating them into specifications for the development team etc. Plus you have the typical “waterfall” problem where the more time and budget you spend on requirements gathering, the less you have for development and testing.
And in practice, at least at the companies where I’ve worked, clients don’t want to pay for (or salespeople don’t want to bother having to sell for) business analysts and project managements. We didn’t even have a BA role at my last company (although they were sold on the SOW).
Absolutely. Users tend to specify only the stuff they anticipate, not the response that the system should make to things they don’t anticipate and to corner cases. When I got a request I always had to ask what they wanted to happen in all the situations they hadn’t considered. It was really helpful to be a subject matter expert also.
But that isn’t practical, since there often isn’t enough development work over the long run to keep people who are both skilled in an area and in development occupied.
I’m just asking for those folks to critically think a little and ask a few questions if things are ambiguous, contradictory or flat out absent. I’ve had developers just hide behind the “that’s the way it was in the requirements” way too many times.
At least at my college engineering job, our engineers worked really closely with the construction guys- there was constant back-and-forth where the construction guys would see something/notice something and ask about it. Then when I got out of college with a CS degree, I found that it didn’t work like that in the technology world- they’ll just build to spec without uttering a peep.
I don’t think the developers are doing that because they are lazy or dumb, but because they don’t understand the subject well enough to know what they don’t know.
A non-IT example. My wife writes online encyclopedia entries on biology, and rewrites some written by other people. She can tell if the original writer understood the subject or not. If you’ve ever written on something you don’t truly understand, you’ll get it.
I suspect there also can be the issue of the developer getting maligned for not getting “obvious” stuff implied in the requirements, and just giving up.
Sketching a section of code and trying to figure out how to handle all the cases that become obvious only when you dig deep is a revelation which most non-programmers never have.
I worked as a civil engineer briefly. I recall instances where you would have the electrician cutting into HVAC ducts to run his cables or the plumbing guy cutting through structural members to lay some pipes or the engineer, contractors and architect at odds with the actual building of a proposed design. Not as often maybe, as you have a lot more regulation and oversight than you do building software.
In my early days building software in the mid ot late 90s, there did seem like a lot more collaboration between business, developers and QA to address ambiguous requirements. But a lot of that changed in the 2000s when outsourcing became more of a standard practice. Some developer in India working for Cognizant or Wipro or whoever is not going to have any context for the single module of code they are building.
