Management and technical career tracks: separate but not equal

Promotion paths for technical people

I’ve worked in technology companies and I’ve seen the same question arise several times: what to do with technical people who don’t want to be managers? What do you promote them to?

(Image credit: Louis-Henri de Rudder, source: Old Book Illustrations)

The traditional engineering career ladder emphasizes management as the desired end-goal and devalues anyone not in a management position. Not everyone wants to be a manager and not everyone is good at management. Some people are extremely technically competent and want to stay technical. What are they offered?

Separate, but not equal

Most companies deal with the problem by creating a parallel career path for engineers who don’t want to be managers. This is supposedly separate but equal, but it always ends up being very unequal in the management branch’s favor. The inequality is reflected in job titles. Director is a senior position in most companies and it comes with management responsibility. The equivalent technical role might be ‘Fellow’, which has overtones of putting someone out to grass. A popular alternative is ‘Technical Director’, but note the management equivalent is Director - the engineers get a qualifying word the managers don’t, it’s letting people know the person isn’t a real Director (they're technically a Director, but...). Until you get to VP or C-level, the engineering titles are always worse.

The management and technical tracks have power differences too. The managers get to decide pay raises and promotions and hiring and firing, the technical people don’t. Part of this is obviously why people choose management (and why some people don’t choose management), but often the technical path people aren’t even given a seat at the table. When there are business decisions to be made, the technical people are usually frozen out, even when the business decisions aren't people ones. Sometimes this is legitimate, but most of the time it’s a power thing. The message is clear: if you want the power to change things, you need to be a manager.

A way forward

Here’s what I suggest. The managerial/technical divide is a real one. Not everyone wants to be a manager and there should be a career path upward for them. I suggest having the same job titles for the managerial path and the technical path. There should be no Technical Directors and Directors, just Directors. People on the technical path should be given a seat at the power table and should be equals when it comes to making business decisions. This means managers will have to give up power and it will mean a cultural shift, but if we’re to give meaningful advancement to the engineering track, this is the way it has to be.

How to hire well

How I've learned to hire

I’ve done a lot of hiring and I’ve learned what works and what doesn’t work to make a good hire (someone who performs well and stays). I’ve come to trust my judgment but only within the confines of a hiring process that covers my blind spots. Here’s a description of what I typically like to do, but bear in mind this is an amalgamation of processes from different employers.

To be clear: what I say in this blog post might not reflect current or previous hiring processes at my current or former employers. I'm presenting a mix of processes with the goal of giving you insight into one amalgamated hiring process and how one hiring manager thinks.

Principles - caution, excitement, 'no', and decency

The hiring process is fraught for both parties. We're both trying to decide if we want to spend extended amounts of time with each other. The hiring manager wants someone who will fit in, perform well, and will stay. The applicant wants to work in an environment that suits them and rewards them appropriately. No one enjoys the interviewing process and everyone wants to get what they want quickly. This suggests the first principle: caution. It's easy to make a mistake when the pressure is on and the thing that will save you is having a good process.

Once the process starts, I try and follow an ‘excite and select’ approach. I want to excite candidates by meeting the team and by the whole interview process and I want them to feel energized by what they experience. I then select from enthusiastic and excited candidates.

My default position is always ‘no’ at all stages. If I’m in doubt, I sleep on it and say ‘no’ the next day. On occasions, I’ve been under a great deal of pressure to make a hire, but this attitude has saved me from hiring the wrong person. Even in the US, unwinding a bad hiring decision is extremely painful, and in Europe, it can be almost impossible. It’s far better to be sure than take a risk. I’ve only changed my mind after a ‘no’ once, and that turned out to be a good decision that I stand by.

My next principle is being humane. The interview process is stressful and I want to treat candidates well and with respect at every stage. Even if they’ve been rejected, I want them to feel good about the process. Let's be honest, sometimes there's just a mismatch of skills - I've said no to some really great people.

(Interviews should be friendly and humane, not an interrogation or a stress test. Image credit: Noh Mun Duek, license: Creative Commons, source: Wikimedia Commons.)

The hiring process

The job ad

I like to think very carefully about the wording of the job ad. It has to excite and attract candidates, but it also has to be honest and clear about the job.

I've had a few candidates who've misunderstood the job and that's become clear at the screening interview. To stop this from happening, I've sometimes created a longer form job description I've sent to candidates we've selected for screening. The longer form description describes more about the role and provides some background about the company. Some candidates have withdrawn from the process after seeing the longer form description and that's OK - better for everyone to stop the process sooner if there's no match.

Resume selection

This is an art. Here are some of the factors I consider for technical positions.

• A Github page is real plus. I check out the content.
• Blog posts (personal or company) or content for marketing is a plus.
• Mention of methods and languages. Huge shopping lists of languages are a bad sign. I also want to know what they've done with languages and methods.
• Clear descriptions of what they've done, with a focus on the technical piece. I prefer straightforward language.
• Training courses. Huge shopping lists are again a no for me.

I don't tend to select on the college someone went to but I know lots of organizations that do.

The screening interview

The first interview is a screening interview with me as the hiring manager. I do this via video call so I can get a sense of the person’s responses and their ability to interact. I always have a script for these calls and always follow the same process. I work out the areas I want to talk about and create the best questions I can to differentiate between candidates. The script gives me a more consistent (and fairer) way to compare candidates and also enables me to learn what works and what doesn’t. For example, if candidates find a question confusing, or everyone answers a question well, I can change the question. For behavioral questions, I ask for examples of the behavior and my technical questions are usually about experience. Here are some examples:

• Can you give me an example of how you dealt with conflicting demands?
• Can you tell me about a time you managed an underperforming employee?
• What’s the largest program you’ve written?
• What are the biggest limitations of Python?

These questions are launch points for deeper discussions.

The technical screen

Next comes a technical screening. Again, this must be the same for all candidates. It must be fair and allow for nervousness. 

I'm very careful about the technical questions that my interview team asks. I make sure that people are asked relevant questions that reveal the extent of their knowledge and skills. For example, if my team were interviewing someone for a machine learning position, I would ask about their use of key libraries (e.g. caret), but I wouldn't ask them about building SVMs or random forest models from scratch unless that's something they'd be doing.

Cultural fit and add

Finally, there are in-person interviews. I like to use teams of two where I can so two people can get a read. Any more than two and it starts to feel like an interrogation. Each team has a brief for the areas they want to probe and a list of questions they want to ask. 

Team selection is something of an art; I’ve known interviewers who are unable to say ‘no’ to any candidate, no matter how bad. If I have to include someone like this on the interview team, I’ll balance them with someone who can say no.  

I’ve heard of companies doing all-day interviews, but this seems like overkill to me and it stresses the interviewee; there’s a balance here between thoroughness and being human. For in-person interviews, I ensure that every team offers the candidate a drink or time out to visit the restroom. 

Where I can, I have the very last interview as a discussion with the candidate, asking them what went well and what went badly in the process. Sometimes candidates answer a question badly and use the discussion opportunity to better answer the question. Everyone makes mistakes and interviews are stressful, it seems like a good opportunity to offer the candidate a pause for reflection and an opportunity to correct errors.

I always look for the ability to work well with others and I value that over technical skills. A good technical person can always learn new technical skills, but it's very difficult to train someone not to be a jerk.

Decision making

Before we go to a decision, I find people the candidate may have interacted with who are not on the interview team. Many times, I’ve asked the receptionist how the candidate treated them. On one occasion, a candidate upset the receptionist so badly, they came to me and told me what had happened. It was an instant ‘no’ from that point.

To decide hire or no hire, I gather the interview teams together and we have a discussion about the candidate. If consensus exists to hire, most of the time I go ahead and make an offer but only after probing to make sure this is a considered opinion of everyone in the room. On a few occasions, I’ve overruled the group and said no. This happens when I think some factor is very important but the group hasn’t considered it well enough. If the decision is a uniform no, I don’t hire. I reserve the right to overrule the group, but it’s almost inconceivable I’d overrule a uniform no. If the view of the group is mixed, I probe those in favor and those against. In almost all cases where views are mixed, I say no - this is part of my default ‘no’ position.

The benefits

I know this process sounds regimented, but there are important benefits. The first is fairness for candidates; everyone is treated the same and there’s a consistent set of filters. The second is learning; if the process is wrong or has failed in some respect, we can fix it. Thirdly, the process is inclusive - the team has a huge say in who gets hired and who doesn’t.

If hiring and retaining good staff is important, then it’s important to have a fair, decent, and thorough hiring process. Through years of experience, I’ve honed my process and I’ve been pleased that the companies I’ve worked for have all had similar underlying processes and similar principles.

Good luck

If you"re searching for a job, I hope this post has given you some insight into a hiring process and what you have to do to succeed. Good luck to you.

Blame free learning

What is blame-free learning?

I’m going to suggest something that’s going to sound innocuous but is a radical and a major departure from the way many organizations are run. I’m suggesting a blame-free learning approach to deal with business failures - I’m advocating it at the corporate level and the personal level.

Here’s what I mean by blame-free learning:

• After some bad event, the team of people involved meets to hold a post-mortem review.
• The team reviews what happened dispassionately, without pointing the finger at anyone. The team produces a shared narrative of what happened that’s factual and not value-based.
• The team comes up with changes to existing processes to prevent a re-occurrence. No blame is apportioned.

Blame-free learning means approaching a failure with a spirit of solving the problem and preventing its re-occurrence, not finding blame. It’s about learning from what’s happened and not repeating it, all without finger-pointing. Blame pits people against one another, shuts down thinking, and creates a conservative and closed mindset. Blame-free learning means people can work together to resolve problems, it also means no one gets off the hook.

Projects gone wild

Let me give you an example of a project gone wrong and two different responses.

A company is bidding for a large contract. To win the contract, the engineering team needs to make some changes to the product, the QA team has to test the product, and the data team has to supply the test data. Unfortunately, the engineering team deprioritized the work, leaving it to the last minute. The QA team manager got sick and didn’t delegate the task. The data team had scheduled a data migration just at the time when they needed to pull the data for the test. Finally, the salesperson had to attend a family wedding so couldn’t submit the RFP on time. The company loses the contract.

In a case like this, you might expect a post-mortem review to examine what happened (many companies don’t even do that). The post-mortem review could easily degenerate into finger-pointing with the most politically powerful group pinning the blame on the least powerful. It’s the search for a scapegoat. Everyone walks away aggrieved, knowing that this will probably come up in performance reviews later. Human relationships are damaged.

(Most project post-mortems are fights for blame. Image credit: Old Book Illustrations - Image in public domain)

A blame-free learning approach refuses to apportion blame, but rather focuses on changes to the process and preventing the problem from recurring. The first step is to develop a shared narrative of what happened. This should be factual and neutrally written. In the example I gave you above, it might say “The QA Team Manager allocated the work to himself, but before he could execute it, he became sick and couldn’t work on the project. Because he was sick, he couldn’t delegate the work.” Participants in the post-mortem are forbidden from blaming anyone but instead are encouraged to think about how the problem can be avoided in the future - by changing processes for example. The result of the post-mortem might be instructions to managers to improve communications, proper setting of priorities, some overall project management, etc.

Heathrow Terminal 5

A version of this approach was used for the construction of Heathrow’s Terminal 5 building [OECD]. Typical large construction projects can end up quite adversarial, with the contractors pitted against project management to apportion blame and extract extra money. Heathrow airport’s operator, BAA had conducted research that indicated that no construction project of this size had been completed on time in the UK, the safety record of these types of projects were poor, and that quality standards were often not met. To get the project done on time, and on budget, BAA did things very differently. The contract had BAA assuming the risk, but with contractors incentivized to solve problems not engage in finger-pointing. Importantly, profits were negotiated and baked into the contract which meant that if a problem occurred, the contractors were incentivized to fix it quickly and maintain their profit margin rather than arguing. An issue with the air-traffic control tower construction illustrates the point. The steel towers were out by 9mm, but instead of blaming each other and litigating, the contractors were incentivized to work together to find a solution, which they did [Gil]. The construction work was completed on time and on budget.

Bureaucracy and fear

I worked in a company with a very formal review system. Someone in a different group applied a process very rigidly and blocked my group from moving forward on a project. They wouldn’t budge and wouldn’t explain why. I had to escalate my issue to move my project forward, which we did. What happened next was enlightening. The person who wouldn’t budge came to see me and explained what was going on. They told me they had previously been marked down in the performance review system for being too flexible so they were scared of allowing any deviation from the process and that’s why they had stopped my project. They came to see me because they were terrified that they would be blamed this time for not being flexible - they begged me not to take the issue further. I told them I wasn’t out for revenge and I would drop the issue - the person looked immensely relieved. Blame was a huge part of the performance review system; it was effective at establishing control but hopeless at innovation and flexibility. My colleague learned one thing from the entire process: fear. They did change their process after this, but only just enough to let my project through, they stayed rigid, just in another way.

With blame-free learning, this would have played out differently. The person would have still blocked my project and I would still have escalated to get things moving, but my colleague wouldn’t be afraid of the review system and we could have had a constructive post-mortem review of how the process could be changed; maybe with a more flexible process that might have retained the original process goals but let other projects through as well as mine. We would all have walked out of this with good working relationships intact.

But what if I can't get everyone's buy-in?

You can do blame-free learning on your own. In fact, this might be the most productive way to do it. Imagine you have some kind of bruising experience at work, for example, a project was late or delayed or some other bad thing happened, also imagine there were several other parties involved, with a lot of blame to go around. You’re hurting and you want to lash out, so you blame others - which may well be correct, but it’s unhelpful. By blaming others, even if you’re correct, you lose the opportunity to learn. Here’s what I suggest in this case:

• Wait until your anger/frustration subsides. You have to be calm for this to work.
• Think through the situation as if you were an outsider and construct a neutrally worded description. No loaded phrases (‘he should have...’). If you can’t do it with neutrality, you may need to let more time pass to calm down and gain perspective.
• With all the knowledge you have now, think about what you could have done differently. It’s only about you, not anyone else.

Yes, this is hindsight, but it’s not about apportioning blame to you, it’s about learning what you could do better in the future. You have the knowledge now that you didn’t have before, so you should be able to do things better. This is all about figuring out what you can do to change you.

Get started

Implementing something like blame-free learning can be very hard across multiple groups, but it's easier to start within a single group. Even easier to start with yourself.

References

[Gil] https://personalpages.manchester.ac.uk/staff/nuno.gil/Teaching%20case%20studies/BAA%20T5%20Agreement%20.pdf

[OECD] https://www.oecd.org/governance/procurement/toolbox/search/allocation-risks-during-construction-heathrow-airport-terminal-5.pdf

Serial killer! How to lose business by the wrong serial numbers

Serial numbers and losing business

Here's a story about how something innocuous and low-level like serial numbers can damage your reputation and lose you business. I have advice on how to avoid the problem too!

(Serial numbers can give away more than you think. Image source: Wikimedia Commons. License: Public Domain.)

Numbered by design

Years ago, I worked for a specialty manufacturing company, its products were high precision, low-volume, and expensive. The industry was cut-throat competitive, and commentary in the press was that not every manufacturer would survive; as a consequence, customer confidence was critical.

An overseas customer team came to us to design a specialty item. The company spent a week training them and helping them design what they wanted. Of course, the design was all on a CAD system with some templated and automated features. That's where the trouble started.

One of the overseas engineers spotted that a customer-based serial number was automatically included in the design. Unfortunately, the serial number was 16, implying that the overseas team was only the 16th customer (which was true). This immediately set off their alarm bells - a company with only 16 customers was probably not going to survive the coming industry shake-out. The executive team had to smooth things over, which included lying about the serial numbers. As soon as the overseas team left, the company changed its system to start counting serial numbers from some high, but believable number (something like 857).

Here's the point: customers can infer a surprising amount from your serial numbers, especially your volume of business.

Invoices

Years later, I was in a position where I was approving vendor invoices. Some of my vendors didn't realize what serial numbers could reveal, and I ended up gaining insight into their financial state. Here are the rules I used to figure out what was going on financially, which was very helpful when it came to negotiating contract renewals.

• If the invoice is unnumbered, the vendor is very small and they're likely to have only a handful of customers. All accounting systems offer invoice generation and they all number/identify individual invoices. If the invoice doesn't have a serial number, the vendor's business is probably too small to warrant buying an accounting system, which means a very small number of customers.

• Naive vendors will start invoice numbering from 1, or from a number like 1,000. You can infer size if they do this.

• Many accounting systems will increment invoice numbers by 1 by default. If you're receiving regular invoices from a vendor, you can use this to infer their size too. If this month's invoice is 123456 and next month's is 123466, this might indicate 10 invoices in a month and therefore 10 customers. You can do this for a while and spot trends in a vendor's customer base, for example, if you see invoices incrementing by 100 and later by 110, this may be because the vendor has added 10 customers.

The accounting tool suppliers are wise to this, and many tools offer options for invoice numbering that stop this kind of analysis (e.g. starting invoices from a random number, random invoice increments, etc.). But not all vendors use these features and serial number analysis works surprisingly often.

(Destroyed German Tank. Image source: Wikimedia Commons. License: Public Domain)

The German tank problem

Serial number analysis has been used in wartime too. In World War II, the allied powers wanted to understand the capacity of Nazi industry to build tanks. Fortunately, German tanks were given consecutive serial numbers (this is a simplification, but it was mostly true). Allied troops were given the job of recording the serial numbers of captured or destroyed tanks which they reported back. Statisticians were able to infer changes in Nazi tank production capabilities through serial number analysis, which after the war was found to be mostly correct. This is known as the German tank problem and you can read a lot more about it online.

Simple things say a lot

The bottom line is simple: serial numbers can give away more about your business than you think. They can tell your customers how big your customer base is, and whether it's expanding or contracting; crucial information when it comes to renegotiating contracts. Pay attention to your serial numbers and invoices!