What I Learnt Building My First Engineering Team at Motorola

In 1997 I was promoted from senior developer to engineering lead at Motorola. I was twenty-five, had been writing code for three years, and had no formal management training. The team was six people. Here is what I learnt in the first eighteen months.

The Transition Nobody Prepares You For

The hardest part of becoming a manager as a developer is the identity shift. For years, your value was measured by what you personally built. Now it is measured by what the team builds. Your direct output drops to near zero. Code you would have written in a day now takes a week because you are interrupted constantly.

Most new technical leads respond by continuing to code heavily and neglecting the management work. I did this for the first three months. The result was that individual contributors were unblocked when I was available and blocked when I was not — I had made myself a bottleneck.

The shift that fixed it: I stopped thinking of myself as a developer who also managed, and started thinking of myself as someone whose job was to remove obstacles and make the team faster. My code was less important than their unblocked time.

Hiring: The One Decision That Compounds

I made two hires in the first year. One was excellent; one was a poor fit for the role. The excellent hire made the whole team better — she raised the standard for code quality, asked the questions nobody else was asking, and took ownership without being asked.

The poor hire consumed more of my time than all the rest of the team combined. I spent months trying to coach him to a standard he was not going to reach, deferring the conversation I should have had earlier.

The lesson I took: hire slowly, be honest about standards, and address mismatches early. A team of five high performers outperforms a team of eight average performers. Holding a role open is almost always better than filling it with the wrong person.

What "Technical Leadership" Actually Means

Before the promotion I thought technical leadership meant making the architectural decisions and being the best coder. In practice it meant:

Setting and maintaining standards. Not by dictating them, but by being explicit about what good looks like, modelling it in my own work, and addressing gaps through code review and direct conversation.

Making the implicit explicit. Assumptions that exist only in one person's head create risk. Who owns the deployment process? What is the definition of done? What do we do when a production incident happens at 2am? Writing down answers to these questions took time but eliminated recurring confusion.

Protecting the team's focus. Interruptions from other teams, scope creep, unrealistic deadlines — a large part of my job was absorbing or redirecting pressure so the team could work without constant disruption.

Communicating upward. My manager needed to know what the team was delivering, what the risks were, and what was blocked. This was not natural for me — I had spent three years with my head down writing code. Learning to communicate status clearly and proactively to management was one of the more important skills I developed.

One-on-Ones

I started doing weekly one-on-ones with each team member about six months in, after a developer handed in his notice citing a lack of career direction. I had not known he was unhappy.

The format was simple: 30 minutes, weekly, their agenda not mine. I was there to listen, not to give status updates. What was frustrating? What did they want to learn? Where did they want to be in two years?

The information I got from these conversations was more useful than anything from team meetings. Problems surfaced before they became incidents. Good people told me what they needed to stay.

The Mistake I Made Most Often

Moving too fast. Making a decision when I should have slowed down and got more information. Resolving a conflict between two team members by taking a side rather than understanding both positions fully.

Speed was valued at Motorola. Fast decisions, fast delivery. I over-indexed on speed at the expense of correctness. The decisions I got wrong cost far more time to fix than the time the fast decision saved.

The reframe that helped: a decision I make in five minutes that turns out to be wrong will cost the team two weeks. Taking an extra day to get it right is almost always the better trade.