Moving From Overwhelm to Breakthrough

Not long ago, I had a meeting with my boss, who also happens to be one of my mentors, and after some other discussion asked him one of my favorite open-ended questions:

What should I be thinking about that I’m not yet?

After a few moments of thought, he started drawing a diagram that I’ve roughly recreated below:

work and impact

He highlighted that I, and many of our team, are operating in the middle area on this graph.  We’re working hard, we’re efficient, and we’re getting a lot done.  We feel like we’re just barely keeping up, but we are keeping up and we’re making serious progress.  He also pointed out that some of our team members who’ve struggled, and sometimes left, got stuck in the left hand side of the graph, feeling like they were pouring work in and never able to get ahead.

Then he challenged me.

I want you to figure out how to get you and everyone on your team over into the right side of this graph.

Moving from Holding On to Breaking Through

Operating on the right side of the graph means getting more impact for less effort.  It means optimizing not just for efficiency but for effectiveness.  It means rethinking goals and tasks to create radically different strategies.  Lets take a look at what this can mean in different areas.

Breakthroughs in Software Engineering

Breaking through in engineering means finding ways of overcoming the ‘Not Invented Here’ syndrome and leveraging existing tools and libraries.  It means boiling things down to the root of the problem and creating radically less code to solve the same number of problems.  It means learning and using the most efficient frameworks and investing time and energy in your tooling.  It means automating your tests, streamlining your deploys, and biasing every project towards creating something that can be reused and repurposed.

Breakthroughs in Customer Support

Breaking through in customer support means finding ways to move from the 1 plus 1 plus 1 model of supporting customers to a leveraged and scalable one.  It means taking problems that come up over and over again and writing documentation that clearly resolves them.  It means taking a set of individual customers and creating a place where they can converse, create community, and help solve each others problems.

Breakthroughs in Marketing

Breaking through in marketing means turning your best customers into your best evangelists. It means empowering others to write your content, spread your message, and bring new people into the fold.  It means finding creative ways to connect and reuse your content and materials across multiple mediums and locations.  It is creating self-perpetuating material that engage people, causing them to interact and create new material that further engages people and spins up the marketing flywheel.

Breakthroughs in Management

Breaking through in management is successfully engaging in this exercise with each of your team members.  It is moving away from making sure tasks get done and moving towards reimagining productivity and effectiveness.  Away from keeping checklists and towards teaching and mentoring.  In essence, away from management and towards leadership of empowered team members that self-manage.

Where else can we break through?

As I’m mulling on this more and more, I find myself wondering how I can apply this perspective to other parts of my life.  What does breakthrough parenting look like?  I live my parenting life somewhere between the left and middle of this spectrum, more often on the left.  What does breakthrough fitness look like?  Breakthrough relationships?

Leave me a comment, I’d love to engage on these ideas.

Technical Leads

The skills that it takes to become a good engineer are not the same as what it takes to lead a team.

Let me tell you about a situation that I saw unfold before me recently. I’ve been consulting at Sony Electronics with a web software group there. The team lead was about to leave for a new position, and they had selected a successor, who I’ll call John. John is an excellent software engineer – he
regularly tackled challenging problems, was involved in architectural decisions, had demanding standards in code reviews, and was clearly the most senior full time engineer remaining on the team. Besides, except for me, and I was a part time consultant, no one else seemed even remotely ready.

John was interested in the new responsibility – it seemed like the next step in his career, not quite in management but starting to assume a leadership role – and while he was anxious about it he agreed to take it on. There were a few weeks remaining before the prior team lead was going to leave, so the plan was to transition him gradually, having him take on more and more responsibility over the next few weeks.

The challenges started almost immediately. Asked to lead a technical meeting to come up with a proposal, John faltered. He opened with a long rambling monologue that left noone in the room certain about what was trying to be accomplished. As he called for participation, there was first silence, then disjointed conversation. Eventually, his manager and myself spoke up to help guide the meeting and get it back on track. This would have been fine, had John been open to feedback about how to improve, but either due to defensiveness or due to a feeling that he had all of the skills he needed, he wouldn’t or couldn’t hear it.

The issues continued with additional meetings – when we met with the product owners to figure out details of the next release, John sat through the meeting saying very little. Questions about details, give and take about technical vs business tradeoffs, push back against irresponsible features, it all fell to other members of the room. When asked about it later he said that it was a ‘business’ meeting, and he wasn’t sure what to say.

The skills that it takes to become a good engineer are not the same as what it takes to lead a team.

This situation didn’t end well – after a few weeks of this, with the old team lead about to head out and the management feeling desperate, I was asked to co-lead the team with John. We worked together reasonably well, but it was always a little awkward and several months later he left the company for another position – purely technical – in the bay area.

With this experience freshly in mind, I’m now working to train the next team lead before I wrap up my time consulting with Sony. But it got me thinking about the skills that it takes to be an effective technical leader. They’re learnable, many of them are actually fairly concrete, but they’re not the same skills that it takes to become a good engineer.

I’ve learned them in a combination of being mentored, years of Toastmasters, and trial by fire as a startup CTO. But I wonder… where do we expect engineers to learn them? And from what I’ve seen, good team leads are even more rare than good engineers, so why aren’t we being more deliberate about training them?