Feeds:
Posts
Comments

Archive for the ‘Leadership’ Category

Winners, Losers and Those Still Playing: Finite and Infinite Games

Posted in Books, Future, history, Leadership, tagged , , , , , , , on 07 Oct 2019| Leave a Comment »

There are books that inspire. There are also people who inspire. This review is about a book that inspired a person who inspires. It also inspired that person to write a book to inspire people.

I’ve been following Simon Sinek for a bit now. For the past few years he’s been speaking about a way of looking at things that differs from the common view. He’s also written a book (releasing in October 2019) about it titled, “The Infinite Game.” This review isn’t about Simon, his videos, or upcoming book. It’s about the book that inspired him.

That book, by James Carse, is Finite and Infinite Games.

Unlike many of my recent reads, this one was a bit on the compact side, coming in at under 150 pages. The interesting thing to me approaching the book was how such a short volume had inspired Sinek to take its concept on the road.

In typical university professor process, Carse opens by describing the endpoints of a spectrum, games of a finite and infinite nature. He asserts these to be just that, endpoints. We are left to conclude that there are other games within the spectrum, but none are explored. Although this would have allowed for a larger volume, there really isn’t much point. If you’re the kind of person who buys this book and doesn’t appreciate that it’s been written by a philosophical / political / historical viewpoint, the additional material wouldn’t have enabled you to get any more out of it. On the other hand, if you do, you’ll have little difficultly extrapolating the spectrum and its related historical and political examples.

Once the groundwork is laid, the author spends a chapter exploring a seemingly obvious point. “No one can play a game alone.” This appeals to our sense of self. We exist in relationship to the not-self. We cluster our selves into communities in relationship to other communities and nation-states likewise.

From here, the book explores our traditional view of games. Winners and losers. We see how this binary / hierarchical viewpoint demands the existence of a time-bound context (world). For Whovians this represents a fixed point in time. Examples would be the 1962 United States World Series (baseball) champion or the victors of a battle. The interesting element of which is that of any fixed point in time, it never changes. It is never different. It also never improves. Implicit in this view is the requirement of losers as well as accepted, well-defined rules.

In the broader world we see analogs to zero sum games. We see companies constantly defining themselves in terms of being the number one firm in something contextualized by a specific time period. These tend toward ever increasingly pointless hair splitting. The question becomes, “to what end?”

An interesting point, which I’d not previously considered, was that finite games require an audience. That is witnesses. These serve to validate the victor and their victory. They also are responsible for carrying the memory of the event, anchoring it in time.

It is only now, two thirds of the way into the book, that the other end of the spectrum is examined. To do so, the author has us look to nature (well actually anything not contrived by human beings).

As one might have come to conclude, the world (and by extension universe) got along just fine without us and will probably to do again. Carse points out that in and of itself, the world has no narrative structure, it simply is. In the same way an infinite games is the complete opposite of a finite game. It has no fixed rules, no audience, no winners, no losers and is not time bounded.

So what is the point of an infinite game?

To keep playing.

Players come and go. Objectives change. But, at the end of the day, playing is its own motivation. In this view of the world, there are no enemies to be defeated, there are rivals to out do. Without rivals (other players) you aren’t playing a game. There is no attempt to reach a pinnacle, but rather to be pushed to exceed ones own success.

In a finite game you declare victory. Once at the top of the heap, it’s all down hill. Finite games are by their very nature self-limiting. There is no incentive to excel once you’ve attained supremacy. We have seen time-and-again companies creating new and innovative technologies only to hold them back because they were already number one. These same companies lost that position to others not held back by past glories.

I have seem many times how in the software world, companies have milked the “completed” product cow while at the same time refusing to invest in keeping that same cow current in terms of technology. It is only after decades of neglect that they realize that they can no longer add features and that a generation or two of graduates have passed by since anyone was taught how to work with the technologies used in said cash cow. And then the cow dies.

T.S. Elliot said, “Immature poets imitate; mature poets steal; …” Pablo Picasso said, “When there’s anything to steal, I steal” Steve Jobs spoke likewise. These are views of those constantly improving their craft. Learning from and incorporating the best we see in others vs. simply attempting to exploit the weaknesses we see is a hallmark of the infinite game player. The other players of their infinite games are not opponents but rather rivals. Opponents seek our defeat. Rivals seek our respect. Opponents want their fixed point in time. Rivals desire that every day we push them to be their best.

Not long ago, someone said to me, “unicorns want to be around other unicorns.” According to Guy Kawasaki, Steve Jobs said, “A players hire A players; B players hire C players; and C players hire D players. It doesn’t take long to get to Z players. This trickle-down effect causes bozo explosions in companies.” I prefer Eric Dietrich’s thought, “A Players Don’t Hire A Players — They Partner with A Players.”  We can look to the rise and fall of stack ranking in the technology world to see the negative impact of the finite game in a world where the goal is to create the future.

Upon finishing the book I was left with a sense of affirmation and sadness. I recommend this book to anyone who intends to undertake any endeavor over the long term.

 

 

Read Full Post »

Suite Job: What’s a CTO

