Essential Agile

In my previous article, “The Technology Executive and the Software Craftsman,” I discussed how software developers like me who were trained in the earlier software engineering disciplines that were managed based on the waterfall model felt that there was something fundamentally flawed with the model. We knew that close collaboration between developers and clients usually yielded better results, but the formal waterfall process created barriers to that collaboration. In this article, I will explore the fundamental flaws of the assumptions underlying software engineering as managed by waterfall models. I will then discuss how Agile software development methods address those flaws by addressing the inherent design-centered process that we know as software development harnessing its people-centric and social aspects.

Engineering Software as a Flawed Assumption

While the waterfall model, when applied to software development, has taken its share of disparagement over the years, the failings of the waterfall model itself are merely symptoms of what I see as a flawed assumption about software development. That assumption being that software is engineered at all. Engineering as defined by Wikipedia is “the application of mathematics, empirical evidence and scientific, economic, social, and practical knowledge in order to invent, innovate, design, build, maintain, research, and improve structures, machines, tools, systems, components, materials, and processes.” Engineering frequently assumes formal methods and disciplined sequencing of development steps. It is no accident that when the development of software is viewed through the lens of engineering that the waterfall model takes center stage as the incarnation of the software development process.

Many a long-time practitioner of software development believed that viewing software development as an engineering discipline was attempting to shoehorn a more iterative process into a formal engineering discipline when in fact the process of developing software was another animal altogether. In current software development thinking, we talk more about software as being designed rather than engineered. Part of the Wikipedia’s definition of Design states, “Designing often necessitates considering the aesthetic, functional, economic and sociopolitical dimensions of both the design object and design process. It may involve considerable research, thought, modeling, interactive adjustment, and re-design. Meanwhile, diverse kinds of objects may be designed, including clothing, graphical user interfaces, skyscrapers, corporate identities, business processes and even methods of designing.” When we view software development through the lens of design which involves interaction, collaboration, and adjustment, the problems with the engineering-centric view become apparent.

Software Design as a Better Paradigm

Engineering infers technical competence, adherence to standards, sequenced collaboration, and top-down management to enforce process and standards since those are assumed to determine timeliness and quality. Design infers technical competence, collaboration, managed discord, and servant leadership to remove obstacles to progress in response to uncertainty. So why does assuming software development is an engineering discipline so often result in late projects and dubious quality? There are two reasons. First, engineering assumes that a problem can be almost completely understood up front, and only minor adjustments will be needed on the back end of the process to account for requirements changes. Second, and in what is bound to be a controversial comment, engineering values process and standards over individual judgment and intuition. In practice, because software systems tend to be complex and involve the sometimes subjective judgments of stakeholders, we seldom have a clear picture of the problem to be solved early in the software development process. Rather, the requirements become clearer over time, sometimes taking 30-50% of the project timeline to become well understood and enumerated. Engineering processes are not tolerant of such uncertainty while design process assumes uncertainty.

Design is a better model for software development simply because the process of design acknowledges the uncertainty of requirements and seeks to adjust and redesign as needed. At this point, some will say, “but design is part of any disciplined software development process.”  To those I say, treating design as a discrete component of the software development process denies the reality of rolling uncertainty and evolving clarity of the requirements. Rather, the entire software development process from end-to-end is an ongoing design process where the understanding of the problem evolves and necessitates almost continuous solution readjustment.

Clarity Through a Shifting Paradigm

When we get used to the idea that software development is better thought of as design process than as engineering discipline, key discriminators of success begin to emerge. First, we acknowledge that project timelines cannot be established at the beginning of the project. My own experience has shown that committed timelines can only be established after about 30-50% of what will become the total timeline has elapsed. Knowing this is important because executives and managers may have differing expectations about the timeliness of software delivery that need to be managed. This is not to say the Agile methods cannot establish and meet deadlines but rather that deadlines are established well after the project is underway. This is a fundamental shift in thinking about and setting delivery expectations. Second, the role of the project manager shifts from managing to deadlines to managing collaboration and removing obstacles to success. This is a critical distinction because many formal project management methods lean toward top-down management which is not amenable to iterative collaboration. It’s important that emphasis is placed on finding project managers who act more servant leaders versus managers of milestones since managing uncertainty means that risks will arise that must be mitigated collaboratively. Finally and most importantly, viewing software development as design highlights the fact that software development is an inherently social activity where interactions between people are valued over formal processes which seek to control such interactions. I have written extensively about the necessary tensions that exist in software development that need to be managed in order to produce great software. Engineering approaches seek to eliminate these tensions using process while design approaches acknowledge the existence of tensions and harness them to produce better results.

The Essence of Agile

Agile software development methods continue to evolve and are far from perfect. However, Agile methods more closely match the iterative and collaborative processes that align more closely with the true nature of software development. Still, engineering mindsets persist and manifest themselves in Agile shops. Agile by its very nature replaces tightly controlled engineering steps with a necessarily fuzzy set of guidelines. For example, the Agile Manifesto states the following:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

I run into Agile practitioners who seem to replace the word “over” with the phrase “instead of” in the above guidelines. I don’t mention this to impugn but rather to highlight that dogma that is necessary for engineering discipline sometimes creeps into methods that are pragmatic by their very essence. Because Agile is inherently pragmatic and experimental, I find it valuable to continuously reinforce the “spirit” of Agile over its “letter.” Here are few examples.

Spirit versus Letter

The Agile Scrum method has a number of rituals that are intended to promote collaboration. Among those are sprint planning, stand-ups, showcases, and retrospectives. When we first adopted Agile Scrum at one job, we tried to be rigorous with requiring that these rituals were held in uniform ways. Over the course of time, some in the development staff began commenting on how they were not getting value from some of the rituals, for example, stand-ups and lobbied to do away with them. We went back and forth about whether stand-ups were needed. The more dogmatic supporters of Agile maintained that they were a required part of the process and that their use should be enforced. The more pragmatic Agile supporters argued that stand-ups were not needed because they were accomplished in other ways. After listening to both factions, I asked what was the “spirit” of a stand-up. Obviously, the spirit was to ensure the teams had a daily progress checkpoint. I found that while some teams needed the structure of a formal meeting because the team members worked independently, other teams worked more collaboratively on a daily basis and kept themselves more constantly informed of progress. In the former case, the team needed stand-ups to assess progress while the latter team had ad hoc stand-ups without the need for formality.


So what are the lessons to be taken away? Software development is an inherently social process where technically competent people come together with their customers and iterate through a process that more closely resembles design than engineering. While there are some required steps needed to ensure fitness and quality, much of the Agile process in inherently fuzzy and open to pragmatic experimentation and adjustment. In Agile, one must keep in mind the spirit of the tenets of the Agile process and be careful to adhere to those intentions lest unreasoning dogmatism creep in and attempt to bend the people to the process rather than bend the process to the people. This does not mean that Agile development should devolve into an uncontrolled process. There are firm needs to enforce application lifecycle models and quality gates to ensure that best practices are followed and that traceability and validation can be maintained. But these necessities need to be balanced with the flexibility and pragmatism that Agile represents.

When a proper balance is struck between necessary practices and areas where experimentation and flexibility are promoted, you will find that your Agile teams will work more closely together to find solutions to their own problems. When teams are permitted to be experimental, they also tend to be more cohesive leading to more engaged and satisfied team members. If you focus on attending to the essence of Agile over strict doctrine, I think you will receive better results, and your teams will thank you for it.



The Power of Intention (in software development)

In my previous article, “Designing an Accountable Software Development Organization Part 2: Vision, Levers, and Tensions,” I discuss the tension that exists between requirements, governance, and technical delivery activities within a software development organization. The tension between these activities is a necessary part of developing truly great software since they provide checks and balances between sometimes competing agendas. In that article, I illustrate the effects that tension on misaligned organizations and discuss how better organizational alignment helps the software development leader manage those tensions and keep them healthy.

