July 25, 2025 • 28 mins
In this Episode, the hosts discuss the impact of layoffs at Microsoft and the broader tech industry, the evolving roles of consultants in the age of AI, and the challenges of requirements gathering in software development. They emphasize the importance of adaptability, user feedback, and the need for companies to navigate the changing landscape of employment and technology effectively.
Takeaways
The average worker faces 275 interruptions daily.
Microsoft's layoffs reflect a shift towards AI focus.
Job security is a growing concern in the tech industry.
Consultants must continuously adapt to new technologies.
Requirements gathering is often fraught with challenges.
Prototyping and user feedback are crucial for success.
Small incremental changes are preferable to large overhauls.
The role of requirements in software development is evolving.
Companies must educate themselves on software development processes.
Change is inevitable in the tech landscape, and adaptability is key.
Sound bites
"Microsoft cut 6,000 jobs in May, 2025."
"Our job titles will change as well."
"Requirements gathering is a minefield."
Chapters
00:00 Intro
00:33 Requirements Gathering: Challenges and Best Practices
01:44 Navigating Client Expectations and Change Management
02:45 People need to reinvent themselves
08:26 Decision-Making Dynamics in Teams
09:08 Engaging Stakeholders in Requirement Reviews
10:12 Prototyping vs. Traditional Requirements
11:52 The Future of Requirements in Software Development
12:56 Understanding Requirements Debt
14:17 Key Takeaways and Recommendations
14:24 Managing Interruptions in Work Environments
17:52 The Role of AI in Productivity
19:26 The Future of Work and Notifications
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:25):
The number of the day is
6,000 layoffs.
Microsoft cut 6,000 jobs in May, 2025.
It's 3 % of head count.
And it's preparing another round in July and mainly at sales and customer facing teams asit refocuses on AI.
What do you think it will affect?
Do think from our delivery point of view we'll have more people available?
(00:45):
I can go first.
think we'll see a huge impact on that when it comes to a partner's Maybe I'm biasedbecause I'm from Northern Europe, from the Nordics.
So the layoffs weren't really in our region in those magnitudes as in, for example,Redmond.
(01:10):
Lost some good people from engineering.
I'm not going to contradict that.
But I'm not convinced that there's going to be a huge product or persona impact withstakeholders and the tech, per se.
Areti, what do you think that some people say they're all going to be rehired after thefinancial year starts again?
mean, some of them maybe they might go for other positions in Microsoft because this isthe thing with Microsoft.
(01:33):
They are laying people off, but then at the same time there's job ads coming out, right?
So it's the net effect of it.
Will some people want to reapply?
Yeah, probably.
Will they get hired again?
Yeah, possibly.
It's the way they work as a business.
But what I would say as well is from speaking to people that work for Microsoft, they tendto also have the mentality that
at Microsoft as a one-year contract, that if you get renewed, that's a great thing, butyou shouldn't assume it.
(01:58):
There's people that have gone through multiple layoff rounds while they've worked forMicrosoft for 10, 15 years.
But I think as time goes on, we will see people that have worked for Microsoft for many,many, many years, less and less potentially.
I think there is an element of
temporariness when you work for Microsoft, nothing's forever.
(02:20):
But I think even more so now, the way that technology is changing, they have torestructure their business because I think we have to remember Microsoft is a business
that is focused on still existing in a hundred years.
They are not focused on making money year on year.
That's not the game that they're playing from a business strategy perspective.
So they have to make choices like these inevitably if they are to continue existing.
(02:44):
So we have to remember that as well, as unpleasant as that is.
People think that somehow AI replacing jobs, but what we can hear from Microsoft is notactually that is actually infrastructure for AI needs money.
If it's a team leader watching us or maybe like a practice lead, does he need to worryabout his own job security, working for a partner, working for a customer?
(03:04):
What do think?
I think we all need to worry about the environment in which we are operating in becausetechnology and the IT industry in general, we have tough margins that we need to meet I'm
talking about Europe and the UK specifically, because it's my kind of backgroundexperience.
So we don't have the unlimited infinite budgets we once had, which were really good fun.
(03:28):
We now have customers that are actually looking to
reduce their spend and do more with less.
obviously AI is all about doing more with less as well.
So they're looking for that kind of economy of scale for lack of a better word with theirtech.
So I think we are as partners operating in a more difficult environment now and ourcustomers are, and that's why we are.
(03:50):
And that's why also Microsoft is because it's all, we're all affecting each other.
We're all connected in this IT wheel of life.
So.
Yeah, but our job titles will change as well and what we're doing will change.
How many of us have business applications in our job titles right now?
Probably won't in a year, if not earlier than that.
(04:12):
Yeah, I think, I think one thing that, people need to be conscious of is developingthemselves, self-development.
I've been, I've been telling that story for six or seven years to my colleagues, toothers, you know, other, other, other professionals, to partners.
We all know that it's a constantly evolving journey, being a consultant in businessapplications or AI or whatever we wanna call it.
(04:39):
And I think in AI business solutions, and I think in the past, and I wanna argue, I thinkin the past four or five years, people have gotten by fairly well without having had a
very deep need to dramatically.
reinvent themselves and to read to grow professionally dramatically in a dramatic sense,but I think that now in the age of AI That has finally changed I've gotten by Five six
(05:08):
seven years without Becoming a deep dive a learner in power bi or canvas apps and that'sbeen a tech choice for me Because I like to wave my hands.
That's another story but in the age of AI
You really need to pick up those skills.
Everyone needs to pick up those skills, not just consultants, but also all the managementlayers.
And then, are some of those management layers or practice directors, what do we want tocall them, will they become redundant?
(05:34):
Honestly, I don't know.
But I think if they don't get the idea of AI, they will become redundant.
So let me be here the contrarian.
what kind of signs we will have for project leads, team leads to be redundant, to make theredundant.
Actually what we see happening on Microsoft and it's more sales and customer service.
Humans in a loop need to be stayed around and just checking what's going on there.
(05:57):
I feel that more senior role you have in the team, the safer you feel.
But what do you think about this more contrarian view?
I think your role is different if you're in senior management or senior leadership in apartner because you're not doing the building anymore.
You're looking after the people that are doing the building, but you have different skillsand experience that you need to use.
(06:17):
Being a good leader, does that change over time to a certain extent, but not as much asbeing a good consultant to Antti's point.
It's a lot harder being a good consultant.
then it is being a good manager or a good leader.
Not that that's easy for some people to be a good manager or a good leader, but they aresoft skills that you need to practice and to a certain extent learn and then you learn
(06:38):
them for life.
Whereas if you're a consultant and you're learning skills right now, you are in thatendless circle of learning new things on a platform that is changing, on software that is
changing, on infrastructure that is changing, on security that is changing, on a cloudplatform that is changing.
And it's...
It's a huge stack, the Microsoft stack.
(06:59):
So you have to by default specialize in certain areas of it.
It's impossible otherwise to be an expert, so to speak.
But it's very, very hard and you have to be okay with
things changing all the time around you and being out of date fairly often.
And that can be very unsettling for a lot of people.
(07:19):
So it's not for everyone.
just to be a contrary again, I think that was that kind of narrative of change was herefor decades now.
how managers against consultant, because I like this angle, so managers against consultingconsultants in AI age.
whose job is most secure.
what a question.
don't think that, well, I think that consultants, I think that's a given if they don'tpick up the skills that are required in today's world, then they are going to be out of
(07:49):
date.
I think that's a no-brainer.
To what extent is something that remains to be seen?
How well versed do I have to be in AI and in which areas of AI?
What do I need to be able to build, consult on and so on?
That remains to be seen.
But the investment is pretty big.
(08:13):
At least I felt that way.
Then for managers, I think like my brain,
keeps coming back to where is our business going with AI.
And that's primarily my point when I say that managers also need to be able to pick up AIand understand what it is, especially in an ecosystem, what I call a brand owner
(08:34):
ecosystem, where not nearly every single one of us are ISVs, independent software vendors,but we are in a true time and materials or fixed price based consulting business.
So as managers, managers need to be able to steer that business in a, you know, in an airquotes right direction to take their business into AI.
(08:54):
And that's easier said than done.
I mean, that's a lot easier said than done.
think that's what I'm seeing the majority of again, the majority of consultancies partnersstill doing the same thing today as they've always done.
We're still in early stages, but the faster we can pivot to being
I don't want to say AI first, to really have our strategy and our business in AI, thefaster we're going to succeed.
(09:21):
AI aligned.
AI aligned, yeah.
Are we ready for Wheel of Fortune segment?
How do you feel?
Yeah, let's do that.
Yeah, because we're trying to do something for listeners who joined us first time.
We're going to, we have a list of topics pre-cooked for the session.
All of them are very actionable and they were very practical for people who run teams, forpeople who do delivery and manage delivery.
(09:46):
So since we have so many brains on this session, we want just to give you actionableitems, but we don't know the topic, no one knows, so only Will of Fortune will tell us.
So how it works, we choose the topics and then, sorry, the Wheel of Fortune will choosethe topic and it will choose somebody who has to be contrarian.
The working title for that role is FNO Lead, Facts and Objections.
(10:11):
and I hope that you will enjoy and you'll have some fun listening to our conversation.
So let's choose the first topic.
So the first topic is, can somebody read for me because I have it mirrored.
minefield.
Who will be the contrarian in this call?
Oh, it's you Antti.
So that was easy.
(10:31):
Okay,
so requirements gathering.
Let's give something actionable.
Let's you have an elevator pitch and we have like 15 seconds, no, 50 seconds, half aminute.
And just we need to give them like true like meat of requirements gathering, what kind ofpitfalls and already you'll keep us checked if we start going too much into what official
(10:54):
Microsoft wants to hear and you can give your opinion too.
So no, maybe Auntie you can start.
No, you've let go ahead.
I'll pick your brain based on yours.
For this one, I don't want to go first.
Okay, gotcha.
So for me, the key thing about requirements gathering is I actually do not believe in along list of requirements, you all days of waterfall.
(11:18):
And I remember I've been on the project years ago in the corporate days, my corporatedays, and we had like a specification of, I don't know, it was like 10 pages, 20 pages,
all of them were just requirements, requirements, requirements.
So the next iteration was user stories, which was just a more fancy way of capturing thesame requirements.
But I honestly believe I'll be in workshops.
I believe in design thinking.
(11:38):
you have, if our listeners heard about that stuff, if you have never checked it, just goand check it.
It's just you run workshops.
You just ask people, tell me what you're trying to do in your existing system.
Tell me how you see your future and when you can map it out and let everyone else in theroom to see what's going on.
Just even if it's those small stickers match to the wall.
That's your starting point.
(11:59):
It's not an Excel spreadsheet So this is my quick run and I can obviously go deeper about,yeah, Antje, what do you think?
Yeah, requirements gathering.
I think it simply depends on the consultants consulting and then the business users andhow they get along.
(12:19):
The methodology that we have, whether it's just waterfall requirements filled in Excel,user stories and with their acceptance criteria.
They can both work.
might neither or neither of them might work.
I think it comes down to chemistry and to again, chemistry between those, let's say two,three, four people that are doing the requirements together.
(12:46):
But naturally, know, it's like still the consultant.
I think they have the biggest lead on that.
And the biggest responsibility is on them.
I think that
simply time and attitude plays the biggest part.
If there's not enough time to do those workshops and to go through those, whatever youhave, user stories or whatnot, and you don't have the attitude to actually go and do it,
(13:11):
then we're gonna fail.
I think those are the two biggest pitfalls.
You can do lots of
Again, you can do lots of kinds of things.
You can do dialogue mapping.
I know Paul Combsy, I try to follow him on dialogue mapping.
That's his area of expertise.
You can do a lot of different things, but still, no matter how good the consultant is withtheir methodology, if the attitude isn't there, you're not spending enough time on it,
(13:39):
then you're not going to succeed.
All right, what do you think?
Did we share any BS, any things which are unreasonable?
No, I think it's reasonable.
think for me, one thing that we need to remember is that we have a role to play asMicrosoft partners and our client has a role to play as well.
And we have all been there where a client comes up with a boil the ocean list of thingsthat they want the software to do.
And we know from our experience of projects that if you try to give people too many newthings all at once, that will be very overwhelming for them and they need time to adjust.
(14:08):
So there is that element of change management that
tends to be little bit forgotten and adoption as well in terms of how new systems aregoing to be implemented, how are all systems are going to be commissioned, the data, the
data, the data, the data that gets forgotten as well all the time until it's too late.
The data, yeah.
(14:28):
But also the fact that you can't be all things to all people.
So if you've got too many stakeholders telling you what they want the requirements to be,and they're very inflexible and they want everything on day one,
and they are not willing to make compromises, it makes it very difficult to deliver valuequickly.
And I think this is a thing that we need to consider when looking at requirements.
And that's the minefield of requirements or user stories or whatever you want to callthem, is that you should be looking to invest in software and then get value out of it
(14:54):
quickly.
And if you, the bigger you make your list of requirements, the longer it's going to takefor you to have a system that is working and is actually giving value and is fixing
whatever problem you're trying to fix by implementing it.
And you have to know what that problem is and you have to know how to monitor it at theend that it's actually making a difference.
yeah, small steps are better than big bangs.
(15:15):
Starting small and then going from there because once you have something live inproduction, then you'll get feedback from people and you'll get buy-in and you have to
make sure that people feel like it's their system, not the system that's been put inplace.
Yeah.
Do you have any horror stories from where you can share here?
Because I have one.
Do you have any?
I mean...
(15:38):
Not giving names.
This...
Okay, I'll share my story.
Yeah.
I think it's a, I think the, I have horror stories of, know, systems going live and no oneusing them.
That cost millions, you know.
oh can share, but requirements related, yeah.
requirements gathering wise, I've had situations where the client has said, I don't knowwhat my requirements are, can you tell me?
(16:02):
You're a consultant, can you tell me?
Yeah, yeah, yeah.
Can you please give us acceptance criteria?
No, not really, we just wanted to do this thing.
Yeah, can you write our user stories for us?
Can you write our acceptance criteria for us?
There are good ones as well, but I would be lying if I didn't say that there are more badones than good ones.
(16:27):
I don't know if that tells something about me or something else.
I think for the good ones, sometimes you just hit it off with a customer.
The chemistry just works.
Like I said, I'm repeating myself.
And I think when you just hit it off with a customer and you have good chemistry,requirements gathering tends to go a lot easier.
(16:48):
The other opposite I think is when business simply has no idea what it's like to be in asoftware project and to talk about requirements, how to define them, how to define
acceptance criteria.
when they've either never done it before or they don't get training for it.
(17:14):
So yeah, I do the pros outweigh the cons in experience wise?
For me, unfortunately not.
I'd say that for actual bigger projects, I have more horror stories or cons than I do havethose pros.
Antti touches on something very important there actually, which is the amount of time thata software project takes for the people that need to do these things like requirements
(17:36):
gathering.
Because a lot of the time, and I'm sure we've all been there, those people have a job todo and this is thrown at them sometimes very last minute.
And they've got to try and juggle having a job or having a team or running the businesswith having conversations and workshops and giving us this information and documenting
what's there.
give to the consultants so they can understand it better, that kind of thing.
(17:58):
there is, think a lot of clients underestimate how much time of their own teams it's goingto take to support a software development project.
And sometimes you get big delays because of that or frustrations.
And like Antti says, it's the time.
Sometimes people just do not have the time.
And I think a lot of times we go too fast from defining requirements and their acceptancecriteria to, user stories and their acceptance criteria, again, whatever we want to call
(18:24):
it, to actually trying to implement them.
And the reason I'm saying that is a lot of times what I'm seeing is when we're coming upwith a requirement and kind of defining this is how, like, this is what we want to do.
we get an internal debate at the customer on that immediate first level stakeholder andthen their manager sometimes even kind of three levels up on how should this thing work.
(18:50):
The first level stakeholder says that, this is how it works.
I own this process.
This is how it works.
And their manager comes in and starts contradicting.
the initial stakeholder and there's too much internal debate that I'm seeing withcustomers.
And I think that throws easily throws off the entire budget causes, the project and budgetcauses delays and causes just overall confusion.
(19:15):
Don't you think there is something on us, know, people who have to supervise and see howconsultant interfaces with the end user.
if I as a consultant spent all day creating this requirement, you need to spend at leastone hour digesting and writing and giving me feedback.
Well, usually end user has no more than five minutes.
It should be super simple to digest.
Yeah, you would have a lot of different levels of detail that are needed.
(19:38):
You'll have your product owner that needs to sign everything off and say, yeah, this iswhat we want.
But then when you go up a level, you wouldn't really specifically be talking about userstories or requirements.
You were talking about in more generic terms, high level terms.
And you should be, otherwise you're going to lose your audience completely.
And the higher up you go, the less time those people have.
(19:58):
They want you to get in, get on, get out.
So if you don't need anything start by hey, I don't need anything from you.
I just want to give you information on X otherwise, you know be very clear what whatyou're looking for and we need to be Clear as well in terms of who's responsible for what
and who makes decisions on what?
Otherwise you're going to have a situation on your hands where you've got a deadlockbecause people can't agree on a way forward.
(20:22):
How much time we need to assume the VP would spend on signing off those requirements,signing off that acceptance criteria.
I'm a big fan of visualizing things and not humongous blocks of text or lists ofrequirements or things like that.
I think it's if you visualize a process and you say, this is what you do right now.
This is how we need you to change the process for whatever reason.
I think those are the kind of conversations I would expect to be had at that level, notreally the user stories themselves.
(20:45):
tangible, you talking we need to have like, do not assume that you have more than oneslide, or do not assume you have more than five minutes, or you actually, or if you want
really have people in the room go and run some kind of session, be there.
Yeah, I think that the, I think that the kind of like the first level stakeholder thatunderstands the process that we're talking about should be proficient enough to sign off
(21:08):
on that without their higher ups.
having to contradict them.
think if their higher-ups contradict them, then there's a bigger problem.
The higher-ups would need to understand the high-level importance and meaning of thatrequirement so they can validate that it actually is something that this process
(21:34):
revolves around and then this is the way the process works.
There's not a need to change that process.
That's of course something that we oftentimes do.
The higher up says, hey, this Barbra, we don't want this process to work like this.
So it becomes process development and then things get out of hand.
Now, should that happen?
I think it depends.
You don't wanna build a system that
(21:56):
that's based on incorrect processes.
But what I am saying is that those things should have been thought through before we getinto that requirements gathering.
And then the higher up should kind of give a glance on, this is what John Doe or Jane Doeare saying about the process.
This is how it's defined.
This is how it should work, looks good.
(22:19):
Let's proceed.
So just to make it a little bit more spicy, what do you think if it wasn't for contractreasons, for legal reasons, do you think we could get away with not writing any
requirements or be as light as possible, just moving from prototype to prototype, justshowing to customer every week something new going on?
What do you think about this?
(22:39):
What's the pitfalls?
What's the advantages?
I think that it's a great way to go generally.
Even if you have requirements, you should be doing regular show and tells because justbecause someone says they want a black car, that can be interpreted in many different
ways, right?
There's a black car and there's a black car.
So seeing the system is and getting feedback from users, that's what validates whetherwhat they ask for is actually what they meant.
(23:03):
Because a lot of the time we will ask for something and someone will assume that we meanX, Y and Z, but actually we don't.
We meant something completely different.
So regardless, think whether you have requirements or not, you should be doing thatprototyping process all the time, because that's the only way you know you're hitting the
target otherwise.
And that the target that you're hitting is the target they want you to hit to a certainextent.
(23:23):
But at the same time, I think there is that element of, yeah, the prep beforehand,particularly what problems are you trying to solve?
And can you slash should you change your business process?
Is your business process the problem?
Because a lot of the time we've seen situations where a very broken process is implementedin a system.
(23:44):
And actually people then start complaining about the system, but it's not the systemthat's the problem.
And you need to try and wiggle that out beforehand.
And it's time well spent because you don't want to spend a lot of time developing softwareto continue working in a...
to support the broken process, basically.
So for me, the process mapping side of things is more important than the requirements to acertain extent.
(24:05):
I'm a huge fan of let's just build, but I don't think it works for huge businessapplications, big systems.
It doesn't make sense when you're building a five million pound or dollar a year ERP, youcan't just jump into building and see how it goes.
But I'm a huge advocate of that approach in smaller engagements.
(24:29):
But I think Areti you said a lot of the
You said a lot of the gotchas there, the process, know, we have to have an understandingthat the process works, that we're not trying to, you know, fix a bad process with a
system.
But I don't think we need to go all in into requirements.
I think we can have something higher level and ensure that, like, look at the process andthen simply start building and fail fast.
(24:54):
And I do think that that's the direction where
We're going more and more with agents as well as applications.
You know, our canvas apps are model driven apps from Power Platform that we can now buildwith these, new things that Microsoft are releasing where you just give a prompt and you
(25:16):
get a functioning, a pretty, pretty well functioning app.
Plan designers or what have we.
So shall we declare in this podcast that requirements are dead?
Ha ha ha ha ha.
I agree with you.
If you can do through prompt engineering, build stuff, then fundamentally
majority of requirements are driven by contractual obligation, contractual management,relationship management rather than need, development need, So this is my horror story.
(25:43):
One of consultants years ago,
the consultants here was writing requirements as explicitly as possible and they were likereally elaborated multiple lines it was really hard to go through them and when it was a
critical moment came where customer was not agreeing to them consultants shown to can'tuse it to customer and say hey this is what you signed this your signature and is and the
client told I don't care what I signed up what I signed off I don't care about thisrequirement what I told this time I need something else so fundamentally if requirement
(26:10):
doesn't cover even from contractual point of view
Probably in the court it might work, but in real project if you sweat every single commathat probably goes away.
I think it is valuable because a lot of companies, and think Antti mentioned this as well,they might go into software development projects without having done software development
(26:30):
before or looking into exactly what is involved in software development and what's goodsoftware development and what's bad software development.
So there is that element of educating yourself before you go into that project and knowingwhat it will take for it to be a success from both sides of the fence.
In terms of our requirements debt,
No, think the prompt is effectively the requirement now.
(26:52):
So if anything, they may be more important than ever.
mean, wherever you want to have them is fine as long as, you know, they are accurate,valid and correct at the time of writing.
But this is the thing, we also need to be aware that things change very quickly, as wehave talked about earlier.
So just because something is the right answer right now doesn't mean it's going to be theright answer later on.
(27:14):
And the later on used to be five years from now.
Now the later on is probably
a year and half from now.
AI solutions right now, they'll probably be technical debt in a couple of years, which iscrazy.
But that's the reality of it.
Newer models, newer infrastructure, you name it, it's all moving very quickly to catch up.
So we need to be aware that what we're building right now may also have a much shorterlife than we've ever expected it to.
(27:38):
So the takeaway is that companies laying off people is inevitable if they want to survive.
We just have to deal with that change.
It's not necessarily always bad news.
You never really know what is right for you and what is wrong for you when it happens.
It's only in hindsight you find out anyway.
We've gone deep immediately.
(27:59):
But other than that, obviously we've covered the fact that
the kind of requirements, gathering exercise, don't boil the ocean, try things out, fail,make it okay to fail and fail fast and know what you're getting yourself into.
Do your research.
The number of the day is
6,000 layoffs.
Microsoft cut 6,000 jobs in May, 2025.
It's 3 % of head count.
And it's preparing another round in July and mainly at sales and customer facing teams asit refocuses on AI.
What do you think it will affect?
Do think from our delivery point of view we'll have more people available?
(00:45):
I can go first.
think we'll see a huge impact on that when it comes to a partner's Maybe I'm biasedbecause I'm from Northern Europe, from the Nordics.
So the layoffs weren't really in our region in those magnitudes as in, for example,Redmond.
(01:10):
Lost some good people from engineering.
I'm not going to contradict that.
But I'm not convinced that there's going to be a huge product or persona impact withstakeholders and the tech, per se.
Areti, what do you think that some people say they're all going to be rehired after thefinancial year starts again?
mean, some of them maybe they might go for other positions in Microsoft because this isthe thing with Microsoft.
(01:33):
They are laying people off, but then at the same time there's job ads coming out, right?
So it's the net effect of it.
Will some people want to reapply?
Yeah, probably.
Will they get hired again?
Yeah, possibly.
It's the way they work as a business.
But what I would say as well is from speaking to people that work for Microsoft, they tendto also have the mentality that
at Microsoft as a one-year contract, that if you get renewed, that's a great thing, butyou shouldn't assume it.
(01:58):
There's people that have gone through multiple layoff rounds while they've worked forMicrosoft for 10, 15 years.
But I think as time goes on, we will see people that have worked for Microsoft for many,many, many years, less and less potentially.
I think there is an element of
temporariness when you work for Microsoft, nothing's forever.
(02:20):
But I think even more so now, the way that technology is changing, they have torestructure their business because I think we have to remember Microsoft is a business
that is focused on still existing in a hundred years.
They are not focused on making money year on year.
That's not the game that they're playing from a business strategy perspective.
So they have to make choices like these inevitably if they are to continue existing.
(02:44):
So we have to remember that as well, as unpleasant as that is.
People think that somehow AI replacing jobs, but what we can hear from Microsoft is notactually that is actually infrastructure for AI needs money.
If it's a team leader watching us or maybe like a practice lead, does he need to worryabout his own job security, working for a partner, working for a customer?
(03:04):
What do think?
I think we all need to worry about the environment in which we are operating in becausetechnology and the IT industry in general, we have tough margins that we need to meet I'm
talking about Europe and the UK specifically, because it's my kind of backgroundexperience.
So we don't have the unlimited infinite budgets we once had, which were really good fun.
(03:28):
We now have customers that are actually looking to
reduce their spend and do more with less.
obviously AI is all about doing more with less as well.
So they're looking for that kind of economy of scale for lack of a better word with theirtech.
So I think we are as partners operating in a more difficult environment now and ourcustomers are, and that's why we are.
(03:50):
And that's why also Microsoft is because it's all, we're all affecting each other.
We're all connected in this IT wheel of life.
So.
Yeah, but our job titles will change as well and what we're doing will change.
How many of us have business applications in our job titles right now?
Probably won't in a year, if not earlier than that.
(04:12):
Yeah, I think, I think one thing that, people need to be conscious of is developingthemselves, self-development.
I've been, I've been telling that story for six or seven years to my colleagues, toothers, you know, other, other, other professionals, to partners.
We all know that it's a constantly evolving journey, being a consultant in businessapplications or AI or whatever we wanna call it.
(04:39):
And I think in AI business solutions, and I think in the past, and I wanna argue, I thinkin the past four or five years, people have gotten by fairly well without having had a
very deep need to dramatically.
reinvent themselves and to read to grow professionally dramatically in a dramatic sense,but I think that now in the age of AI That has finally changed I've gotten by Five six
(05:08):
seven years without Becoming a deep dive a learner in power bi or canvas apps and that'sbeen a tech choice for me Because I like to wave my hands.
That's another story but in the age of AI
You really need to pick up those skills.
Everyone needs to pick up those skills, not just consultants, but also all the managementlayers.
And then, are some of those management layers or practice directors, what do we want tocall them, will they become redundant?
(05:34):
Honestly, I don't know.
But I think if they don't get the idea of AI, they will become redundant.
So let me be here the contrarian.
what kind of signs we will have for project leads, team leads to be redundant, to make theredundant.
Actually what we see happening on Microsoft and it's more sales and customer service.
Humans in a loop need to be stayed around and just checking what's going on there.
(05:57):
I feel that more senior role you have in the team, the safer you feel.
But what do you think about this more contrarian view?
I think your role is different if you're in senior management or senior leadership in apartner because you're not doing the building anymore.
You're looking after the people that are doing the building, but you have different skillsand experience that you need to use.
(06:17):
Being a good leader, does that change over time to a certain extent, but not as much asbeing a good consultant to Antti's point.
It's a lot harder being a good consultant.
then it is being a good manager or a good leader.
Not that that's easy for some people to be a good manager or a good leader, but they aresoft skills that you need to practice and to a certain extent learn and then you learn
(06:38):
them for life.
Whereas if you're a consultant and you're learning skills right now, you are in thatendless circle of learning new things on a platform that is changing, on software that is
changing, on infrastructure that is changing, on security that is changing, on a cloudplatform that is changing.
And it's...
It's a huge stack, the Microsoft stack.
(06:59):
So you have to by default specialize in certain areas of it.
It's impossible otherwise to be an expert, so to speak.
But it's very, very hard and you have to be okay with
things changing all the time around you and being out of date fairly often.
And that can be very unsettling for a lot of people.
(07:19):
So it's not for everyone.
just to be a contrary again, I think that was that kind of narrative of change was herefor decades now.
how managers against consultant, because I like this angle, so managers against consultingconsultants in AI age.
whose job is most secure.
what a question.
don't think that, well, I think that consultants, I think that's a given if they don'tpick up the skills that are required in today's world, then they are going to be out of
(07:49):
date.
I think that's a no-brainer.
To what extent is something that remains to be seen?
How well versed do I have to be in AI and in which areas of AI?
What do I need to be able to build, consult on and so on?
That remains to be seen.
But the investment is pretty big.
(08:13):
At least I felt that way.
Then for managers, I think like my brain,
keeps coming back to where is our business going with AI.
And that's primarily my point when I say that managers also need to be able to pick up AIand understand what it is, especially in an ecosystem, what I call a brand owner
(08:34):
ecosystem, where not nearly every single one of us are ISVs, independent software vendors,but we are in a true time and materials or fixed price based consulting business.
So as managers, managers need to be able to steer that business in a, you know, in an airquotes right direction to take their business into AI.
(08:54):
And that's easier said than done.
I mean, that's a lot easier said than done.
think that's what I'm seeing the majority of again, the majority of consultancies partnersstill doing the same thing today as they've always done.
We're still in early stages, but the faster we can pivot to being
I don't want to say AI first, to really have our strategy and our business in AI, thefaster we're going to succeed.
(09:21):
AI aligned.
AI aligned, yeah.
Are we ready for Wheel of Fortune segment?
How do you feel?
Yeah, let's do that.
Yeah, because we're trying to do something for listeners who joined us first time.
We're going to, we have a list of topics pre-cooked for the session.
All of them are very actionable and they were very practical for people who run teams, forpeople who do delivery and manage delivery.
(09:46):
So since we have so many brains on this session, we want just to give you actionableitems, but we don't know the topic, no one knows, so only Will of Fortune will tell us.
So how it works, we choose the topics and then, sorry, the Wheel of Fortune will choosethe topic and it will choose somebody who has to be contrarian.
The working title for that role is FNO Lead, Facts and Objections.
(10:11):
and I hope that you will enjoy and you'll have some fun listening to our conversation.
So let's choose the first topic.
So the first topic is, can somebody read for me because I have it mirrored.
minefield.
Who will be the contrarian in this call?
Oh, it's you Antti.
So that was easy.
(10:31):
Okay,
so requirements gathering.
Let's give something actionable.
Let's you have an elevator pitch and we have like 15 seconds, no, 50 seconds, half aminute.
And just we need to give them like true like meat of requirements gathering, what kind ofpitfalls and already you'll keep us checked if we start going too much into what official
(10:54):
Microsoft wants to hear and you can give your opinion too.
So no, maybe Auntie you can start.
No, you've let go ahead.
I'll pick your brain based on yours.
For this one, I don't want to go first.
Okay, gotcha.
So for me, the key thing about requirements gathering is I actually do not believe in along list of requirements, you all days of waterfall.
(11:18):
And I remember I've been on the project years ago in the corporate days, my corporatedays, and we had like a specification of, I don't know, it was like 10 pages, 20 pages,
all of them were just requirements, requirements, requirements.
So the next iteration was user stories, which was just a more fancy way of capturing thesame requirements.
But I honestly believe I'll be in workshops.
I believe in design thinking.
(11:38):
you have, if our listeners heard about that stuff, if you have never checked it, just goand check it.
It's just you run workshops.
You just ask people, tell me what you're trying to do in your existing system.
Tell me how you see your future and when you can map it out and let everyone else in theroom to see what's going on.
Just even if it's those small stickers match to the wall.
That's your starting point.
(11:59):
It's not an Excel spreadsheet So this is my quick run and I can obviously go deeper about,yeah, Antje, what do you think?
Yeah, requirements gathering.
I think it simply depends on the consultants consulting and then the business users andhow they get along.
(12:19):
The methodology that we have, whether it's just waterfall requirements filled in Excel,user stories and with their acceptance criteria.
They can both work.
might neither or neither of them might work.
I think it comes down to chemistry and to again, chemistry between those, let's say two,three, four people that are doing the requirements together.
(12:46):
But naturally, know, it's like still the consultant.
I think they have the biggest lead on that.
And the biggest responsibility is on them.
I think that
simply time and attitude plays the biggest part.
If there's not enough time to do those workshops and to go through those, whatever youhave, user stories or whatnot, and you don't have the attitude to actually go and do it,
(13:11):
then we're gonna fail.
I think those are the two biggest pitfalls.
You can do lots of
Again, you can do lots of kinds of things.
You can do dialogue mapping.
I know Paul Combsy, I try to follow him on dialogue mapping.
That's his area of expertise.
You can do a lot of different things, but still, no matter how good the consultant is withtheir methodology, if the attitude isn't there, you're not spending enough time on it,
(13:39):
then you're not going to succeed.
All right, what do you think?
Did we share any BS, any things which are unreasonable?
No, I think it's reasonable.
think for me, one thing that we need to remember is that we have a role to play asMicrosoft partners and our client has a role to play as well.
And we have all been there where a client comes up with a boil the ocean list of thingsthat they want the software to do.
And we know from our experience of projects that if you try to give people too many newthings all at once, that will be very overwhelming for them and they need time to adjust.
(14:08):
So there is that element of change management that
tends to be little bit forgotten and adoption as well in terms of how new systems aregoing to be implemented, how are all systems are going to be commissioned, the data, the
data, the data, the data that gets forgotten as well all the time until it's too late.
The data, yeah.
(14:28):
But also the fact that you can't be all things to all people.
So if you've got too many stakeholders telling you what they want the requirements to be,and they're very inflexible and they want everything on day one,
and they are not willing to make compromises, it makes it very difficult to deliver valuequickly.
And I think this is a thing that we need to consider when looking at requirements.
And that's the minefield of requirements or user stories or whatever you want to callthem, is that you should be looking to invest in software and then get value out of it
(14:54):
quickly.
And if you, the bigger you make your list of requirements, the longer it's going to takefor you to have a system that is working and is actually giving value and is fixing
whatever problem you're trying to fix by implementing it.
And you have to know what that problem is and you have to know how to monitor it at theend that it's actually making a difference.
yeah, small steps are better than big bangs.
(15:15):
Starting small and then going from there because once you have something live inproduction, then you'll get feedback from people and you'll get buy-in and you have to
make sure that people feel like it's their system, not the system that's been put inplace.
Yeah.
Do you have any horror stories from where you can share here?
Because I have one.
Do you have any?
I mean...
(15:38):
Not giving names.
This...
Okay, I'll share my story.
Yeah.
I think it's a, I think the, I have horror stories of, know, systems going live and no oneusing them.
That cost millions, you know.
oh can share, but requirements related, yeah.
requirements gathering wise, I've had situations where the client has said, I don't knowwhat my requirements are, can you tell me?
(16:02):
You're a consultant, can you tell me?
Yeah, yeah, yeah.
Can you please give us acceptance criteria?
No, not really, we just wanted to do this thing.
Yeah, can you write our user stories for us?
Can you write our acceptance criteria for us?
There are good ones as well, but I would be lying if I didn't say that there are more badones than good ones.
(16:27):
I don't know if that tells something about me or something else.
I think for the good ones, sometimes you just hit it off with a customer.
The chemistry just works.
Like I said, I'm repeating myself.
And I think when you just hit it off with a customer and you have good chemistry,requirements gathering tends to go a lot easier.
(16:48):
The other opposite I think is when business simply has no idea what it's like to be in asoftware project and to talk about requirements, how to define them, how to define
acceptance criteria.
when they've either never done it before or they don't get training for it.
(17:14):
So yeah, I do the pros outweigh the cons in experience wise?
For me, unfortunately not.
I'd say that for actual bigger projects, I have more horror stories or cons than I do havethose pros.
Antti touches on something very important there actually, which is the amount of time thata software project takes for the people that need to do these things like requirements
(17:36):
gathering.
Because a lot of the time, and I'm sure we've all been there, those people have a job todo and this is thrown at them sometimes very last minute.
And they've got to try and juggle having a job or having a team or running the businesswith having conversations and workshops and giving us this information and documenting
what's there.
give to the consultants so they can understand it better, that kind of thing.
(17:58):
there is, think a lot of clients underestimate how much time of their own teams it's goingto take to support a software development project.
And sometimes you get big delays because of that or frustrations.
And like Antti says, it's the time.
Sometimes people just do not have the time.
And I think a lot of times we go too fast from defining requirements and their acceptancecriteria to, user stories and their acceptance criteria, again, whatever we want to call
(18:24):
it, to actually trying to implement them.
And the reason I'm saying that is a lot of times what I'm seeing is when we're coming upwith a requirement and kind of defining this is how, like, this is what we want to do.
we get an internal debate at the customer on that immediate first level stakeholder andthen their manager sometimes even kind of three levels up on how should this thing work.
(18:50):
The first level stakeholder says that, this is how it works.
I own this process.
This is how it works.
And their manager comes in and starts contradicting.
the initial stakeholder and there's too much internal debate that I'm seeing withcustomers.
And I think that throws easily throws off the entire budget causes, the project and budgetcauses delays and causes just overall confusion.
(19:15):
Don't you think there is something on us, know, people who have to supervise and see howconsultant interfaces with the end user.
if I as a consultant spent all day creating this requirement, you need to spend at leastone hour digesting and writing and giving me feedback.
Well, usually end user has no more than five minutes.
It should be super simple to digest.
Yeah, you would have a lot of different levels of detail that are needed.
(19:38):
You'll have your product owner that needs to sign everything off and say, yeah, this iswhat we want.
But then when you go up a level, you wouldn't really specifically be talking about userstories or requirements.
You were talking about in more generic terms, high level terms.
And you should be, otherwise you're going to lose your audience completely.
And the higher up you go, the less time those people have.
(19:58):
They want you to get in, get on, get out.
So if you don't need anything start by hey, I don't need anything from you.
I just want to give you information on X otherwise, you know be very clear what whatyou're looking for and we need to be Clear as well in terms of who's responsible for what
and who makes decisions on what?
Otherwise you're going to have a situation on your hands where you've got a deadlockbecause people can't agree on a way forward.
(20:22):
How much time we need to assume the VP would spend on signing off those requirements,signing off that acceptance criteria.
I'm a big fan of visualizing things and not humongous blocks of text or lists ofrequirements or things like that.
I think it's if you visualize a process and you say, this is what you do right now.
This is how we need you to change the process for whatever reason.
I think those are the kind of conversations I would expect to be had at that level, notreally the user stories themselves.
(20:45):
tangible, you talking we need to have like, do not assume that you have more than oneslide, or do not assume you have more than five minutes, or you actually, or if you want
really have people in the room go and run some kind of session, be there.
Yeah, I think that the, I think that the kind of like the first level stakeholder thatunderstands the process that we're talking about should be proficient enough to sign off
(21:08):
on that without their higher ups.
having to contradict them.
think if their higher-ups contradict them, then there's a bigger problem.
The higher-ups would need to understand the high-level importance and meaning of thatrequirement so they can validate that it actually is something that this process
(21:34):
revolves around and then this is the way the process works.
There's not a need to change that process.
That's of course something that we oftentimes do.
The higher up says, hey, this Barbra, we don't want this process to work like this.
So it becomes process development and then things get out of hand.
Now, should that happen?
I think it depends.
You don't wanna build a system that
(21:56):
that's based on incorrect processes.
But what I am saying is that those things should have been thought through before we getinto that requirements gathering.
And then the higher up should kind of give a glance on, this is what John Doe or Jane Doeare saying about the process.
This is how it's defined.
This is how it should work, looks good.
(22:19):
Let's proceed.
So just to make it a little bit more spicy, what do you think if it wasn't for contractreasons, for legal reasons, do you think we could get away with not writing any
requirements or be as light as possible, just moving from prototype to prototype, justshowing to customer every week something new going on?
What do you think about this?
(22:39):
What's the pitfalls?
What's the advantages?
I think that it's a great way to go generally.
Even if you have requirements, you should be doing regular show and tells because justbecause someone says they want a black car, that can be interpreted in many different
ways, right?
There's a black car and there's a black car.
So seeing the system is and getting feedback from users, that's what validates whetherwhat they ask for is actually what they meant.
(23:03):
Because a lot of the time we will ask for something and someone will assume that we meanX, Y and Z, but actually we don't.
We meant something completely different.
So regardless, think whether you have requirements or not, you should be doing thatprototyping process all the time, because that's the only way you know you're hitting the
target otherwise.
And that the target that you're hitting is the target they want you to hit to a certainextent.
(23:23):
But at the same time, I think there is that element of, yeah, the prep beforehand,particularly what problems are you trying to solve?
And can you slash should you change your business process?
Is your business process the problem?
Because a lot of the time we've seen situations where a very broken process is implementedin a system.
(23:44):
And actually people then start complaining about the system, but it's not the systemthat's the problem.
And you need to try and wiggle that out beforehand.
And it's time well spent because you don't want to spend a lot of time developing softwareto continue working in a...
to support the broken process, basically.
So for me, the process mapping side of things is more important than the requirements to acertain extent.
(24:05):
I'm a huge fan of let's just build, but I don't think it works for huge businessapplications, big systems.
It doesn't make sense when you're building a five million pound or dollar a year ERP, youcan't just jump into building and see how it goes.
But I'm a huge advocate of that approach in smaller engagements.
(24:29):
But I think Areti you said a lot of the
You said a lot of the gotchas there, the process, know, we have to have an understandingthat the process works, that we're not trying to, you know, fix a bad process with a
system.
But I don't think we need to go all in into requirements.
I think we can have something higher level and ensure that, like, look at the process andthen simply start building and fail fast.
(24:54):
And I do think that that's the direction where
We're going more and more with agents as well as applications.
You know, our canvas apps are model driven apps from Power Platform that we can now buildwith these, new things that Microsoft are releasing where you just give a prompt and you
(25:16):
get a functioning, a pretty, pretty well functioning app.
Plan designers or what have we.
So shall we declare in this podcast that requirements are dead?
Ha ha ha ha ha.
I agree with you.
If you can do through prompt engineering, build stuff, then fundamentally
majority of requirements are driven by contractual obligation, contractual management,relationship management rather than need, development need, So this is my horror story.
(25:43):
One of consultants years ago,
the consultants here was writing requirements as explicitly as possible and they were likereally elaborated multiple lines it was really hard to go through them and when it was a
critical moment came where customer was not agreeing to them consultants shown to can'tuse it to customer and say hey this is what you signed this your signature and is and the
client told I don't care what I signed up what I signed off I don't care about thisrequirement what I told this time I need something else so fundamentally if requirement
(26:10):
doesn't cover even from contractual point of view
Probably in the court it might work, but in real project if you sweat every single commathat probably goes away.
I think it is valuable because a lot of companies, and think Antti mentioned this as well,they might go into software development projects without having done software development
(26:30):
before or looking into exactly what is involved in software development and what's goodsoftware development and what's bad software development.
So there is that element of educating yourself before you go into that project and knowingwhat it will take for it to be a success from both sides of the fence.
In terms of our requirements debt,
No, think the prompt is effectively the requirement now.
(26:52):
So if anything, they may be more important than ever.
mean, wherever you want to have them is fine as long as, you know, they are accurate,valid and correct at the time of writing.
But this is the thing, we also need to be aware that things change very quickly, as wehave talked about earlier.
So just because something is the right answer right now doesn't mean it's going to be theright answer later on.
(27:14):
And the later on used to be five years from now.
Now the later on is probably
a year and half from now.
AI solutions right now, they'll probably be technical debt in a couple of years, which iscrazy.
But that's the reality of it.
Newer models, newer infrastructure, you name it, it's all moving very quickly to catch up.
So we need to be aware that what we're building right now may also have a much shorterlife than we've ever expected it to.
(27:38):
So the takeaway is that companies laying off people is inevitable if they want to survive.
We just have to deal with that change.
It's not necessarily always bad news.
You never really know what is right for you and what is wrong for you when it happens.
It's only in hindsight you find out anyway.
We've gone deep immediately.
(27:59):
But other than that, obviously we've covered the fact that
the kind of requirements, gathering exercise, don't boil the ocean, try things out, fail,make it okay to fail and fail fast and know what you're getting yourself into.
Do your research.
Popular Podcasts
24/7 News: The Latest
The latest news in 4 minutes updated every hour, every day.
Crime Junkie
Does hearing about a true crime case always leave you scouring the internet for the truth behind the story? Dive into your next mystery with Crime Junkie. Every Monday, join your host Ashley Flowers as she unravels all the details of infamous and underreported true crime cases with her best friend Brit Prawat. From cold cases to missing persons and heroes in our community who seek justice, Crime Junkie is your destination for theories and stories you won’t hear anywhere else. Whether you're a seasoned true crime enthusiast or new to the genre, you'll find yourself on the edge of your seat awaiting a new episode every Monday. If you can never get enough true crime... Congratulations, you’ve found your people. Follow to join a community of Crime Junkies! Crime Junkie is presented by audiochuck Media Company.
The Clay Travis and Buck Sexton Show
The Clay Travis and Buck Sexton Show. Clay Travis and Buck Sexton tackle the biggest stories in news, politics and current events with intelligence and humor. From the border crisis, to the madness of cancel culture and far-left missteps, Clay and Buck guide listeners through the latest headlines and hot topics with fun and entertaining conversations and opinions.