Office Apps and Services MVP,
Enterprise Architect 🟑🟑🟑
thoughts on Architecture, Automation, Development and Technical Leadership
M365 Azure SPfx PowerShell DevOps keep it simple. keep it honest. keep it real.

⚜️ Episode I of V - A Technical Baseline

Get your curiosity caps on, we’re about to embark on a five-part journey (the first one, more to follow) through something that will change the path of your technical projects, … or at least, I’m hoping it will (for better ! not worse 🀠).

So it begins …

I’ve been tech-leading technical teams and communities for a while now, and I often get asked what are the crucial baselines to get started to drive technical projects\teams. So, it makes total sense, to start this story with what has been working for me and my teams\communities\clients.

And yes, it’s a bit of a long list, and a lot of bla,bla, bla, and looks too generic, nevertheless, I wish someone had given me this list when I started …

I’ve been using it for years so it’s a good starting point

  1. Technical Baseline Commitments

  2. πŸ‘οΈ Clear Vision and Goals

    We must define a clear and compelling vision for the team or community and establish measurable goals that align with broader organizational objectives.
  3. πŸ—£οΈ Effective Communication

    Develop strong communication skills for both technical and non-technical stakeholders, fostering an open and transparent communication culture within the team.
  4. 😎 Leadership, Motivation, Community

    inspire and motivate team members through effective leadership by understanding individual strengths and weaknesses to build a cohesive team..

Those previous sentences sound like pre-made jargon, but take a moment to think about it and mature on it.
  1. πŸ§‘β€πŸ’» Technical Proficiency

    We must foster continuous learning within the team and stay updated on industry trends and emerging technologies.

    It is quite difficult and really hard to be “updated” on everything, companies keep dumping new stuff every hour, nevertheless, it’s a must.

    πŸ’‘TIP:A trick we as a team usually use is to keep a close eye on the community and the open source projects (PnP initiative is one of them), they are the ones that usually bring the new stuff first.

  2. πŸ‘¨β€πŸ« Promote coding standards, and best practices

    This is mandatory, we need to prioritize code quality and testing to ensure reliable products\projects even operational tass. Things like code reviews, unit testing, and continuous integration must be enforced.
  3. ♾️ Proper Tooling and Environment

    No surprises here : mandatory.

    Tools are important so make sure you have it all: DevOps with Continuous Integration\Deployment (tasks, source control repos ), VSCode, Visual Studio, or whatever is adjusted to your needs. They can make or break a project, period. Choose wisely.

A long time ago in a galaxy not that far, far away…

I’ve worked with a team that was still deploying projects\products manually ( a couple of powershell\bash scripts but still …): they were spending approximately 3 days to deploy a new version of the product … say what??? 🀷

Looking at the entire process put in place at that time, it looked like a Monty Python sketch :

  • manual process
  • each step implied validation and configuration by 2 resources
  • complex deployment methods

The entire process was a nightmare and led to a lot of problems and errors.

We’ve implemented a simple CI\CD pipeline (no rocket science there), and the deployment time went from 3 days … to 1 hour.

So if you think DevOps and Pipelines are not for you, think again: it must be part of developers, IT consultants, and DevOps engineer’s DNA.

It became part of the initial project setup, no matter the size, even for small projects.

Environments, Environments, Environments

Ready-to-go technical environments are essentials as they significantly enhance efficiency and ensure quality helping in streamlining workflows, minimizing the chances of errors, and enabling effective management. We also need to make sure our environments are isolated and reproducible.

That’s where containers come in.


Containers provide isolated environments with their filesystem, networking, memory, and CPU, ensuring that there are no conflicts with other projects or software on the local machine. Why is this, so important?

Developers/IT Consultants and DevOps folks need to be able to work on multiple projects without worrying about conflicts between dependencies, libraries, or software versions. We need isolation and we need it fast!

Containers also offer reproducible builds, providing the exact same environment every time they’re launched, which helps in avoiding “it works on my machine” issues. The days of setting up a new environment from scratch are over, and containers are the reason why.

Still not using a container?

If you are a Developer, an IT professional, or a DevOps engineer, you’re missing a lot …

🦾 Being productive with automation

Development workloads and workflows should be streamlined by providing pre-configured environments within containers ready to code\script in, straight out of the box, reducing the setup time for starting a new project and allowing us to dive right into work without dealing with any installation or configuration.

I do remember the days of setting up a new environment from scratch and it was a time-consuming and error-prone process.
Containers changed the game.

The automation of repetitive tasks, such as testing, building and deployment and everything that can be scripted should be part of the container, ensuring that the process is consistent and repeatable across different environments…. every single time.

Keep in mind that is not just for Developers, the IT ,DevOps and even the support\operational folks must use the same concepts.

πŸ§™β€β™‚οΈ Customization, flexibility and consistency = high quality projects no matter the size

Environments must be flexible and easy customizable , to meet specific needs and requirements.

The flexibility allows a consistent environment creation across different stages ensuring that the environment is in a predictable state throughout the process.

Encapsulating the environment within a container ensures that everyone in the team is working in the same environment, leading to more consistent and predictable outcomes

Probably most of you already know the concepts of the mentioned baseline, containers, and automation, but I've still seen a lot of teams and projects that simply don't have a clue what's going on in this field.

Hope it helps, and if you are already using these concepts, keep it up, it’s the way to go.

Stay tuned, and get ready for the next episode Episode II of V - Revolutionize your tech workflow with a single command

Marginal Gags (small hand-made cartoons) credits : awesome Sergio Aragonez ! creator of Groo, the Wanderer

See also