Need someone to lead product or development at your software company? I lead product and engineering teams and I'm looking for my next opportunity. Check out my resume and get in touch.

A framework for onboarding new employees

May 15, 2020

When hiring new employees the process of getting them ready to be productive members of the team is usually arbitrary and disorganized. The HR process of getting payroll and benefits set up may be effective, but training someone in the way the actual work happens is not. Most of the time onboarding consists of, "Chuck will show you what you need to know." Chuck isn’t given any guidance to follow, and every new employee gets trained differently.

To learn how to cook hamburgers at McDonald’s, a new employee watches several hours of video, then gets a hands-on demonstration, and finally cooks a few burgers while someone monitors. When we hire someone to build complex software products, the onboarding process is, "You’re smart, I’m sure you’ll figure it out."

Running a good onboarding process is essential to making sure new employees are productive, satisfied, and effective.

There’s no single good way to onboard an employee. The details of the role, the company, and what makes for an effective teammate differ. Instead of One True Process, here’s a framework for creating one that you can adapt to each situation.

Read more »

TV hosts as a guide for software managers

May 10, 2020

I’ve been watching master interviewers recently and thinking about them as a model for what a software manager should be doing. Late night TV hosts and long-form journalists like those on 60 Minutes are fantastic interviewers and great models of how to lead a software team.

tv interviewer

A good interviewer doesn’t lead the discussion. He doesn’t tell the subject what to talk about. He understands that the subject is the focus, the expert on the topic.

She knows her audience, and helps the interview subject know them too. She gives context about what the audience will like, what has worked and hasn’t worked in the past. She guides the interview keeping it focused and from running too far off in tangents. She looks for nuggets that might be interesting to explore further and encourage that exploration.

She keeps track of time, so the person they’re interviewing doesn’t have to. Instead of a list of topics to check off in a certain amount of time, she has an overall goal for the interview, and an outcome to guide it towards. If time becomes tight, she will find ways to focus the remaining time on the most important things.

An interviewer produces bad interviews when he thinks he is there to be in charge, to run the interview. When he sticks to a rigid schedule, and ensures that he asks and gets answers for the list of pre-defined questions in a pre-defined order, the quality suffers. The answers are unpredictable so the rigid schedule predictably gets off track. Some topics end up rushed, especially those toward the end, and there’s no time to explore an interesting topic discovered during the course of the interview.

The interviewees come away dissatisfied. They weren’t there to think, they were there to implement someone else’s ideas.

Many software managers think that the job is to run the development process. Define a list of requirements. Turn those into tasks. Enforce discipline so that each and every task gets done on a predictable schedule to meet the estimates.

This turns out like those pre-scheduled rigid interviews. Tasks at the end get rushed, and done poorly. Discoveries along the way don’t get explored. The product might meet all the requirements, but there’s no soul to it. It’s mediocre and probably poor quality.

The team is dissatisfied. Instead of thinking and solving problems, they were a task machine, taking someone else’s ideas and implementing them on someone else’s schedule.

Whether she’s in a management position over the team or a product manager responsible for creating a product with a development team, a great software manager acts more like a great interviewer.

She doesn’t jam every minute of every day with pre-planned work, knowing that slack time is important both because of the unpredictable time required for the work. She knows that the team will discover new interesting ideas as the product takes shape and she makes sure the team will have time to explore those. She doesn’t act as the time-keeper, enforcing time boxes, but instead gently guides the team into making sure the most important work gets done in the time available.

A great manager is a facilitator and moderator. He’s not the owner of the team, or the most important among them, or the task-master.

He comes with the context and understanding of what the customer needs, and what the team goals are. He makes sure the team keeps all those in view, and gently guides discussions and explorations in that direction. He looks for interesting patterns and options to explore that further those goals, and steers the team away from irrelevant tangents.

A great manager provides guide rails from within which a team can explore safely. She’ll help the team stay on track, not because she needs to enforce some notion of control and schedule, but because she can free the team to be better when they don’t have to think about things like schedule and which metrics they’re chasing. She can keep track of those, and provide nudges and reminders to keep things moving in the right direction.

The best interviewer is invisible, measured by the impact of the resulting interview. No one measures him by how much he knows about the topic or how many questions he got through or how well he kept to the schedule.