Posted in Computers, Leadership, Software Development, tagged , , , , , , , on 04 Aug 2018| Leave a Comment »

As someone in the technology sector, on a fairly constant basis I get asked the grown-up equivalent of “what do you want to be when you grow up.” This is, of course, “where do you see yourself in N years.”

Now, most of the time, this is a question with all the gravity of “nice day, isn’t it?” Sometime, however, the inquiry is sincere. And my answer is provided with the same weight as the question.

And, for reference, my answer hasn’t changed all that much since I was about seven. Happily, the way that I answer has become a bit more sophisticated. My end game position is that of CTO (Chief Technology Officer).

Many of my contemporaries have gone the route of management. This is cool with me. You shouldn’t be doing engineering and science if you don’t have it in you. By in you, I intend the sense given by The Oracle in The Matrix when she told Neo that you know that you’re the one when you feel it “balls to bones.” Seriously. There are far easier ways to make a decent living than the constant demands and uncertainty that comes along with the endeavor of technological advancement. Hell, forget advancement, just using technology is a hard slog.

For me, working with technology and constantly expanding the reach of my understanding within that sphere is one of my core drives.

So like anything else I’ve ever set as a goal, I researched this thing I’ve set my sights on.

Let’s unwrap what I understand today.

It’s relative new

As C-suite positions go, the CTO is really young. Only the CISO (Chief Information Security Officer) position is newer. As you’d imagine it’s not like there weren’t technology companies before CTO roamed the Earth. Prior to recognizing that the technology landscape was changing so quickly and on such a continual basis that a board-level position focusing exclusively on the implications of such change, technology was the domain of either the CIO (Chief Information Officer) or CEO (Chief Executive Officer).

There was a realization that technology falls into two broad categories: present and future. You can think of these as tactical (product development) and strategic (futures research). Investopedia says that a CTO “examines the short and long term needs of an organization, and utilizes capital to make investments designed to help the organization reach its objectives … [the CTO] is the highest technology executive position within a company and leads the technology or engineering department.”

This division of labor is not unlike the was that Computer Science became an independent discipline. It too is dual-rooted. There were schools where the computer (singular) was managed by the Math department and those managed by the Electrical Engineering department. You can tell the difference in the focus in curriculum. It will be either theoretical (math) or applied (engineering) in nature.

It’s not only one

The position of CTO is in no way one-size-fits-all. Presently, it’s possible to identify four distinct sub-species of CTO. This diversity reflects the nature of the companies and how technology fits into their culture and mission.

We can identify these four by where the fall on the spectrum described by amount of business change and percentage of products and services based on information.

 

CTO quadrants

As can be seen, these are four very different animals. This is why you would expect the CTO from a relatively stable business in the manufacturing sector like GE (big thinker) to be very different from one at a business experiencing near constant change and highly-dependent on information in its products like Facebook (visionary). Neither of those would look anything like the stable business, high-dependency Apple (external-facing) or high change, low-dependency AT&T (information manager).

The Infrastructure Manager

CTO quadrant - infrastructure manager

 

Typically seen in companies with low dependency on information-related technologies, but with business models experiencing large amount of change (technology change impacting how the business is run), the Infrastructure Manager CTO reports to the CIO and is responsible for addressing how to build out and leverage technology to reduce cost and encourage technology adoption across business units in order to gain efficiencies.

The Big Thinker

 

CTO quadrants - big thinker

The Big Thinker CTO is the response to never-ending growth of things utilizing information technology. We see this type in companies with stable business models and a relatively low dependence on information as a part of their products. We see their focus on strategic initiatives such as:

  • Advanced technology
  • Competitive analysis
  • Technology assessment
  • Prototyping
  • Planning
  • Setting architectural standards
  • These CTO answer to the CEO and peer the CIO. Here we have a division of the IT and engineering departments. They act as change agents, typically having a relatively small elite staff. They are influencers rather than controllers.

The Visionary and Operations Manager

 

CTO quadrant - visionary

In companies in the throws of business change (increased technology complexity) and highly dependent upon information in their products and services, the CTO will be the Visionary and Operations Manager type. Answering to the CEO, this is the prime mover of the company. Their responsibilities are all encompassing. They drive business strategies and exploit new technologies and then implement those same technologies throughout the business and product groups. We see the CIO reporting to the CTO in this view of the world.

The External-facing Technologist

 

CTO quadrant - external technologist

Information-driven companies with stable business models will tend to have the External-facing Technologist CTO. As with the Big Thinker type, this CTO peers the CIO with both answering to the CEO. Here the focus in on the identifying new technologies, exploiting them, and evangelizing them both in and outside the organization.

Areas of Impact

If we visualize the areas of impact for the four type, we can see the natural focus areas for each.

infrastructure managerbig thinkervisionaryexternal technologist

Observations

Greg Brockman, Stripe’s CTO, said that other CTO’s “viewed themselves as the facilitators of the technology organization. Sometimes this was about connecting senior engineers. Sometimes it was mentoring. … I realized the most important thing to do was to empower our engineers to make big changes and improvements.”

