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.