Even after achieving the best organizational alignment which allows tensions to bubble up to the right level where they can be managed, the requirements, governance, and technical delivery folks will occasionally go toe-to-toe over issues that arise. The question is when things get heated between disagreeing parties, how do we ensure that tensions stay healthy or more importantly, how do we restore health to an already unhealthy tension? The answer is both simple and complex and comes down to a single word: Intention.

The Right-Wrong Game

The need to be right and to avoid being wrong is hardwired into people. Unhealthy conflict is defined in terms of what I call right-wrong games. Right-wrong games are usually characterized by zero-sum thinking where one party believes that to be right; the other person has to be wrong and vice versa. Also by definition, there is no middle ground and no giving ground. When I see people engaging in these conflicts whether, through email, text messages, or other means, I imagine them sitting opposite one another at a table doing verbal battle face-to-face. When you dig deeper into these conflicts, there is usually a single root cause: each party has attributed a contrary intention to the other party and is allowing that preconception to drive their actions and emotions.


Let me give you an example. A product manager and software architect are locked in a battle over software requirements and how to implement them. The product manager insists that the requirements must be accepted in their entirety in order to meet the customer’s needs while the architect is looking for requirements flexibility in order to make a more maintainable implementation. The product manager believes they have the customer’s best interest at heart because requirements are paramount and that the architect wants to take shortcuts to make their job easier. The architect believes that making a more maintainable solution will benefit the client by ensuring higher quality and that the product manager is taking a short term view and being inflexible.

So what’s happened to make the relationship fail? The product manager and architect have attributed bad intentions to their opponent and then allowed their perception to drive behavior and emotion. In short, each party believes that that other is out to thwart their best intentions, and each party is hell-bent on stopping the other because each party is convinced of the virtue of their position.

Breaking the Right-Wrong Game

When faced with these conflicts, the best outcome is to get both people on the same side argument working toward a mutually beneficial solution. In short, they end up side by side on the same side of the table looking out together toward a common solution.


So, how is this accomplished? The parties in conflict need to come to the understanding that they both share the same intention. Namely, to provide the best solution for the customer. They will come to realize that they both want the same outcome and only differ on the means to achieving that outcome. They must realign on their intention and acknowledge that the other party shares that intention. This does not usually happen in the heat of a right-wrong battle and requires a cooling down period first. Even then one party or the other may not what to give ground. It’s the job of the software development leader to bring the warring parties together and get them to reveal their own intentions and acknowledge the good intentions of the other person. With a little guidance from the software development leader as the a third-party, the two parties will come to realize that they both have the same intention at heart. The goal is for two parties to become allies in finding a solution that aligns on their common intention.

Reducing the Occurrence of Right-Wrong Games

The key to reducing the occurrence of conflict in software development organizations caused by intention misalignment issues is to prevent such conflicts from starting in the first place.  To do this, the software development leader must define the intention in collaboration with their team, seek alignment on the intention, and constantly reinforce it. In my own software development organization, we have three primary intentions: Delivery software that is the best fit for the business, deliver high-quality software, and deliver it when we promise we will. These three intentions may seem intuitively obvious for a software development organization but, often, they are assumed rather than made explicit and are spoken about in a trite manner.

Recently, our team delivered a major software release designed to allow more customers to migrate to our new platform. The team pushed extra hard to meet a deadline and succeeded in delivering on time despite numerous obstacles. At the weekly status meeting near software delivery time, I made sure to reinforce with the team how they supported the business by delivering the right functionality, with high quality, and on time. All throughout the effort, the team was focused on the goals and aligned on our common intentions. When obstacles occurred, they came together and found ways to overcome them…usually on their own and without management intervention. They made a hard task look easy all because they worked together. I couldn’t have been prouder of the team for their commitment and the results.

Be Easy on Yourself

As a software development leader, it’s all too easy to get frustrated and annoyed when inter-team conflicts arise. I know this first-hand because I sometimes feel this myself. When I have a moment to step back and reflect, I remember that software development is the art of balancing tensions to get the best results. Software development is a human endeavor involving high-performing people who sometimes see their peers as obstacles to meeting their intentions. When you want to jump out a window out of frustration born of interpersonal conflict caused by misattribution of intention, remind yourself that your software development staff is well-intentioned and wants to do the right thing whenever possible. In short, be easy on yourself for not being able to avoid these conflicts and be easy on your team since we all share the same virtues and vices when it comes to relationships. Your team needs a periodic and gentle reminder that they all aligned with the same intentions. Rather than forcing a result, more likely than not,  you will find that your team will come together and find their own solutions and get a sense of satisfaction in doing so.



Agile Software Development Team Empowerment: A Holistic View

Over the past six decades, software development has evolved from what was thought to be an engineering discipline complete with rigorous methods and processes to much more of a crowd-sourced social engagement involving skilled craftsman and iterative collaboration.  Executives and managers have had to adjust their thinking from a “command and control” style where every aspect of software development was tightly timed and controlled to a “servant leader” style where the goal is to empower the team to make decisions and remove obstacles to their success. I have written previously about these  “softer” aspects of software development. In this article, I will pull together the previous concepts into to a holistic view of Agile software development team empowerment. My intention is to create a framework which can lead to more productive teams that produce high-quality code stemming from of business-focus, trust, and collaboration.

Before I begin, there are a few assumptions I make as precursors for any software shop as follows:


Good Talent. Any high performing team needs to be staffed with talented staff. Most well-functioning agile teams will police their own ranks and either help to raise the performance of mediocre members or identify those that need extra help and support. This self-policing comes from a strong sense of team and focus on the development goals. If you don’t hire the best talent and then allow Agile team dynamics to work their magic, then you may be forced to resort to command and control means to reach your goals. Resorting to command and control methods with Agile teams usually produces the undesirable outcomes of demoralized teams and high turnover.

Best Intentions. Most software development staff, given half the chance, will strive to understand a align with the business goals. In cases where they don’t, it is usually traced to a failure of the culture to support employees’ line of sight to the business. We must assume from the start that both software development staff, management, and executives work from a common set of good intentions. It is when we attribute mistakes to bad intentions that software projects spiral out of control in a frenzy of finger-pointing.

Supporting SDLC and Tooling. Agile software development is adaptable to many industry scenarios. Teams need an established software development lifecycle which sets expectations for how Agile is applied and governed. Agile works equally well at any point along the spectrum from loosely to highly regulated industries. Teams also need appropriate tooling to support their use of Agile and these are abundant. Open source shops might use tools from Atlassian or HP while Microsoft shops might use Team Foundation Server. The tools are mostly fungible across target technology stacks, but it is important to use a toolset to enforce SDLC quality gates and to automate manual tasks and tracking.

With assumptions out of the way, let’s drill down on the steps toward the empowerment of software development teams.

Organizing the Teams for Success by Keeping Tensions Healthy

In the three-part series, “Designing an Accountable Software Development Organization,” I discuss the principles of organizing a software development shop for success. The very nature of software development includes the tension between project requirements, the ability to translate those requirements into high-quality working code, and the governance to ensure that it’s done in an orderly and timely fashion. It is impossible to avoid these tensions, but it is possible to design an organization that acknowledges and harnesses the healthy tension while avoiding the tensions from becoming destructive. Put another way, the tension between requirements, technical delivery, and governance are necessary to producing great software. It is entirely up to managers and executives as to whether the tensions will remain healthy or turn toxic. Software developers will flock to healthy shops and flee toxic ones.

Supporting Decision-making by Maintaining Line-of-sight to the Business

All too often, business keeps its software development staff in the dark about key business strategies, goals, successes, and failures. At the same time, we expect our software development staff to make key decisions about software requirements and their implementation to drive business success. To use an old 1950’s B science fiction movie quip, “This does not compute.” In the article, “The Technology Executive and the Software Craftsman,” I discuss treating software development staff less as vendors who simply produce a product and more as partners who share a common desire for favorable business outcomes. The goal is to create a line-of-sight from the business to software development to enable better decision-making at the closest point of impact. This turns software staff from simple doers to thinker/doers who constantly weigh the needs of the business in their decision-making process. This is best summarized by L. David Marquet in Greatness. Creating line of sight and empowering decision-making at the closest point of effect will not merely provide incremental gains in team effectiveness, but will increase effectiveness multi-fold.

