Walking thru the Fire!

We’ve all been there. The day is going smoothly. Until it isn’t! Without warning, something happens and you find yourself with flames reaching up around you and the pressure mounts. It’s at this moment when you find out the true character of the team you work with. I’m not just referencing the people that either report directly or indirectly thru you, but your peers, team members across the organization that engage in the resolution of the issue or create the communication strategy, and the leadership team.

I continue to be amazed at the team that I am lucky enough to be a part of every single day! We’ve recently had some issues pop up unexpectedly and it pure pleasure to watch these folks in action. Like any other organization, we have our fair share of challenges communicating with each other, getting decisions made in a timely manner or with projects hitting hurdles that they shouldn’t hit. If everything ran perfectly, there’d be no need to any of us to do our jobs. Right?

Most recently we had a production issue pop up – yes, it does happen. Anyhow, this issue wasn’t a burn down the house issue, but it was still important and it did have impact. My job is to engage and clear the deck where I can for the folks actually having to work the problem, provide a framework for the decision process, to ensure that the team is putting logical steps in place to validate the resolution and to ensure communication up to our executive team.

I’ve always respected how this team responds to production level issues. Without needing to be told, people assemble together, open up a conference line and the artificial walls that exist on a day to day basis disappear as people work the issue. In this particular instance, the folks involved had commandeered a spot around one of our engineers where people involved in the issue had congregated – sometimes we grab a conference room, sometimes we just pull together around a desk and work the issue. This day, it was the informal – people floating in and out of the group as needed to work the problem, troubleshooting the issue, and moving the ball forward. During the day we had developers, leads, Unix engineers, Unix admins, architects, database analysts and management members floating in and out of the conversation depending on what was needed to either walk thru what was known, replicate the issue and ultimately to find a reasonable resolution to the issue.

Nobody panicked, everyone felt comfortable challenging statements that were being made and checking individuals to ensure that the thought process was valid. Nobody took those discussions as personal challenges, everyone was working to ensure that we found a resolution to the real problem. I won’t lie, we chased down a few rabbit holes and had to back out before we ultimately found the real culprit and were able to truly solve the problem.

I love this team! They not only challenge each other to be the best, but they challenge me to be my best.

If you'd like more information on my background: LinkedIn Profile

Accountability ... It's For Everyone!

Accountability: the state of being accountable, liable, or answerable.

Software Engineering is as much art as it is engineering. From the engineering side, their are best practices that guide developers on how to structure code, ensure the contracts between functional silos are maintained, ensuring performance constraints are adhered to, etc. On the creative side, there are a million different ways to write a specific function, as code is created, the engineer has the ability to choose how the exact implementation will be constructed.

From a management perspective, it can be hard to set and ensure that our teams are on track with specific milestones. Over the years I have tried several different tactics. Some have worked better than others. Recently, I've come to believe and rely on the following as a way to ensure that the leaders within my team have a pulse on what is going on within their teams and can actually provide factual responses to the question of 'where are we at'.

First, we established daily stand-ups within each of the resource teams. These run separate from any project related meetings/stand-ups that the project managers may run. Our goals with this 15 minute activity are to:

1. Open up communication within each of the respective teams and let every team member have visibility into what is happening.
2. Ensure that there is accountability within the team - everyone knows what the promise is and has to speak to what they've accomplished and what is coming up next.
3. Give the leaders of each team insight into current tactical activity to ensure that team members are working on what they are supposed to be working on, eliminating unplanned work, shifting resources to address roadblocks, and validating that the appropriate progress is being made to meet the established milestones.

These meetings run quickly - typically 15-20 minutes and each team member goes thru the following items:

1. What did I accomplish yesterday - was I able to deliver on what I promised.
2. What roadblocks am I encountering - do I have a path forward or do I need assistance.
3. What is my promise for tomorrow.

I am not able to attend every stand-up for every team, but I like what I'm seeing within these meetings. Team members are engaging with each other and have a better understanding of what all is being worked on within the team. When there is a problem, people are offering to jump in and help resolve the issue. When people have a little bit of down time, they are volunteering in the meeting to help other team members out with their tasks or are jumping ahead on stuff that still needs to be done.