“It’s not a simple job to understand all the technology out there,” says Unisys Corp’s global CTO Fred Dillman. “Today the pace of change is so much faster, and businesses are becoming more and more dependent on technology. So the CTO is being asked to be the real expert in technology and understanding what technologies will affect the business in the future and help determine when and where to invest.”

My fit

So, where do I see myself in all this? Tricky question.

Honestly, it varies. As the Version Control Systems Architect at Metrowerks, I was evangelizing source code control. At The Altamira Group, I rocked the visionary thing. Most of my CTO-esque activities have fallen into the Big Thinker bucket. Researching futures and educating engineers and management is where I spend the bulk of my time.

Roger Smith noted that “[t]he significant role of technology in strategic business decisions has created the need for executives who understand technology and recognize profitable applications to products, services and processes. many companies have addressed this need through the appointment of a chief technology officer (CTO) whose responsibilities include:

  • monitoring new technologies and assessing their potential to become new products and services
  • overseeing the selection of research projects to ensure that they have the potential to add value to the company
  • providing reliable technical assessments of potential mergers and acquisitions
  • explaining company products and future plans to the trade media
  • participating in government, academic and industry groups where there are opportunities to promote the company’s reputation and to capture valuable data

Integrating these technology-based activities into the corporate strategy requires that the CTO nurture effective relationships with key people throughout the company. These include the CEO, members of the executive committee, chief scientists, research laboratory directors, and marketing leaders.”

Regardless of the specific needs of the organization, I’ll continue to strive to provide the best information in a timely fashion to those who need it.

References

 

 

Read Full Post »

Tales of Future Past: On Grand Strategy

Posted in Books, history, Leadership, Uncategorized, tagged , , , , on 06 Jul 2018| Leave a Comment »

I always find myself impressed at how nation-states and their leaders exhibit repeating patterns of behavior. This is expertly explored through space, time and scale in John Lewis Gaddis‘ latest book On Grand Strategy.

Dovetailing beautifully into my previous post’s assertion that I am an experiential gestaltist, Gaddis’ work takes us from Persia to Greece, China, Spain, England, France, Russia and the Americas. The book deconstructs battles and their attendant strategies, the motivations of their commanders, and the moods of the peoples involved.

From the outset, Gaddis presents us with the metaphor he will return to time and again. That of the fox and the hedgehog. These represent the approaches of alert outward-directed probing with stealth and of unwavering belief and inward-directed defense of that belief.

He shows that time and again battles are lost because leaders lack the ability to see changes in the situation before them. This may manifest in populations simply abandoning territory as was the case in both Xerces‘ attack of Athens and Napoleon‘s of Moscow. Forcing your attacker to extend their supply lines should give pause to any commander, and yet, time after time we see overconfidence leading to defeat.

We see how Elizabeth skillfully balances force and guile to turn a seemingly weak position with respect to the attacking forces of Spain’s (God will make it work out) Philip. Like Xerces, Philip believes that his forces cannot fail. Less so because of their intrinsic numerical advantage and more because of his steadfast belief in his divine mission. His confidence extended to failing to provide adequate direction to his various forces and ignoring losses due to bad weather. Elizabeth, on the other hand patiently and judiciously used her limited resources.

The British colonies in North America are examined and we see the interplay between the colonials and the empire. As the United States are forming, the choice to kick the can of addressing slavery down the proverbial road of history is in full display as they draft their Declaration of Independence and Constitution. We jump to the American Civil War where leaders are struggling with the consequences of being at once a nation based on democratic ideals and yet built on slavery. They were very well aware that the monarchies of Europe still looked on them as an untenable aberration. A hypocritical one at that.

And we see into the churn that formed the backdrops of both World Wars. Also, how England worked to engage the United States and how others tried to prevent its engagement.

Throughout it all, we are presented profiles of leaders who are either able or unable to navigate the ambiguities of the realities before them. There are those without a compass, unable to achieve goals because there are none. There are those whose compass is trusted to the exclusion of the terrain. They find themselves, like those today blinding following navigation apps, ending up going off cliffs and ending up in lakes. Knowing where you are going is important, but if you fail to allow for the terrain and weather conditions, you will not do well.

On the whole, the book provides us a valuable mirror. It is amazingly timely given that we are in a period where our leaders seem again poised to engage in actions demonstrating that they have failed to either study of learn from the teaching of Sun Tzu, Thucydides, Augustine and Machiavelli. Their message could be described as success is found in following the middle way, embracing both certainty of mission, preparation and proper respect for the fluid nature of engagement.

Read Full Post »

Cutting to the Quick: The Software Craftsman

Posted in Books, Computers, Education, Leadership, Software Development, tagged , , , , , on 20 May 2018| Leave a Comment »

Sometimes you can spend years trying to find a book that you can recommend to someone who’s asked you a question. My latest read, The Software Craftsman: Professionalism, Pragmatism, Pride is one such book. A recent volume in the Robert C. Martin book series, this volume by Sandro Mancuso is not what it appears to be. And that, is a good thing.

When you look at the other books in the Martin series (Working Effectively with Legacy Code, Agile Estimating and Planning, Clean Code, The Clean Coder, Clean Architecture, …) you see topics decomposed and methodologies expressed by which the title’s subject is achieved. That’s not what you get with The Software Craftsman. In my case, that was a very fortunate turn of events.

