Category: Leadership

The Art of Meaningful Communication: Building Trust, Listening, and Understanding

~ Michael Wahl ~ Leave a comment

Over the past few years, I’ve found myself revisiting the lessons I learned in grad school. Among the various courses and competencies, I’ve gravitated back towards the realms of Management, Finance, Leadership, Strategy, and Communication.

Today, I’d like to share some reflections on communication—specifically, my experiences and insights regarding natural, comfortable discussions versus those that leave me feeling uneasy. While the title may sound straightforward and obvious, mastering effective communication requires significant time and effort. However, once you invest in building trust, active listening, and understanding others, the rewards are abundant and enduring.

If you were to ask my wife and family, they would tell you that I genuinely enjoy engaging with people. Often, when the conversation becomes captivating, we lose track of time. While I don’t mind engaging in small talk about the weather, technology, baseball, or football, what truly fascinates me is getting to know individuals on a deeper level—learning about their personal history and discovering what brings them joy in life.

When I engage in a conversation, my aim is not merely to collect data or superficial information. Instead, I strive to ask thought-provoking questions that elicit deeper, more meaningful responses. If your goal is to establish and nurture lasting connections, both you and the person you’re communicating with should feel at ease during the conversation and look forward to the next interaction.

It’s crucial to focus on how you treat the person you’re speaking with, as an old saying goes: people may forget some or all of what you said or did, but they rarely forget how you made them feel. Avoid dominating the conversation with discussions about your own career or educational background; instead, listen intently and learn about the other person. Rest assured, you will have your time to share, and through the diligent cultivation of strong relationships, you’ll have ample opportunities to discuss yourself.

By implementing these principles of trust, active listening, and understanding, you can embark on a journey to master the art of meaningful communication—an endeavor that will enrich your relationships and leave a lasting impact.

Rethinking DevOps and Engineering Teams?

~ Michael Wahl ~ Leave a comment

Knowing where you are headed, and where you have been

Today you may have pilots/POCs (proof of concept) that have skipped critical phases such as MVP (minimum viable product), and MMP (minimum marketable product), in other words, you have pilot/POCs that went straight into a live production environment.   

Perhaps you have other scenarios where the pilots/POCs made it to the MVP stage, but the cross-functional teams necessary to support were not included or kept, whether this was done due to time or budget constraints isn’t always completely clear. At the MVP stage, you should understand the ultimate objective and the problems you are trying to solve for customers. Additional team members will likely need to be brought in to represent the various areas such as security and the Ops/Infrastructure service. The security and service functions help to define the non-functional elements which support this live production environment, beyond simply the Pilots/POC environments. The security functions are particularly important to ensure that you are aligned with specific data privacy/compliance requirements, in addition to following and implementing various best practices around how you will store and transmit the customer or other protected-sensitive data. 

You may also have prior scenarios where you have taken your pilots/POCs to the MMP stage. Customers who were actively using a particular product or service, but as with the MVP stage, the security and Ops/Infrastructure service teams were not included, or the staffing wasn’t adequate to support running/growing a live environment beyond the POC.  

Team Approach and Alignment 

The above section is important to cover first, as I think it helps to communicate where you may want to go next with teams which also includes DevOps-Platform, engineering, and security resources.   

As you continue ramping and perhaps even preparing for additional Pilots/POCs with your current fleet of Products and Services, you need to plan how your teams will do the work, and specifically what types of work they will be doing.  I will cover this in greater detail below, but essentially, you need to be able to break down these larger projects/problems into micro tasks that fit within an agile team. There are too many different domains, and subdomains that exist today within any given Product/Service – infrastructure and systems the team supports today.  

  • Teams/Squads with experts for each of the POCs 
  • Active Stakeholders which include Product Owners or the equivalent  
  • The team will have general software developers/engineers, and platform (IT Operations/Security) engineering resources partnered together to accomplish various work items, tasks, etc as deliverables in each sprint. Sprint reviews help the teams, which include the various stakeholders, leadership/management, and other stakeholders with visibility, accountability, and communication.    
  • Documented, evolving but clear service workflows, escalations, and interactions with the other teams. 
  • Current and ongoing documentation    

Near-Term Decisions

  • Backfilling/hiring for your principal/chief engineer/arcitechture role(s)
  • Consider moving to one centralized platform to track your work, store and update documentation – maybe its Notion, Basecamp, JIRA, etc.    
  • Moving to one ticketing system for Development, Security, and Service-related issues – maybe JIRA Service Management or something similar.  
  • Communication platforms (Slack, Teams, etc) 
  • RD time – Friday afternoon or another time when team members can work on CIs, other low-hanging fruit work items in the backlog 
  • Do we want teams to use Tribes, Squads, Teams, and Departments? The goal is ultimately to have smaller teams following agile.  
  •  Platform Engineering/DevOps Teams and Topologies 

