Subscribe via RSS Feed

Author Archive for David.Katauskas

What Taking-a-Hike Can Teach Us About Business

Hiking in autumn forestSomething Special…

This week I have something special for you. A guest post from one of my best friends. Dave Katauskas regularly shares insights that  make a huge impact on a team’s performance and success.  The story below has changed how he and I make choices within our daily work.

So, without further ado, I hope you enjoy the following blog post as much as I did.

Have I got a story for you!

Recently, my friend, we’ll call him “Bob”, and I decided to hike on the Ice Age Trail in Wisconsin. This was in preparation for our bucket-list-goal of walking a portion of the Appalachian Trail.  We knew any hike would be a challenge merely because we were non-active desk jockeys, 50+ pounds overweight and past middle-aged.  If you’ve ever seen the “before and after” photos in most health diets, we would be in the “before” picture.  I believe that sums it up.  Yet, we were determined and eager to get started.

Let’s get going!

On the first day of our 2-day hike, we set out on the Ice Age Trail to explore the wilderness and just enjoy ourselves.  We saw many great sights and regularly rested with food and water from our backpacks.  It was a great day with perfect weather.  All of the elements indicated that this day would run flawlessly.  In an eerie sort of way, this was strangely similar to the optimism and energy we have when starting a new and exciting project.

Knowing that this first leg of the hike was only a day hike, at some point in our journey we would need to turn around and track back to our car.  The morning went well. We felt strong, full of energy, sharing a great time on a beautiful day. The morning was going quickly and before we knew it, we reached the five mile mark. It was just after lunch that we started to think that turning back at this point would be smart. The second half of the hike would probably go slower.

After looking at the map, there was a ridge ahead that would provide some interesting views and a shelter.  Feeling physically able and still eager, I suggested that we squeeze in a few more miles before turning back.  Bob had a gut feeling that we needed to turn back because we may be reaching our physical limits.  He’s older and more out of shape. Of course, he was also being risk adverse. We all have a Bob on our project!

We clearly weren’t in agreement, so we discussed it a bit.  But without the definitive proof that we were actually reaching our limit, we decided to press on. His version of this story is that I convinced him to press on. We agreed to turn back at mile seven.

Around mile six, the path changed to a steep incline. I mean a painful, slow, incline.  But we made it to the top and to mile seven.  We felt great at arriving at the top of the ridge and rested on the trail near the tall grass.  Unfortunately, the view wasn’t as spectacular as we had imagined.  In fact, there was no view at all except for tall brush and grass.  But we still felt great at making it to mile seven!

So we took a break and decided that it was time to turn back.  The first seven miles were great so the next seven should be equally great…right?  As you’ll read later, we were oblivious to the fact that we were just short from the real “point of no return”.

It’s really not that much farther…

Well, about two miles into the return trek, we realized that we were out of water.  In addition to that, our legs and feet were starting to become very fatigued and sore.  But press on we did, not that we really had an option.  So, another two miles later (that’s 11 miles total for the geeks doing the math…like I just did) we were now becoming worn out. The storm clouds started rolling in, the wind was picking up and our flawless day was no longer looking so flawless.  We now had as additional sense of urgency to stay out of the impending storm.  Yet, we still had about three miles to go.  We saw the coming gloom, we still had plenty of trails in front of us and we were in pain. Talk about a “Death March”! (Have you ever experienced a software project similar to this?  Doesn’t this really sound like the beginning of a death march?)

Houston, we have a problem

The next mile became a struggle as our bodies were not actually equipped to deal with the demands which we had placed upon them.  This next mile was truly indicative of what the final two miles had in store of us.  Our legs started cramping, each step was actually painful and we were thirsty.  We limped along, well aware of each and every step. We genuinely weren’t sure if we would make it back to the car without some assistance.  (How many times have we committed to more than we can successfully handle?  Or actually know what we are really committing to?  On the plus side, we did know that were very close to needing to ask for help.)

And then it happened…

It became apparent to us that our short term view of what we thought was feasible became a decision that ultimately created pain, anxiety and the possibility of failure.  To add insult to injury, it started raining. (The “death march” continues)

After a long while, we finally reached our destination and found a covered bench.  We sat for a few minutes, then headed toward the car; a distant 12 feet away.  Limping and cramping is what I remember mostly.  After what seemed like an eternity, we walked from the bench to the car.  Now we just needed to get in.  We somehow managed to hold back the man-tears. Well, at least I did!