The best managers are those whose teams have the biggest impacts.

The Improvement Flywheel

April 29, 2020

Improvement flywheel system diagram

A few weeks ago on Twitter, John Cutler posted what he called "the wicked loop" of product development problems.

A team doesn’t execute well, which leads to pressures to deliver things faster. Those pressures come from both inside and outside the team.

Read more »

Managers and technical ability

December 26, 2019

There’s a belief in the software development world that you can’t manage developers unless you’ve been one yourself. This often gets reduced to the shorthand that some manager "isn’t technical."

We say someone is "technical" or "not technical" as if this is a binary choice. In reality, it’s a giant scale. I spent much of my career as a developer before shifting to product management. Twenty years ago I wrote a web server and a database engine. I was CTO at two of my companies. I barely understand the basic concepts behind Kubernetes.

Am I technical?

It’s clear that I was technical. But am I still? Is "being technical" something you lose over time? If "technical" is a scale, am I technical enough?

Lisa used to be a network administrator and now is a development manager. She can still design and troubleshoot a network, so she’s clearly "technical." She told me that she’s struggling as a development manager and thinks it’s because she wasn’t ever a developer.

There was a study that found hospitals run by doctors perform better than hospitals run by people without medical training. It’s unlikely that doctors turned senior administrators would be able to lead a complex surgical procedure or would be up on the latest treatments for specific illnesses. Their medical skills and knowledge would be too rusty to be effective. Being a manager of doctors is a completely different career than being a doctor was and managing is now their primary skillset. Then what makes doctor-run hospitals better?

Being familiar with what it’s like to be a doctor is what leads doctor-managers to do a better job running hospitals. They know what it’s like to do the work, they understand the challenges, the tradeoffs, and the decisions that face doctors daily. This is they are better at leading other doctors.

The best development managers are former developers themselves because they understand what goes into developing software. It’s not because you need to be the technical expert to lead developers. But because you need to understand what it is like to be a developer.

This is why Lisa is struggling. She has a technical mind and understands technical concepts, but she has no frame of reference when her team is deciding the tradeoffs between two design options.

I suspect this translates beyond "developer" or "not developer" as well. Someone that has spent their entire career developing web applications won’t understand the things that make writing embedded firmware unique. Putting a web developer turned manager in charge of a firmware team would have the same problems that a network admin managing the team has.

A surgeon likely wouldn’t make a good manager of virologists.

The further up the management ladder you go, the less you get involved in domain-specific things, so the less your specific domain will matter. The surgeon that can’t manage a virologist team could lead a cross-functional group of teams, even when that includes virologists.

I don’t need to know Kubernetes to lead an ops team. I don’t need to know ops to lead an organization that includes an ops team. It’s enough that I can grasp any high-level technical concepts if someone in my organization needs to explain them to me.

Managing developers requires you to be a specialist. Managing development managers requires you to be a generalist. The closer you are to the people doing the work, the closer your skills need to resemble those of the people doing the work. It’s not a matter of "being technical."

Dysfunctions of output-oriented software teams

September 17, 2019

When I see ineffective product teams, it almost always stems from a focus on delivering features instead of delivering value to people. From sales to marketing to product to engineering, they are more focused on output than they are on outcomes. They ask, "did we ship that feature" more than "did we and our customers achieve better outcomes?" No one asks if what the team is doing is really working.

John Cutler calls this a Feature Factory. Melissa Perri calls it the Build Trap. Whatever you call it, the symptom is that you’re measuring your progress by how much you build and deliver instead of measuring success by the amount of customer value you create.

An output-focused team doesn’t measure the actual impact of the work, doesn’t know what metrics are important, and can’t connect the product work to the whatever core metrics they actually do have.

Instead of metrics and objectives, they have deadlines and customer commitments. They can’t cut committed scope to meet these deadlines so they cut quality. They still miss the due date, and now have a product that is both bad and late. Other departments berate the developers for not providing more accurate estimates. No one ever asks why the word "estimate" means "commitment" in this team.

To fit things into the schedules and meet the estimates-turned-commitments, managers come in to assign and track tasks. The output-focused managers are more concerned with "resource utilization" as if the people building the product are machines. They don’t have well-integrated teams, leading to frequent handoffs between people, and siloing of knowledge and responsibility. Those handoffs lead to backups and gaps in the schedule, so they play team Tetris to try and keep developers busy, which makes the problems worse.

