The Changing Role of the Technology Leader

Infoworld has recently taken a view at How will the CIO's role change by 2020 which was followed up with discussion on linkedin.  I found the article more focused on taking a guess at changing technologies more than changing roles so I decided to take a crack at how I see the role and related skills changing (or staying the same) over the next 5 or so years for technology leaders (CIOs, CTOs, et al):

1. Technical innovation skills.  For companies where technology doesn't enable them to differentiate or compete in the marketplace (that is, no technology development just technology enablement), the technology role will be less critical and demoted to a lower position in the organisation and led by a more operational tech leader.  In companies where technology is developed in a unique way to compete and create value, the role should stay at an executive level and require more innovation and advanced business skills.  Technology innovation leaders will need to know how to speed up rate of change, decrease the costs resulting from rapidly changing requirements and how to scale.  Separation of innovation vs non-innovation business types and resulting change of roles underway now and continuing for the next few years.

2. General technical skills vs other business skills.  Technology leaders aren't business leaders, P&L owners or product managers, otherwise they would be in one of those roles.  They are at the leadership table to be the experts on how technology can delight customers and enable and grow the business.  They fulfil P&L owner aspirations and create highly functional fulfilment envelopes around product and service owners.  This is no different than the HR or Finance leaders, each experts in their area servicing the needs of business line owners.  Similarly tech leaders need to be business savvy and communicate effectively by translating technology concerns to and from business ones.  No change other than non-tech leaders are becoming more knowledgable about tech resulting in increasing communications fidelity of tech concerns in the future.

3. Technical understanding of data security. Due to technical complexity, the technical leader will have to increasingly expand their knowledge of cybersecurity.  They will need the business acumen to strike a competitive commercial balance between flexibility and cost versus risk.  This means increasing knowledge requirements on the technical security side to effectively manage related staff and vendors balanced with sufficient knowledge on the commercial side to collaboratively determine an appropriate commercial balance.  Increasing rapidly the last few years and will continue to do so for some years.

4. Technical understanding of regulatory, legal and compliance requirements.  As nations increasingly understand and depend on the Internet there will be changes in regulations and taxation on Internet activity and supporting infrastructure.  Changes will continue to come from government, banking and infrastructure providers.  This is an area of risk management typically at board level and the technology leader must not get caught out by the changes.  Gradual changes on-going for last 10 years and will continue with occasional "surprise" activity spikes.

5. Ability to identify and remove non-core business and technical activity.  Business process analysis, service delivery, remote staff management and change management are assumed technical leadership skill sets.  Similarly outsource/offshore skills should already be standard for cost reduction and scaling access to talent.  These will increasingly combine in the future to remove non-core processes, products, and services from the business - not just for IT but across the business.  Crowd-sourcing and flexible staffing models will expand.  Changing rapidly for the last few years and will continue for some years.

6. Understand the management of a highly distributed and integrated solution.  Technology delivery continues to fragment requiring increasing expertise at sourcing, integration, and service delivery.  The technical leader must orchestrate different suppliers, a growing number of which are outside of the company and the technology leader's direct control through commercial/contractual expertise and building deep relationships.  Continuing to increase and fragment over time.

7. Budgeting in an opex world.  The technology leader will need to understand how pay-as-you go cloud models and how to transform an organisation dependant on capitalised project thinking into an opex oriented one.  Just starting to change and will accelerate rapidly for next few years.

8. Management of legacy systems and data sets.  The "cruft" of legacy systems and data repositories along with data retention driven by regulatory requirements continues to to expand cost inertia around the technology leader's responsibilities.  Hooking costs to business owners will help.  Knowledge of rapid legacy virtualisation, tiered storage technologies, and integration "envelope" architectural approaches will be required.  Long time problem and will rapidly worsen until better solutions and special-purpose outsource providers come into play in a few years.

9. Understanding of data architecture, access and reporting.  IT has become increasingly effective at monitoring and reporting on technology concerns, including monitoring of customer related data, and is seeing benefit to converging the data into a single reporting system.  Similarly the business has opted for separate and expensive reporting, dashboarding and bolt-on analytics further fragmenting the data.  Further compounding the challenge are cloud/SaaS solutions being sold "around" IT which will eventually need to be integrated and virtually consolidated using data aggregation.  Technology leaders will need to understand the organisation of data, it's benefits and how to make it pervasively and transparently available and what tools and data sets to converge on to enable the business to have a more consistent view of business results and customer activity. Many fragmented efforts underway now from different directions consolidating in the longer term.