Aligning Intentions and Setting Expectations Between Management and Software Development Teams

In addition to the disconnect between business goals and software development, there can also be a disconnect between the senior executive team and software development staff. In the face of this lack of understanding, software developers sometimes fail to understand how and why decisions are made. In the article, “The Technologist’s Guide to the C-Suite,” I discuss the various roles at the executive table as well as what each role is concerned about and listens for. My intention is to foster an understanding on the part of the software development staff so that they will be more effective at synthesizing requirements stemming from and evangelizing solutions to senior executives. The end result is to create better collaboration that ultimately engenders trust.

Identifying Risks, Removing Obstacles, and Continuously Improving

Once we have a well-organized and well-informed software development team, we move onto the nitty-gritty of developing software. As mentioned in the introduction, software development management is transitioning from a traditional “command and control” style of tight control to a “servant leadership” style of team empowerment and removal of obstacles. With a well-functioning Agile software development team, the obstacles to success are frequently external to the software development effort itself that manifest as inefficiencies in the development of software. The obstacles may be related to requirements instability, churn on architectural design, unmanaged tensions between groups, or any number of other issues. In the article, “Better, Faster, Cheaper: Picking Three,” I discuss a model for managing risks to the timely delivery of software in Agile projects. The purpose of the delivery risk model is to identify obstacles to team efficiency as early as possible them work to mitigate those risks. When the delivery risk model is applied judiciously, the end result is higher quality code, more timely delivery, and less time spent fixing defects later, i.e., better, faster, and cheaper. The delivery risk model is an essential part of any servant leader’s toolkit. Without it, risks accumulate and snowball precluding the opportunity to head off problem while they are manageable. Further, the delivery risk model is a gateway to continuous improvement efforts where teams learn from and correct mistakes rather than get punished for making them.

Before concluding, there are some management caveats follows:

Management Traps

Sprint Micromanagement. Agile software development is by definition a highly iterative and self-correcting process. This works when teams are permitted to make mistakes, be honest and transparent with themselves and their management about issues, and work to correct those mistakes. A “command and control” mindset often drives managers and executives to micromanage Agile teams at the sprint level by holding teams strictly to burn down goals and punishing teams when they do not meet those goals. This is a grave mistake since it drives Agile teams to artificially pad estimates, limit transparency, and hide mistakes. Rather, I recommend setting interim delivery goals spaced throughout the project and have executives and managers hold teams accountable for those deliverables. The team should then be allowed to experiment and adjust their own processes within the sprints to improve velocity and quality without fear of punishment. Obviously, the teams need to deliver the agreed-upon functionality for the interim deliverables and may need to push harder to do so. But if the team is permitted to control the progress of sprint, they will usually willingly find a way to meet the interim deliverables.

Agile Dogmatism from Above. Agile methods are a fluid and changing set of guidelines stemming from the original manifesto. Agile software development is designed to adapt to the business and technical challenges at hand. In a strange twist of irony, I have encountered managers and executives who take a dogmatic approach to Agile methods and strive to impose strict doctrine around process and procedure. I recommend starting with a well-defined Agile process then listening to the teams about what’s working and what’s not. Experimentation and adaptation are at the heart of Agile, and the team should be allowed to make adjustments within reason. Depriving the team of this opportunity not only stabs at the heart of the spirit of Agile methods but disempowers Agile teams to influence their own destiny.

Agile Dogmatism from Below. Agile practitioners can sometimes be dogmatic as well. One of the  more persistent narratives I’ve heard says that Agile is not about committing to or hitting deadlines. My response continues to be, “Any software development methodology that cannot deliver on a predictable timeline does no good service to the business.” Another chestnut asserts that Agile is about producing software rather than documentation when, in fact, Agile values working software over documentation but does not preclude the need to produce documentation. As from above, there is a certain irony about dogmatism when applied to Agile by its practitioners.


Developing truly great software has never been easy. Software is among the most complex things produced by humans. Its complexity stems from the vast number of states that a software product can assume. In short, the “soft” is software assumes complexity and flexibility. Getting software right is as much a social engagement as a technical one. There are vast tomes and training materials about getting the technology right but woefully little guidance on addressing its social aspects. In this article, I have endeavored to highlight the social aspects of software development and provide a framework for getting best from the skillful and well-intentioned professionals who develop it. In the end as with any social endeavor, we get better results when people are fully engaged in a trusting, collaborative environment. Great software happens where talented people and great software development culture intersect, and that’s what empowerment is all about.



Mining for Diagnosticians

There are many diverse talents among technologists. Some excel when challenged with creating new applications. Others love to maintain and enhance existing systems. Others thrive when developing system-level tools and utilities. Still others gain validation from designing and implementing exceptional user experiences. One of the most intriguing and compelling skill sets is that of the diagnostician.

Complex and vexing problems arise throughout software development projects. Developers are constantly diagnosing and solving these problems which make the diagnostic skill set part of every developer’s repertoire to varying degrees. Having been exposed to many software projects and many developers, I’ve noticed that diagnostic abilities are a key discriminator between good developers and great developers. Further, I’ve also noticed that the more exceptional diagnosticians often eventually find themselves in leadership roles. I have asked myself what distinguishes the skills of a great diagnostician and what these skills might have to do with career progression. I have come up with some key factors that I believe are implicated in the phenomenon:

Holistic View

The best diagnosticians maintain a broad view of the systems they develop. They may be experts in some parts of the system, but they understand the coupling between components and the flow of information between them. They are able to understand the system at multiple levels from logical design to physical implementation. This holistic view represents a mental map of the system and helps the diagnostician to navigate rapidly through its parts. This ability to create and maintain a big picture view is also commonly found in those who end up leading technology endeavors.

Deep Bag of Tricks

Complex problems frequently require complex solutions. Master diagnosticians maintain a deep and varied set of tools to help them explore problems. I have witnessed developers abandoning their canned tools altogether and resort to lowest common denominators techniques akin to print statements and traps when the most advanced tools give up the ghost. Innate resourcefulness and a willingness to try anything are traits found in many leaders.

Avoids Wild Goose Chases

Getting stuck on a problem is a common occurrence when diagnosing a software problem. The best diagnosticians seem to have an intuition about when they are traveling down a fruitless path. They actively and quickly eliminate fruitless paths and move onto other opportunities. Put another way; they focus on the goal of solving the problem and follow problems wherever they lead. The best leaders intuitively temper dogmatism with pragmatism to find more efficient paths to goals.

Values Accuracy over Guesswork

Making assumptions and testing hypotheses are part and parcel of the diagnostician’s trade. However, great diagnosticians temper guesswork with accurate assessments of their findings. How many times have you seen a developer insist that the source of the problem must be XYZ only to find out later that they were far off the mark? The best diagnosticians spend very little time being attached to their assumptions. They accept the evidence and move on. Leadership also requires testing assumptions based upon data and changing course when the evidence does not fit the assumptions.

Keeps Their Ego at Bay

It’s human to believe that our own efforts are probably not the cause of problems. In software development, it’s all too easy to assume that the problem is caused by someone else’s code. The best diagnosticians often assume that their software could very well be the cause of the problem and will look there first. They park their egos at the door in their search for the answer leaving no stone unturned. Leaders that are best at empowering teams frequently exhibit this same ego-less approach to social interactions. They are not afraid to admit mistakes and change course as a result.

Avoids the Blame Game

It’s all too common too for technical staff to point the finger at each other when difficult problems emerge. Master diagnosticians avoid this game altogether. They know that blame is pointless and harmful to the diagnostic relationship where collaboration is the key to efficiently solving the problem. Great leaders also focus on moving disparate teams toward a goal and know that cohesion is more effective than division.