Long-Term Issues and Decisions

  • Solutions to help teams manage the unplanned work coming in 
  • Leveraging some RD time, enablements  
  • Reducing the amount of context switching issues between projects, tasks, products, customers 
  • Reducing Longer lead times
  • Teams managing/handling platform/system support/break-fix, need a better way to identify, log and track, prioritize with the best and available resources. 
  • Teams/Resources managing/handling implementation/migrations, onboarding, and ongoing support, same as above, need a better way to identify, log and track, prioritize with the best and available resources. 

Other Potential Issues 

  • The engineering teams can become too large 
  • Systems can become monolithic 
  • Work can become blocked across software engineering and service/operations resources 
  • Teams/members become too specialized which can create dependencies 
  • Software/platform/systems can become too large and complicated
  • Documentation becomes nonexistent or not kept up to date 
  • Original/Key team members leaving an organization taking critical knowledge and specialized skills and domain knowledge 
  • DevOps resources may face a large number of requests from the various engineering squads/internal customers.  As those product squads – software engineers all advanced and leveled up, the requests coming in can became more domain and subdomain specific.   

Proposed Team Structure – Includes Software, Platform, and Engineering Resources

  • Using more of a micro team/squad approach, project/work items can be organized into two-week agile sprints and required team members – resources can be bundled/grouped to accomplish a sprint goal. Having available DevOps FTEs, for example, could be assigned along with another engineering resource.
  • The smaller/micro teams help with frequent, focused communication. 
  • Instead of a centralized DevOps person/resource, having more of an embedded platform engineering/ops embedded into dev teams/squads. It will take some time to find the flow that works, but this really will depend on what works for the various teams.  
  • More focus on the domain and subdomain skills and knowledge required. 
  • For each of the potential solutions products and services defined platform required, and the services needed to run, scale, and secure the solution.     
  • Responsibilities for building, deploying, supporting, and retiring a specific service within a business. More business and customer focused. 
  • The teams below will exist in some part to reduce the number of disruptions, distractions, and overload that’s placed on the stream-aligned team.  
  • External/temporary help-support/services to help the teams quickly upskill or implement other best practices to support the stream-aligned team. 
  • Provides specialized services such as machine learning, and analytics/reporting components.  
  • Working with the team leads, and principals to discuss a new team topology and approach.   
  • Based on the adoption and effectiveness of this new approach, we would then consider whether to roll out a similar team structure for other teams within an organization.

Are you an Owner or a Contributor?

~ Michael Wahl ~ Leave a comment

Maybe said differently, do you find yourself more in leadership or individual contributor situations?

I think either of these is perfectly fine, but take time to reflect, and ask yourself. If you are still unsure, look at some of the primers below.

  • Do you or the team need specific direction for all or most of the work or projects?
  • When you or the team get stuck, can you keep going or do you stop and wait to be told what to do next, what to try, what to stop doing?
  • Do you do only what you are asked, any extra work, do you go above and beyond?
  • If you have concerns, or respectfully disagree with an approach or idea do you keep quiet and keep your head down?
  • Do you propose solutions?
  • Are you the one executing, deploying, implementing, and testing solutions?

From an engineering, DevOps, and support perspective, especially at the senior or principal levels, staff members all know the work is never done, there is always a backlog, and there is always something that needs a little improvement, review, updates, etc. The owners know this, and they automatically move on and work on this extra work when their scheduled sprint, project work is complete.

Sometimes within DevOps, and other areas of support, we find situations where there are gaps in ownership, or the classic case where every owns or shares something, when it reality no one actually owns it. I think we see even more of this in small, lean companies or teams, maybe even in proof of concepts or early stage products, where much of the focus is on continuous customer deliveries, and feedback loops to ensure solid traction and value. When we get to production or to more mature, and crtitical workloads, these ownership issues or lack of ownership period creates a huge risk for the organization and its teams.

Going back to the start of this post, if you went through the list I had above, and found you answered Yes to all or most, it may mean right now you are more comfortable as an individual contributor and maybe less as an owner. Depending on your own personal or career journey, this maybe what you want, or this may be something you wish to change going forward. The good news, the decision and the change is yours to make, but you must first have the awareness to see and acknowledge it, then put in the time and make the necessary changes!