When an output focused team tries iterations, they defer important things to "later." Everything is pre-planned months in advance, they’re at full "resource allocation," and they’re always late with every iteration. So later never comes.

The managers try to fix all this by adding more top-down process, bogging down the teams. Things slow down, so the managers add more process to fix it and "hold engineers accountable."

How do you escape this method of working? Take small steps and look to continually improve. Start by defining success through outcomes and deciding up from what measurements will indicate you have reached those outcomes.

Accept that it’s OK if you aren’t always busy. Slack in the schedule is healthy and helps give time to explore and experiment. If you’re not focused on being busy all the time, you’ll be able to think more about creating a flow of value to the customer. Above all, empower people. Trust that the smart, capable people you’ve hired will do the right thing. Try managing through Commander’s Intent: define what success looks like, and then let them figure out how to get there.

Evaluative and generative product development

August 30, 2019

When planning a product, a common statement (normally from someone in a sales capacity) is “I haven’t talked to any customers that ask about X.” That may be true, but what about the potential customers that you aren’t talking to?

In the field of user experience there’s a concept of Evaluative vs Generative research. Evaluative is “which of these ideas that we already have are the best options?” Generative is “what are the ideas we have not thought of?”

The two approaches provide different outcomes. Neither outcome is better than the other, and both are usually needed to create a quality experience.

The needs of your customers and the overall market for your product can be thought of the same way. Entirely determining the product from evaluative customer feedback yields one sort of product. "Of the customers that are already finding us, what are their market needs?"

Think about when you go looking for a product to solve a problem for you. You do a sorting exercise and put products into "might do what I need" and "doesn’t fit my needs at all" as a first pass.

Customers never even talk to the companies that don’t fit their needs at all. If the only product ideas you’re considering are those that meet the needs of your current customers, then you’re only going to find new customers that look exactly like your current customers. You’ll completely miss out on adjacent customers.

To expand your market beyond your existing customer profile, you need generative product development. You need to explore product ideas outside of what you’re currently thinking of. Outside of what your existing customers are asking for.

A generative approach asks “what needs could we meet that would help new customers find us?”

Entirely using generative product creation isn’t a great idea unless you don’t have any existing customers. Your existing customers have needs and ideas and can be telling you which of the ideas you have now are most valuable.

Different stages of a product need different balances between generative and evaluative product creation. Mature products in a large market where sales are mostly driven by outbound sales and marketing will need a very different approach than a well-funded startup product that is still learning what their market is and can burn cash to learn. A company optimizing for short-term revenue will lean toward an evaluative approach, and one investing in future revenues will lean toward a generative approach.

But regardless of the way you’re leaning, you need to balance evaluative customer feedback with some generative product growth.

Recently Written

A framework for onboarding new employees (May 15)
There’s no single good way to onboard an employee that works for every role. Here's a framework for creating a process that you can adapt to each situation.
TV hosts as a guide for software managers (May 10)
Software managers can learn a lot from journalists or late night TV hosts and how they interview people.
The Improvement Flywheel (Apr 29)
An incredible flywheel for the improvement of a development team. Fix a few things, and everything starts getting better.
Managers and technical ability (Dec 26)
In technical fields, the closer you are to the actual work being done, the closer your skills need to resemble those of the people doing the work.
Dysfunctions of output-oriented software teams (Sep 17)
Whatever you call it, the symptom is that you're measuring your progress by how much you build and deliver instead of measuring success by the amount of customer value you create.
Evaluative and generative product development (Aug 30)
Customers never even talk to the companies that don't fit their needs at all. If the only product ideas you're considering are those that meet the needs of your current customers, then you're only going to find new customers that look exactly like your current customers.
Product Manager Career Ladder (Aug 19)
What are the steps along the product management career path?
Building the Customer-Informed Product (Aug 15)
Strong products aren't composed of a list of features dictated by customers. They are guided by strong visions, and the execution of that vision is the primary focus of product development.

Older...

What I'm Reading

Contact

Adam Kalsey

+1 916 600 2497

Resume

Public Key

© 1999-2020 Adam Kalsey.