I’ve made it my business to keep on the lookout for great diagnosticians. Frequently, these are the people who make the best leaders since they understand the overall structure of the system, know how to explore paths to solutions efficiently, value accuracy, and seek to operate with low egos and high collaboration. I see the best diagnosticians as “diamonds in the rough” when considering people for positions of technical leadership. Whatever the business or technology domain might be, I encourage the reader to keep an eye out for the best diagnosticians. I think you will find that the best among them could be your own raw materials for the next wave of leaders within your organization.



Princeton Financial Systems: A Memoir

Having worked with some masterful brand developers and marketers, I’ve come to realize that corporate brands mean something. Businesses spend years building their reputations through their commitment to clients and their commitment to employees. The ideals of a business are imprinted on their brand by the actions of each and every employee. This week the Princeton Financial Systems website closes down as the brand is decommissioned to become part of the larger State Street Global Exchange community. I grew up professionally at Princeton Financial Systems or PFS as we called it, having spent over 19 years working there. I started at PFS as a software developer and team leader and departed a little over three years ago as its CTO. It is fair to say that I could not have developed into a business-focused technology leader if not for my time at PFS. There is not a week that goes by where I don’t apply a lesson learned from my years there. I feel it is fitting to mark the passing of the PFS name by sharing some of those lessons.

Having Fun

I interviewed at PFS in 1993. This was about a year after they received venture capital funding and was a period of high growth. I was part of a major wave of new hires. After two rounds of interviews, I found myself face to face in an interview with Jerry Finsen, one of the two co-founders of the company and the technical brains behind the operation. Jerry did not ask me anything about my background or skills. Rather, he was curious about my opinion of the new hardware and software suite he was assembling for his new sailboat. We had an entertaining and animated discussion about the computing and networking technology of the day and how he intended to use it to outfit his boat. I recalled that we laughed a lot during that interview. While I found the interview odd at the time, I realized later that Jerry was gauging my passion for technology. He knew that I had passed interview muster with the others at PFS, and he wanted to see where I truly stood with my chosen trade. He valued passion as well as skill. PFS was populated by passionate and skillful people!

Not too much later and after I was offered and accepted the job, Jerry and I discussed work at PFS. He noted how much fun he was having and told me, “Why would you want to work at a job that wasn’t fun?” PFS was a fun place. We worked hard to grow the client base as is typical of a company in the “take-off“ stage striving to go public or get acquired. We played hard too. I remember working late nights and weekends while laughing and joking over great meals brought in from “Chicken Holiday” and other local eateries. We had company outings at the Hopewell Valley Country Club as well as golf and softball leagues. While the annual user group conferences were serious business, we always took time out to have fun!

Commitment to Clients

Early during my time at PFS, I had been working with a particularly challenging client. One particular day after having had a difficult phone call, I mention to a colleague about the difficult client. One of the network engineers sitting nearby and without turning from his monitor, quipped, “Remember that those clients pay your paycheck.” I can still hear those words from Rich Fox to this day. He had been one of the early employees and had built the technical computing infrastructure that supported the business. He cared deeply about clients and never forgot (or let anyone else forget) from whence our bread was buttered.

In addition to supporting clients who hosted the software themselves, Rich took the business from its early days hosting the product on our servers in a client service bureau through the Application Service Provider days and later to the SaaS era. Starting with a “server in a closet” model, Rich shepherded the PFS infrastructure to a tier 3 professional data center. In all those years, here never lost his passion and commitment. Rich was typical of PFS employees who always maintained a sharp line of sight to clients and supported the business by expertly serving them. Rich died in February 2010 while shoveling snow. He was my friend and a respected colleague. He was among the best of PFS, and I think of him often!

Enriching Partnerships

As with many new software products, they are built to serve a niche. PFS was no exception when they pioneered the automation of insurance regulatory accounting and reporting. PFS built it, and they came. However, PFS was more than just a product vendor. The hallmark of the company was building deep abiding relationships with clients. Scott Ferrante was the COO at PFS for many years and presided over the building of the core functionality of the product and growing the support organization for the client community.

Scott coined the term “Squeeze a Vendor, Hug a Partner.” He was keenly aware that partnerships were the key to sustaining relationships. The partnership ethic differentiated vendors who just sold wares from partners who were invested in the mutual success of both the clients as well as the company. Scott imbued the organization with that ethos from top to bottom.  PFS customer care was top shelf and reached from sales and product management through to the software development organization to the business and technical help desks. Scott was never afraid to make hard decisions when it came to clients. Those decisions were always tempered through the lens of partnerships and mutual client/company benefit.

A Company with a Heart and Soul

Jim Russo, the long-time company CEO was once asked what his job was at PFS. His answer was simple, “To keep sneakers on the feet of the employee’s children.” Jim was a savvy and hard-nosed businessman. At the same time, he was dedicated to each and every PFS employee. I had the privilege of reporting directly to Jim for over ten years as CTO. Jim was my mentor, and Jim continues to be my friend.

Jim believed in the management principle of “subsidiarity.” Simply put, this meant that he wanted decisions made closest to the point of effect, i.e., at the lowest level of the company where possible since the people at that level were closest to and most knowledgeable about the problems. He knew that employees needed to be armed with the information needed to make good business decisions then supported in making and executing on those decisions. Jim embodied this in abundance. I think much of the success of PFS was directly related to well-informed employees making the right decisions at the right time. I’ve never forgotten Jim’s lessons and continue to do my best to apply them today.

Times weren’t always idyllic at PFS, and we went through some rough patches where we had to make hard decisions regarding staff allocations in a global environment. Jim’s direction was clear: We must maintain the dignity of the individual regardless of the circumstance. Maintaining employee dignity continues to be a valuable lesson in an era of a mobile workforce and reduced corporate loyalties in the face of a global workforce. While some left the company under unhappy circumstances, most left with their dignity intact.

In my opinion, Jim was the heart and soul of the company. He was an ethical leader who was not afraid to make hard choices. However, he never forgot that PFS was made up of committed and well-intended people who deserved respect and compassion. I learned most of what I know about management from Jim, and I am grateful to have worked for such as him!

Thank You and Best Wishes!

Businesses are made up of people focused on a common vision, driven by a common mission, and striving toward a common goal. The people at PFS were smart, passionate, committed, and compassionate. They deeply cared about their customers as well as each other. PFS was about leveraging technology to serve business, respecting and partnering with clients, empowering employees to do their best and treating them with dignity, and having fun while doing it! PFS was a proving ground for talent and a forge that tempered many into better business and technology leaders. There are many notable CEOs, COOs, and CTOs counted among their alumni, and many new businesses arose around them. I am proud and grateful to have been part of the PFS experience.

To my former PFS colleagues, I want to thank you for sharing the PFS journey and enriching my life and career. Without you, I would be less than I am. To those who remain in service of Princeton Financial Systems’ clients and products, I wish you success in the next phase of your journey!



Decommoditizing Your Technology Career

I was the CTO of a software subsidiary of a large investment bank during the stock market crash of 2007-2008. Before that time, the company had been using a small number of outsourced and offshore technical resources to augment the software development staff. The parent company had established an offshore technology center in Hangzhou, China and I had done preliminary reconnaissance for obtaining staff from there. We also used resources from a second tier Indian outsourcing company to support software testing. Up until the market crash, our use of outsourced and offshore resources was targeted and fairly modest. The market crash changed all that.

Market forces changed the focus to cost cutting which included staff reductions at all levels. A mandate from on-high regarding new staff requests followed the reductions. The new staffing request policy required an explicit justification for the hiring of onshore staff. The message was clear: If we wanted to hire new technical staff, getting them via offshore or outsourced means was the path of least resistance. The theory was that offshore/outsourced staff was 30-50% as expensive as similar onshore staff and that costs had to be reduced. Management viewed some technical roles as fungible commodities that could be easily replaced with cheaper staff in lower-cost locales. Debating the wisdom and economics of this argument is beyond the scope of this article. Suffice it to say that I was a good lieutenant and knew how to pick my battles. After five years time, over 70% of the software development shop was split between China and India.

