How to lead a software team when you have no idea what they’re talking about

It’s not easy committing resources to a digital product without having at least some technical background. What if you have no technical background at all?

The team may assure you:

• “6 months, max.”
• “It’s better to rewrite this.”
• “This is the way Google does it.”

What should a non-technical stakeholder ask before giving the green-light to a new, costly investment of developer time?

Here are a few questions any stakeholder can ask, regardless of their technical experience level.

Always Review Alternatives

1. If another team evaluates this, what criticisms are they going to raise?
2. What alternatives did you consider before leading with this proposal?

Why these are good questions:

If a competent technical team is making a proposal, they should be able to outline reasonable alternatives, as well as the cost/benefit analysis that went into their final recommendation. Sometimes a team will look with starry-eyed optimism at a shiny new technology, or they’ll underestimate the depth of complexity in their own legacy systems.

You’re not allocating yesterday’s time and money, you’re deciding between the possible futures. Any proposal can look good when compared to what you’ve got today.

Engineers like to estimate all the time they’ll save, or how decoupled their new project will become, or how much easier it will be to find bugs, or to push features, or to scale. Perhaps a more modest, less risky alternative isn’t quite as exciting, or given to green-field development. A fully considered technical proposal should speak fairly of other options in the solution space.

Show Your Short-Term Validation Preference

1. I understand that any project can encounter unforeseen problems. I’m willing to be flexible and change course when presented with new information. What can we agree to measure on a weekly basis to track our progress together?
2. I care most about these measurable outcomes: [user feedback/stability/features/etc]. What weekly progress metric(s) can you offer to track that will demonstrate value in those areas, and how soon can we start?

Why these are good questions:

You need short-term, ongoing validation metrics. A highly experienced team with capable engineers should also want to validate their own strategy. Is this working? Are we running into unanticipated issues?

This also communicates your understanding that building products requires flexibility. Engineers know that business priorities can change quickly based on competitive pressures, so give them the same license to react and change when presented with new information.

Prefer Utility Over Scale

1. This product is too large to commit to an overhaul in one stroke. Can you propose a low-risk, small area of the application in which to prove out your ideas?
2. It’s important to get real-world validation as soon as possible. That would allow us to change course without having to commit to large-scale changes. What measurable quantities would you like to track within the first trial run?

Why these are good questions:

Projects with grand-scale aspirations fail at an alarming rate, and of the projects that do reach grand scale, virtually none of them began with scale as their primary target.

Do not fall into the scale trap. These questions force the real issue: if the plan is wide-reaching change, you must insist on small-stakes validation. Few systems are so beyond repair that changes can’t be made incrementally.

(As an aside, sometimes you’ll hear a developer say they like working on hard problems. Try asking a clarifying question: In a brownfield codebase, right? Oh, you meant not that hard?)

Without a technical background, business decisions related to digital products will involve a base level of trust. Still, using these questions can help direct product development in accordance with business goals, while being respectful of the challenges. And crucially, these questions also increase team trust — trust that both the non-technical and technical parties are willing to compromise approach in an effort to not compromise on outcomes.

• Collin Flynn

  Principal Software Engineer

  More from Collin