Book review - From No to How - How to Get Buy-In and Lead Change

Lloyd — Fri, 05 Sep 2025 23:21:00 +0000

How familiar does this sound?

💡 You have a great idea that is valuable, but everyone says no when you suggest it. They won't go into details or simply raise all hell to block your idea from ever seeing the light of day.

🧭 You want to shift the conversation from No (we have always done it this other way) to How (can we do that)?

🎯 For any Software Engineers who struggle to get buy in for their ideas, drive business value and want the business to ask how we can do this rather than a flat No I encourage you to read "From No to How".

Stages of an Idea through the lens of SDLC

If we step through the first parts of the Software Development Lifecycle we might be able to loosely map this back to driving Business Value and getting people to ask "How can we make this happen?".

1. Planning

Ask yourself:
🧭 Who's the people who will help me with change?
🎯 What's my elevator pitch?

Get 1 to 3 people to bounce your idea off that you know want to drive change.

2. Analysis

Ask yourself:

What is the value this offers?
What Proof of Concept, presentation or other conversation starter will help describe the change and get review and feedback.
Ask Why to find the root cause of the issue you're trying to solve or opportunity you're trying to surface.

3. Design

Ask yourself:

What is the capabilities I need?

Conclusion

As you can see driving value is a key skill well worth learning so you can lead change and get buy-in. It can be as simple as starting a blog, reading a book and having an initial conversation about your idea with someone you trust.

Software #SDLC #FromNoToHow #Engineer #LeadChange #BuyIn #BusinessValue

Links

📖 From No to How

🚵 Software Development Lifecycle

✒️ Why do we need this book

❓ 5 Whys Technique

SDLC and AI

Lloyd — Thu, 04 Sep 2025 23:41:59 +0000

What is SDLC?

What can I use AI for in SDLC?

Ideally you already know the scope, goals and requirements. However as we know they can be a bit fuzzy or unclear for certain parts. As such it's worth working through the SDLC with someone to bounce ideas off such as:

GitHub CoPilot if you're storing everything in the GitHub Repositories which is my personal platform of choice.
M365 CoPilot if you're storing items in SharePoint, Outlook, Word, Excel, Streams. My personal favorite for converting transcripts from meetings into Action items, Converting Emails into an executive summary depending on who I'm communicating to and what they're asking.
Amazon Bedrock for most of your AWS hosted solutions you want to use GenAI with.
Azure OpenAI for most of your Azure hosted solutions you want to use GenAI with.

How does it map to SDLC?

Planning

A lot of planning takes place in meetings where we can loose track of the scope, agenda and point of the meeting. I'm always slightly wary of a meeting with no scope, links or proactive / reactive response to something we have to do.
As such it's best to write up the scope of the meeting, or propose one based on what you think it's about (1 - GHCP).
If you're not proactively planning out the roadmap (8 -GHP), then you may not be prepared as things kick off.

Analysis

A lot of analysis can happen in meetings which is why I strongly advocate for transcripts to be converted into documentation, action items and outstanding questions (2 - M365CP)

Design

Designing the project architecture is probably the least automatable of these. However Templating these so the format that is predictable and feeds into proactively meeting requirements down the line in SDLC is well worth it (1 - GHCP). Remember Markdown is probably the best format for these.

Coding

Lots to cover, I'll just say the design artifacts should feed into this heavily (1 - GHCP).

Testing

Lots to cover again, I'll just say the design artifacts should feed into this heavily (1 - GHCP).

Deployment

Finally, we're at the Platform Engineering phase of DevOps where the developers and engineers are treated like customers rather than force fed some horrible take on how DevOps should work without allowing us to improve it.
If you don't know what it is, start here.
If you're platform is written well the previous phases should feed into this one nicely (1,2,3,4,8).

Maintenance

I haven't forgotten about maintenance, but it needs to be kept in mind that someone has to maintain this. As we shift left, the engineer writing the code is hopefully supporting the code so they have a major stake in making it maintainable.
Again, if you're platform is written well the previous phases should feed into this one nicely (1,2,3,4,8).

What did I use recently?

For the .NET Meetup I used Azure AI as I wanted to use:

.NET.
Predictable responses.
Gamify my Agile board with some theme that's fun for the team (my family).
GitHub Projects for a Career Roadmap for myself that I can template for others.

DEV Community: Lloyd