This is not to say that the journey of the software craftsman is not discussed. It is and in a reasonable amount of detail. But an equal amount of time is given to the ecosystem within which the craftsman practices. These parts of the book are not for the consumption of the craftsman or aspirant, but for the owners of the firms who employ (or should employ) them.

The book does well in describing the trials and tribulations of a member of the craft; from the point where they realized that they aspired to more than the dichotomy of coder / architect; to the creation of the volume itself. It lays bare this false dichotomy within the broader context of the entire point of software development. That being to produce value to the customer and income to the creator. Within that context, there is the easy path of whatever works and the hard path of building a thing that no only does what it is supposed to, but does it in a way which is both high quality and highly maintainable.

At it’s core, this is book about philosophy. In a landscape of Google and go; and compile it, link it, ship it, debug it; this is a thoughtful volume. It makes the point that I’ve never seen in print, that the individual software developer is responsible for their own career development. Not their manager, not their company, but they themselves are responsible. Heady stuff this.

As to the remainder of the book’s material, it’s more a wake up call to upper management. There you’ll find discussion of recruiting, hiring, retaining, shaping change and showing ROI. I know of very few who could look at this volume and come away unmoved.

It might be the separation of authority and responsibility, the hire for what we needed yesterday, the CYA so we get our bonus, or the factory worker mentality encouraged by so many firms today. If you can read this book and not get something out of it, you’re part of the problem.

Truly quality software is designed, built, and tested by passionate individuals working together toward the creation of something which will well serve the customer. Everything else is just code. Any 10 year-old can be taught to write code. I know, I’ve done it. Do you want your life’s critical systems to be build by 10 year-olds? Of course not, that’s a ridiculous question. How about people who are just doing it because they make a better than average day’s wage?

I hope you’re intrigued. At the very least, I hope you’ll reflect on your own views of the responsibilities of a software developer. At fewer than 250 pages, you can read this book in one or two sittings, but reading the book is only the starting point.

 

Read Full Post »

In the Breach or On the Beach: The Character of a Leader

Posted in Books, Leadership, tagged , , on 29 Apr 2018| Leave a Comment »

The book, The Character of a Leader: A Handbook for the Young Leader, is an odd beast. There aren’t many non-fiction books I’ve read where the author uses a nom de plume. According to the Amazon description the author Donald Alexander is an executive officer within the United States intelligence community. Presuming this to be true, they’re desire is to provide a foundation for aspiring leaders and not their own aggrandizement. I say aspiring here because a leader isn’t a title or rank, but rather a state or behavioral characteristic. Leaders can at the same time be led. They are also in a constant state of self-education.

The author argues that a leader is grounded in a set of core characteristics and beliefs about themselves and others. This position is opposed to those who believe that one can be an effective leader and hold that there are no absolutes with regard to attitudes and actions (moral relativism).

Given the books short length (about 120 pages of main text), it struck me as unusual that the introduction was about 15 pages in length. Why not simply incorporate it into the body of the work? My view is that this device allows the author to create the questions that the main text then answers. In a way, it is as though a student approaches a teacher and in asking questions inspires the teacher to assemble a lesson for all their students. I look at it this way because that’s what I have done in similar circumstances. It’s not usually the case that people coming to me with questions realize that their questions are of import to others, but it is the obligation of those of us who people approach with such questions to “spread the wealth.” Noblesse oblige, if you will.

The book is divided into sections defining a working definition of leadership, leadership and character, leadership traits, expectations, becoming a leader, and the fundamental obstacle  to leading (tribalism). It concluded with a call for leading with integrity.

No one who has been in a position of leadership will be surprised at either the structure of brevity of this book. You could put the totality of the facts conveyed onto a business card (I’d’ve said index card, but no one knows what an index card is anymore). But just like a PowerPoint, you don’t need to write every word you’ll speak on the slides (they’re not really slides anymore either). This book is a touchstone. For those newly recognized leaders, this book is a cross between a travelogue and a cautionary tale. For the former, the inclusion of additional material would simply be superfluous. For the later, it might convey the idea that the actions of a leader are paint-by-number, whereas in reality the are very much free-hand.

There are numerous quotes by and about leaders from various periods in history. These both build the case for the author’s assertion that character is essential to being a leader and provide jumping off points for further exploration of specific aspects of leadership.

I am impressed at the tightness of the narrative and the compelling argument made by the author. They strike me as one of those individuals that I would very much enjoy learning from and working along side.

 

 

Read Full Post »

New Tricks: Building an Innovative Learning Organization

Posted in Books, Education, Leadership, tagged , , on 23 Apr 2018| Leave a Comment »

I spend much of my time these days doing long-term strategic research and planning. Part of that time is spent identifying areas where technology training is warranted. The ways and means I use to create and present training materials have been developed through years of trial and error. In the midst of one particular line of research into a non-training-related area, I found Building an Innovative Learning Organization by Russell Sarder.