The residual evidence was apparent by our pampered and ginger walking around the office over several days.  A trip we’ll never forget!  (I’ve certainly been on projects where we limped across the finish line). Yes, pain is certainly one of the best teachers.

How we changed our views

A few weeks after our hiking experience, we were able to reflect again upon our journey and we noticed similarities around how making decisions for short term goals, or decisions based on lack of insight, can have significant effects on long term outcomes.  The decision to continue after mile five was clearly a bad decision.  We talked about the moment, that specific choice, which led us to continue on.

Then I thought about all of the bad decisions that I’ve witnessed and made on project work. But instead of the conversations centering on making a bad decision, we would state that it was just poorly executed. We would never challenge our decision approach or conclusion.  For this hike, our execution was fine; the decision was bad.

We then started discussing some of the decisions that we’ve personally made in directing business objectives and how some of those decisions created pain for ourselves and others.  And, in some cases, it established additional barriers for corrective action.

Our take away…

So, when making business decisions today, I now ask “how can we prevent this from becoming our 14 mile death march?” and “are we just kidding ourselves?”  I was actually able to put this into practice one day when our leadership group was discussing strategic staffing.

We knew that a decision to handle a short-term, non-bulls-eye opportunity would certainly hurt our capability to engage in an on-target opportunity in the future.  So, we had good discussions around that topic and looked at the varied perspectives with our eyes wide open.  We stuck with the strategic goals in spite of a small immediate win.  And since then, we’ve been able to apply that same concept to other growth challenges.

In addition to all of that, Bob and I have since hiked again.  This time, it included a change in our behavior, thinking and knowing our real capabilities.  It was a more pleasant experience.

So next time you have a tough choice and everyone is debating an approach, consider you may be at mile five of your hike, and sometimes, it’s better not to push the limits … because you’ll feel the pain for quite some time afterwards!

Iteration Zero: Reduce Risk Before You Begin the Project

Reduce Software Project Risk Before Construction Starts

Sunglasses-and-RoadmapLast week we talked about the level of planning required to ensure that a journey (whether a travel adventure or a software project) be enjoyable, problem free and capable of delivering better results.

In the first stage of planning for our journey, we identified where we wanted to go and how we thought we’d get there. In software development, this can be thought of as business definition and understanding the business objectives. The second stage of preparation for our fictional journey — studying a detailed map and the purchase of travel gear — can be thought of as Iteration Zero.  This is where the team’s virtual assembly line is prepared. Finally, the third stage of swimming and running is the construction phase.

Iteration Zero sets up the groundwork for construction by implementing the reusable patterns and components in the application architecture and preparing the environment for a development team to be effective. This phase helps to remove the traditional Just-In-Time environment setup that often occurs in the construction phase. By adding an Iteration Zero, you are essentially allowing for time to be utilized more effectively and predictably during the construction phase.

One perception about the phrase “Iteration Zero” is that it implies an agile style of development. This is not necessarily so. The practices in “Iteration Zero” have been used successfully with several different development methodologies.

One of the major dependencies for an effective Iteration Zero is awareness of the success criteria of the project defined and agreed to by the business. They also need to be understood by the technical team(s) before the Iteration.

Creating a Forum to Ask Questions and Learn

One of the most important elements for executing Iteration Zero is the Workshop. The Workshop allows the team to see how the software is going to be developed from a process perspective. Additionally, it helps the team become familiar with the technologies, components and patterns implemented and added to the code solution. This begins the process of the team becoming immersed in the construction process.

In order for the development and quality teams to be effective in Iteration 1, the Business Analyst should begin creating the Business Rules Documentation. Iteration Zero provides them with a jump start from both the development team and the quality team.

Iteration Zero can also be used to identify risky technical aspects of the system. These risky elements should be studied to form a mitigation plan (during Iteration Zero) to learn as much as possible, as early as possible.

Hit the Ground Running

Although there are ways to prevent a project catastrophe, most of us have still seen at least one project land in the dumpster for a myriad of possible reasons. While there are risky elements outside of delivery that can hurt a project, adding and enforcing Iteration Zero is a great way to make sure your next journey goes faster, behaves more predictably, and adds more value to the business.

How is your team using Iteration Zero?

Photo Credit: Thomas Beck Photo

Software Architects: Hit the Ground Running