10. Understanding and encouraging the use of collaboration tools that cross organisational and corporate boundaries.  As less technical staff learn to use collaboration tools technologists have been using for a long time, they will also increasingly access sources of outside information and informal networks to better compete in a global labor market.  Corporate borders will become increasingly porous and if managed well this proliferation of "commodity" information can be used to drive non-core activity out of the business. Becoming increasingly common and with usage increasing rapidly over the next few years.

The fundamental responsibilities of a technology leader such as people management, budgets, strategy, operations, and development all remain.  However, how most of them are done will see significant changes in the future.

What does it mean to be a technologist?

At some point about half way through my career, 10 or so years ago, I started referring to myself as a technologist.

Sure, I got the usual "what a geek" comments early on - I was the guy that fixed friend's computers and saved up for a horrifically expensive mobile phone when they first came out.  Yes, I found myself taking technology night classes at local Uni (pre-WWW, give me a break) and hacking on this and that for fun.  Of course I wrote automation scripts at work to reduce the tedious parts of the job, even though building the tools wasn't actually the job.

Then I got into technology management and was told I'd have to give all that up because good managers knew how to delegate individual contributor work and should spend their time managing.  That never felt right to me so I rebelled and sometime later started calling myself a technologist who also happens to also manage stuff.  Some years later I think my much more technically savvy friends will call me more of a "wannabe" technologist, but that's ok.

About 2 years ago I wrote about what I do as a technology leader.  That blog entry was done in the spirit of trying to help me understand my responsibilities at the time and whether they felt right.  Maybe it also helped others understand the kinds of responsibilities they might have in the future if they wanted to lead technology teams or tune their own technology management responsibilities.  In hindsight, I also discovered (for myself anyway) two important ideas.  First, I uncovered the notion of own and do, concluding that I valued maintaining a balance between the two.  Second, I separated practical day-to-day responsibilities from leadership concerns.

So that brings me to today.  Earlier I stumbled on an article about Skills Every IT Person Needs.  It got me thinking about my old technology leader blog entry and what skills I thought every technologist needs, at least in my world.

So what is my definition of an IT person, or in my book, technologist?

As it turns out, I still think there are two sides, just like my view 2 years ago on technology leadership: a pure technology side and a softer side.  What follows is my definition of an effective "technologist".

On the pure technology side, I think "technologist" implies curiosity, passion and some base of knowledge and skill in four areas:

1. Foundation technology that underpins the technology you work with regularly. "Yep, I know the basic building blocks of a computer and can use them to talk theoretical performance trade-offs."
2. Specific technology areas you directly work with regularly.  "Let's talk about how we can performance tune this Apache server."
3. Mainstream pop technology.  This is what your non-tech friends and colleagues read in the mainstream press and want to ask you about for an "experts" view:  "Hey, can that security problem at Sony happen to us?".  It can also be just simple help requests to sort a home network problem or give advice on which smartphone to buy.
4. Geek pop technology.  A grab-bag of technologies you learn about in geek press and from your geek friends at a very superficial level:  "So tell me, what the heck does the Large Hadron Collider do exactly?" and "Yeah, I can't really explain why I installed Android on my old iPhone."

Non-technical people will challenge technologists on the value in some of these four areas.  When tactically focused, items 1 and 2 clearly create value, so spending time in these areas is easy to justify.  Item 3 creates value when we help educate our non-tech colleagues around how to judge risk, make better tech decisions, and sometimes just lend them a hand to fix something for them.  Item 4 can be justified with learning new ideas that you can apply to items 1-3, but more often you'll just have to accept the tech guy is going to be nerdy sometimes for item 4.

As a career moves on, technologies change and perhaps the span of responsibility widens.  As a result it becomes increasingly difficult to stay on top of 1-4 above.  Difficulty is compounded by living in an age of ever-expanding and changing technologies.  A technologist copes with this by becoming more and more selective about what they dive into and how deep, as driven by how to best get things done - delivering the next product or service.  A good technologist learns their weak spots as well, and knows the areas that they simply can't dive into and instead should create leverage or ask for help.

On the softer side, I believe technologists also have a desire to produce something of value; that is, technology with a purpose.  Technologists want to build products or services that get used and appreciated.  Like taking an art appreciation class, technologists understand what they've delivered in depth and "get more out of it" when their products are used.

I fully accept that there are very successful people in technology that are not technologists.  They tend to manage things and not understand much about what they're managing, instead focusing on breadth and excelling by managing many things at once.  While this can work, a technology department needs to be careful here.  Having people managing something they don't understand is how projects can fail and businesses get sold third party products and services they don't need.  However, so long as there is someone technical around to provide targeted advice, the non-techs can create value and thrive.