The book is relatively short, about 220 pages, but in many ways, you really don’t need more than that to cover the concepts of training. While it’s true that it would take far more to cover all aspect of training, from organization by-in, to facilities, to choice of materials, to length of courses, etc., those are details. And the details are as pointless as ornaments without a tree if you don’t have the fundamentals in place. That’s where this book shines.

Yes, there are all the requisite elements of a business-oriented book (voices from industry, outcomes of research, anecdotes, and the like). Not to mention the mound of acronyms tossed in for good measure. But, I expect those. This book asserts that learning should be a systemic attribute of any thriving company. As such, learning must be part of the culture of the company for it to be successful. You cannot slap training on the side and expect that you will have any serious ROI to the company. It would be like thinking that buying Girl Scout cookies or Boy Scout popcorn has a substantive impact on the members of either organization. Yes, it does provide financial support for programs, but it’s not “the program.”

Training needs leaders, resources, people interested in learning, and a purpose (lest we forget why we do training in the first place).

Training has a structure and that structure is not one-size-fits-all. People have varying modalities of learning. Even the best material won’t work well for everyone. This is were that whole (materials, time, place, etc.) details thing comes into play. But, again the focus of the book is to lay out the challenges and considerations, not specifics.

Finally, you need to see that training produces results. This can be fiendishly difficult to measure, so it’s vitally important to set expectations before doing the training. Being happy is not considered a valid measure of ROI for the company.

As mentioned earlier, the book is replete with references and for those who create training material or even those who want to create an environment within their company where can be effective. It is a good starting point. For those who have been involved in training for some time, the book can serve as a reference that can be used to educate management in the scope, cost and investment (they’re different) necessary to create a learning environment that will have long-term benefits.

Overall, a decent read. I found the interviews with CLOs (chief learning officers) incisive. As with all organization-level things, there are no easy answers. And you do get what you pay for. You’ll dispatch this book in a few hours and then find yourself going back over it later.

 

Read Full Post »

Assuming Control: Taking Charge of a Software Development Organization

Posted in Computers, Leadership, Software Development, tagged , , , , , on 18 Feb 2018| Leave a Comment »

So, you’re the newly minted leader of a group of software developers. Are things really going well or have you merely ‘assumed’ control?

Have You “Assumed” Control

So, you’re now the manager / director / vice president of engineering responsible for a software development team. Are you in control or do you merely assume so? How much do you know about your process, resources, etc.?

It’s 8PM, Do You Know Where Your Source Code Is?

Do you know where your source code is? Without source there is no product. No worries you say, “it’s all in source control.” Cool. Where? Who can access it? Is your IP kept separate from the open source and third party bits you use? Do you have appropriate access control if you have dual company relationships? How much can be accessed by non-developers / contractors? Have your development and IT department worked to establish appropriate backup behaviors to prevent you from capturing third-party source into your corporate backup system in a way that will not withstand an audit? There are mainstream third-party libraries which upon termination of use require removal of all copies. Failure get you an additional year of license payments.

What’s up Doc?

How long would it take to put together a top-to-bottom explanation of any given project in your organization portfolio? Not to have someone explain it all, but simply to arrange a soup-to-nuts set of documents arranged in some kind of self-guided tree that anyone could follow should everyone in the development group be waylaid by aliens. Follow-on, how much critical information is stored only as tribal knowledge, squirreled away in the brains of your staff? How many of your processes require human intervention from a special person to  work at all? Does the documentation you do have match the process you use? Does each piece of documentation have an owner?

The Open Source of Our Disk Content

Do you use open source components? In this day and age, who doesn’t? How long would it take you to inventory your open source use on a per product release basis? Do you have an engineer who works with legal to ensure that the open source you use have licenses that harmonize? Do you have an approval process for using open source? Does you appropriately fulfill the licensing requirements? If you modify the source, do you return it to the author? Do you make the source available on your web site (on a per product / release basis)? On our site, why? In a word “abandonware.” Is this really necessary? Well, there’s open source poisoning. And let’s not forget FSF vs. Cisco. Are your developers using code they found on the web and not worrying because about it because there is no stated license? You do remember that that material is protected under copyright law under the Berne Convention (additional exposition here).

The Very (Threat) Model of a Modern Software General

Does your product ever have interact with anything else? Of course it does. Do you have a threat model for it? At every abstraction level? Do your developers know how to read and create a threat model? A good threat model will help drive your security position papers. Security should be a tangible thing and not simply a warm fuzzy. Make your security staff’s job easier. This also reduces the time required to respond to identified security threats in the wild.

Old Isn’t Gold

There’s a phrase that show up a lot in ads for stock services. You know the one. “Past performance is not a guarantee of future results.” This is absolutely true in software. Whether you’re referring to tools, processes or people, the way things have been done is in no way guaranteed to be best practice, or even supported, in the future. This mirage of stability and security may take the form of build systems without build masters, tool chains no longer available or supported, or any tools that new hires have never heard of. Software development is not a capitalized asset, but rather on ongoing expense. We expect that pens today will serve us well tomorrow, but this is definitely not the case with software tools. Strangely, many companies expect that people will want (and in fact demand) their new software products because of the added functionality. Why would the software tools used to product said software be any different. Additionally, there is the issue of support from the vendor and in some cases the very existence of vendor. It’s akin to acting offended when the doctor you had as a child retires.