A New Look at Iteration Zero

Roadmap1How many times have you been involved in a project where leadership wants more architecture documents produced … but there just isn’t enough information to produce the documents? How about when leadership wants you to start coding the moment the construction phase begins?

While problems like this plague development shops, it doesn’t have to be that way. I believe that there’s a perfect plan (based on the Agile method of Iteration Zero — the phase that occurs after project definition but before construction) to make sure that when construction begins, coding starts.

Getting Out the Door

Imagine we are going on a journey. Whether our journey is a software development project or a trip to a new place, preparing for a journey should follow a process. Journeys that adhere to a process right from the start are much more likely to be enjoyable, problem free and capable of delivering better results.

Let’s say that we want to travel from Toronto to New Jersey. However, there are several things that we do not know about this trip. In fact, we don’t even know all the things we don’t know about yet. And, if we think that we know, we are only fooling ourselves. So what do we do? We pull out our map, and begin to look for the most direct route.

First we need to answer some basic questions such as “How will we get there?”, “When will we leave?”, “When will we arrive?” and “Why are we going?” Mentally, we start a high-level planning session to answer these questions. We eventually determine that we will be traveling on foot because the other options are just too expensive for our limited budget. We also determine that when we travel, we should arrive at our destination in about 30 days. We know that we are going to New Jersey to reunite with some old school buddies. When our visit is complete, we need to trek back to Toronto. This means that the total trip will span 67 days.

Then we start to drill down into the next level of detail. We need to cross Lake Ontario because if we walk around we’ll add another five days. We know that we are very good at swimming and coincidentally were born with webbed feet. We also know that we can swim across Lake Ontario in 3 hours. We plan our route across the lake and make plans to eat at Sally’s Diner in Buffalo, New York. We plan to rest in Buffalo and spend the night.

We then continue this level of thinking and planning as we travel through several states, rivers and finally over the Appalachian Mountains to our destination. After considering the potential for foul weather and our actual ability to make this trip, we realize that the trip will not take 67 days, but actually 84 days. This means that we need to start walking, or swimming, no later than the last week of March to arrive the first week of May. But, it’s already the second week of April. So, now we revisit the plan to include running instead of walking. Such is life.

Now that we have all of these plans, the next step is to actually physically prepare for the trip. The objective of this preparation phase (which takes an entire week) is to ready ourselves for the long journey and allow us to walk out the front door with confidence. It includes shopping for eight pairs of good running shoes, two pairs of hiking boots, a wet suit, some clothes, toiletries, a new back-pack and many other things. Next, we start a more detailed mapping of our exact route. We start conditioning our bodies for our impending, physically taxing experience. Without performing each of these activities, we increase the probability that we will be late for our reunion … or worse, not even make it at all.

We now have everything we need. We are ready to walk out the front door.

So, now you may be asking … what does all of this have to do with Iteration Zero and software development? The whole process described above is all about managing risk and approaching the goal properly. We have identified where we want to go and how we’ll get there. In software development, this can be thought of as business definition and understanding the business objectives. In the second stage of preparation —  studying a detailed map and the purchase of travel gear — can be thought of as Iteration Zero. This is where the team’s virtual assembly line is prepared. Finally, the third stage of swimming and running is the construction phase.

Next week, we’ll determine if our planning process was enough to have a successful journey (or development project) without stifling ourselves with too much complexity.  Process is supposed to enable, not disable.

What does your team do before construction to make sure that when construction begins, coding does as well?

Photo Credit: Scott Meis Photography

How Internal Pressures Can Implode an IT Organization

Roadmap with cities and distances

Know where you are today. Be clear on where you’re going.

Last week, I talked about some of the many organizational pressures that can implode an IT team.  In fact, some of these may apply to other parts of the organization as well.  This week, I’ll take a look at an approach that can shed light onto solving these issues.

It’s All About Perspective

The ability to look inward in a truthful, non-self-serving manner is a phenomenal attribute to possess.  The same holds true when looking at an organization that you’ve helped create.  Allowing myself to pull out from working within the team to working on the team has afforded me valuable insights.  This ability to change perspectives is the best way to look around and objectively survey the landscape.

Once I change my perspective, the focus becomes applying a very simple approach that has been invaluable to me over the years.  Three steps: Where do we want to be, where are we now, and how do we get there?  In that order.

Where Do We Want To Be?

