Category: Uncategorized

I Hear You. An Empathy Journey.

I Hear You. An Empathy Journey.

As I write this, we’re in a gravely unusual time: during the COVID-19 pandemic. Not everyone can work. If we can work, we are either in a hazardous place providing essential care (thank you, doctors and nurses! Thank you, grocers!) or we are working from home where there are countless distractions of trying to do this with a swarming family.

We’re each on a journey to understand how to we operate best and how others operate. It’s often the case that how we operate is very different from how others operate. Learning will never cease. We’re learning about ourselves even though we think we’ve already heard so much open chatter going on inside.

On this journey, I’ve read a useful book called “The Seven Desires Of Every Heart,” by Mark Laaser. In it, he outlines how our hearts yearn for specific things in our lives, our family relationships, our community relationships, and our work relationships. We seek things from relationships trying to satisfy those desires, but sometimes we go about it in unhelpful ways. When we understand what motivates us at a core level, we operate well with the people around us.

As I was tearing through the different desires, they all made sense: about being chosen, about being touched, about belonging to a community, about other things. Each made so much sense. One desire, though, didn’t make sense to me: to be heard and understood. I dismissed it, “oh, that’s something other people must feel.” I moved on with other material in the book that made more sense to me.

Equipped with these ideas, I continued in my relationships. I had vulnerable conversations with my friends. They responded to my personal stories. It was helpful. As I reflected back, I started to notice a pattern: they heard me. They understood me. It was healing.

In our work lives, we think there are rules against being too personal or emotional about anything among our colleagues. In reality, though, emotions are running thick at work! Did I do my project well enough? Am I providing the right service to my colleagues or my users? Am I good enough to do this work?

Understanding where our colleagues are coming from is critical for our mutual success. Do you know how they’re doing? Do you know how easily they’re completing their work? Do you know how they’re handling the stress of work in this unusual time? Do you know if they have barriers they are facing? Do you know whether it’s even safe to ask questions about it? If not, perhaps it’s time to consider adjusting the culture of the team to ensure it is safe to ask. It might be about your individual culture and openness, and how you process vulnerable conversations. Once you ask your team, individually, how they are handling their stresses, I expect each member will be glad you asked. After all, each colleague has a basic desire to be heard and understood.

I’ve encountered a helpful guide spoken by Brené Brown and illustrated by Katy Davis. Let me share that with you. Remember as you watch it, that this operates just as strongly in our work relationships as they do in our homes and communities. It looks a little different, but the “aloneness” feelings in our workplace can definitely be strong, but we’re aspiring to work as teams.

A strong and healthy part of doing empathy well is staying out of judgment. Seeing a colleague right where they are and accepting them in their position is to stay out of judgment. If we respond to them where they are and we accept them in their situation, they are more easily able to move out of a stuck-position and into the team makeup, where we are working so hard together to get the best outcomes for our software (or whatever we are making). This also brings out another one of those basic desires, to belong to a community: to our team.

I watched a recent seminar about Leadership & Management Amid Crisis, given the COVID-19 virus. If you need any proof about the importance of empathy, this virtual-seminar said over and over again: empathy was the number one skill needed by leaders in these times. They also gave an important point about how stress changes our brain chemistry. This change negatively impacts our creativity and innovation. The better that we can reduce our stress, the better we can contribute to our teams. I’ve linked this seminar below.

What are your next steps on your team to increase the hearing and understanding of each other? Can you check with your colleagues on how they’re handling their stress? If not, can you find out why? If you can, why not schedule a conversation now. Stay out of judgment. Hear them where they are. Understand their perspective. Asking this alone would be of help to the other person. If you can offer additional help, ask them if they’d like that help. No matter what, it will be a conversation they will be thankful for.

CNBC, @WORK: Leadership & Management Amid Crisis

Welcoming Women to our Teams Properly

Welcoming Women to our Teams Properly