However, let's say your curious about what makes up a technologist, at least my definition of one.  Maybe you want to set up an induction program for your company's technology department for new hires.  Maybe you want to create a framework to to provide guidance to less experienced staff to progress their career as a technologist.  What might you cover or recommend to them?

As inspired by Skills Every IT Person Needs, and to make this more practical, I've assembled the following checklist of knowledge and skills to be considered a technologist, both the harder and softer sides.

But first a few caveats to explain some biases below:
- I work with Internet and retail gambling systems which colors my world
- I'm pretty far removed from most technical details but that doesn't stop me from having things like "program something in Scala" on my to-do list
- I've skipped some of the items in the Skills Every IT Person Needs list that I certainly agree with, but weren't top of mind when I put my list together
- I've thought in terms of a for-profit business, but at least some apply to not-for-profit and joy-of-creating endeavors as well

Now, onto the checklist, as organized by technology category, followed by the softer attributes.

Foundation technology

• Understand at a basic level what the major parts of a computer are.  Be able to open up a PC case and point them out: CPU, memory, disk, I/O, bus, clock.  Understand storage layers and trade-offs (cache-memory-disk-tape).

• Understand how a browser works: HTML/CSS markup, Javascript/AJAX, HTTP, DNS, TCP/IP.

• Understand a basic web delivery stack:  LAMP, Java, Microsoft.  For example: client side programming and markup; server-side page construction; business logic; database.

• Understand why MVC specifically and separation of concerns generally is useful.

• Understand a few high-use design patterns.  Facades and factories are useful.

• Understand the difference between asynchronous and synchronous design.

• Understand object oriented concepts: Encapsulation primarily, but inheritance and polymorphism as well

• Understand how to design for fault tolerance: clustering

• Understand why backups are important and some ways to implement them.

• Understand a software development tool chain.  Use an editor and compiler to write and run some code. At least write a few simple scripts to automate something.  Be able to read simple code and understand the gist of what is going on.

• Understand what a transaction is.  Atomic, ACID, and locking should be familiar terms.  Bonus points if you understand transaction performance implications and double bonus points for why database synchronized architectures are easier in the beginning but don't scale well later on.

• Understand basic problem solving techniques.  Divide and conquer, process of elimination, hypothesis testing, change conditions and observe, 5 whys - there are plenty more.  Participate in hard problem solving sessions.

Specific technology areas

• Develop at least a high level understanding of your software, systems, and infrastructure architecture.  Jump on the opportunity to be a sounding board for a colleague's architectural frustrations or contribute to a brainstorming session on how to improve the architecture.

• Identify, offer to own, and deliver a solution to a hard problem.  Particularly between-the-cracks, no-one-seems-to-own problem.  If you see someone struggling with a hard problem, ask them if you can help.

• Learn something new about a relevant technology on a regular basis.

• Understand what key departments do and how they philosophically differ: software development, project management, QA/Test, change/release, technical operations.  Understand the different approaches between development and operations.  Why are the best in these two areas wired quite differently from each other?  Why is QA and change/release such hard jobs?

• Manage or help manage a change into production like a production push of fresh code.  Run a release plan early one morning.

• Manage or help manage a crisis situation, an unplanned downtime.  Lead a team to finding the solution.

• Build something that hits production, goes live, people use, and earns money for the business.  Build something you find interesting.  Know how many people use it, how much they like it and how much money it earns.  It's your right, you built it (* confidentiality concerns and third party handoffs can inhibit so best effort!).

