Search for a command to run...
I'm going to share all my secrets with you
I used to be a .NET developer. Nowaways, I am a DevOps solutions architect with a focus on Azure and Kubernetes.
I also love productivity topics, especially when it comes to doing more with less of my time. I'm also a daddy, so time is a limited resource for me.
I appreciate it! Any of these lessons in particular that resonated with you?
Using a pull-request workflow
This is the guide I wish I had
Connecting your GitHub Workflows to Azure AD using OpenID Connect
In this post, Iāll walk through the essentials of configuring an AKS cluster to use Argo CD with an NGINX Ingress Controller. Pre-Requisites Youāll need: An AKS cluster. Hereās a Gist I use to create a simple cluster. Helm 3 Azure CLI A Custom DNS/A...
Have you wondered what it's like to be a consultant before? Are you running into challenges in growing a DevOps culture at your job? I will share it all, and it will be a long blog post. To be honest, I don't know why I'm doing this; I just feel like it needs to be done.
I have been a consultant for boutique, medium-sized, and large consultancies. Before consulting, I was a developer. All of my consulting experience has been in helping companies adopt DevOps practices. Because I am a consultant, I get exposure to many more companies than I would if I were just an employee at them. So, I hope that if you don't know much about consulting, you get a view into my world, and if you're an existing consultant, then maybe I can help you with a challenge you've had.
I was inspired at my day job because lots of our recruits don't have previous consulting experience, so I've been reflecting on what it means to be a "consultant." I thought that others could benefit from the lessons I have learned over the years. I am also doing this for myself because it's helping me reflect.
These opinions are my own, dear employer, don't fire me. š
For context, I live and work remotely for clients in the United States. I know there's an international audience through this medium.
In my view, some "consulting" companies are staff augmentation companies. In other words, the "client" is a company that needs people with certain skills. The "client" can't find people because they don't have a strong brand or recruiting capabilities, their payscales don't allow for competitive compensation, or the company likes to spool up or down the workforce with contractors, etc. When a consulting company does a "staff augmentation" project, the "client" does not expect strong advisory services.
I believe a "consultant" is an advisor and change agent looking to help the "client" achieve their goals. So, in this post, I will share my opinions about projects where I was strictly in that role - an advisor.
Lastly, I consider "DevOps" to include people, process, and technology aspects. So, this will not be a blog post around tips and tricks for creating pipelines or cranking out containers. Spoiler alert: Technology is the easy part. š±
Often, as engineers, we tend to want to put our heads down and crank out code or fix technical issues. But we're human beings, and as humans, we are highly social creatures. There is no "avoiding people." And people also create processes to get stuff done.
So, do the hard things first. You're probably dreading the hard things, and they will most likely be problems related to "people" or "processes."
So, for example, here's a list of things I watch out for.
Here's a strategy I borrowed from a client for greenfield apps - perform a walking skeleton production deployment early in the project. A walking skeleton is just a basic set of the infrastructure deployed to production with very little actual code. Also, a walking skeleton uses Infrastructure as Code and a CI/CD pipeline. The sheer nature of being in "production" will trigger all those processes you dread, and you can get them out of the way early. You will avoid nasty surprises and delays toward the end of the project. You will also gain a lot of practice and confidence deploying to production with the automation you established in the first place.
Remember the "big bang" theory? There was a HUGE explosion, and then there was the universe. Deployments to production can be that way, too - a big bang deployment of infrastructure and code, chaos, and hopefully a working application.
You might be surprised, but so many companies today still wait until the end of the project to release to production. They hope and pray that a big bang will work. Sometimes, they ignorantly think nothing wrong will happen because of their skill and experience.
A big bang deployment is an explosion of Work in Progress (WIP). WIP is unfinished work. The work is unfinished because it hasn't been shipped to production, and you're not learning from it yet. The more WIP you have in the system at one time, the more risk.
Can you make a big bang less painful? Yes. I have had to suck it up and do big-bang deployments before. Here are some tactics that have helped me:
Ideally, if I had a magic wand and I could get rid of Big Bang deployments, I would:
The last thing on this topic, you might think that big-bang deployments only affect companies that are not using Agile. In my experience, just because a company is "using" Agile or Scrum or SAFe doesn't automatically mean they are free from big-bang deployments. I've worked with zero companies that identify as using Waterfall, and I have run into many, many, many big-bang deployments.
When designing a system, I like to bring the client into the design conversations. Maybe have "whiteboarding" sessions or just a series of meetings where we talk. At some point, I begin to form an opinion and have an idea of what I would like to recommend. So, I want to fail fast and validate my assumptions with the client. I also recognize that I might not have all the data points, so if possible, I create a simple draft document or PowerPoint stating options on a part of the system that could be designed. I present the options to a core client team with the goal of learning more. Often, they provide minor feedback or significant feedback. Sometimes the options get smashed together into a new option. Sometimes, we need to create an experiment to validate one of the options to address any concerns. The key is that the client is involved and therefore feels in control of the project's outcome.
In my observations, traditional consulting companies have different project delivery methods. They create a detailed project plan and weekly email reports and assign a project manager to the project. The plan has a clear "design/document/build" phase. Depending on the size of the project, there could be several months before anything is built!
What happens if there are gaps in the design document? Will the implementation go according to plan? Does the project need to halt because the design needs to be flushed out? I'm not sure, but it does sound risky, right?
If the project does get delayed, the client would not feel good about it. Even worse, if the design phase is dragged out until it's "right," it could mean months without actually building something or driving outcomes for the client. In my opinion, the client typically doesn't care about a recommendations document - it just doesn't drive the outcome for them at all. The document is a method for communicating design decisions and rationale.
Overall, I think one huge problem with the traditional consulting approach: the client was not involved in the design process.
How would you feel if you attended 10+ meetings talking about system design, and when you asked a question, the consultant said that the final answer would be in a recommendations document? Then, several weeks or months later, you receive over a hundred pages of the document. So, either:
Alright, so what's the catch to co-creating and designing with your client?
You can't hide.
If you're designing with them in the open, you will get to a point where you have to say, "I don't know." Or "in my experience, that hasn't worked well," or "I haven't tried this solution yet."
So ultimately, the client will know how much you know and how much you don't know. It will come out if you don't know enough about the subject you're talking about.
I don't recommend this approach to someone that doesn't have a lot of experience in the topic.
Active listening is crucial. Stating opinions is important too. So, like any normal conversation, I think talking to a client should be an ebb and flow of listening and stating opinions. This "ebb and flow" is more important the more people there are in the "room." I believe that the "ebb and flow" quality often translates to the customer experience. The reason is that sometimes clients bring in consultancies because they cannot work well with a different team; therefore, if you manage to have two or more teams talking and working together, that's a tremendous value.
Here are two extremes that I am not fond of:
In my experience, it's normal for clients not to read the contract. Maybe, the stakeholder read it but didn't understand the technical fine points. Or maybe the stakeholder is not part of the day-day delivery of the project and did not share with the main people you're working with. Sometimes, I believe that they expect excellent customer service, and they trust that the consulting company understands their needs, so they never get around to reading it. Whatever the reason is, the SOW doesn't matter to them. What matters to them is that they can reach the outcome that they're looking for. It is very possible that you do everything in the SOW within the timeline, and the client is unsatisfied.
If the SOW does not state clearly the goals or outcomes of the engagement, ask the client. Sometimes the client will be a little annoyed since they would have had these conversations already during the pre-sales process. Still, it's better that they are annoyed that the project starts with complete misalignment from the beginning.
I'll share with you some high-level outcomes of my past projects so that you get a sense of how high-level we're talking.
Notice that I did not say, "we want ten Kubernetes clusters, twenty pipelines, and lots of shit doing fancy things."
In my career, I have witnessed engineers that prefer to focus on the "technical" things while they lean on other teammates to do the "people" stuff. The same goes for consulting, and I have witnessed consultants that want to rely on the project manager to talk to the client. Heck, I have done this too. But, in my experience, this is what ends up happening:
I believe it's much more effective for consultants to learn the soft skills necessary to say the hard things and communicate risks to the client. I'll give you an example of hard things I have said before:
I won't lie to you - it takes time and practice. If you're early on in your career, start small. You'll be much more comfortable asking questions when you're a senior team member practicing this skill for years.
I'll be honest with you. I haven't taken the time to learn or understand the principles of SAFe. SAFe is short for Scaled Agile Framework, which was put together to help dictate how to do agile in a large enterprise. I can't speak to the details of exactly why it doesn't fit well with DevOps. But I can tell you my experience.
When I hear that a client is using SAFe, I bear for a long and slow burn-out-inducing project. It could be that 99% of my clients that have implemented SAFe have implemented it incorrectly, so it could be that it's not SAFe's fault. Based on opinions from others more well-versed in this topic, I don't think that's the case.
When I engage with a client organization that's typically already using SAFe, we have to use that delivery model to deliver a project. So, here are my observations about trying to deliver a project under SAFe:
Did you know that big tech companies don't use SAFe? Even just Scrum, for that matter?
Here is the fantastic article mentioned in the tweet.
So, do you have to do what big tech companies do? Nope.
But this data point probably means that you don't need SAFe to be able to be successful, right?
Before trying to undo SAFe at your company, read my other points.
So, it's likely that you'll have to learn how to make the best out of it. Here's what worked well for me:
Edit: Lastly, here's a great guide from Agile thought leaders.
The sunk cost fallacy is when someone decides to keep going in a specific direction because there's been too much time, money, and effort put into the project. I can't tell you how often a client has chosen to continue doing something a certain way just because they've spent too much time on the implementation.
The ego is a self-protection mechanism that we all humans have. The ego jumps out to help our self-esteem when we feel threatened. Maybe, we feel incompetent if XYZ were true, or we feel like we lost control if XYZ were true, or our bosses won't like us if XYZ were true. When someone has an extraordinary amount of ego, especially when they choose to listen to information based on the status of the person giving the information, it's going to be hard. Add some sunk-cost fallacy, and it becomes a fast-moving training heading for a cliff.
Here are some examples:
As a consultant, you can't control the client's decision. You have zero control. You only have the power of influence. If you run into someone with an extraordinary "ego," then the best thing you can try is to speak to his/her ego and provide information tied to status. In the end, if they don't value or respect your authority on the subject, they most likely won't listen. It might as well be an immovable object.
So, if I encounter a lot of ego and they're protecting something that cost them a lot of time and effort to implement, I pick a different problem to tackle. Usually, there are a lot of problems to solve, so this is not an issue. But if the problem they're protecting is crucial to the outcome for the client, then I'd have to lay it all out on the table and say the hard thing. In practice, I would probably escalate the issue and add other key personnel to the conversation to increase the stakes and the pressure.
If you picture a medieval times battlefield where armies fight close combat with swords, then the army on top of a hill usually has the advantage, and they try to defend the hill. The opposing army then fights uphill to defeat the enemy, but it will be more challenging. If you don't like the combative analogy, think of yourself as a love warrior trying to spread love š. You will still only have enough energy to climb some of the hills.
When I start a project, I look for the "hills." The hills are challenging topics that will require a tremendous amount of emotional energy. Because of the energy, these initiatives will take, I pick one or two. Based on experience, I rule out some hills automatically because I know it probably won't help the project move forward.
Here are some of those "hills" that I always avoid:
When I make recommendations, I imagine having a "trust budget." Each big recommendation and big ask that will mean a lot of work for my client will consume from the "trust budget." Before I make these recommendations, I visualize how much of my trust budget I will consume. Often, I have a zero trust budget at the beginning of a project with a new client because I haven't delivered results yet.
So, if trust is earned via results, I quickly try to increase my trust budget so that I can make recommendations. Therefore, I am looking for some quick wins.
Quick wins are painful problems that are relatively easy to solve. When clients hear a low-effort solution to a nagging problem, they feel relief and excitement. And, if you're able to solve the silly problem along the way, then tell them afterward... they might make a statue of you outside their building.
Here are some examples of quick wins I have delivered:
What if you can't find a quick win?
Then listen closely and ensure you'll solve the main problem extremely well. The key point is that when you deliver your recommendations, you want them to be heard. If you sense skepticism when talking to the client, that's probably an indication of a low "trust budget."
But skepticism is different than curiosity. Skepticism is "Do I trust this consultant that they can solve this problem? Have they done it before?". Curiosity is, "Okay, if this solution works, it would be amazing. How do I make this happen? What could go wrong?"
Don't be dogmatic. Don't hide behind "best practices." Explain why something is better or more effective.
I don't like "best practices." It implies that everyone should make this master list of things, and if you're not, then it's bad, and you're failing. They can also be a crutch to consultants.
I'm much more interested in the essence of a "best practice." Why is this a good idea? Why should your client do this? How much effort will they need to place to get the benefit?
For example, "it is usually best practice to usually keep secrets out of source control because if you decide to give read access to a repository to a contractor, then they can see those secrets and use them to gain access to an environment that they shouldn't have access to."
So, when you understand why something is considered "best practice," you can discuss risks vs. benefits with your client. If you're having trouble explaining why something is considered best practice, you probably don't understand it well enough yet.
Some of the best projects I have delivered can be attributed to this single decision. Think of your team like a team of Avengers. Every person brings something different to the team, and each person has strengths and weaknesses. So, play to everyone's strengths.
For example:
When everyone agrees on what areas they will own upfront, it is much easier for the team to self-organize and react together. In contrast, if a team optimizes for "busyness" or time, then Jimmy, who doesn't have as much coding experience, might miss some crucial recommendations.
Although I cannot find the source, I heard of a study that found that average people thought the "best" doctors were the ones that had better bedside manners, not the more skilled ones. If this is true, it could also apply to many other aspects of life.
Receiving medical care can be a very vulnerable moment. Engaging with a consultant can also be a vulnerable moment since companies don't hire consultants when things are going well. Sometimes, the project that a client is sponsoring could mean a promotion or maybe the last ditch effort before they leave the company.
So, what is the client experiencing?
Do they feel listened to?
Do they feel understood?
Do they feel like they can trust their judgment?
I learned this lesson through a unique project. My consulting company has three teams working for a client organization. My team was the highest performer, and the client liked it best, but it wasn't because of me. It was because of my teammate.
At the time, I believed that delivering amazing client results was doing lots of great technical work. I put my head down, and I worked furiously to drive results. On the other hand, my teammate was not as ambitious; however, he did stop and strike up conversations with my client. He found out they both had military experience and loved Asian cuisine. Later, we ended up going to dinner with our client at a hole-in-the-wall yet amazing Korean BBQ place, and it was amazing.
I remember thinking, "Wow, what am I? Chopped liver? My client loves my team because of my teammate. I don't think it has anything to do with me."
My teammate just genuinely cared about the person in front of him. My client felt listened to and probably felt like they could talk openly when we had to make tough decisions at work. With time, after more dinners and lunches, we got to hear more stories and context from our clients. The relationship was growing into a friendship, and he likely felt very understood.
Wouldn't it be better to go through a vulnerable moment with someone you can trust?
Building a relationship with a client is very important.
You can't control how people feel. You can control how you say things in a way that minimizes the chances of someone being triggered and raising their defenses.
For example,
Consultant: Why are you doing it that way? That's not best-practice.
vs.
Consultant: Hmm. I am not tracking. Help me understand. What's the value of doing it this way one more time? I fear that we might not reach the project's goal with this approach.
When I think about how to ask questions, I think of two things:
To ask from a place of curiosity, I often have to take a deep breath, put myself in the client's shoes, be empathic for them, and assume that they are trying their best given their circumstances.
Also, by avoiding using the word "you" forces me to talk about my experience. No one can challenge how I feel or what I have experienced. It is my truth.
Don't get me wrong. I am still me, and I am still a person with flaws. I always have moments where I think to myself, "what the f*?." The difference is that when those feelings arise, I acknowledge them and take a moment to think about the person in front of me.
Side note: I was fortunate to work with an organizational psychologist at a previous consultancy. She trained me and fellow consultants to avoid certain words so we could speak more collaboratively.
We had this posted in our office so that we would remember to use the vocabulary.
As a consultant, you probably don't get hired into totally functional companies. From time to time, you might be caught in the middle of an internal political battle where someone ultimately loses their temper. That's a moment where you can add a lot of value.
Here's a recount of something that happened to me:
Person 1: We can't design the network this way. It leaves XYZ vulnerable. We'd need another ABC service and another firewall.
Person 2: Ah ok. But this part of the design is ok, right?
Person 1: No, it's not. We can't link these networks together because XYZ is vulnerable.
Person 2 gets frustrated because he wants to go live with the project.
Person 2: We need to start doing things in a new way! We can't be doing data center crap in the cloud!
Yelling continues, then stops for a second.
Me: Yeah, Person 1, I understand what you're saying. What if we get rid of the issue? Because this is a greenfield deployment, could we say that workloads that don't meet these criteria won't be able to be hosted here? That way, we can ship and don't have to design for all possible use cases, especially legacy ones.
Honestly, I can't tell you if this conversation moved them closer to the goal. I can tell you from more than one account that sometimes groups bring you in because they feel pain points in "dealing with another team." They want someone to help them work with another team. So, if I didn't try to be a mediator, I would have had zero chance of moving the outcome forward. If they weren't working well together before they hired me, then they will probably not magically begin to collaborate, right?
The best thing you can do is try; if it doesn't work, it's not any worse than before.
I have to tell myself this all the time. I want people to like me, and I enjoy working with people that are having a good time. But, sometimes, what the client needs is not a friend. Sometimes, they need to hear what is wrong or what could go wrong - directly and clearly.
"If we don't do this soon, I fear we'll not have time to go to production."
"I know the burndown chart says we're tracking to finish the project; I strongly feel that we will need more time than our board says."
"I know you have spent a lot of time on your solution. I want to present you with the alternatives so you know our stance and the surprises that might come up. I would hate for you to continue your current path without knowing the risks. Ultimately, it's your decision, and if you choose to continue on this path, you know the risks."
So don't avoid saying the hard thing because you are afraid they won't like you anymore. Also, remember, watch your tone!
Early in my career, learning that I had no control was probably one of the biggest lessons that took me the longest to learn. I kept getting frustrated working with some clients because they were not listening fully to my advice. I had to learn that I have no control over what the client decides or does.
I have no "skin in the game." I don't work for the company that they work for. I probably won't get fired if this project does not go well. So, it's only fair that if they hold the risk, then they decide, right?
Instead, the only tool you have is influence.
How do you influence?
Think of social media influencers like YouTubers. What do they do?
All those things apply, minus the YouTube channel.
Have you ever sat through a painful presentation where an engineer is presenting to upper management, and management seems disinterested? Was it painful? Did it seem like it was dragging on?
McKinsey is a world-renowned management consulting company. McKinsey uses "top-down" communication. Instead of telling a long story and finally providing the key point at the end, present the key point first and then explain.
This blog post is an example of that kind of communication. The key points are delivered as headings. The points might not make sense unless you read the explanations like this one. But, you have the option to determine if the key point is something you're interested in, and I'm not holding your attention hostage.
I think this blog post in story form would be much more difficult to read. You would have to read everything to get the twenty-eight lessons I am sharing.
As an engineer, you might cringue, but I find PowerPoints very useful. I find them useful because they're a tool that allow me to help break down complex ideas into small chunks and communicate them effectively. For example:
If you want to learn more about the McKinsey method of communication, here's a great video from an ex-McKinsey consultant.
Unless you have decades of industry experience and managed not to become a manager, you probably don't have experience being a professional system administrator and developer. So, you likely only have experience in the Dev or the Ops in DevOps. If you're a junior DevOps engineer, you have a serious disadvantage.
Part of playing politics and reaching agreements is figuring out what different people want to achieve. Very generally speaking:
If you have a different perspective on each group of people care about, that's ok. However, let's leave out security for the following metaphor; otherwise, it is too complicated.
Imagine that your role as a DevOps enabler is to be a bridge for "work." At one end of the bridge, there's "development," and at the other end, "operations." You have made your customers happier when you ship one unit of "work" across the bridge.
So, to become an effective bridge, you must know a bit about "development" and "operations." If you started your career as a developer, then you probably have gaps in operations, as I did. If you started your IT career, you probably have development gaps. If you started your career as a junior DevOps engineer, you probably have gaps in both realms. The key here is to know enough about each role so that you can speak their language. Being able to speak about what someone cares about is a great way to build trust. The more you can speak in someone's language, the more they will think, "you are one of us." And in dysfunctional environments that need the most help, there's usually an "us vs. them" mentality. No pressure. The better bridge you can be, the better advisor you will be.
So truly, here are some of my standard tactics to build more trust:
How would you interact with people if you thought of yourself as a doctor?
Would you try to find the root cause of a symptom instead of pushing pills first?
In this case, pills are tools. If you push tools all the time, you're not going to solve the root problems. Sometimes organizations require a lifestyle change, which means a process or culture change.
So, think about the care plan for the organization. It could start with a tool to alleviate some profound pain but then think about process improvements to solve the deeper issues.
Consulting companies are businesses. Most consulting companies charge their clients by the hour. There is usually a margin between what they pay the consultant and what they charge the client. It's that simple.
So, because of the billing method, a consulting company makes more money when:
I'll be honest. I find these to be extremes. I wouldn't work for a consulting organization that's doing these practices on purpose to make more money.
And, humans can be exceptionally good at smelling intent.
Also, we humans can be very sensitive to perceived ill intent. Think used car salesman.
For example, one time, I was working with an excellent client. We had a great relationship. They had asked for a follow-up engagement and given me a list of items to help them with. However, it was in the middle of a heavy sales process change, and I needed approval from general managers and go through a "deal review." I was so focused on getting approval and fighting the spreadsheets that I lost sight of the hourly rate we were charging the client before the process changed. I was trying to get approval so we could start soon, but the new rate was considerably higher. We sent the proposal to the client; they expressed that they had sticker shock (the price was extremely high). The relationship ended.
I believe that they thought that because we did a good job and they were asking for more help, we were being bold and raising the rates because they needed us. In reality, I was scoping what they had asked for and made a mistake carrying the proposal through the heavy-handed sales process.
The lesson to be learned is to remember what your company is incentivized to do and consider how your client will feel. Don't overcomplicate solutions, be transparent about delays, communicate early and often, and be mindful that a client must maintain your solution, show urgency, etc.
I'll leave you with this: imagine you hired a good plumber to fix a leaky pipe and he was charging you $150/hour. How would you feel is he was taking his sweet time and moving slow and looking ineffective? If you had a low budget, I think that would give anyone a little anxiety.
If you're a consultant, you might like this one. Request a virtual desktop instead of a laptop when starting a project that's less than a year. A virtual desktop allows you to easily switch between your company's and the client's communications without needing a fancy KVM.
Side note: here's a product idea: a very fancy KVM for consultants. Before giving up and accepting virtual desktops, I vigorously searched the market for the perfect KVM that would be supported by MacOS and Windows so that I could keep my peripherals plugged in one place and switch between computers effortlessly.
Consultants often have to get access to the client's systems to perform the work. Many companies have security postures that don't accept using the consultant's workstation, hence, bringing their own device. Instead, many enterprises like to provide laptops to contractors so that they can connect to the network from a device they can trust and control.
Well, if you're a consultant, these devices can pile up. I have an ugly laptop that's been collecting dust next to me for six months after I finished the project. š
I was once doing a project with a client that also hired AWS Professional Services (AWS consulting). I overheard the AWS project manager tell the client that using virtual desktops instead of laptops was part of their contract. I found this interesting because it took me two months to get set up with a laptop. It took the AWS consultants two weeks to get set up. Then, I started asking my clients for virtual desktops for short/medium projects.
By using VDIs, I was relieved that I didn't have to agonize anymore about having all this clutter and physical devices everywhere. Also, starting the project with virtual desktops is often much faster than with laptops.
I hope this doesn't happen to you, but I once had to make a round-trip of seven hours to go to a location to get a proprietary badge and then drive another nine hours round trip to pick up a laptop. The badge unlocked the laptop. Then, another time, I had to drive an hour each way, sit outside a client's branch location at a Chinese fast food place, get on the client's Wi-Fi, then talk to the IT help desk for two hours to get my awesome laptop set-up.
Another tip for a new consultant.
On top of getting a new laptop from clients, we are often given an email address by the client. So on top of our actual work email addresses, we end up with all these other identities and inboxes for each client.
At the beginning of my consulting career, I tried hard to solve this problem. The reality is that many enterprises lock down any customizations to their emails so that you can't use external OAuth applications. Heck, I had one client that monitored their emails so closely that I was strongly warned that if I ever forwarded an internal email to an external account, an automated system would pick it up and fire me. I was also strongly advised not to print anything because I would be automatically fired.
You will have multiple emails and identities. Just accept it. It's the consulting tax. š
Last tip for an existing consultant, especially one that hates Windows. š
To be clear, I like Windows, even though I'm in the DevOps field. I'm writing this blog post from a Windows 11 laptop. š¤
However, I wouldn't say I like Windows as a typical enterprise setting, and that's because of all the controls and bloatware that enterprises install. I bet everyone hates slow laptops and funky issues due to bloatware.
Just like you can ask for a virtual desktop, you can also ask for what operating systems they support. Rarely do enterprises support Linux for workstations. Sometimes, you might get lucky, and an enterprise supports MacOs. Most of the time, enterprises only support Windows.
Many engineers like to say Keep It Simply Stupid (KISS). I agree. But I think simplicity is relative.
What you might find simple, I might not find simple. What I could find simple, the client might find complicated. What the client might find simple, I might find an abomination.
I think simple takes work. I don't think arriving at the first solution is often the "simple" one. Doing the least amount of work can be "lazy." So, I'm going to do this... I'm going to give you a Steve Jobs quote. š
āSimple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it's worth it in the end because once you get there, you can move mountains.ā - Steve Jobs
There have been times that I worked hard to make a solution "simple" for clients. Here are some of the attributes I'm looking for:
I learned this one from a co-worker recently. I think it applies to a lot of organizations.
What is described in this Wikipedia article, and what I have experienced, is that often we can easily focus on trivial things. To "avoid designing the bike shed" means that if you're designing something important like a nuclear power plant, then don't place as much importance on designing the bike shed next to the power plant.
Recently, I was on a project to design a very important enterprise-scale landing zone for the cloud, meaning the cloud foundation. The client was interested in discussing naming conventions and spending time on them. Naming is hard. I get it. So, I'd rather use a naming convention that a reputable source created rather than waste precious mental energy creating my naming convention that I'll probably get wrong.
Be aware of this for yourself, your teammates, and your clients. You might be stuck discussing something that will not improve the nuclear power plant.
Have you met someone that seems like they're exuding confidence? I'm not that person, and I've always envied that to some extent.
Instead, I'm naturally quite the opposite. I have a lot of self-doubts, and I double-guess myself. So, I've asked co-workers, "you sound so confident; how do you do it?."
Sometimes, some people may sound confident, but inside, they are still scared. Their physiological responses are ones that you might not see. For example, when I get nervous, you can tell. My ears turn red, I start to sweat a lot, and I start to stutter and think slower. So, some people might be nervous, yet they don't show those clear signs, and then you might make up a story in your mind that they're confident because they sound so assertive.
The true solution that I found that works for me is practice. The more I do something, the more confident I get. So, I accept it and give myself permission to be nervous when I'm not great at something yet. If I keep showing up and doing, I will eventually get better and be much more confident.
Here's a book that helped me and might help you: The Confidence Gap: A Guide to Overcoming Fear and Self-Doubt.
Do you remember a time that you worked with someone that was really critical?
Maybe they weren't criticizing you, but you were listening to how they criticizing someone else. I've come to know someone with this tendency, and when I hear what they think of themselves, it's rough. I wouldn't want to be in their brain. There's a lot of stress and hate, so if they're hard on others, they're likely even harsher on themselves.
Watch how you show up with others. If you're passing judgment, you're likely to pass a lot of judgment on yourself. Be kind to yourself.
Also, it works the other way around. When working with someone overly critical of you, try thinking about how much harder they probably are on themselves. If I hear harsh criticism from someone, I find it useful to think about their inner struggle. It helps me center myself and lower my defenses because I realize they're also struggling.
I know there's so much content out there. I'm honored if you've read some or all of this article. Remember, I'm just a random dude from the internet, and some of my lessons might or might not help you.