Throughout that period, I had to ascertain which roles needed to be kept in-house and which roles were commodities that could be externally sourced. Employees continually expressed concerned that their jobs might be moved offshore and were looking for career advice on how to avoid being displaced.  The answer was fairly simple. We could not risk offshoring/outsourcing key roles that added unique value to the business, and I frequently advised the staff on this point. Those roles fell into a few buckets as follows:


We had a small group of technologists who did exceedingly well at facing off with customers. They could both evangelize our technical solutions to customers and communicate customer technology needs back to the business. In my experience, this is a rare skill for a technologist and is a key differentiator in supporting the sales organization. Further, the industry had changed over the preceding ten years to a point where the technologists representing the customer had an almost equal say at the negotiating table to those representing that customer’s business needs. Having our technologists facing off with the customer had become critical to the success of the deal.

Solution and Product Architecture

As a financial software company, our products and solutions were the “secret sauce” to ensuring future business success. Offshoring/outsourcing any role supporting the formulation and evangelism of either solution (products + services) or product (technical) architecture represented a risk to the business. People in these roles required a deep understanding of the business domain, knowledge of the capabilities of the company, and the skills to synthesize that knowledge and understanding into value-added solutions and product features. These skills take a long time to cultivate, and we needed to keep these roles close to home if the business was to thrive.

Project Management

Managing complex projects is a skill requiring attention to detail, a focus on the goals, and the ability to collaborate with a diverse set of personalities. Globally distributed resources created by the increased use of offshore/outsourced staff added a new layer of complexity to this job. We prized people who could manage projects in this environment. The best of these folks understood our corporate strategy and goals. They also understood the dynamics of the organization knowing where the pools of expertise existed and how to maneuver inevitable political and cultural obstacles. In short, they knew how to exert organizational influence to align project resources with execution to achieve corporate objectives. It was imperative that these people remained in-house and that we retained them.

In Hindsight

The years surrounding the stock market crash of 2007-2008 were challenging. We made a lot of tough decisions that displaced good people. The times forced us to take a cold, hard look at the many roles that made up a successful software development business and make choices. In the end, the remaining technology staff positioned themselves and the business for success by gaining a new understanding of what constituted value to the business. While the lessons were hard, I think many technologists emerged with a new appreciation of their role within the business and what was needed to achieve superior results while avoiding becoming commodities.



Harmonizing the Voices: Getting Software Usability Right

Getting the chance to redesign a commercial software product is a rare opportunity in the life of a software development leader. I’ve been fortunate enough to have had that opportunity twice in the past decade. The first was a technology and user interface overhaul of an investment management system. The second was a complete redesign of an interactive response technology (IRT) system used to manage the operations, drug supply, and patient engagement for clinical trials. In both cases, these systems are intended to have a lifespan of a decade or more, almost an eternity for software. In the case of the IRT system, it is possible to have longitudinal clinical trials that last for 15-20 years that need continuous support on the same technology platform.

Because the lifespan of these systems is so long, you seldom get to redesign them. It was essential to the business that we got these redesigns right, especially the design of the user experience (UX). If we did not, we’d spend much valuable development capacity tweaking the UX designs rather than spending that capacity on new features that add to the value of the product and generate revenue for the business. Further, just like when you meet someone new, you only have one chance to make a good impression. If your UX is clunky or off-putting, at best you’ll frustrate users, and at worst you’ll diminish your competitive edge.  Moreover, by UX, I do not just mean the look and feel of the user interface (UI), I mean the entire experience of using your software from UI to workflow to help capabilities and the like.

Why it is hard to get UX right

Often when we think of UX design, we think of graphic artists and developers prototyping screens and making things look pretty. While that is part of design, the design process when done right is a social endeavor that brings together product stakeholders with often competing and sometimes contrary views and finding order in the chaos. The goal of the design engagement is to harmonize the many discordant voices by synthesizing their needs and opinions into a coherent design that not only meets their needs but provides a means to develop sustainably on the vision of the design.

Prospective customers often have firm notions of what they need and want from a system, but their view can be clouded by prior bad experiences. Users often have well-reasoned operational expectations of the system, but their view can be biased by how the system works now and sometimes opposed to trying new ways to accomplish the same task. Product managers are experts in understanding market, prospective customer, and user needs and translating those into product features. However, they frequently lack the capability to systematically and constructively solicit feedback on UX concerns and synthesize those into a holistic plan for the UX design. In short, there is an abundance of really great ideas but no good way to manage the social engagement that leads to great designs.

It is important to take a pause here and note two principals that guide my decision-making about UX design. The people who designed the UX for the previous system will inevitably have strong opinions about how the next system should behave. While their opinions need to be aired and considered, my first principle says, “If the same people who designed the last system design the next, the next system will end up looking suspiciously like the last.” This is not an indictment of the previous system designers but points to the need for a new synthesis of prevailing views focused through the lens of the business strategy. Further, there is a temptation to believe that UX design is little more that “twiddling some pixels” on a screen and that developers are suited to handle it. My second principle says, “Never have developers determine your UX design.” This is not an indictment of developers but points to the need for more rigor in UX design.

How to get UX design right

Getting to a great UX design is neither easy nor inexpensive. However, doing so pays dividends in the end. In the two system redesign cases I cite above, I engaged a local UX design firm to help us sort it out. Electronic Ink in Philadelphia, PA knew how to engage stakeholders and bring harmony to discordance. I cannot overemphasize the value companies such as this add. They have the people, process, and technology to engage the cacophony of stakeholders and harmonize their input into a solid path toward thoughtful and sustainable UX design.

Here’s how the engagement worked:

The first part of the engagement was intended to provide stakeholder reconnaissance for the current state of the existing system and begin to discover the required components of the future state. In the case of the IRT engagement, the various system users were defined as personae and were job shadowed and interviewed to assess the good and bad aspects of the current system state. The engagement revealed nine key problem areas. “Frustration scores” comprised of physical effort, cognitive load, task repeats, and error potential were produced for each of the nine areas. The frustration scores largely dictated the priority of each of the nine areas. Here is one such example:


The current state assessment revealed key issues and non-issues with the current design. This helped us understand what was working and what was not so that we could avoid past mistakes.

The engagement then turned to the future state. During this assessment, Electronic Ink designed possible solutions for addressing the problem areas identified in the current state as well as bring their design expertise on best practices to bear. Stakeholders were then engaged in an iterative process of discussing and refining the proposed solutions intended to address the nine problem areas identified in the current state exercise.  For reference, the “Excessive Navigation/Clicking“ issue was labeled as priority “#3”. Here are some examples of the suggested mitigation approaches:


The by the end of the future state engagement, we had over 20 distinct UX solutions specifically designed to address the current state issues while bringing industry best practices to bear on the solution. The engagement also delivered a conceptual framework on which to hang key system features based on stakeholders’ understanding of user workflow.

The second part of the engagement involved the active collaboration of UX designers and developers. The Electronic Ink team used the artifact developed as part of the future state engagement to develop interactive wireframe models. Stakeholders then assessed the wireframe models iteratively. After each iteration, the wireframe models were refined and taken back to the stakeholders for reassessment. At the end of the iterative assessment process, we ended up with wireframe models of key usability patterns assembled into a “pattern library”. These usability patterns were used again and again within the product to produce repeatable and familiar workflows, visual controls, other cues making the product consistent and easy to use. Further, our UX staff was able to take the design patterns and extend them after the engagement ended.

Selling the spend to stakeholders

In the end, we invested heavily in the engagement, and I must admit that selling it to the executive team was no easy matter. The executives were skeptical about investing in a six-figure consulting engagement for something that seemed a rather simple and intuitive task. However, the longevity of the platform dictated the need to get the UX design right, and the competitive advantages that we could gain were compelling. Even then, I built in engagement checkpoints where we could end the engagement and money spent if value was not apparent. The two-part engagement was also valuable since we would take the findings from the first part and implement them ourselves if implementation seemed fairly obvious. In the end, we completed both parts of the engagement.