These simple questions and setting aside 20 minutes a day to discuss, has altered how we are handling things within the team. First, I believe we have significantly reduced the unplanned work. Second, we have much better visibility into when a team member might be stuck and people are jumping in to help - either by just talking things thru or actually getting on the keyboard and solving issues. More importantly, I would also argue that my teams are communicating better. Communication is the key to everything, if we talk with each other, we solve problems and create wins!

If you'd like more information on my background: LinkedIn Profile

Be the change, don't wait for change!

Let me walk down memory lane for a few moments. My first formal job in the technology field was actually not doing software development, but was in sales and training. I sold IBM PCs, Compaq Computers and System 36’s. I was also expected to teach courses for the store that I worked for – Lotus 1-2-3 and dBase III. For those of you with memories going back that far, yes, I’ve dated myself. I would venture to state that most of the team that work with today, would have no clue what a Compaq luggable computer was nor even understand what an IBM Baby 36 looked like.

I sold computers for a year before I found a company that would hire me as a developer. While I did well with the sales aspect of it, I knew that selling was not my cup of tea and was not something that I wanted to pursue as a lifelong career. Getting that first development job felt right. Ok, I had been doing contracting since I was a teen, so this was really just coming home to what I knew I was meant to do. Pounding out code was comfortable, solving problems gave me a rush and was what really fed my soul. It was good to know what I wanted and then to find a company actually willing to let me pursue my passion.

I was hired to come in and develop software using Clipper (this was a compiled version of dBase III). Creating financial solutions for a very specific industry. I learned a lot in that first professional development role. How to truly plan for and test code – testing was not an afterthought, but something that was worked on just a diligently thru the development process as was the actual coding. I learned how to work on a team – understanding the role of the people creating the requirements, performing user testing, performing QA testing and then having to package up and deliver the code. Team also meant working with other development engineers to ensure that the stuff I was building fit with the stuff that they were building. When I was doing contracting, I was a one man show and did not truly appreciate the interactions needed to fit my stuff in with the work everyone else was performing.

Over the years I have had to learn and use several languages. In middle school and high school I formally took a Fortran course and taught myself how to code in basic. I can’t remember if I took Cobol or Assembler as a class, but I know by the end of high school, I could use both of those languages. Assembler was not something I enjoyed, but I could do it. I had also learned how to program using Basic. So, by the ripe old age of 18 I was able to hack around with 4 separate languages. College reinforced Assembler and added Pascal into the mix, along with several different theory courses. While I was acting as a sales rep, I was able to have access to a Compaq luggable and during the evenings I was able to teach myself Turbo Pascal. I also taught myself dBase III and was able to get a hold of the Clipper compiler and teach myself how to use that to compile the dBase III programs I was creating. Since then, I’ve taught myself additional development skills – C, C++, MS Visual Basic, CA Visual Objects, Java, Python, Ruby, Ruby on Rails, JavaScript, PHP, Objective C, Swift and others. I’ve also figured out how to use HTML, CSS and other web tools. This doesn’t include all the frameworks that I’ve learned along the way. I will be the first to admit that I’m not an expert in most of the previously mentioned languages, but I at a minimum can hack my way thru a development session using the languages mentioned above.

Why am I listing off all this stuff? Well a couple of reasons:

1)      Lifelong learning is critical within the technology arena. Those who think that they can learn 1 or 2 things and use that their entire career are in for a world of hurt. I would say over the last 30 years, the pace of change and expectations of picking up different development skills has accelerated – much the same as in other professions. Today’s focus on DevOps and other paradigm shifts, is forcing developers to learn new skills and become even more adaptable.

2)      There is a tendency to ‘get comfortable’ and develop new code using technology that you are familiar with – you can get it done quicker! However, at least in my organization, I sometimes need/desire to have people jump between teams and this requires that they be able to utilize different technology skills – C++ vs Java vs Objective C, with a little Python thrown in here and there to make things interesting.

When I first started programming there was no internet, no on-line help, no instant messaging to help me figure out how to get around different programming problems. There were thick manuals that I had to sit back and read. Today, engineering teams can use the internet to find solutions to problems, to find sample code or entire libraries/code that solve the particular problems that they encounter.