What may have worked well a few years ago may not be the optimal solution for today.  This is simply because our surroundings continually change.  So, resetting the baseline and re-establishing alignment can be a continual process.  Understanding how the organization will be measured and knowing what problems you’re trying to solve today will be the starting point to crafting your solution.  Not knowing where you want to be is like driving a car with a blindfold.  You’re bound to hit something and you won’t get anywhere.

Getting the right group involved is a great way to start the alignment process.  During that process, it may become clear that others have different agendas, goals and ideas on how something should be implemented.  Facilitating this group alignment on where the organization needs to be and establishing a common vision will allow everyone to head in the same direction.

This is also the time to make sure your goals will solve the problems as they are perceived today.  If silos exist or technology is scattered as I described last week, then perhaps one of the goals is to look at how to create horizontal technologies that can be shared amongst the silos.  The goal could be as simple as creating a shared platform which has an added benefit of getting the teams communicating more.

Where Are We Now?

This is where taking a step back is the most helpful.  Being immersed in something for an extended period of time gives us a single perspective of what we know to be true.  Because many teams have a lot of knowledge about what already exists (after all, they live it every day) it can be tempting to breeze through this phase.  Do not breeze.  Do.  Optimally, document the enterprise architecture of the technologies, processes and roles that exist.  You will most certainly uncover some interesting aspects of your surroundings that were previously based on assumptions.  If you have found this to be true in your experiences, please share in this blog discussion!

How Do We Get There?

This is the part where a roadmap is created.  This is typically the most difficult phase.  It has been equated to creating a solution to changing the tires on a moving race car.  It can be difficult, but do-able.

Not only is this the most challenging phase, but it’s also my favorite.  This is also the same phase where you should consider inviting the solutioning team from the first phase. They are invested in the destination, so it only makes sense that they should have some passion and energy around getting everyone else there.  Don’t go it alone.  Following this approach, you will begin seeing a team start to craft a common vision and a plan that is designed to accomplish what may have previously been thought as impossible.

The Bottom Line

Continually measuring and re-aligning has helped me immensely in preventing my teams from imploding.  This is not a tool that gets used once and discarded.  It’s designed to be used continually.  The frequency will be determined by the velocity of change in your organization.


  • How have you had to cope with organizational pressures and how did you get started toward resolution?
  • How did you engage the right people for the solutioning phases?
  • What obstacles did you overcome?
  • What other pressures have you seen implode or hurt an organization?

Photo Credit: Goldemberg Fonseca

How Internal Pressures Can Implode an IT Organization

Implosion1Last week, I talked about some of the organizational mindsets that lead to misalignment within an IT team. This week, I’ll look more closely at some of the specific pressures that can cause problems for the team and impact IT team performance. These are based on some of my own experiences in my role as an Architect.

Team Silos and Lack of Communication

Larger IT organizations often contain splintered groups that focus on either specific functional or technological areas. These groups can easily become silos. This can result in redundant efforts and solutions, dissimilar technologies, or disjointed entry points for business requests. More importantly, these silos may not easily communicate, inhibiting collaboration. Probable result: If a technology group makes changes and deploys, they run the risk of clobbering another team’s systems. Usually, they won’t know about it until production issues arise. The teams are neither in alignment on technology, people or process. This has the potential to bring progress within the IT organization to a standstill.

Pressure to be Bleeding Edge

Have you ever witnessed a technology team adopting new technologies for the sake of being bleeding edge? This desire to be bleeding edge is another factor that can cause pressure on the IT team. There are certainly many cases where new technology solves problems and creates additional efficiency. But what about the team that wants to utilize a new technology only for the sake of playing with new technology? It may perform the same function as the current technology, but just does it in a different way. Is there any value in that?  Does it help attract talent? Can it be adopted and integrated without any additional effort? Does it position the team to becoming more nimble? Does it align with long-term objectives of not only IT but the organization as a whole?

If some members of the team answer “yes” to these questions and some answer “no”, then the use of some new technologies can cause misalignment on the IT Team.  They may either have conflicting agendas or may just be out of alignment with how they need to accomplish the task-at-hand.

Teams That are Always Stretched