By Lady Pain (Marta Manso) [CC-BY-2.0 (http://creativecommons.org/licenses/by/2.0)], via Wikimedia Commons

I’ve scarcely had the chance to work with women in my engineering career. They are very, very uncommon on teams I’ve been on and in classes I’ve attended. This article is actually not directed toward women. This writing is instead directed to the men this community is saturated with.

We are stronger in our teams when our teams are more diverse. Have you noticed? We get more ideas from our teammates when they come from different backgrounds from different places in the world. Diversity comes in many forms: age diversity, gender diversity, cultural diversity (which encapsulates all sorts of things), technical diversity.

When you get different people into a circle, if you are able to capture the different ideas in the circle, great ideas happen. I need people in my circle with different ideas than me to come up with a cumulative great idea.

Every time I’ve had women engineers to work with, I’ve found them to bring great talents to the team. I’m not sure if everyone else noticed, but they’ve been collaborative, observant, investigative, passionately skilled, and/or intuitively able to share vulnerable feedback I needed to hear. I don’t believe their unique qualities were fully realized.

There are well-established groups to promote women in engineering. I’ve never been to any groups to see them work. As a man, I’m not sure if I’m welcome. I probably am, but in this blog, my goal is to address how we welcome, encourage, and equip others in our teams to help them deliver their best.

My introductory Computer Science course in college was in the required curriculum. It was taught by the department-chair and we all took it. We worked through the lessons, and we did some labs in C/C++. The professor seemed to know what he was talking about. One year after I took it, a friend in my dorm took the same class. She had a very different experience! My friend is super smart, but she told me that this department-chair gave her disparaging remarks. These remarks were as if she didn’t belong in the computer-science lab, and she belonged in a kitchen somewhere. It was crazy to hear what would come out of his mouth. How could my experience be so different?

Here’s why my experience was different: I am male. That’s it. I was born with an XY chromosome.

My friend ultimately decided that computer science wasn’t for her. She moved on to a different curriculum. She became a successful pharmacist.

This experience dragged on my heart. How could a woman survive this type of harassment? How many women experience this? How could I not have noticed? When one of our leaders do this during a class (or during a meeting or other interaction), how many of us males consequently learn that it’s okay for each of us to also harass? Would we necessarily know if we’re diminishing someone’s participation on a team? Perhaps not!

The truth is there are many spaces in our technology communities where harassment is commonplace. From Stack Overflow, to Linux Kernel message boards, to our pull requests and water-cooler conversations down the hall.

My belief is that the women engineers I’ve worked with are so talented because they have survived so many obstacles. They’ve had to prove their worth over and over again and excel beyond normal expectations. They’ve pushed against the harassment and been forced to learn beyond what is normally expected of their male counterparts. Out of necessity, they’ve evolved into huge potential assets to the teams who get to work with them. Unfortunately, not all teams are ready to notice those unique qualities.

Men, if you have women on your team, I challenge you to notice their unique qualities. Give them broad bandwidth to make their unique contributions and for them to challenge your team’s standard point of view. They likely have excellent ideas on innovative ideas that they’ve not felt safe to share: it is your job to make it safe for them to share. Challenge your own point of view that you might not be noticing your teammates’ greatest abilities to innovate for your team.

Gender is only one of the many differences we have. Are there any other differences in our teams that prevented us from hearing great ideas?

What makes members of our team different is also what makes our teams better. Those differences give our teams an inventive advantage.

Additional Resources:
* Women in Computer Science: Assumptions to Avoid
* Girls Who Code
* MotherCoders

Curiosity And Bravery As An Engineer

Curiosity And Bravery As An Engineer

Sometimes I have a technical conversation with my son and I notice, “He doesn’t actually know what he’s talking about.” He struggles hard to say things he’s conjecturing on. It’s actually very easy to spot. And it’s not just with him: I think it’s easy to identify anyone in conversation when they don’t know the answer struggle to articulate answers they don’t actually know. Have you ever noticed this?

As a parent, it’s a great opportunity to help my son admit, “I don’t know.” It’s a brave thing to admit.

When I hear anyone say, “I don’t know,” it’s a huge trust builder! It becomes clear the other person had to admit that they’re limited. They are unable to answer. It is vulnerable. It is truth. It’s also an opportunity to connect: neither of us knows the answer to the question asked. It is hard to admit.

When I hear an engineer admit, “I don’t know,” I trust that person more. It specifically tells me that when he or she gives a direct answer, it means he or she does know it. I don’t have to second-guess their level of understanding as a listener.

I always want to know the answer to questions. There’s a part of me that feels incomplete with unknown answers. It is as I have a hole in my knowledge, and I take pride as an engineer knowing stuff. If I have a hole, I feel like an inadequate engineer, but that’s not real. It’s part of the journey.

The work of an engineer is not to know all the answers. Our work is to discover answers. It takes bravery to start this work.

In these moments I don’t know an answer is where learning begins. Curiosity is the activation-energy to learning. Curiosity is the right kind of response we can explore new answers and new ideas and understanding of how things work. These are also times when engineers can connect best: we discover an answer together.

Innovation is often a logical result of discovery: it might result in an amazing idea. We can be open enough to what we didn’t already know. We can take other kinds of experience we’ve had and apply them to a new concept we’re actively learning about.

As an engineer, the fewer answers we have solidified, the greater the opportunity we have for learning and innovation. I encourage you to bravely admit an answer you lack. Be ready to start the needed work of discovery.

What will you innovate next time you admit, “I don’t know?”

Democracy: Ownership Of Our Process

Democracy: Ownership Of Our Process

We do what we’re told to do. Every day. Every iteration. Every release cycle. We finish our software features, and our customers are happy about what they get. And at every iteration, we do better at making code, because we’re continuing to improve our software, our infrastructure, and our tests. In the spirit of the Scrum process, we’re also improving our process. We can call this continuous improvement.

If we are closely following the rules of Scrum, we’ve instituted a retrospective regularly scheduled into our process. Our goal during a retrospective is to make our process better. We typically have one for every sprint, we invite all the team members to the retrospective, we look at both the good things that happened in that sprint, the things that need improvement, the ways in which we can improve, and we make specific goals to improve our process.

It’s easy to fall into a routine each day at work. Retrospective might actually become routine. The more routine sets into our mentality at work, the less likely we are able to innovate. This is highly true also for our retrospective and the goals coming out of it.

A critical element of a retrospective is voting. As a member of a scrum team, we can vote about what is important to how we work. Managers don’t vote. Product owners don’t vote. C-level people don’t vote. Neither customers nor users vote. We vote as members of our scrum team, and with each vote, we own the process of what we’re doing.

Consider with me some ways to make the best of our retrospective process.

Mental preparation

We make complex software! Doing what we do, it is too easy to forget about all the things that happened in a sprint iteration! Just like we spend time thinking about software architecture before we start building software, we ought to spend time thinking about the successes and the opportunities we had to improve during the sprint. It’s best, even, to jot those things down as notes as they happen. We then would return to those notes during the retrospective.

As we make our notes, we would both celebrate things that went well and opportunities to improve. Consider, that some events might both have gone well and have been an opportunity to improve.

Dot voting, private voting

As stated above, voting is the real substance of ownership of our work. Let’s do voting right!

Each item on our lists is likely very different from the others. In a retrospective, we have lots of items to consider! It’s not realistic to vote just for one item. If we can use many votes, we can spread our concern across many items and prioritize what we need to.

I once worked in a team where we each had 10 votes. In the process, we had one member who waited until everyone else voted, and then placed all ten of his votes on a single item. One time, that item didn’t receive anyone else vote for it. In effect, this one member canceled every other person’s vote and controlled the direction of the retrospective. That was not team ownership, but ownership by one guy. Let’s try something else: private voting.

Our democratic process in the United States (and most places) means that we vote privately. We don’t know how others are voting until the very end when all the votes are cast. Were we to know how voting is going before we vote, that process would probably look very different. We might need the help of some software-tool to do private voting: it’s important to ensure team-ownership.

Following up on goals

Lest we fall into routine, it helps to follow up on what our goals from the previous retrospectives. We need to apply those goals to the work at our desks. This is more difficult than it seems!

In some cases, we can create work-items that have specific objectives to improve. Those work-items need to come into our sprint cycle (and be estimated and prioritized with other work). This can ensure the completion of those goals, but it could require competition with other goals from the product point of view.

In many cases, retrospective goals aren’t clearly about repeatable events, but about patterns in our process. It helps to have a Scrummaster come alongside what we are doing in the sprint (or possibly many sprints later), to help us ensure the best practices we agreed on as a team.

How we use the retrospective is an entirely good use of time within a retrospective. This sounds paradoxical, but it can be a very good discussion for a team to discuss how they ensure goals get best executed.

Software tools for retrospective

I’ve worked with a few different tools for retrospectives, and I can’t say that it’s important to use a tool, unless you have members of the team working remotely. As long as the process ensures the dignity of each vote and each member’s desire to improve the team, using a tool isn’t important.

Putting that aside, I’ve used these tools. FunRetro and Retrium are tools aren’t that different from my point of view. They make both make use of a GUI that looks like post-it-notes.

My favorite is a tool from Team O’Clock, where the interface is very deliberate to walk a team through the specific parts of a retrospective, helping a team stay timely with the meeting. It appears this software also helps move through daily-standup meetings and planning-poker, too, but I’ve not used this implementation.

In summary, doing a retrospective is a critical step in making a team own their process. It can help ensure each member is fully owning what they are doing, and they are more fully engaged in what they are doing. Each member can be proud of the continuous improvement process that they are a part of.



Improving Our Code: Infrastructure

Improving Our Code: Infrastructure

We can only improve upon something if we can repeat it. Every moment of every day, if we can repeat the same steps, we can refine those steps, improving on ourselves.

When we make a recipe, we can use the defined steps. Oops! This needs less salt. It baked for too long. We can improve the steps by making notes in our recipe, such that we can improve it. The refining is the same in the software world, for our making of software.

In the past, I received a series of C++ source files for a project I did not create. The original authoring team was disbanded. The source files included no definition of how to build it or how to apply specific third-party dependencies. It was written for Windows, and the goal was to make it work in macOS or Linux also. As an aficionado of GNU-based building (macOS/Linux/UNIX), I found myself unable to figure out at the time what was needed in Windows-based infrastructure. Infrastructure code is just as important an ingredient as the source code itself.

We can trick ourselves to check off the “infrastructure as code” checkbox if we include CMake instructions (or similar instructions). It’s not enough! Let’s think about other infrastructure we need in our code:

  • Automation scripts for grabbing third-party dependencies
  • Information about the build machines. This could be defined lots of different ways:
    • Ansible playbooks, to configure a build machine or a test machine (Or other configurations with Chef or Puppet)
    • Dockerfile definition files or configuration files for a container
    • CloudFormation or Terraform files, to configure a small network on the cloud
  • Jenkins configuration files, written in Groovy, for a tool to be able to start building a project
  • Database data file, for use with tests for some initial construct of testing
  • Automation scripts for releasing
  • Automation scripts for tagging source code
  • Automation scripts for creating documentation (like Swagger, Doxygen, …)
  • Automation scripts for packaging an installable product (Windows .msi, macOS .pkg, RedHat .rpm, etc)
  • Configuration files for configuring Apache or php
  • Pull request or issue templates used with your SCM, to ensure consistency with how you explain changes
  • Coding-style configuration file, to ensure consistency of your coding style
  • Anything else you can think of. Be creative.

This looks like a long list. Admittedly, not every bullet might apply to each project, but the more of these items we put into our code, the more we can improve upon.

Self Service: Empowering Your Team

Self Service: Empowering Your Team

My first professional software position was at Silicon Graphics. While there, I worked on a team building internal tools for the electrical-engineers I worked with. We worked closely with those engineers to help them organize all their data to build circuit boards and integrated circuits.

Also on my team was an administrator of databases, tools, and our SCM tool. He tried to describe to me what his role is, and he said, “I make my work obsolete every day.” At this time in my career, this was very confusing: why would we make our own job obsolete?

The irony of this statement, was that amidst so much restructuring within the company, this team member is not considered obsolete at all. He’s proven how valuable that attitude is, that he is empowering engineers to get more done.

Today, the modern version of this “make my job obsolete” attitude is seen in the 2019 Accelerate State of DevOps Report. In the report it is called “on-demand self-service.” We can see from this research, that getting manual tasks out of the way, developing automated systems, is a powerful way to empower development teams (and end-product users) to meet their goals more quickly.

As a DevOps engineer, I want to ask myself during my work, “Can what I’m currently doing manually be turned into an automated process?” It’s the same attitude of making myself obsolete. It’s the same attitude of “self-service” taken from the State Of DevOps reports.

The automation of tasks that empower developers to do self-service might be labeled “Technical Debt.” I’ve been on teams with product owners that balk at the cost of technical debt. This kind of technical debt is priceless: manual work is time-consuming, error-prone, and could require documentation or training. Automation of those tasks frees engineers to get more done with less effort and greater precision. This is a huge win-win for everyone.

P.S., the “Accelerate: State of DevOps” research is an incredible resource to review. If possible, add your team to the research findings. It is potentially quite powerful for your team’s growth and your end users. I’ll write more about this in future posts.

Making Remote Work. For Everyone

Making Remote Work. For Everyone

If you’re a software engineer, you do remote work. Yes: you.

Even if you come into your office everyday, you still do remote work! Chances are, one of your colleagues works remote on a given day. You might have someone working from home for the day, someone who works every day from their home, or someone stuck in traffic during the morning standup. Sound familiar?

Traditional thought says this is not ideal, but there are lot of good reasons for folks to be remote. Above all, it gives employers the freedom to find the very-most talented team members. It also grants employees the ability to manage a family-priority that could be otherwise difficult on a given weekday.

Having remote colleagues is an opportunity for everyone on the team to try and fix the

Five years ago, I would think, “I never could do remote work.” At the time, I was working with a local team that had a few members working from their homes. I subconsciously felt like those teammates were less available to me, but it was my own flawed thinking. I later was forced to be a remote employee myself. I learned from my original perception, and I dove head-first into good-practices of remote work. Let me share that learning with you.

First, I’ll share three practical steps for everyone involved, even if you typically work from the main-office. Then I’ll share four tips for those that typically work from a remote location.

Turn on your camera!

According to research, a small portion of our communication is the actual words we use. Much more of what we communicate is the immeasurable, non-verbal stuff like our gestures and our tone of voice. In our meetings, we have a responsibility to be fully present with our colleagues.

Modern conferencing software use video cameras that are built into our laptops. We need to ensure we’re always using this. If we don’t, the others in our meeting cannot see our eyes or our hand-gestures. If we don’t, they hear much less of what we’re trying to communicate.

Even if you’re the one at your office and the other person is remote, you also need to be seen. Both of you need your camera on.

Your team needs to see you.

Screen Sharing

The best conferencing software has the ability to share screen and even offer others control of our screen. In effect, this is the same as being able to point to our monitor or hand someone else the mouse. These are basic opportunities that should not be lost.

For the record, my favorite-conferencing-software award goes to Zoom. It works on all kinds of devices, including Windows/Mac/Linux/Phone, and it does the screen sharing well. It even allows paid users to “Record to Cloud,” which prevents complicated video-file sharing from our desktop.

Your team needs to see what you’re working on your screen.

Record software demos

Demonstrating our software is imperative. It is part of the best practices of any software team.

Recording demos of our work makes it easy to communicate changes. Those changes not only impact our team, but they also impact users (new users and users that need support). Recorded demos can also help create user-documentation and training materials.

Though this is a good practice generally, it is a specific help when the team is not co-located. Those recordings can be seen any time they are needed.

When you complete a piece of work, make a recorded demo and share it with your team.

Travel. Be there.

For a team member that remotes everyday, it’s important to actually be in person as much as possible. In particular, the first week (or two), it is imperative to be in person. This is a time of trust-building and learning-the-ropes with the new team. It’s also the right time to get hardware, get a security badge, do training, or attend orientation.

I remember my first week at my remote position. Being in the office, I was able to attend brainstorming sessions. My team had a problem testing our Linux-based library. I got to listen to the problem. I have lots of Linux experience, and the team didn’t know it yet. I offered specific solutions to the current problem. An hour later, the whole team got an email from my new colleague that was praising my help with the team that I hadn’t even met yet! I was a little bit embarrassed, but in general, it built a ton of trust. This experience would’ve been impossible from a distance.

Trust can only be built in person. Be present, in the flesh.

Lunch while in person

I noticed that no one scheduled meetings during the lunch hour, because everyone was expected to be eating at that time. Meanwhile, I would often go out to eat while traveling. What a great opportunity to invite someone to join me!

This gave me the opportunity to build connection with individual members, connection that I would rely on all the other days of my work from my remote location.

The key to this, would be to schedule that time before I arrived to my office’s city. The week before, I make appointments with those colleagues. So far, they always accepted, and the time was always well spent!

Build community, especially breaking bread together.

Eliminate distraction

Teammates in the office are surrounded by their teammates. For remote employees, we might be surrounded by family, by pets, and possibly by work-chores that need to be done. Take notice!

It can be most helpful to get a dedicated office space in our home. This should be off-limits to our family. I’m all for a dog keeping us company, but children or spouses can easily become a distraction. Our teammates deserve our focus.

I take the approach of renting a dedicated office space in my town. I found a very affordable office, preventing those kinds of distractions I’d have at home. I cannot wash my dishes. I cannot fold laundry that just finished in the dryer. My cat will never jump up in front of my laptop to seek attention.

In my town, there is a great community workspaces that are for rent called 1Q1. Spaces like this are full of other work professionals with laptops. These might be good option for a short term rental (or even a long term one).

Set up your space to ensure you are focused on your team’s work.

Make your connectedness a priority

It can be easy to take our remote-ness for granted. It’s easy to dismiss being remote as normal-life. If we forget that we’re remote, we can too easily not notice when our team needs us.

During a daily standup, it’s important to notice that our colleagues might need specific help. We need to be deliberate to start conversations the rest of the day. Starting conversations while in person is very human-nature, but starting conversations while remote is deliberate! As a remote employee, we ought check in on our teammates. These conversations that we start with our colleagues can be instrumental in helping them have a productive day.

My manager has taken pride in how I handle my remote-ness. He knew I didn’t take it for granted. When he announced my work-anniversary to my team, he wrote:

Tyler’s ability to remotely connect and collaborate across different teams is amazing. He can be working from Mars and folks who work with him would not feel the difference given his ability, willingness and flexibility to connect as needed.

Listen carefully to your team, and start conversations.

It’s a good mission, that even though have remote employees, we can still be 100% engaged and 100% part of our team. Mission accomplished.

Continuous Learning

Continuous Learning

The world is moving. In our industry, it moving rather fast. Too easily, as individuals, we can be left behind.

On most days at work, I find a preponderance of opportunities to learn. Some days, I’m just putting in lines of code. Those days are sluggish. I tend to get more excited and productive in work-seasons that I have the chance to learn new concepts or technologies.

Thankfully, I’ve worked at a large company, where I can find or meet a colleague that has advanced skill in something we wish to learn. Sometimes, I can use their code as a template for what I need to do. I can also get their help to get me started learning, where that person introduces me to core-concepts. If the sharing is good enough, it can translate into a shared code-base. It can also turn into code-review or pair-programming. It might be difficult to find people in this position, but the work of finding someone like this is worth it!

Sometimes, finding a colleague with specific skill is not available. Certain technologies we need could be be too new. We might also want to learn while we’re between jobs. (Being between jobs is a perfect time to learn new things!) In these cases, we need to get creative. Let’s break down some ideas.

Conferences, Meetups

Nothing beats meeting people in person: people whose professional goals match your own. We can extend our professional network, learn about how others are solving problems, and learn about great new solutions.

Many conferences have add-ons for training. 10 years ago, I attended a conference that included also a boot-camp to learn Jenkins, a tool for building software. It meant a few additional days of travel and a little additional money, but the benefit of getting hands-on training was huge.

Some conferences are expensive, but take heart! In many cases, conferences are streamed live or available on video. Consider, for example, QCon, a software conference in San Francisco. All of their 2018 talks are available online. This does prevent us from meeting other professionals, but the great core learnings are available. They can also be shared with our teammates.

Many urban areas have great meetups! Consider a meetup in Boston called TechBreakfast. At this kind of meetup, we see both new software concepts and investors meeting in the same place. (Not to mention free breakfast) This is a huge win for all attendees. Is there a meetup like this in your town? If not, what kind of technology meetups are in your town?

Online Learning

Most of us on software teams are no longer at university. We cannot easily enroll in a university class. Happily, we have many opportunities to take classes. It’s easy to find what we need! Many of these courses are cheap or available with a free-trial.

Besides these courses, many companies that promote technology also make helpful videos for their technology. Consider, the following:

These are just a few that I found. Take a look on YouTube for what you need. Lots of folks make videos about technology, but the best documentation comes from the original authors of the technology.

Learning doesn’t have to be about taking courses or attending conferences. Learning happens when we face any kind of new challenge. What kinds of ways are you learning?

What makes you tick?

What makes you tick?

Our brains are always running. Yours might be running on the next obstacle our team faces. Maybe it’s on a new approach to testing code. It could be running over a next great date idea with your spouse.

What’s true is that our brains are always working. Our thoughts have patterns to them. Understanding those patterns empowers us to organize our thoughts and direct our paths, not just in our teams but also in our homes and social lives. In my journey, I’ve made huge advances in understanding how my brain works and what gets me going.

Four years ago, I traveled back to the town I went to college. I was having a rough patch in my life when I sat down with my friend Brent. He helped me do some analysis of the things I’m passionate about. He made some observations. He noticed that when I was in college, I used to be an advocate for an environmental-advocacy group. He paired that with another I was doing at that time: I was a public advocate to motivate people to make care packages for unfortunate kids. The causes were different, but the work I was doing was the same: public speaking and advocacy.

Brent and I share the same faith background. He called it a “God-created-identity,” that we can identify a specific purpose we are made with. With this identified, we can much more clearly pursue our goals around what motivate us.

Since that time, I’ve undergone many different personality tests. They’re typically a little fun and they take a little introspection. How do we tick? They help us understand what makes us unique. In software teams, we each need that uniqueness to bring our best to a team. When we can identify our uniqueness, we in fact bring more of ourselves to the table.

We also ought support each other’s uniqueness. My colleagues are different from me. That’s great! Our team is stronger from our differences. It can be a challenge in some ways to resolve differences, but we bring much more to the table when we embrace those differences and understand unique perspectives.

In the professional world, a commonly used personality test is the Strength’s Finder survey by Gallup. It is helpful for an individual to take those strengths to understand themselves better (I will leave my strengths in the comments section of this post). Most likely, knowing your individual strengths is helpful for a career-direction standpoint.

To take it to another level, an entire team could take the Strength’s Finder survey. When I know my colleagues’ strengths, I can reach out to them for different kinds of challenges we face. They are often better equipped or more passionate about certain challenges, and the net result for the team is greater strength.

“Know thyself” is an old adage. It is no less useful today than it was in ancient Greece. We empower ourselves for greater things when we can better understand how we operate and how our team operates.

Software Best Practices. Shared.

Software Best Practices. Shared.

The world is better when we share ideas.

The best teams advancing the most innovative ideas are teams that listen carefully, share their ideas (even the ideas that seem crazy), and get curious on how to advance their best ideas. This is difficult, because our world of technology is fast-paced, when seen at a high level. We see our neighbors create incredible ideas, and our first impulse is to work harder to try and compete. Hard work has value, of course, but the competitive mindset easily puts us on the wrong track.

Competitiveness and hard work at our desks often means we stop collaborating. It also means the “crazy ideas” we might have get stored away for a future day when it’s more safe to create. (I’ll share more about Psychological Safety in teams in a future post)

I am a “Type 2 Enneagram:” my goal is to help others. In my work life, my goal is to help professionals like me get better at what they do. They wish to help everyone around them get the best outcomes. As a software-professional, this is a true passion of mine. I’ve found this best as a “DevOps Engineer” or “Build & Release Engineer.” Having a role like this, I help ensure the developers around me get their software out to production with:

  • Great ways to collaborate and plan their work. I can be passionate about certain Scrum ceremonies, and how we can truly bring our best at each iteration.
  • Great ways to store and share our code. Writing code is easy. Sharing code in a group is not always easy. It takes care to be respectful in the issues we write and the pull-requests we review.
  • Great ways to test our code. There are SO MANY different tools to ensure our code is of good quality. Surely, there are many tools I’ve never heard of. There are pitfalls and gotchya’s to each, and when we discuss our best outcomes, we start making our test-code really lock down the best code.
  • Great ways to deploy our software. Truly, we cannot improve what we deploy without being able to repeat it. The process of compiling, signing, packaging, testing, and releasing our code has so much infrastructure embedded in it, and our best practice would be to encode all of that infrastructure: “Infrastructure as code.” Once codified, we can truly improve it for every release.
  • Great ways to collaborate. Colleagues are all over the planet, and even if they’re local, colleagues often work from their homes on many days. There are rich technologies to collaborate remotely. Often, we put up barriers to collaborating well: we’d rather not turn our camera on. We’d rather not reach out to that colleague we’re so different from. To bring out our best, especially as engineers tackling complex problems, we must overcome these barriers.

With this blog, I hope I can share lessons learned, and hear others’ share their lessons learned. We each have unique ways we’ve tackled these kinds of problems. We are technically diverse, and there is magic in that diversity. I hope by creating a forum, we can each bring out change us that bring out our best.

I look forward to the conversation.

-Tyler

Theme: Overlay by Kaira
Houghton, Michigan