I remember having to write my first authentication and control system to wrap around a system. Today, I can go out to git and find dozens of complete libraries that perform basic application authentication to complete 2FA and access control within applications.

The tools available today make it much easier for developers to gain a basic proficiency of a given language. You can find on-line tutorials that guide you thru downloading a new language, creating your first project and stepping you thru the ins and outs of the frameworks. I would have killed to have access to those types of tools as I was starting to develop software.

As software engineers, we shouldn’t be afraid to pick up new skills. As leaders, we should be encouraging our team members to take a look at the new languages, scripting languages and frameworks. We should all be looking at ways to increase our efficiency, deliver functionality faster, increase the quality of what it is we are building and keep an eye on emerging trends that may impact the systems we create and support.

If you'd like more information on my background: LinkedIn Profile

Recapturing our Youth!

This has been an interesting period in my life. My wife and I recently moved our youngest son out of the house into his dorm, so that he could begin his college experience. It was a really incredible day, seeing his excitement and watching him and all the other kids in the dorm move in. Yes, we were busy setting up the room and getting all of his stuff tucked away. Yet, while all this was occurring kids were wandering the halls beginning to meet each other. The excitement was visible, everywhere!

Over the last couple of weeks, he has made it a mission to visit each of the floors in his dorm, using a Frisbee to start up conversations and get to know the people he now lives with. He has wandered into other dorms in an effort to get introduced to more people and build his social network. He and his friends have introduced themselves to people tailgating the football games and expanded their social circles. He seems to be on a mission to get to know as many people as he possibly can – yes, he thrives on social experiences.

Looking back at my own experience as I made the transition from home to college, I remember the fear, the excitement and the fun of leaving home, meeting new people and having new experiences. It got me thinking about how change is viewed in the office, let’s just say it is not necessarily a positive within our teams.

Let me walk thru a recent experience – over the last year we have been introducing the use of Kanbans as a tool to visualize enterprise project activity across the organization and within my teams using team stand-ups to talk thru the tactical daily promises. Our daily stand-up meetings are focused on simple communication – what did you promise yesterday/did you deliver, what roadblocks are you encountering and who needs to jump in to help remove the roadblocks and what are you promising for tomorrow. Can we move the card on the Kanban? Yes, we are crawling before we walk, walking before we run and running before we try and leap. These are things that many folks within the organization and within my teams have advocated over the last several years.

We are not fully Agile, not sure if we will ever get there, but we are trying to use some of the tactics within projects where it makes sense for us.

What I find interesting is the pushback we have received along the way. I was expecting some of this, but was surprised when some of the very people promoting Agile techniques began to resist the actual implementation of some of these techniques. Some of it came down to – well if you aren’t going to implement and adhere to the entire Agile principles, than how do you expect me to get onboard. Other times it came down to, well I’m not really comfortable trying this in-front of other people.

I get it, we hate change. But when did that shift occur? Again, I look back to my sons as they grew up. They constantly were experiencing change, each year asking to take on new responsibilities. Tackling new topics at school, meeting new teachers, being a part of school sports, taking on roles within the student council. Outside of school, trying various sports when they were younger and then adjusting to changes as they progressed with their athletic talents. Sometimes taking on leadership roles, other times acting in support roles. They grasped for these opportunities, not expecting failure and looking for the next challenge.

Yet, somewhere in our path to adulthood, we start to resist change. We like the stability of knowing what it is we are doing, what comes next and who does what. The funny thing is we talk about change, until it happens to us.

Ultimately, we need to be agents of change for the companies we work for today. In the past, there were periods where businesses did not need to worry about rapid change. That dynamic is no longer true, businesses must continually evaluate the products and services that they are providing, the competitive pressure of local and international competitors. If you’re not constantly ensuring that you are serving your customers, your customers will walk away.

I encourage you to recapture that spirit of youth where you wanted change. Where you weren’t afraid to accept change. If our businesses are going to succeed, we need to continually change to adjust to the needs of our customers.

If you'd like more information on my background: LinkedIn Profile