Being Senior in a Technical Field

This seems like something that the Harvard Business Review should have written up many times.
Still ...

Successfully being senior is not the same thing as staying current and keeping up with technology. This is PART of the job, but the junior folks will be doing this, too, and they are less expensive and often more enthusiastic. A sergeant in the US Army isn't expected to be a better private than the new recruits. The sergeant has extra responsibilities on top of that of the privates.

Likewise, a senior technical contributor isn't being senior if he or she is simply better at the current technologies than the recent hires. Being senior involves more than that.

In general, as you become more senior, but still technical, the job becomes less just about just implementing solutions (though I believe that skilled senior technical folks should continue to do this). Instead,

Junior folks are expected to answer questions that more senior people pose and solve problems that more senior people give them. The most junior folks do this with supervision and as these folks become less junior they are expected to work more independently. Eventually, however, the job involves less of doing what someone more senior has decided must be done and the job becomes deciding what must be done. Or at least participating in those decisions.

A few concrete example might help.

Example: Realtime or Not?

Junior folks will implement a system that someone else architects and designs, but someone (senior) must make the high level decisions. Is a given software system going to be a real-time system or not? Real-time is difficult compared to non-realtime, and you don't want to solve a harder problem than you must, but if you NEED a real-time system and don't build one you are in trouble. Building a real-time system unnecessarily and failing to build one when actually necessary are two different failures, but both can risk the success of a project. The more senior engineer is going to be responsible for having an opinion on this and being able to communicate it clearly.

Example: How Scalable?

Simple problems call for simple solutions, but simple solutions often cannot scale to substantially larger problems. Understanding the problem well enough to choose a simpler solution when possible, but solving the complex problem when necessary is the job of the senior engineers. Junior engineers tend to either solve the simple, toy problem whether this will scale up as necessary OR tend to want to solve the maximally hardest problem because it has not risk of failing to scale. As with the real-time question, both choices can fail: A too-simple solution may fail when the problem grows and a too-complex solution may fail to work at all or may require excessive resources to run (e.g. requiring a computer cluster when a laptop should be sufficient).

In theory, the marketing department is responsible for understanding customer requirements and using those to specify new features or products. In practice, senior technical folks need to understand the customer requirements, too, so as to not mis-interpret marketing choices. In addition, the marketing folks may miss technical opportunities that are available. Senior technical folks who understand the customers and the products bring a different, and valuable, perspective.

"How should we do XXX" may best be answered with "We shouldn't do XXX at all. Instead we should do YYY." Additionally, "Should we do XXX or YYY?" may be best answered with, "Neither. We should do ZZZ." Folks don't expect junior engineers to come back with these responses. Folks do expect senior folks to do so.

The more junior employees are often hesitant and unsure of themselves (others are confident to the point of overconfidence ...). These folks may need to be encouraged to try new things and/or step out of their comfort zone. They need to be told that the occasional failure is okay (as long as folks further up realized that risk was being taken ... sometimes that folk further up is you) provided that they learn something and that the risk had a reasonable chance of working.

Occasionally, the junior folks will want to do something that you know is a bad idea. Depending on the cost, it may be your job to let them do this so that they can see the results. There is a difference between being told something and experiencing something.

Junior folks are often afraid of making mistakes. One of the responsibilities of the senior folks is to provide oversight of the junior folks. Another responsibility is to take the blame if/when the junior folks screw up. Not ALL the time, but sometimes. Occasionally, the junior folks may want to take a risk but are afraid. The senior technical person's job includes encouraging the junior folks (if the risk is reasonable) and then (a) taking the blame if things work out poorly ("I told them to go ahead") or (b) handing out praise if things go well ("This was their idea. They did well ...").

Management (mostly) should not be second-guessing senior technical people's technical judgement. Line management is yet another set of skills and it is unlikely that the senior management is qualified to know the correct technical choices. The senior technical folks are responsible for this. But ... when management asks for a technical judgement, management doesn't want waffling and/or hedging! It is the senior technical folks job to know the answer, not to duck it.

Example: Yes!

I was once in a very senior technical review (e.g. the company CEO and president were both present...) for a product that was expected to ship soon. The company president asked me one, and only one, question about the software:

Is it going to work?

I provided a one word response: "Yes."