Pay no Attention to the Man Behind the Curtain

Do you have projects which are the equivalent of the mystery meat you were served in school for lunch? You know the ones. Old projects or products kept around because there’s one really important customer who still uses it. The kind of projects that rely of AS400‘s or AIX cross-compilers to work. The ones where if one particular individual left the company, you’d end up having to pay them as a contractor just to do the build. This is the hardware / process analog to knowing where your software is. If you have these, they will require special attention and not in a good way.

See No Evil or Monkey See, Monkey Do?

If your software development organization doesn’t believe that there is any reason to review the full offering every two years or never looks outside the organization when setting future directions, you have a big problem. The superstars who brought the organization their last breakthrough are only as good as the last thing they learned. As was heard at GE, “Woe unto ye corporate superstars who have not this day performed a miracle, for you shall be known as bums.” If you never look outside, one day you will discover that you have not been surpassed, you have been rendered irrelevant.

Can’t Touch This

If you’re not organization won’t even consider touching sections of the code base because there might be testing impact (scheduling or resources) or the “you can only change the code if a failure has been identified via some test,” you have severe issues. There are advances in every aspect of computing every day. From the processors, to the compilers,  debuggers, static and dynamic analysis tools, to the very algorithms, someone is working to make the software development process easier, faster, safer, and less fattening. To declare a piece or vast chunk of the code base untouchable says that you don’t understand it and are afraid that merely looking under the hood will loose all kinds of unspeakable horror; or that you hold the belief that the code in question is the realm of genius and mere mortals may not intrude.

Back to the Future

In any sufficiently complex system, there is a not insignificant amount of time between design and production. When instantiated in hardware, the lifetime is further extended. Issue of support will demand that less than state-of-the-art tools be expected and managed. If your product has a lifetime of ten years and you build it with tools, techniques and targets from ten years ago, where do you think you’ll be by the time you end-of-life the product? Where will the people who can work problems be? If you’re lucky your organization will have an Office of the CTO. For those of you who just did a head tilt, the mandate of the CTO’s office to keep abreast of futures. So even if you can’t use the bleeding edge tech today, you can be aligned for when you can. These are people you can go to with the “what if” questions. They provide options and evaluations. Let’s be real, you probably have your product developers working on existing products. You also probably have a very short design phase for new features and products. It’s amazing how many products have suffered from just getting something working and calling it good. Wouldn’t you rather have something better than the top result on Google driving your product design?

Is This the Way to the Vice-President’s Office?

In any healthy organization, you can expect that your developers will want to advance. Do you have a clear, straight-forward and consistently-applied technical career ladder? It should cover both the qualifications, duties and expectations of each rung. Is it up-to-date? Do the engineers understand it? Are there soft aspects? Is it actually used? This is a hearts and minds thing. It speaks to the relationship between staff and management. Some people will reach a particular level and be completely content. Others will want to run the ladder. Having a documented path, gives everyone a basis for conversation and a way to set goals.

On the Bench or On the Beach?

So the organization you’ve assumed has the people, skills and processes to handle all your current needs. You’re golden, right? Now ask yourself how deep your bench is. Do you have an inventory of your teams skills? Is it up-to-date? How fast can you assemble an inventory? Look at it.

Are you tracking the current software industry trends in terms of desired skills, programming languages and tools? Why? Look at your bench. See the rookie end? How do you think they select what they study in school? The smart ones are being guided into the high-demand skill areas by the time they’re in their second year of school. Where is all this drive coming from? The FANG companies. They’re the cool kids. They run at scale. They have the money to explore. They’re the companies you’re competing with for new graduates. Save money and see where they’ve been, what’s worked, what hasn’t and where they’re signalling the future is. Remember, you can tell the pioneers by the arrows in their backs.

Did you notice how the TIOBE and Stack Overflow surveys differ on programming languages? They’re using two different metrics. TIOBE sample commits to open source, Stack Overflow surveys active developers.

Now look at the middle of your bench. It’ll be the biggest section. They’re your bread and butter. Are their skills fresh? This speaks to the career ladder. If you’re using a ladder with out-of-date qualifications and expectations, where does that put you? Do you have mechanisms in place to keep your teams fresh date current?

The veteran end of your bench represent your heavy hitters. These individuals have depth or breadth of experience in domain or technology. If you’re extremely lucky you’ll have a few who have both. There may be a tendency to let them get a pass when it comes to their staying current. Don’t ever give them a pass. With great experience comes great expectations. It’s far too easy to simply trust the word of experience without making sure that they aren’t simply recycling knowledge they gained decades ago. Remember that your organization is competing in a global arena. These are the people who should be spending a large amount of their time exploring both the state-of-the-art and the competitions; and also digesting and disbursing that knowledge within the organization. If you’ve got insular vets setting direction, you’ve got a recipe for failure. Maybe not today, but rest assured, the piper always gets paid. Choice of processor, operating system, development language, communications protocol, user interface all come with cost not only today, but downstream. Finally, are your veterans creating information silos in order to ensure their position or do they make sure that knowledge is spread as far as possible within the organization? The former creates an environment of dependency, the latter spurs innovation. The rookies and mid-career developers must never believe that the views of the veterans are unassailable.