Stretching from time-to-time can be very healthy. It keeps a team aware of their limits and capabilities. It also helps a team to gel and rally around an effort that has a sense of urgency. Then, during the non-stretch times, it allows the team to think strategically, place more focus on refactoring which will allow it to scale for the next stretch. On the flip side of that, a team that is never stretched can have morale issues and may not deliver value at the velocity that is expected. But while the resulting atrophy isn’t healthy, teams that are always stretched are in worse condition. Stretching can result from task overload, following an antiquated process, working with unfamiliar technologies and working toward an unrealistic goal.

In any of the situations above, design and development decisions are usually made with the highest priority being: “Get this pain away from me as quickly as possible”. Decisions consistently made in this mode, usually create technical debt. If an IT organization consistently resorts to short term fixes, it compromises its potential and future progress and we begin to see implosion at the organizational level — not a sustainable plan.

What are some of the pressures has your IT team faced recently?


Next week, I will delve into some of the approaches that can be used to rectify these situations or prevent them from happening in the first place.

How Internal Pressures Can Implode an IT Organization

When an IT Group Unravels

Many of us have gained valuable insight from articles about lack of business-IT alignment. But what about an IT organization that is misaligned with itself? How prevalent is this and what causes it to happen? There are many kinds of organizational pressures that can cause this to occur. Over the next two weeks, I will reveal how IT can implode from within.

This week, I’ll talk about what leads up to an IT organization becoming internally misaligned. But first, let’s define what “misaligned” means. It means that groups or individuals think that they are all focused on the same agendas, have the same motivations and are marching to the same objectives and goals, but in reality, they are not.

Think of a deep sea submersible designed to withstand immense pressures.  During a deep dive, all it takes to implode that submersible is a single breach that isn’t discovered until it’s too late. Similarly, an IT organization may be designed to be resilient to pressures and stretching, but may have weaknesses that eventually reveal themselves and result in implosion.

So What Causes an IT Team to Become Misaligned … With Itself?

I’ve been hearing a lot lately about how IT should actually be a part of the business team and not exist as a separate entity. In reality this is not actually practiced in many organizations. For the most part, IT exists as a separate, autonomous organization. Given that this is the norm today, this post will assume that situation.

There are cases when business provides exactly what an IT organization needs to deliver value. Yet, despite that clear direction from the business, the technology group still fails to deliver. What resides at the core of this issue? Why do we still see technology groups with silo mindsets, separate agendas, different motivations, and  little, if any, insight into what makes the other groups tick?  I believe it all starts with a lack of understanding of how to unite these technology groups and individuals into a single, cohesive and effective functioning organization.

Separate, non-transparent, or seemingly conflicting agendas and motivations can kill any alignment within a team.  Like functional groups looking to gain a competitive advantage or reduce operational costs, the technology groups are trying to manage technology costs in real-time, reduce risks, deliver value and leverage centralized technologies to support and keep pace with functional changes. Notice any real similarities in what drives groups described here? Neither do I.

I’ve never met a technology group that didn’t have the desire or best intentions of providing superior value to the business and the company.  Unfortunately, passion alone will not cut it in today’s market. In fact, this passion can actually be the catalyst that exposes the IT team’s potential to implode. And that’s a good thing. It allows us to see the signs before the damage actually happens.

Is This IT Team Ready to Implode?

Have you ever been in a situation where the business summoned IT to deliver some seemingly ambiguous value on some seemingly arbitrary date? Or perhaps the business drivers weren’t communicated to everyone. You might have even wondered why an initiative was chosen and given to IT in the first place.

An IT organization may hear something like this: “The business has a strategic initiative to enable our partners to integrate into certain aspects of our operations. This will allow us to reduce costs by 3%. We need to provide them with access and limited control over certain portions of our systems and we need it no later than March 15th.  IT, please deliver this objective and start development next week.”

In this scenario, commitments were made without the technology buy-in. Technology teams often ultimately say, “We will start next week and figure it out as we go. It sounds aggressive but it should be ‘do-able’”.  The functional group interprets this as a commitment from the technology group. However, without more clarity around a vision of success for this project, the business will probably not get the value they need to satisfy their agenda. And, IT will most likely be held accountable when they don’t deliver. Everyone loses.

Although the IT team had a desire and passion to help, they also set themselves up for implosion on the project. They accepted the cards they were dealt without saying “In addition to what you have provided, we need X to be successful”.  In other words, they set themselves up for failure rather than move forward informed and empowered to deliver on expectations.

Next week, I will dig deeper into some of the specific pressures that can cause a team to implode and how to meet the challenges.

Has your team ever come close to implosion? What cause did you identify?