Internal stakeholders were probably the toughest to sell since they believed that resources within our company could produce a UX design. My prior experience with these engagements was able to convince them that while we had much of the capabilities needed, the ability to engage stakeholders and elicit insights and translate those to UX designs was not among those internal capabilities.

Finally, external customers were probably the toughest to engage. In the case of the investment management system, customers were eager to engage, but much coordination was needed since customers were widely distributed geographically. The IRT system case had a different problem. Pharmaceutical companies are correctly concerned about the security surrounding their intellectual property and seldom allow third parties to shadow their work. We were able to find proxies for end users since our company uses our product on behalf of customers in many cases.


The results obtained were similar in both UX design engagements. Once we completed development and deployed the finished product, feedback from end users was phenomenal. Users not only praised us for “listening to them” and including features that mattered to them but commented how the system almost anticipated their needs before they realized they needed it. The consistent design patterns mitigated user training burdens. In the case of the investment management system, the improved design reduced the total number of distinct user screens from about 1500 in the previous system to about 800 in the redesigned system.

The product development teams not only delivered the new product but now had the tools to sustain the UX design in a systematic and disciplined way since the design patterns removed much of the guesswork for how the product would behave. However, most importantly, the business received a compelling new product to drive business growth for another decade.

Clearly your UX design engagement will be unique to your business. What is not unique is the social aspect of the engagement needed to get to a great design. Few companies are equipped to harmonize and make sense of the cacophony of great ideas found within their organization. If you have the opportunity to revisit the UX for an existing product or innovate on a new product, I strongly recommend seeking out a partner to help guide you. You will be amazed at the results and won’t have a moment’s regret. Oh, and your customers will be forever grateful for the thoughtfully designed and easy to use software products!



Aha Moments: A Love Story

After much soul-searching and reflection, I changed jobs a little over three years ago. I had been at my previous gig for over nineteen years and had almost grown up there in a professional sense. I moved to my new job and found myself surrounded by really bright and eager managers and technologists. Many were at a similar point in their careers now to where I had been those many years ago when I started my last job. They were good at their jobs and eager to grow their careers. I found myself in the role of mentor to some of these folks.

I spent much time thinking about what advice might be useful to help them drive their careers forward. In doing so, I reflected on my experiences with the various people whom I considered my mentors. I realized that my professional development was influenced by a series of mentorship encounters that led to “Aha” moments that shaped my perspective. In 20/20 hindsight, I did not recognize some of those encounters as mentorship at the time since some were uncomfortable while others were chance encounters, but the insights gained at the time were just the same.

Let me share a few of my own Aha moments:

You will not get ahead if people do not want to work with you

I admit that when I came out of college, I was full of myself. I had done pretty well in my undergraduate education, and I thought of myself as a pretty talented software developer. While I was good at my job, I was also cocky and just a bit impatient with others. My manager was very complimentary of my technical skills but at one point had a pointed conversation with me about my ability to collaborate. She pulled me aside one day and said, “I know that you are a good developer, but rumor has it that some people get annoyed when working with you. It seems that you are sometimes impatient to get an answer and sometimes don’t want to listen to other views. I am concerned that people might not want to work with you if this keeps up.” This was an uncomfortable moment for me since I had never had one of “those” conversations at a job. After I had gotten over the initial discomfort, I realized that she was trying to help me succeed. I knew intuitively at the time that I was sometimes impatient in my desire to get results. She identified a blind spot with me that I needed to address. I worked to become a better listener and team player, and her message has stayed with me. Fast forward and I find myself in similar situations with own eager, talented staff. I know how uncomfortable it was for her to have that conversation with me. I realize she acted out of a commitment to me and my career development. I admire her for her willingness to point this out, and she continues to be a role model for my own difficult conversations with staff.

Beauty in technical design elegance

I was five years out of college working as a software engineer. I was in graduate school evenings working toward a Masters in Computer Science. One of my first classes was Data Structures and Algorithms, which I greatly enjoyed when I took it at the undergraduate level. I loved the elegance of solutions afforded by the practical use of data structures and their accompanying algorithms, but the “nerd” in me was too embarrassed to say it out loud. I had a professor for the class who was passionate about this topic. He would get enraptured when explaining the intricacies of subjects like digraphs and height balanced AVL trees. I could tell that this guy loved this topic, and his enthusiasm was infectious. I mentioned after class that I enjoyed his lecture and commented about his passion for this. He and I had a long talk about the aesthetics of data structures and the elegance of the solutions they spawn. My professor exemplified what I had been afraid to show. I ended up asking him to be my graduate advisor and was fortunate enough to have him as my teacher for numerous classes. Since that experience, I have never been bashful about commenting on the beauty and elegance of technical solutions. In fact, I have found make kindred spirits among those who identify themselves as software craftsman.

Coming to grips with self-imposed limitations

I have stuttered since I was about four years old. The only times it got in the way was when I had to do public speaking in school. I became a master of wiggling out of these requirements sometimes playing the sympathy card. I did learn to “hyper-prepare” when I had to present so, at least, my grasp of the materials was not adding to my source of dread and learning to prepare in this manner certainly helped my grades. In one of my early jobs, I worked with some very senior software developers who at the time appeared to me as “grizzled veterans” of the early days of software. One of these guys “adopted” me for some reason that I could not fathom at the time. One day while we were chewing the fat, he said to me, “Charlie, I know that you struggle with your stuttering. But sooner or later, you’re going to have to come to grips with it if you want to advance in your career. Managers expect you to present to teams, and you seem to avoid it.” No one had ever had such a pointed and frank conversation with me about my stuttering. In fact, most people politely ignored it “like the plague” tacitly indicating that it made them as uncomfortable as it made me! I knew that he was right, and his words stayed with me for years until one day at another job they needed someone to go out on sales visits to explain technical interfaces to clients. I heard about the opportunity and remembered my former mentor’s comments. I raised my hand and volunteered for the role. I was scared to death, but the opportunity got me over my fear of public speaking and helped pave the way for advancing my career.

Lessons learned

In each anecdote above, I learned something about myself that helped shaped my career direction. I realize that these conversations were sometimes as hard for my “mentor” to deliver as they were for me to hear. However, I realize that mentorship is as much an act of love (maybe tough love) as it is a chance to share wisdom and learn from it.

For those on the mentoring side of such a conversation, don’t be bashful about being frank and honest. People are often blind to their weaknesses or even embarrassed about expressing passion for their craft. Mentoring is at the same time about acknowledgment and exploration. You may be that “grizzled veteran” or seasoned manager that is looked backed upon fondly for providing an uncomfortable insight that helped a bright, eager rising star to shine.

For those seeking mentorship, don’t limit your exploration to just kind words and gentle encouragement. Seek out those who are willing to risk the relationship and be candid with you. Often others see our blind spots and weaknesses much more clearly that we do. It is out of concern for your well-being and career advancement that true mentorship happens. Realize that it is often as hard for mentors to deliver tough news as it is for you to hear it! Look for these encounters and take them for the acts of love that they are!



Considering Your Technology Career. Part 4 of 4: The Mature Company

In Part 1 of “Considering Your Technology Career,” I described a model for assessing satisfaction with your current employment situation, and I urged the reader to consider what is truly satisfying in their career. Remember that the four dimensions that I chose (Interest, Compensation, Bureaucracy, Prospects) were of special meaning to me. There may be other dimensions that you wish to consider that have special meaning to you. In this article, I will describe the mature company and provide some anecdotes based upon my experience. I will then apply the satisfaction model to the mature company. Along the way, I will discuss some more subjective elements of a mature company that you may want to factor in when considering if joining a mature company is right for you.

Let’s go.