View to a Skill

We’ve explored the experience axis of the bench, but what about the skills axis?

If you speak with your development staff about a new technology / methodology / language and you hear, “that’s cool, but here we …,” it’s time to get those wagons out of the circle. This is sure sign that developers are either unwilling to work on their skills or have been beaten down by management in the past. The former is a one-on-one issue, the latter is a systemic problem.

Back to your skills inventory. Does your organization have the right skill sets to accomplish your mandate? If not, can you get there from here? If you can’t what will you do? If you can, how will you engage and implement? Do you have individuals with skills who aren’t being engaged where they could have a positive impact? It shouldn’t matter their tenure. Do you have team members with skills your teams need? How can you uplift the teams with their knowledge? What if they don’t have skill in the area of teaching others? Your organization should have an active mentoring program in place. If you can mentor one person, you can explain to someone who can train others. Your mentors can be brought into group teaching as domain experts. Your team members with teaching experience already know how to extract information from various sources. To them domain experts are a source capable of answering questions.

The Grass is Always Greener

What is the flow of the development staff? Do developers see sustaining and current projects as a dead end? This may be indicative of the shiny ball syndrome. If developers are climbing over one another to get to the greenfield project is it because there’s the perception that only the shiny and new get resources and the attention of management? Does every greenfield project manifest the same patterns of behavior as the sustaining and current only with newer tools? Are greenfield projects used to reward performers rather than being staffed based on background? When a developer moves to a new project, is sufficient knowledge transfer done to ensure no loss of continuity? This information is particularly indicative of the nature of the organization and is a way that management communicates the value and priority of various projects.

Princely Behavior

Is your organization a minefield of fiefdoms and politics? Allocate half your time to dealing with it. Few things will run your development teams into the ground faster than time lost for engineers trying to please two masters. Many people would like to believe that software development is a democratic process. That’s a very naive view. If that were the case, we’d vote on every decision and everyone would have equal weight to their opinion.

And, Action

Keep in mind the words of Brian Kernighan and P. J. Plauger in their book The Elements of Programming, “Write and test a big program in small pieces.” Make your plan with modest, attainable, measurable goals. It’s no different than creating a software project plan. As you proceed, beware individuals with an all-or-nothing attitude. No large undertaking will cover all the bases regardless of planning. Don’t let the desire for a mythical über-solution stand in the way of a good partial solution. Solve problems in the priority order of the problems, not the perceived importance of individuals or groups.

Homework

Image credit: Four Worlds. Creative Commons.

Read Full Post »

Principles in Practice

Posted in Books, Leadership, tagged , , on 29 Oct 2017| Leave a Comment »

Whenever I take long trip I try to bring a book to read. When I went to CppCon 2017 in September, I brought Ray Dalio‘s Principles. Ray founded the world’s largest hedge fund. His company Bridgewater, is the exemplar for his book. [29 April 2018 Note: I’d actually completed the book during that trip, but got distracted by other things. I let this linger for far too long.]

At this point, I could assert that having created an organization a large and successful as Bridgewater would be justification for following the methodology he espouses. After all, isn’t that what we do, chase success is search of our own? If your desire is to leverage Ray’s book for that, you’ve failed before you’ve even started.

The information you will find in Principles is slow burning. Everything about his methodology requires tremendous time, effort and attention to detail. Let’s look at how the book decomposes:

In the first part (of three), he gives his personal backstory. This takes about 120 pages of the 550 or so page book. That’s a lot of exposition for a book ostensibly about life and work being able to be systematized. Then again, this isn’t a “here’s a fish” kind of book. If someone is going to purport to present a set a principles leading to success, you need to establish that you actually have the chops. And those chops don’t come from those whose success is inherited or the result of random chance. As has been said in many forms, “you learn nothing from success, but you learn everything from failure.”

The second part (about 150 pages) is devoted to life principles. The takeaway here is that work success is an extension of who you are. Your work, as opposed to your job, is not a coat to be put on, like some bulwark against the financial storms of life. To many his life principles are quite Machiavellian. While having clear goals is the basis of any true achievement, and root causing problems and designing solutions around them are in service to that end; both not tolerating problems that stand in your way and doing what is necessary to achieve results fall into the ruthless bucket. In no way am I opposed to his principles. In fact, I wouldn’t have personally accepted his work principles had he not been ruthless in his personal ones.

The third part is the thing we came to see, it covers his work principles. Here again, we see the division into thirds. They are culture, people and organization.

In the area of culture, first and foremost are the dual concepts of radical truth and radical transparency. On this foundation is having meaningful work and relationships. Next, and where I’ve seen many companies fail miserably, the culture needs to accept mistakes but demand that people learn from them. Once things are spun up, you have to keep everyone in sync. This goes back to the ideas of radical truth and acceptance of mistakes.