• When you're more junior, find an area of technology and make it your own.  Become the guru, the expert, the goto-person for that area.  As you progress your career, master a couple of areas as a guru.  When you're more senior, occasionally sharpen and leverage your knowledge in these areas and make a real hands-on contribution to a project.  Moving into management doesn't mean you should give up your guru status in any area, it just means you're just not quite as good at it as you used to be (but you're still competent because you were a guru at one time!).

• Know when your ignorance or skill deficit is hurting the business.  Go seek help, ask questions and train if you can.  A little business hurt is sometimes the cost of you learning - that can be ok, but be transparent about it.  Renegotiate your responsibilities if you simply can't do what's being asked of you.

Mainstream and Geek Pop Technology

• Use some flavor of Windows and Unix at home.  Use what mainstream users use, at least once-in-awhile.  Manage your home systems - installs, upgrades, trouble-shooting, repairs.  Make your own backups.  Recover from a failed disk.

• Be willing and able to fix a office issues, PC, printer, or basic network when you're visiting someone's office or a friend's home.

• Security.  Be able to clean a friend's system of viruses and malware.  Read the mainstream articles about security failures so you can proactively talk about them with concerned colleagues.  Understand the basics of how criminals break into systems and steal data.

• As for Geek Pop - that's up to you.  Let your interests be your guide.

Soft skills - non technical attributes that will help you create value

• Be able to communicate.  Document, email, blog on a topic.  Create sustainable business value through creating durable enterprise knowledge using tools like wikis.  Be able to speak and present effectively in various situations from one-on-one to large audiences.

• Understand the basics of project management, including important tradeoffs - schedule, scope, resource; quality, risk, technical debt.  Try to educate people about these tradeoffs when they try to constrain all of these dimensions of your work. Walk away from them in the nicest possible way and escalate to your boss if they don't understand it.

• Understand when it's time to fix things for the short term or the long term.  Both are often important but sometimes you have to pick and recommend because you're best placed to do so.

• Learn how things get done.  Who can you ask to do things?  Who controls priorities, allocation of resources and budget?

• Understand how the business makes money.  You should understand how your daily work enables the business to interest customers and earn money.  What do you need to know to make intelligent decisions and prioritize tasks on daily basis to help increase revenue?

• Understand a process your involved in end-to-end.  Rebel against the process if it's broken.  Work from within it to improve it.  Work with the people in the process to really own the process, customizing and optimizing it to the team's needs.  Make it hum.

• Pay attention to your balance between managing and doing.  Managing is overhead, sometimes but certainly not always necessary.  Doing is creating tangible value.  If you find yourself just forwarding email back and forth, have the confidence to remove yourself from that path.  You're not creating value.

• If you want to change jobs, perhaps to one with more seniority, then just do the job.  Too often people get hung up on not doing what they're not being paid for even though they want the job.  Consider it an investment.  If you do the job well, recognition will follow.  It has to.

• Don't ever apologize for being a technologist.  You should take great pride in knowing what you know.  However, try understand that what excites you really doesn't do it for most non-technologists.  Find a few mainstream topics that interest you that you talk about.  Home science projects don't count.

Conclusion

There are many views of what it takes to be a technologist.  For me it comes down to curiosity, selective understanding of the details, trying to make things better, and creating and delivering products and services that customers like.

Responsibilities of a CTO, CIO and other Technology Leaders

What does the CTO, CIO, IT Director, or VP of Technology do? There are many names, but what we're talking about is the person who owns all of technology for a business or an at least somewhat self-contained unit within a business. Of course this will vary a lot based on the size of the company and the company's raison d'être.

Context #1. I work for an Internet services oriented business. Its a medium sized business owned by a bigger business. I went back through a few months of my memories, emails and notes, here is what I was up to at one point or another.

Context #2. I have a strong belief that you should be clear on what you own versus what you do. I'm probably 50/50 between my own individual contributor work and IT management. So while I own and am responsible for all of technology for the business, most of the work is done by my team, while I do just a tiny little slice of of it. And to be fair, sometimes when I'm doing, I'm thinking about how to create leverage so I can shift what I'm doing to someone else and step back to just owning.

Context #3. IT output should always have a customer. I sometimes get tempted to pull in a product management capability into IT. This is typically due to lack of business engagement or my desire to offer a complete solution, particularly having team skills that enable us to think through complex requirements for our customers. We do this sometimes, with bitter-sweet results. The business has even less skin in the IT game and they become even more disinterested in the product and are reluctant to receive something they didn't help create (even though they didn't want to).

A similar pattern happens with backoffice systems. Right after something new goes live its possible that the project team knows the product better than the customer, especially if the customer has shied away from the hard business/domain logic thinking required to deliver a real product. The shorter the IT weening period the better.  From a cost and efficiency perspective, IT should get back to their main job of IT and the business must come to terms with their level of (sometimes lack of!) engagement during the project.

So in my world, Context #3 means IT doesn't own product management or non-technical product operations, or at least tries to hand it over as fast as possible.

With these contexts in mind, I've roughly divided my responsibilities into two sets: meta concerns and actual responsibilities.

The first are "meta" concerns - useful skills and traits which when bundled together help define leadership.

Meta Concerns (Leadership!)

• Communication
• Out - to customers
• Up - to the CEO, board, shareholders (KPIs and dashboard views)
  
• Across - to my peers - finance, operations, marketing, sales and accounts, product
• Lots of wiki, lots of slides
• Transparency encourages trust
• Out in the open about failures - who messed up what and when; what you're going to change (and not change)
• Drive and re-enforce important cultural attributes
• Transparency
• Over-communication
• Wallow in failures - learn and improve
• Incremental delivery
• Make sure you know and understand what you own; don't treat everything as a black box; pick a few things and understand them in depth
• Ownership
• Learning - sharing information, retrospectives; curiosity
• Sense of urgency
• Change management
• Organizationally
• Major platform/product changes
• Creating leverage
• Both for myself and helping my team to do as well
• Balancing supplier/external, outsourcing, contracting versus hiring leverage creation
• When can the business afford to create leverage versus having to make do with what is already present (budget vs leverage)
• Debunking leverage when it doesn't really exist but is represented to (internally, suppliers, in related businesses, as offered by others)
• As can be funded by the business - I keep spinning out aspects of my job to those that make a full time job of it. Each should be better and more qualified at that job than me and I expect to be able to learn from them
• Managing the politics

Areas of Responsibility

The following is a more practical view of what I own or do, all of which is supported by the meta level skills and traits above.

• People
• Organizational structure
• Recruitment policies, methods, process
• Recruitment plans, including consensus building, approval, sign-off, execution
• Closing on preferred agencies if used for recruitment
• Succession planning, risk management
• Coaching and mentoring
• Conflict resolution
• In-house, outsource; contractor, consulting firm; build competency or not
• Budget
• Yearly overall definition
• Expenses (human; everything else)
• Capex
• As driven by business strategy, key projects
• Monthly to quarterly evaluation of actuals to targets; adjust and warn/alter where needed
• Review and sign-off on invoices and expenses over a certain level
• Re-negotiate changes
• Technical strategy
• Supports business strategy (and helps define it, take it to the next level of details and tradeoffs)
  
• Communicated up/down/across/out in various ways
• Evangelize the strategy overall, but typically aspects of it
• Efficiency versus innovation balance
• Enterprise/Systems/Software Architecture
• Top level architecture (edge of systems, key subsystems, main software components)
• When high spends are involved
• When there are significant proposed changes in business strategy/direction
• Particularly at the edges between teams and major components (e.g., QA to Release; supplier to internal integration)
• Provide various views/summaries of the systems/software/components up/down/across
• Evangelize and push priorities of "wiring and plumbing", "quality of life", and "-ilities" changes (e.g., stability, scalability; as often internally technically originated as driven by vague business requirements)
• Emergent technology trends, what and how to take advantage of them
• High level, first pass, "does this make sense", "can we do this" business development support
• Work and delivery priorities
• As meshed with business priorities
• Project/portfolio planning - cross-portfolio coordination
• Communicate and summarize out/up/down/across
• Maintain close knowledge of where the business is, what people are thinking - I should be 90% right when I prioritize projects and allocate resource and the business will only fine tune around the edges if I'm close to to pulse of what is going on
• Conversely, need to create consensus and buy-in on tech priorities to make sure business is in support
• Outsourcing
• Processes
• Operational, delivery
• Pioneer some processes, collaboratively build others
• Drive incremental improvement
• Internal and customer/partner facing
• Initiatives
• Directly own several themed high level initiatives to address systemic or complex issues that the business and IT team is otherwise struggling to address
• The initiatives end up being composed of a number of projects. I do the work for the initiative itself but then own the related projects.
  
• Mergers and acquisitions support
• Be a catalyst to find break-through solutions when the business or team are stuck
• Initial solution creation
• Regular development
• Hotsite issues
• Come up with new options
• Encourage incremental solutions
• Be a catalyst in finding smaller increments to be delivered
• Help business (non-tech) to take an incremental view
• Help convert features/complexity into a managed risk
• Provide brainstorming/input on how technology can be used to solve business problems
• Have at least a basic understanding of all functional areas of the business
• Communicate and collaborate in their language
• Key supplier management
• Networking in the community
• Domain/sector specific
• Relevant technology areas
• Hotsites
• Making sure that hotsites receive top priority and that everyone who needs to is paying attention and involved
• Not just in tech, but also in non-tech cross-functionally where needed
• Creative engagement of resources not normally available
• Partner and customer interaction
• Learning what they really want
• Help craft solutions
• Gain needs sensitivity to better create and prioritize solutions
• Business domain knowledge, awareness of competition
• Corporate IT interface point (if business is owned by a bigger business)
• Corporate governance
• Audits (statutory IT audit)
• Board reports
• Corporate, secretarial, treasury management of IT business units (e.g., outsource/offshore IT unit)
• Government, regulatory compliance
• Support development of business strategy
• Contribute to product roadmaps, particularly very technical aspects
• Quality assurance
• Office/desktop IT/support
• Policies
• Security
  

Of course everyone is better or worse at these things - no-one can be excellent at all of them, especially on any given day.