matureIf you’ve read parts 2 and 3 of this series, you have probably noticed that there are different business forces at work driving the company. In a start-up, those forces are driving innovation to develop a compelling product. In a take-off, the business forces are driving sales to build the book of business to increase the value of the company in advance of either selling the company or taking the company public. The business forces driving a mature company are more complex and are in relation to the type of company. Keeping matters simple, there are two types of mature companies, publically held and privately held. Publically held companies distribute stock and are owned by shareholders. Privately held companies owned by private entities including individuals, foundations, or trusts. They have much in common. Both are driven by competitive market forces to grow revenue and margins. Both can have similar management structures governed by a board of directors and run by executive management.

They also are different in key ways. Industry analysts typically judge the performance of public companies against stated company goals and competitor performance.  Their judgments frequently drive investor behavior that in turn drives the stock price of the company. Frequently, the board or directors and executive management strive to manage the company to analyst expectations that can be a mixed blessing. In an up economy, public companies will heavily invest in innovation to grow top line revenue. In a down economy, the same companies will frequently cut expenses to maintain margins. Cost cutting can mean shedding employees or finding cheaper sources of labor as was the aim of outsourcing boom of the last decade. Often, executive management will see-saw between revenue generation and margin optimization over the course of years all to manage analyst expectations. Responding to these expectations frequently drives changes in executive management and even in the corporate structure should the company consistently fail to meet expectations. In short, public companies are driven to excel through shareholder and analyst pressures that manifest themselves in response to quarterly earnings reports and annual statements. When public companies are at their best, the use their resources to drive change and innovation according to a strategic plan. When they are at their worst, those same pressures drive tactical and severe cost cutting measures that are often painful to employees.

Private companies are a different animal. Because they are not subject to the scrutiny of shareholders and industry analysts, they frequently take a longer view rather than managing quarter to quarter. Because private companies can be more strategic than public companies, they can choose to invest for the long run. On the other hand, those same shareholder and industry analyst forces that can drive a public company to excel do not exist for a private company. The lack of this source of pressure can sometimes lead the owners to hesitate to implement change in the face of competitive pressure.

So let’s apply the satisfaction model to the mature company.


In both start-up and take-off companies, the interest level for me is based on technology and engagement. By engagement, I mean the extent to which the company empowers the employee to make decisions driving the future of the company. Being hired for one’s expertise then being tapped for that expertise is one of the key sources of motivation, at least for me. This engagement is almost a given in start-up and take-off companies since the company finds good employees and set them loose on a problem. Mature companies can sometimes operate differently. At times, a mature company can employ top-down management that can strangle employee initiative. I try to avoid these circumstances whenever possible. My counsel when looking for a mature company is to find one that actively engages employees in finding solutions from the bottom-up. It is not too hard to figure out how a company thinks about employee engagement during the interview process, and I encourage you to do so.

Additionally, mature companies may realize that the very size and scope of their company can stifle innovation. In the face of this realization, experienced executives may compartmentalize innovation with the company in an attempt to isolate it from pressures that may seek to stifle change. You might see this if you ask how the company is organized. Working within one of these islands of innovation can raise interest level.

My “Interest” rating above reflects the variability in employee engagement and willingness to innovate. The very nature of a mature company can limit innovation through risk aversion and market forces driving expense control. However, more progressive companies realize that innovation does not happen by accident and will strive to remove roadblocks to engagement and innovation. Mature companies can provide and interesting and engaging experience but you may have to dig to find it.


In many ways, mature companies offer many more low-risk compensation opportunities than either start-ups or take-offs. Public companies often have total compensation plans that include equity components. Private companies may also have incentive compensation programs that are almost exclusively cash-based. Benefits packages can be more robust in larger companies.

It is important to note that since mature companies have made it through their start-up and take-off phases, they are usually more stable. As I said above, public companies may tactically control expenses that can affect employment stability and compensation growth. My experience with private companies tells me that they are less prone to employment stabilities issues, but they are far from immune.

On the other hand, because mature companies tend to be lower risk ventures than their earlier stage counterparts, the opportunity for dramatic compensation growth is often less with a mature company. Mature companies allow employees to trade off risk for reward. If you are at a stage in your career where you prize employment stability, then a mature company might be for you. Understand that your compensation growth may be lower than you would like, but that can very well be the cost of stability.

My “Compensation” rating above reflects the variability of working for a mature company. On one hand, you may experience slow compensation growth in exchange for stability. On the other, incentive compensation and benefits packages may be more robust which can yield an overall higher total compensation profile.


As I mention in my previous articles, bureaucracy tends to be low in start-up and take-off companies. Take-off companies are more likely to have more established bureaucracies to keep staff focused on their tasks rather than having to attend tasks in areas like HR and IT. Mature companies usually have well-established bureaucracies focused on attending to operational details that enable the company run efficiently. When working for mature companies with established bureaucracies, I live by the following rule, “There are four gods that you must appease: Audit, Legal, Finance, and IT. Don’t picks fights with them because you’ll probably lose.” There are two aspects to this sentiment. On the positive side, the bureaucracy helps the company run efficiently and protects it from risk by enforcing a certain amount of orthodoxy. This is a good thing when the bureaucracy supports the business in constructive ways like standardizing technology configuration, rollout, and support. Bureaucracies can get in the way when they impose onerous processes that can impede progress and hinder innovation. When large companies fail to innovate it is often because the business ends up serving the needs of an entrenched and inflexible bureaucracy rather than the bureaucracy enabling business progress as originally intended. The battle between Apple and Sony to capture the MP3 and music sales market, in my opinion, is instructive in this regard. Apple was able to beat Sony with the iPod because Sony was unable to get out of its own way despite having a technology lead. On the other hand, IBM was able to gauge correctly the innovation-stifling effects of its bureaucracy and create an independent business unit within IBM that created the original IBM PC.

My “Bureaucracy” rating reflects the simple fact that mature companies usually have established bureaucracies designed to impose orthodoxy. It is important that you understand the role of the bureaucracy to be able to navigate it effectively.


Your prospects within a mature company can vary considerably. On the upside, mature companies can offer greater stability and job security than start-ups or take-offs. Frequently, if you are not happy in one job within the company, you can post for another. In fact, this is one of the greatest strengths of the better mature companies that actively encourage this. Multi-national companies frequently offer “secondment” or “expat” packages to qualified employees willing to relocate to new offices abroad to help get started in new markets. It is almost like working for a start-up company without the risk of job loss. These can be great opportunities to grow your career and see parts of the world you might not otherwise see. Also, if you like the job you do and aren’t interesting in branching out, then a mature company is often happy to have “sustaining” employees providing reliable support to the business.

On the downside, mature companies can appear intimidating in their processes and sheer size. Sometimes employees can end up feeling “stuck” and jobs they do not like. I am dismayed when employees get lost in mature companies and actively advise them to seek mentorship to help steer a path forward in what can sometimes feel like a daunting environment.

My “Prospects” rating reflects the variability in the opportunities offered by mature companies. At their best, mature companies can provide stable but interesting work environments where an employee can see their career mature without the risks inherent in start-up or take-off companies. At their worst, mature companies can feel like intimidating mazes that are challenging to navigate.

Final Comments

I sincerely hope you have found this four-part series enlightening and helpful. My intention has been two-fold: To help you gauge your satisfaction with your current job in the hopes that you can find ways to improve areas of dissatisfaction. Alternatively, you might find that another situation in another type of company may be more to your liking. In either case, going into a situation armed with insights and with your eyes wide open can help improve your satisfaction, avoid dissatisfaction, and help you chart a plan for career advancement and happiness. I once worked for a company in the take-off phase where the founder told me, “If your job is not fun then why bother doing it.”  These are sage words that have stayed with me for over 20 years!



Considering Your Technology Career. Part 3 of 4: The Take-off Company