On the people front, you must hire the right people. Hiring the wrong people will kill your company eventually. In that vein, who the people are (life principles) is more important that what they know. People with a good foundation can be built upon. Those without can’t. Finally, you must constantly refresh people’s skills. This rigorous regime of renewal is not something that everyone can embrace. When people don’t … well, we’re back to Machiavelli.

Lastly, he addresses the organization itself. In many ways, his approach to the organization is identical to that of a person. The same issues of goals, problem tolerance, evaluation and improvement apply. That may sound like I’m short changing that part of book, but given Ray’s premise that work is an extension of the self, it’s only natural that the organization is an extension of the people working there.

This book is one you will either embrace as an affirmation, or reject as too demanding. As to why I don’t believe that there’ll be any middle ground, the title says it all. You either see the material in the book as principles or you don’t.

I, for one, do.

Read Full Post »

Learning From the Past (Apollo Edition)

Posted in Apple, Leadership, Software Development, Space Exploration, tagged , , , , , , , on 22 Mar 2015| Leave a Comment »

I believe that you can learn a lot about people through the things they fill their heads with. Over time the mechanisms for this process have grown in number and availability. Once people would travel great distances seeking out teachers. Of course if you were powerful enough you could have them come to you. Once we managed to get the teaching down in permanent (well mostly) form, you didn’t actually need to bother with the whole physical presence thing. Still the needing the scribe thing made this practical only for the silly rich. By the time we get to the 20th century the super clever public library idea meant that you could recommend a book to someone without running the risk that their dog would eat the only copy for a thousand miles. The mid 20th century added audio and by the end video to the menu. With the advent of the internet, we could not only find materials to borrow from libraries with ridiculous ease, but could reserve it and get an email when it was ready for pickup. Then came the Kindle, Zinio, Netflix and the iTunes store. Now if someone is ingesting some bit of knowledge, in all likelihood, you can too (and within minutes).

So, what’s with the Burke-ian prologue?

Well, I was reading The New Yorker‘s article The Shape of Things to Come, about Jony Ive and the future of Apple. Among the bits of past, present and impact; was a fascinating bit. Ive was watching Moon Machines [iTunes Store]. Not expected that.

I’ve always been a bit of a space wonk, so I was interested just on the face of it. What I found fascinating was that a person born in 1967 England best know for early 21st century industrial design saw something of interest in a series dedicated to the United States’ Apollo program.

Having now watched the series, there are things that jump out at me. As with every time I take in something that’s been recommended (if person with the time constraints of a SVP at Apple mentions that they see value the spending time, that’s a hint one would be ill advised not to take advantage of), I strive to understand how it relates to the person, their work and goals. Ive’s comment speaks volumes.

… like the Apollo program, the creation of Apple products required “invention after invention after invention that you would never be conscious of, but that was necessary to do something that was new.”

The Apollo program was a tech start-up writ large. The goal was abstract; the time tables unyielding; the cost astronomical (literally); the toll on people and their relationships severe. In the end, the successes were ascendant and the failures devastating. The six episodes take on major aspects which had to work together in order to assure the success of the program.

The lessons of Apollo are applicable to endeavors in science, business, politics and design. Issues of control, quality, planning, communication and contingency are laid bare. As are their failures. Of particular distinction are the moments of crisis. Unlike anything before or since, we have documentation of and visibility into the people who stepped up to lead their teams and the processes through which they overcame them.

In an era of ever-increasing abstraction and the misplaced belief that you don’t actually need to understand how things work in order to produce something of quality, Moon Machines provides timely lessons. The quality of the end product begins with the confluence of domain and technology, not the application of one to the other. The speed and manner of disposing problems during a crisis depends greatly on the depth of understanding extant in the team of the two questions: What do I have? and What do I need? As well as the understanding of how to get to the latter using the former.

In the end, I have a greater admiration of those involved in Apollo thanks to a comment by Jony Ive.

Read Full Post »

Dale Carnegie: The Man Who Influenced Millions

Posted in Books, Leadership, tagged , , , , , on 16 Jun 2013| Leave a Comment »

I wasn’t sure what to expect from Giles Kemp and Edward Claflin’s book “Dale Carnegie: The Man Who Influenced Millions.”
Having been a member of several speech clubs in the past, as well as having made a lifetime worth of presentations, I really didn’t think there was much to be learned from Carnegie’s course.

I came across a review of Carnegie’s book that mentioned that Carnegie left out a chapter on dealing this toxic personalities. This is the book referred to.

To some extent, I find Carnegie’s life to be ironic. To the public, he’s perceived as being the the perfect speaker and someone at ease in any situation. In reality, he was uncomfortable outside of his “school’s” environment. He created a mechanism that allows people to be more self-assured and better at dealing with others. But, being able to teach others does not imply mastery of the techniques being taught.

In my reading of impactful individuals from the last 300 years, I am saddened that there is very little possibility for someone to replicate their path in today’s world. Carnegie never completed junior college ant yet was able to achieve great success teaching even the captains of industry.

Unlike the traditional biography, vignettes are presented from contemporary (1989) Carnegie classes.

The book is well worth the read.

Read Full Post »

Older Posts »