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.