In Part 1 of “Considering Your Technology Career,” I described a model for assessing satisfaction with your current employment situation, and I urged the reader to consider what is truly satisfying in their career. Remember that the four dimensions that I chose (Interest, Compensation, Bureaucracy, Prospects) were of special meaning to me. There may be other dimensions that you wish consider that have special meaning to you. In this article, I will describe a prototypical take-off company and provide some anecdotes based upon my experience. I will then apply the satisfaction model to the take-off company. Along the way, I will discuss some more subjective elements of a take-off that you may want to factor in when considering if joining a take-off company is right for you.

Let’s go.


The take-off stage is probably the most interesting and potentially rewarding growth phase of a company. Having usually begun life as a start-up company, the take-off survives the perilous early days and has built a great product suite with a demonstrated clientele and sales pipeline. A start-up becomes a take-off usually because the founders have reached the limits of their ability to grow the company further given the financial, manpower, and technical resources at their disposal and are looking to take the company to the next level. Most commonly, that next level positions the company to go public by creating an initial public offering (IPO) or to be purchased by a larger company. In either case, the founders are seeking a dramatic leap in company growth and financial returns on their sweat equity.

So how does the prototypical take-off company take off? It’s simple; they seek investors to infuse cash and know-how to enable growth. Investors come in two main forms: Venture Capital firms and Private Equity firms. The aims of each type of investor is the same, to inject capital into a fledgling company and help it grow to a point where the investors can cash out and get a tidy return. The details of the distinction between the two investor types are beyond the scope of this article but here is an article that describes the differences between venture capital and private equity firms.

Remembering that the end game of the take-off company is to go public or get acquired, it’s important to understand how investors measure the value of the company and know that it’s grown to the point of sale or IPO. That valuation fairly simple in concept too. The purchase value of take-off company is usually measured in multiples of the annual sales revenue or multiples of the sales pipeline. So the goal of the take-off company is to grow sales and gain clients usually to the exclusion of all else and in any way possible as quickly as possible.

Why is it important for you to understand the goals of the take-off company? For two reasons. First, if and when the take-off company gets acquired or goes public, the real value of the firm lies in the equity of the company, i.e., the stock. Being granted equity in the form of stock as terms of your employment is critical if you want to get a better return for your efforts. Future compensation is the main reason that many technologists join take-off companies. In my case, I joined a take-off company shortly after they received a round of venture capital funding and they were hiring to position themselves for growth. I received a modest amount of equity. Three years later, the company was acquired, and the stock became valuable after an additional three-year vesting period. The vesting period took place during the height of the “.COM” boom and we were fortunate enough to see the stock price of acquiring company double in those three years. I got lucky by being in the right place at the right time. By the way, three years between venture capital and private equity investment and selling the company or going public is a typical expectation placed upon the take-off company by the investors.

Second, the take-off company may have to do things that are ordinarily unsavory to a technologist to make sales and grow revenue. For example, the take-off firm I joined decided that it needed to win a large key deal quickly. There were features the prospective customer needed in the product, and they couldn’t wait for the features to be delivered as part of the next major software release. Executive management made a decision to create a separate software version to expedite the development of the needed features without having to wait for the next release of the core product. The chief product architects knew that having two versions of the code would create a maintenance headache down the road and lobbied to overturn the decision. In the end, the decision was upheld, the version was created, the features were added, the deal was won, and it created the expected maintenance headache downstream. Since the goal was to generate revenue to increase the value of the company to lead to an acquisition or IPO, branching the code was the right business decision in spite of adding risk later when the code would have to be merged back into the core.

One cautionary note worth mentioning is about “IP Trolls” also known as “Patent Trolls.” IP Trolls are companies that acquire technology companies for the intellectual property usually in the form of patents. IP Trolls care only about the IP and will quickly shed the employees of the companies they acquire. If you find yourself working for a take-off company that is acquired by an IP Troll, get your resume and social media profiles updated because you will probably find yourself without a job shortly after the acquisition takes place. A quick search on Glassdoor can help you identify if the acquiring company is an IP Troll.

So let’s apply the satisfaction model to the prototypical take-off company.


As I said above, many technologists join take-off companies due to the promise of making money from equity. It’s worthwhile to remember that most take-offs were recently start-ups, so the founders are still around, the products are relatively new, and the excitement level is usually high. In many cases, the investor cash places the product on the fast track for both feature and technical innovation. My experience with take-offs is that they are often fun and interesting places to work. The race to acquisition or IPO makes them fast-paced, so be ready to trade off some of your personal life for the prospect of a return on your efforts. Since take-offs are more likely to be better staffed than start-ups, you’re more likely to become part of a great technical team. I met many talented technologists from my days in a take-off firm, many of whom remain in my network of revered colleagues.

My “Interest” rating above reflects the technical, feature, and team opportunities understanding that there will be variability. The founders are still around, they’ve hired new talent (maybe even you), and the product and ideas remain fresh. I will offer a word of caution. As I said above, at times take-off companies will make business decisions to drive growth that will result in unsavory technical choices. If you’re lucky enough to stay through an acquisition or IPO, you may find yourself cleaning up after the take-off decisions. In the example above, I lived through the acquisition and was part of the team that had to figure out how to merge the various code branches back into the core. It was not a fun time but was necessary. Go into take-off companies with your eyes wide open and don’t be discouraged if the chickens come home to roost after the company is acquired or goes public!


In my opinion, compensation is the primary allure of take-offs. If you remember my discussion of total compensation in the first article, take-offs add the possibility of credible equity returns in addition to a base salary. Sometimes the salaries can be on the lower end but the take-off company is all about increasing the value of the company to sell the company or to take it public. It important that you join in the equity stake as terms of your employment. As before, the discussion of negotiating your equity stake is beyond the scope of the article. However, take-offs and startups share similar models for granting equity, so a link to an article on the topic might be helpful.

My “Compensation” rating above reflects the possibility of good returns on your effort. After all, a Venture Capital or Private Equity firm have invested in the company, and they are motivated to see the company succeed so they will get a return on their investment. They’ve done your homework for you, so you get to join them on the journey to possible returns. There are never any sure things, but the take-off company is further along the way to success.


Remember that take-off companies were probably start-ups in their recent past so they will focus on efficiently removing roadblocks to success. Further, they are highly motivated by their investors to grow the business. You can expect a relatively low amount of political intrigue and bureaucracy since the employees have a unified mission. However, since the company is growing, they will insist on more organizational orthodoxy in key area so that employees stay focused on their primary mission without being distracted by other tasks. In short, human resources, IT, governance, and other “institutions”  form, so others don’t have to split their time performing those jobs. Plus, the company will need to mitigate the risks inherent in company growth by institutionalizing core services like human resources and IT. In short, you can expect to wear fewer hats in a take-off than you might normally wear in a start-up and there will be somewhat more bureaucracy to deal with in exchange.

My “Bureaucracy” rating reflects this increase in formal process and governance in exchange for your ability to keep your head down doing what is need to support business growth.


Just as with working for a start-up the experience working for a take-off can boost your career by exposing you to aspects of a business that you might not otherwise see with a lower downside risk of the company failing out from under you. While you might not get to wear as many hats and your exposure to new parts of the business might be less than those available with a start-up, the possibility of better compensation and a better team experience could very well outweigh the exposure opportunities. I found that working for a take-off provided me with learning experiences from exposure to talented people. Whereas the start-up had me doing things I might not otherwise do, working for a take-off helped propel my career forward due the learning experiences I gained working with people in disciplines different from my world of software development. It was there that I gained knowledge and experience with infrastructure and sales disciplines. Both were key to my future as a CTO.

My “Prospects” rating reflects the both the opportunities to grow in your career as well as the opportunity to gain compensation for your efforts.

What’s Next?

If a take-off company meets it growth potential and get acquired or goes public, it usual enters the “Maturity” phase where stable and predictable growth is usually the goal. In part 4 of “Considering Your Technology Career”, we will examine the “Mature” company and use the model for assessing satisfaction to explore possible sources of satisfaction and dissatisfaction.

Stay tuned!