Are you a university student worried about securing a job after graduation? Or are you a leader finding it difficult to receive adequate support from other teams or departments? You may also be searching for something to help you stand out for your next career growth opportunity. Many people misunderstand the value of having and building professional relationships. Building relationships can improve your career in many situations. However, you must start now! Professional relationships work best when you have them before you need them. Nobody likes hearing from you only when you need something. Think about that friend who only calls when they are moving 😊. You're being held back because you haven’t yet invested enough in professional relationships! Value of Professional Relationships Over years of supporting people’s careers, I have observed that people on upward trajectories have something that sets them apart. In school, being smart or working hard will often set you a

I have had the fortune of learning a lot about development processes and how people approach work. It is always amazing to understand what excites people about work and how they see their role in creating our products. I find great pride in helping people evolve their practices to improve how products come together. Let's explore some observations I have made about what drive people to optimize, and some ideas on how to move to a different way of thinking. What drives optimization? I have noticed a typical driver in how many groups and companies define their development practices. These practices start by working to prevent pains the team has encountered in the past. We build our documentation, processes, and automation around avoiding things that have happened to us before.  “This happened once, three years ago, and in response, we implemented a rule to prevent it from happening again.”  I will share a scenario from my experience.  One of the teams I work closely with adapts

As you climb to higher management levels and begin leading other managers, keeping in touch with your team's pulse can become difficult. Understanding what is happening at the lowest levels can help you wrap context around what your team brings you. You may also need to build stronger support for your goals and direction.  Introducing skip-level one-on-ones can be an effective way to increase your engagement and understanding with your whole team. The most important thing you can do with your time is communicate with your team! How to start If you are serious about strengthening your connection with your team through skip-level one-on-ones, you should start with a plan. It is critical to be clear about what you want to achieve with these conversations, or you may cause stress or conflict within your team. Clarify Your Goals Start by setting aside some dedicated time to consider what you want to achieve with these one-on-ones. Here are some questions to answer to help you.

There is one question that I ask very frequently. "Are you winning?".  When I ask this, I often get an awkward smirk in return and some kind of "What do you mean?". The Race A large part of my early life was dedicated to sports and athletics.  With most sports, there is always a clear winner.  I would like to argue that there is rarely a clear loser. Many world athletes participate in activities like track and field, cross country, ski racing, marathons, and more.  Most of these people focus on improving their skills, abilities, and results.  Anyone who has shown improvement or set a personal record will walk away from the event feeling a sense of accomplishment that is hard to replicate anywhere else.  These people feel the true meaning of winning.   Are you Doing Better Today than Yesterday? This is the real question, isn't it ?  You win if you have learned something new, completed that difficult task, or  helped a co-worker get unstuck. I consider i

Some of my youth was spent around farms and ranches, which has left me with interesting perspectives. I could talk/write about these perspectives for a while.  I will focus on one area in this post: reusing old tools to build new ones. Not Developed Here Many software engineers are keen to borrow others' ideas or snippets of code. They are often on board with using an entire library or program that does everything they need. Getting them to use something they didn't create can often be challenging , as it may not directly meet their needs. Or sometimes, they think they can build a better mouse trap so every other one out there won't suffice. We hear things like, "That's not how it should be done.” “What they did doesn't make sense,” and “I can build what we need faster than integrating that system." These are all forms of saying, I didn't make this, and I know I can do a better job, so I won't use it.  I've personally done this many times. It’s

We usually lean toward terms and methods from other engineering disciplines in software development.  In some ways, this is good, and in others, it isn't.  All engineering disciplines have a strong history of learning from the past and improving on what was done before.  However, there is one aspect where I do not think software development should follow others, and I'm sure many know it well, the construction analogy. The Construction Analogy " We've got to start with a solid foundation and work from there. "  Software development strategy is very frequently related to buildings and construction.  We tend to describe software as a single building with many rooms and interconnected hallways.  When using this analogy, of course, you need a strong foundation.  More importantly, you need a clearly defined plan for everything about the building before you start. It isn't possible to build the proper foundation without knowing everything about how the buildin

Just about every problem I work through in my role boils down to needing to communicate more and more often. Early on, as an engineering leader, I had to tackle a strange communication problem. I led a small team of 3-4 engineers who supported our production development teams. This team had fully embraced a Scrum mindset, and due to rapid prototyping requirements, the team worked in one-week sprints. This means we had planning, standups, retro, and demos every five days. Between standups and other ceremonies, they collaborated daily, looking for peer reviews and technical support. They were proud of their ability to be direct with each other, not needing to "sugarcoat" the message. Yet there was still a problem. The team was always working in drastically different directions and at various technical levels, constantly bickering about what needed to be done. One-on-ones with me were full of complaints about other team members and were always heated. How could there be such