What is now called "agile" (which has been bastardized from the late 90's "XP") is specifically designed to stop this from happening: every day, you have to "stand up" and recite what you did yesterday and what you're going to do today. If "scrum" is being followed properly, there's somebody listening who's actually recording what you said you were going to do yesterday and compare it to what you say you did yesterday and call out any discrepancies. So no, you don't need permission to do something as long as it only takes an hour or so and you can hide it somewhere in your daily standup tasks. Anything that takes longer than this needs to be reviewed and approved - and this is entirely the point of the methodology and the only reason it's ever adopted.
Middle manager here! There are many different categories of "my team is working on something unapproved", and my response is varies greatly. Here are some categories:
1) I found a problem. I spent 5 minutes opening a ticket. - Great. Thanks
2) I found a problem. I spent 2 hours figuring out whose fault it is. - Hmmm, does the problem really matter? Can we just fix it on our side?
3) I found a problem. I spent 2 hours fixing it. - Is this really our problem to fix? Can we open a ticket and move on? (Note the similarity with #2)
4) I accomplished the task in a new way. - Is new also better? Does the solution also align with some ambiguous objectives that I haven't fully disclosed to you? Do I need to include you in more meetings so you understand more weird objectives (and then waste more time!)
5) I did a cool thing that you didn't even thing about! - How can I present this so Sr leaders get excited and approve working on this more?
#5 is by far the best, and I genuinely enjoy a teammember who is excited about something that also makes a positive impact - and I LOVE telling leaders why we need to change direction because of something new and cool that MY TEAM FOUND.
> some ambiguous objectives that I haven't fully disclosed to you
Isn't the one of the major pillars of Agile to let the devs know about all the objectives, so they can make better solutions? You know, the sole reason the Business Owner is one of major the scrum roles?
In your opinion, are the 5s possible without spending time on 2s, 3s and 4s? If one always stops working on a ticket after 5 minutes (scenario 1) and files a ticket "to be closed later" rather than investigating - and getting in trouble depending on how the investigation goes (2, 3) - how does the developer get enough expertise to get the big wins? How does a developer get experience implementing 5s without hitting an occasional 4?
My original comment is all about how you present your self in the daily standup.
You get 10 mins in the stand up. What do you say?
"I spent 30 minutes trying to fix a trivial thing that will get resolved as soon. As I get off the call" - bad idea
"Work is going slower than expected, but I'm making progress. Make sure leaders know this is REALLY hard" - better idea
"I spent all day making mistakes, but I eventually got something better than planned" - This is good
Here are some tips:
ASK FOR HELP. If it is a real problem, don't wait until stand up to ask for help.
Don't focus on the problems. If you talk about how you can't access email, it sounds like you spent 8 hours waiting for the email to come back (which, if true, I need to know about it much sooner)
Help me brag about you. I REALLY need to tell leaders that the team is rocking. Let me know when you: solve a hard problem, get good results, teach someone else something good, learned something from someone else. You AND I benefit if you do well.
> So no, you don't need permission to do something as long as it only takes an hour or so and you can hide it somewhere in your daily standup tasks.
If you're having to hide work that you think is a good use of your time, then communication and process has already broken down. It doesn't matter what methodology you claim to be using or complaining about.
So... in other words, exactly what I said: "agile only exists to explicitly prevent people from spending time on anything other than what they've asked for, and been granted, permission to do"?
No. Working on a team does that and has nothing to do with agile. Prior to agile ever existing I wouldn't go off on my own doing whatever I wanted for more than a day or so unless I checked in with my team. It's not about asking or granting permission, it's about being a good team member and communicating.
"Hey commandlinefan, I know you've been waiting a week for X, but I decided to go do Y. Oh, you needed X to finish something important, and could have gotten someone else to do it if I let you know? Yeah, I don't like to ask for permission."
> If "scrum" is being followed properly, there's somebody listening who's actually recording what you said you were going to do yesterday and compare it to what you say you did yesterday and call out any discrepancies.
Seems to me that if you can't justify why not keeping your stated commitments was in the interest of the team and the company, then the issue is with your communication and not the process itself.
Exactly. And if somebody wants to complain about a process methodology not working because management at their company is stupid or a bunch of assholes: nothing fixes that.
90% of the time the cure for needing to do "undercover" work is explaining that it is needed to accomplish what the company expects to get out of a task. It often happens that incorrect assumptions get embedded in a plan, and an engineer is asked to do X on the assumption that doing X will also accomplish Z, and they think, "Ugh, they want me to do X but they won't give me time to do Y and Z, what the fuck do I do, Z isn't going to get done and then it will be my fault because I was tasked to do X and they think that's the same thing." Just communicate: "I think what is expected is that if we do X then Z will also be accomplished. In this case, doing X won't accomplish Z. We will also need to do Y and Z, which is additional work."
Then if they say, "Just do X," you don't have to fret about Y and Z, because you have set expectations appropriately. In a dysfunctional environment, where the scrum master or project manager is mechanically executing a process without knowing what any of it means, you may need to escalate or reach out beyond the team to find somebody who appreciates your warning that X will not accomplish Z.
Of course there may be no such person, but in that case, no process will save you.
I've even seen this used effectively to talk about technical debt. "Look, I think the assumption in management is that we're making progress on moving away from the legacy services and deprecating our old auth solution, but in fact, if we do this we will be making ourselves even more dependent on the legacy services, and we'll be adding new public APIs that can't be properly secured. I just want to be sure that [manager's name] is aware that that is how we're shaving a month off this plan." Needle scratch, management wasn't aware that there was any downside to the expedited plan that project management had squeezed out of the engineers, because project management did not understand the language of technical debt. It was all engineer blah blah to them, and it didn't occur to them that management needed to hear it.
Very much this. I find it necessary to make even the most simple and obvious connections explicit in group contexts. This is even more useful when dealing with people who are further away from the problem, or aren't focused on the issue at the level of detail of the people in the trenches. I'm not sure I can tally the number of hours that I spent reminding people at the C-level that, while all the work being done related to removing dependencies on system Foo was useful work, if they still wanted application Bar, then system Foo was never going to go away and they'd still be stuck with ongoing licensing costs for system Foo. And I wasn't even trying to convince them to stop spending time and effort, I just wanted to make sure that they knew the actual cost that application Bar was going to be solely responsible for, so they could plan for it, or do better cost/benefit analysis.
It's sort of crazy, I'd get an oh, yeah, every time I'm mention some of these things, but the facts would sort of slip out of their minds. I think they'd also get together with other managers who were confident that system Foo would be going away in a few quarters who either didn't know about application Bar, or didn't need to care about it, and their enthusiasm would cause the details to sort of get mentally overridden.
There is definitely an art to managing expectations and making sure that efforts and goals and scope are aligned.
> Very much this. I find it necessary to make even the most simple and obvious connections explicit in group contexts.
This took me years, and I mean many years, to fully understand. I would say things like, "If we're doing X, shouldn't we also do Y? I mean, we need Y for Z...." which is not nearly as effective as, "If we are doing X, I think the expectation is that we will accomplish Z, but doing X will not accomplish Z."
Both statements say that if Z is desired, X will not suffice. But the scrum masters and project managers hear the first as "the engineers want something," which primes them to ignore you, and the second as "management expects something," which primes them to pay attention and process what you're saying.
The simple solution, I think, is to give permission. Look for ways to optimize, simplify, refactor. Do it within story work when that makes sense. Don't "hide" it but if you have some time, do what you feel is important and interesting let the team know what you found out. Set the example. You shouldn't need a JIRA ticket to improve the system, do a quick spike or take a s** and on my team, you don't.
Yes, at some point, management can ask you to justify the work you did. They are paying you, after all. Scrum and agile was never about letting people do whatever they wanted do. Management has already had a role in making sure there were appropriate limits set. In other words, if you're responsible for building a word processor and end up building a video game, I think it's appropriate for someone to ask what are you doing?
The issue with the process itself is how that justification is provided. If you have data to justify something, then the process works fine. If you don't have that data and need to put in some work to obtain it, then you have to somehow justify that work, and the only way to do that is by "getting permission", i.e. buy-in from the rest of the team.
If you put it in context of the situation described in "You Don't Need Permission", doing the customer discovery cannot be justified except through buy-in from the CEO. If Suresh (from the story) has a daily standup with his CEO, then he can't do customer discovery because of the process.
I think I'd disagree here. This article is not about scrum but about trust. Here's a quote from the article:
>As head of sales and marketing, Suresh didn’t need his CEO to buy into the process or give his permission to start the discovery process. He was in charge.
Suresh is a VP of marketing. It's his job to develop a plan, get buy-in, and execute on it. If the CEO is standing in the way, then all this boils down to is that the CEO is micromanaging his VPs. No process can solve for that.
The article is not about scrum. This particular thread of discussion is about scrum, because that's what the comment that started it was about, and also your comment that I replied to.
I was merely framing the discussion in terms of what is written in the article, to illustrate what the problem with scrum (or capital-A agile in general) is.
You are now replying to my specific example, instead of my argument about the problems with scrum.
Yes, because context matters. If you want me to respond to agile, this is why you don’t have management at standup. To prevent micromanagement. My whole point is that there’s nothing inherently wrong (or right) with agile. It’s a process. The success of it depends partly on the people involved. One principle of agile is the right people on the right team.
This kind of reply makes discussions about agile very frustrating for me. Not only does it conflate agile software development, as a set of practices, with the myriad of processes and practices like scrum, but it also deflects perfectly valid criticisms with insinuation that "you're doing it wrong".
Most people would never think of either pretending that the waterfall model is without problems, nor that it can never be successfully applied to any project. Why, then, is it not acceptable to admit that scrum does, indeed, have limitations that stem from the way it reduces the autonomy of the individual team members?
I'm not sure where "the right people on the right team" comes from -- it's certainly not in the agile manifesto -- but it's just the right grade of vague to be less than useful in practice. It's like saying that every problem can be solved in only two steps: 1) determine what you have to do, and 2) do it.
I don't see any reason for denying that scrum, in its most widely-practiced form, complicates or even discourages certain tasks and behaviors that can be beneficial under correct circumstances. It shouldn't be controversial.
Yes, scrum limits individual autonomy. An effective team that is working together is far more productive than an individual. As a manager/director/executive, I'm far more interested in optimizing and rewarding one of my team's performance than any individual on the team. That's what I mean by "right team right people". I would rather get rid of the 10x developer who is unable to work and communicate with others and instead put a 1x developer who is capable of improving his team. That is what I see as the divide here. Developers are focused on their individual performance whereas I am focused on the whole team.
> every day, you have to "stand up" and recite what you did yesterday and what you're going to do today. If "scrum" is being followed properly, there's somebody listening who's actually recording what you said you were going to do yesterday and compare it to what you say you did yesterday and call out any discrepancies.
This is the best explanation of this metgodology I’ve ever read
> This is the best explanation of this metgodology I’ve ever read [emphasis added]
I assume that is a typo, but if it is, it's my favorite typo of the week, because it reflects so well how I feel about that kind of daily standup: scrum masters who act like little tin gods.
Most of the companies I've worked with take a more practical approach, but I have been involved with some who did it exactly the way GP described. It really rubbed me the wrong way.
I don’t know. I think it’s not a bad idea to do some “stakeholder management”, especially if you’re in new country and/or organization that might be used to doing things differently.
Also:
> Given the ubiquity of Zoom, he could use it to rapidly get out of the building to the U.S. to test some hypotheses and gather some initial insights.
This is definitely easier said than done. But yeah it’s the right thing to do.
Maybe poor Suresh just wanted to vent a bit with an old friend? I wonder if he was aware that their conversation was turned into a blog post.
I recognise a bit of Suresh (if that’s his real name) in myself but still agree with Steve’s advice.
Suresh and his boss were already talking. “OK I’m on it and I’ll start sounding out some potential customers” would have done quite nicely I think, honour satisfied on both sides.
My gut feeling or guess is that Deep inside, Suresh knew it wouldn't work. Or it would take years and insane amount of effort to get it working in US. Because he knows medical in US is a bag of hurt. So may be telling his boss wasn't about permission, it is about getting the same level of understanding what the heck they are getting into. And setting some level of expectation ( Burning lots of money ).
I am also reading his boss is overly excited on the idea. Mostly likely because of some stupid marketing research big number of TAM and potential revenue without thinking much about the consequences. And I have seen far too many of these people in charge of business.
Maybe his boss had already oversold it to the board, and was setting Suresh up as the scapegoat for its failure.
Maybe Suresh knew this and was trying to limit the failure so that he has some kind of plausible justification when the shit hits the fan.
The interesting bit is what Suresh does if his Customer Discovery process discovers that there's no way this will work in the USA. Does he go back to the boss and tell him that (and what does he do then if the boss insists on going ahead)? Does he re-invent the product for the USA without telling his boss? Does he just resign because he's been put in an impossible position?
>Maybe his boss had already oversold it to the board, and was setting Suresh up as the scapegoat for its failure.
That was what I wanted to mention but didn't write it out. Cynicism are not always welcomed.
I have been in far too many of these shit. It isn't things cant be done. But you need full trust and autonomy with lots of money. i.e Is the company willing to burn millions?
Saying just go and do it is easy without giving them resources and budget. And that is precisely what the CEO should have done. CEO should have sat down and talk him through. Giving him full support. So they both know what they are getting into and they are in it together. This is more common with founders but not CEO or managers.
And this happens a lot, I would even call it a norm outside of Tech industry.
On your last point: Yes, there is naive excitement around ideas. And it's easy to dismiss it. But then again: What is certain anyway? What would get started if you didn't systematically and naively dismissed risks?
> I wonder if he was aware that their conversation was turned into a blog post.
To that, Prof Blank might reply that he didn't feel he needed permission!
More seriously, I definitely agree that just because Zoom is available, that doesn't make this easy to do. Indeed one might have said the same thing 50 years ago slightly differently, Zoom or no Zoom:
"Given the ubiquity of the telephone, he could use it to rapidly get out of the building to the U.S. to test some hypotheses and gather some initial insights."
"I think, says that everything you do illegally, you do efficiently. This, of course, is perfectly obvious. For one thing, you do not write at all because writing on an illegal project is suicide. For another thing, you work with whatever equipment you have on hand, and of course, you do everything on your lunch hour, which starts at 8:00 in the morning and finishes at 5:00 in the evening. Another thing, when it doesn’t work well and it is illegal, you drop it very quickly and kill the project."
- Sidewinder: Creative Missile Development at China Lake, Ron Westrum
There are two kinds of Steves in this world: Blanks and Klabniks. There are the Blanks, who write about not needing permission, and there are the Klabniks, who write about needing a borrow checker.
• The Steve who told me I would never be able to write a 6502 disassembler because "this is a microcomputer, and it operates on completely different principles than the mainframes you've worked on." (He was neither a programmer nor a hardware engineer.)
• The Steve who threw out several months of my Python work and ordered it rewritten in C++ because "we need precision in our calculations, and C++ has both floats and doubles, where Python only has floats." (He had a Python certification at our company, but he didn't know that a Python float is the same as a C++ double, a 64-bit floating point value.)
I've been having fun transpiling python floats into rust f64 and c++ double last few months.
Sometimes the rust way of doing things is very detail oriented and breaks the smooth flow of thought to code that python enables.
Probably best to make that zoom call (write python) and then have an evidence based conversation about how you didn't lose precision and performance is as good as rust or c++.
Both of my Steves predated the pandemic, but yes, whether Zoom, face to face, or a phone call, that is excellent advice which I followed each time.
Unfortunately they were both very strong-willed, and I didn't get anywhere with either of them.
I ran into the first Steve at a natural food store in Palo Alto. We got to talking about this little computer company he was starting with a friend and how they needed a 6502 disassembler.
We didn't have a business deal or anything, but I was curious about the 6502 and it sounded like a fun side project, so I got to work on it.
He called me a couple of days later to tell me I wasn't capable of doing it. I tried to explain that I'd written code on a variety of computer architectures and the 6502 was a fairly simple one, but he said "I'm sorry, my mind is made up. You couldn't possibly do this."
I said to myself, "who is this Steve guy telling me I can't program?!" I went ahead and wrote enough of the disassembler to be a good proof of concept.
Our phone call hadn't gone well, so I decided to visit their office with a printout and show him the code. It was listed at 770 Welch Road, near the Stanford Barn.
When I got there, nothing looked like a computer company, there was just a row of telephone switchboards. I told one of the telephone operators I was looking for Apple Computer, and she said "um, this is their answering service." So I walked out and told myself, "These guys are flakes. They're never going to make it."
The second Steve was a little less interesting. I found out about his objection to Python floats near the end of a team meeting, and he had another objection too. Some of our code would need to be written in C++ regardless, and there was no way to call C++ code from Python. I told him about CLIF and SWIG, which were both widely used at our company, and I explained the float vs. double thing. But like the other Steve, he said "my mind is made up, we have to rewrite everything in C++."
Knowing what I know about Steve Jobs, I have to wonder whether the whole thing was a bait to get you (and everyone else he mentioned it to) into proving the concept before they signed a contract. What do you think? You reckon he was baiting you or it was an honest mistake?
That is a really interesting speculation, and of course we will never know the answer.
I do think it was ignorance about programming, combined with Steve's infamous arrogance. I'd programmed in machine language on a few different architectures by that time, and not just assembly but binary machine code too. To me the 6502 just looked like another instruction set.
But as you might guess, I have sometimes wondered "what if" I'd pushed back more.
Would I have ended up a billionaire or at least a multi-millionaire?
Or would Steve have driven me to the brink of despair, as he did with a few other people? (One dear friend of mine once said in an interview, "You may find that some people who worked with Steve won't want to talk about their experience.")
Or perhaps worse for the world in the long run, could my involvement have led to Apple Computer's downfall? The dirty little secret is that I didn't have a 6502 chip to test my code on, but I was working at Tymshare [1] at that time, I had a Teletype [2] machine at home, and Tymshare had a 6502 emulator that I used to test my code. Oops! What if they had gotten wind of this and sued me and/or this little Apple Computer company?
Indeed you are correct. In fact, when I was writing my comment I just said "(He was not a programmer.)" and then decided to add "nor a hardware engineer" to disambiguate.
I didn't want to put in the second Steve's last name (hoping not to burn too many bridges), and I liked the parallelism of just mentioning each one by first name.
Well, the second Steve case really depends on the overall outlook. If a big chunk needs to be in C++ then the question is, do you really want to have two languages at the problem? Especially if the goal is a shipable binary later (which is possible but painful in python). Also it is a question about available stuff.
Yes, those are valid and important considerations. In this case it didn't need to be a shippable binary, it was just run internally. We had the infrastructure to seamlessly handle a mix of Python and C++, and the team members were familiar with both languages - other than the exceptions noted above.
This was a set of geographic data importers for some messy data in a variety of formats from multiple countries. The data quality was so bad that north and south were sometimes reversed, or even worse, north and west would be reversed, among many other problems.
This required a lot of ad hoc code to clean up the data. It was originally written in C++, with all the data importers linked into a monolithic binary with an eight-minute build time for a one-line change. (Or a half-hour for a full build.) So if you spotted one data error and wanted to clean it up, it was an eight-minute wait to try your code.
When I changed it to use a Python front end that cleaned up the data and fed it to a simplified C++ back end for the compute intensive part, the C++ code hardly ever had to be rebuilt, and there was no build time at all for the Python part. So you could explore the data interactively and easily figure out how to clean it up.
Technically, this was a huge win.
Socially, not so much.
OTOH, if you ever interview me and ask the "behavioral" questions: "Tell me about a time when a project went really well" and then "Tell me about a time when a project didn't go so well", I can use this episode for both questions!
Thanks. I agree, this is like a textbook case when to use a hybrid approach. Maybe the manager wanted to make sure he will always have enough people assigned to the project (so make it more difficult to maintain)? (A very dark management pattern)
The idea that py2many is pursuing is to avoid having to deal with two languages and interfacing via python C-API. In other words you write your C++ or Rust with the python syntax, fixed width, signed/unsigned integer types and static typing and transpile to get the same effect as writing C++ by hand.
You'd give up any dynamic features of cpython in the process.
Indeed it does, but see my other comment in the thread. We had some compute intensive code that needed to be in C++, so using a double (or "float" in Python) gave us a common datatype for both languages.
> If you’re in charge or part of a customer-facing organization, you don’t need to wait for permission to talk to customers to test hypotheses
This is pretty important and seems to get overlooked.
If you're trying to kick off an initiative that benefits customers, but not in a manner that can be quantified to business stakeholders (one we've struggled with is getting management support to build tools that improve API documentation for customers who develop on our platform), reaching out directly is a useful way to gauge the landscape and come back with a better understanding of who your target customers are and what they struggle with.
That's evidence from the horses mouth that you can take to management to get sponsorship for your project.
Article is nonsense. He's just found a way to dismiss a problem that guy has in a way that makes him feel superior. "You don't need permission" -- is a way to try to assert a higher status and pretend there is no real problem, rather than having to acknowledge a problem.
The CEO needs to be onboard with something as critical and basic as customer discovery. If he doesn't like the idea then that actually could interfere, and is bad news for the organization. And actually could disrupt the process and cause a conflict with the boss if he tries to do it in the open. Of course he has to do it anyway, but the boss not buying into it is not something he can just ignore.
Its a critical judgement error and also partly a rejection of the expertise of the employee and a failure to incorporate basic information into the overall strategy.
So I hope he is successful in his discovery and the rest of his job, despite his boss's poor judgement.
But as far as the article, I am not a fan of people that dismiss real problems and try to gain status by putting others down in a backhanded way, which is what the title is.
It's clear the issue was about how that wasn't working. I'm sorry, but that sounds like pretty naïve. Many of us have worked for these kind of CEOs, with enough experience to think they know what they're talking about but not enough actual education to make the right decision.
Managing someone is about enabling them, not bullying them. The CEO doesn't 'get to ' make the decision, they are tasked with making the correct decision. That means understanding from their experts all the issues. The CEO in question seemed to be ignoring their expert.
I don't expect every CEO to do what I described, but if your CEO doesn't want to listen to you when you're supposed to be the head of sales and marketing why would you continue to work for them?
The guy raised possible issues with the CEO's plan and was ignored. If he's worth his salt, why wouldn't he be looking to find another company where he's valued more appropriately for his role?
What you "can" and "cannot do" should be formalized in the organisational structure. If it isn't you'll always run to your manager and ask for permission, this can be problematic if your manager is micromanaging, then you'll constantly have to meet expectations you don't anything about...
I see. My team would literally never hear about this discussion with the CEO. We'd start working on US operations and I would assign some people to do Lean user validation. As would be my prerogative in that role, as they would already know how to do and would be expecting to do as a first step.
As head of sales and marketing, Suresh didn’t need his CEO to buy into the process or give his permission to start the discovery process. He was in charge.
Is this some kind of business rule I'm ignorant of? No matter what my title says I'm in charge of, if I start doing something I already know my boss doesn't want me to do I'm going to be in trouble. It's all well and good to say "Fuck you, the paper says that was my job" but that's not going to help you if the boss decides you need to go.
`Customer Discovery` is always critical, and it is Product and Marketing people's job mostly. They need to discover something, a positive sign, BEFORE going to build the thing. They are scouts. They can use MVP's, small prototypes or even mocks to validate the path.
However most of the time managers skip that step. They want to move the army of the engineers towards a path where the path is not scouted enough. They want to first build the thing then try to sell or do marketing about it. What they miss is people's time and money, or in ancient times it was people's lives. It is really bad for a C-level or a leader.
What Suresh should have done is just doing it, because it is in his job description as a Sales and Marketing person. Besides producing marketing jargon, nice presentations or creating weekly reports to the C-levels; he should go there and discover customers, needs, potential sales. If he fails the discovery there is 2 outcomes. First he is a bad explorers, then you need to replace your P&M guy, sorry Suresh. Second, there is really nothing to discover. Then this is good, it can prevent a catastrophe, a potential bankrupt due to going to the wrong way. No offense C-levels, you should thank Suresh.
It seems clearly implied that this quick-moving CEO is demanding a US product launch without giving Suresh the time and budget to do it properly, so priority changes from doing the job of a "head of sales and marketing" to not being blamed for taking a risk.
The article reads more as "you don't know what customer discovery is" and less "at your position you don't need permission". The title implies the opposite.
Or care about looking like he is in control and knows what is going on in his department? (With the usual caveat that I of course no nothing about your particular situation.)
Sound advice. I would add find allies. Executive types are very politically savvy and will listen to you more if you have other executives or influential people backing you up.
The irony is that one statement "Worse, given how expensive clinical trials are in medtech, I’m concerned if we build a product that isn’t commercially viable, we’ll be out of business before we even start.” actually makes it clear the real problem is they need permission for the device.
So it is more like 'you do not need permission except when you need permission' (no permission to ask your manager, but you still need approval by government agency)
Isn't that for the CEO to decide, whether or not he needs permission? “We’re disruptors! Discovery is going to slow us down. We need to move quickly!” sounds like a pretty clear strategy statement. And in turn it's for the board to decide whether their CEO is making reckless decisions and needs to be fired for putting the entire company at risk.
I realise that if you're dealing with incompetent and dangerous retards as bosses you have to sneak sound practice in under the radar. I'm sure that's how things like version control and automated testing made it into many software organisations. But it needs to be realised that this is an extremely toxic work environment and shouldn't be brushed off as easily as saying "you don't need permission".
Ideally yes. But i would be concerned that 6 months later the CEO asks me why sales aren't ramping up and doesn't want to hear that we were selling the wrong thing because of insufficient upfront analysis. Meanwhile the board might have heard a version of events from the CEO that subtly shifted the blame away from him.
Concerned? That's the entire skill set of a CEO - spinning things. You can take it as a given that the board is hearing exactly what the CEO crafts to maximize their success. Nothing subtle about it.
