No matter what my role is within a company, I want to work in an empowered, trusted, team that works together to deliver things we can all be proud of.

Old-fashioned “command and control” hierarchies or completely misunderstood applications of agile have caused misery for people working under them, and do not result in successful products. I want to avoid working in those kinds of environments.

These questions won’t always be relevant for every company. A 2-person startup probably doesn’t have the notion of a product owner (the 2 people are implicitly the POs!) but I feel the principle of most of these questions stand.

Who decides priority of work?

Ideal answer

A product owner, guided by research and UX practitioners, assigns hypothetical value to stories — but the team decides what to work on, so they can decide how best to deliver value. That might include playing spikes, addressing technical debt etc.

It should be a collaborative relationship between product people and engineers.

Warning signs

Teams with no autonomy eventually fail. Software engineers are paid the mega-bucks to solve problems, not blindly work through tickets. Without autonomy the wrong things are prioritised, productivity tumbles and systems will fall apart.

• PO as manager
• Feature factories
• Spiralling technical debt
• Bad relationship between engineering and product

How are users’ problems solved?

Ideal answer

The end user is at the centre of what the team does. User stories are user stories, a brief amount of text trying to convey what problems the user is trying to solve and why.

People from all disciplines get together, discuss it, figure out what needs to be done to try to solve the problem and figuring out ways to know if we’ve succeeded. Ideas include,

• UX team reaching out to users for interviews
• Developers creating cheap prototypes along with thinking about possible long-term solutions
• The team going back and admitting that they don’t understand the problem rather than just blindly building something
• A story typically is not finished with a release of software. Many iterations are made to gather feedback to learn how to solve the problem better for the user.

This style of working gets everyone invested in the project and feeling involved.

This environment is where real innovation comes from because smart people have a better understanding of the domain and have the space to solve real problems.

Warning signs

A select group of individuals looks at user’s problems and generate numerous tickets in JIRA for technical people to administer. Developers have little to no idea the purpose of the work and cannot offer feedback on what is being worked on.

• Story robots
• Feature factories
• Bad products

The tickets have very little resemblance to stories and are instead barely validated, overly specific, solutionised tasks for developers to work on.

Work “happens”, arbitrary targets met, but both users and development teams are not happy.

What’s the general makeup of experience? Do you hire many juniors? How heavily white and male is your engineering department?

Ideal answer

Hiring from a diverse range of experience gives us a diverse team, which is a good thing in terms of productivity, environment and being the right thing to do.

Seniors should feel proud to help less experienced people grow, and the juniors help challenge assumptions.

An environment of continuous learning with coaching and mentoring is just nice.

Often people who have worked for less than <5 years have had a bigger impact on me and the teams I’ve worked in than the engineers with 10 years.

Warning signs

Don’t have time to train people. What else do they not have time for? We all need training and space to think regardless of experience.

I want to work in an environment that encourages and supports people from any background. If your engineering teams do not have any female leaders for instance, that is a bad sign.

How often do you release? Who releases?

Ideal answer

Feedback loops are so important in software and product development. Whether its feedback given by customers, or realising something you’ve shipped has introduced a bug; the sooner you get this feedback, the cheaper and easier it will be to act on it.

Developers should be in charge of releasing code, and because of that they’re forced to write good automated tests and having excellent operability. They should be focused on optimising for a reliable, quick release pipeline so they can make changes to the software frequently and safely.

Product owners can be in charge of features becoming visible to users if that’s needed (e.g., use feature flags), but copying code from one server to another is a technical concern, not a product one.

You are continuously delivering code to production on green builds. This question will also tell me about your testing approach (or lack of!).

Warning signs

Manual testing

• Points to a lack of thought as to how to deploy software safely.
• Usually coincides with poor engineering, lack of automated tests begets lack of high internal quality.
• Doesn’t scale.

Gatekeeping (release managers, or some kind of sign-off step):

• Lack of trust.
• Empire building.

Lack of DevOps culture

If you have a “DevOps team” who are in charge of releasing software then I suggest you read a book about DevOps because you have missed the point. Focus on the principles, not the tools.

Do you have delivery / project managers? What do they do?

Ideal answer

Project managers (PMs) can be extremely useful with coordination across bigger sets of people, helping to understand X team dependencies. They often do a lot of “glue work” for the team to help them work more effectively.

Warning signs

"Striving to ensure that no resource be idle is the biggest generator of waste." —Eli Goldratt

PMs are incentivised to “maximise developer output” and the company has no idea what the value of slack is. If your team is always running at 100% capacity, how do you expect it to improve? Hint, repeatedly cracking a whip will not improve your team.

Slack is critical and is widely written about. It’s weirdly ignored by a lot of project managers. Teams running at full capacity all the time are brittle.

“Projects” are poison to good software. What happens after your deadline?

• Implies no feedback loop with customers, just ship stuff for hitting deadlines sake rather than doing something useful.
• Bad incentives. Celebrate hitting deadlines but won’t talk about whether the product is actually worthwhile.

If they dictate priority they’re just as bad as POs as bosses.

Do you have QAs? What do they do?

Ideal answer

If you do, they are there to act as coaches in respect to how to build high-quality systems (think testing, operability, etc). They also might be individuals who have time and space to do exploratory testing to find new insights about the system.

QA should be a responsibility shared by the team, not a role.

Warning signs

• Separate individuals writing tests
• Gatekeepers
• Army of manual testing which leads to slow releases, slow feedback loops, etc

Do you have UX engineers? What do they do?

Ideal answer

UX are researchers and educators.

They reach out to users and learn about their needs, often they’ll bring other disciplines such as engineers with them, so they also gain first-hand appreciation of the problems you’re trying to solve.

From there they work with the team to figure out how to solve these problems.

You’ll often find the UX people sat with engineers scribbling on paper to agree upon cheap experiments to try to understand these problems.

The UX team revel in learning, striving to learn more about users and then documenting and presenting their findings.

Warning signs

The discipline of UX is conflated heavily with visual design.

Rather than actually thinking about the user’s problems they are trying to solve, they spend more time worrying about making pixel-perfect designs for the product owners to rubber-stamp. This is a real waste of talent and energy, they’re UX experts to serve the users, not the whims of POs.

This way of working leads to costly feedback loops where engineers have to implement these pixel-perfect solutions only to find they are impractical in some way, or don’t actually meet the user’s needs.

Often they seem not attached to the software team, rarely collaborating or learning with the team. Instead, they’re working very far in to the future making mockups for software you may not even write.

All of this looks like siloed work in a waterfall project.

How do you validate your work? What makes you decide to start initiatives? What makes you end initiatives?

Ideal answer

You have a vision to guide your company but acknowledge there’s lots to learn. Mistakes are fine so long as you learn from them.

You have a learning environment, you’re always pushing for faster more effective feedback loops. A part of this is trying to find ways to cheaply validate ideas, and you lean on your software development teams to help you do this.

You’re not afraid to cancel an initiative or change it radically if you need to. Plans are changing all the time, driven by these learnings.

Empowered and involved teams bring ideas that are also prioritised

Good ideas don’t arrive during quarterly planning

Customers are involved and we work with them closely to help build a great product.

Warning signs

• Immutable product roadmaps
• Long backlogs
• Optimising for predictability over good products
• Development team feeling disempowered and uninspired
• Lack of feedback loops
• Lack of end-user involvement, if at all.

Can we stop selling people things that aren't possible to deliver? Please? Users and customers need to be involved in development of their software. If you don't want to be involved, you can't complain when the resulting software doesn't work for you.

https://twitter.com/ChristinGorman

Do you have fixed deadlines?

Ideal answer

Obviously, we don’t have infinite money but working to a strict deadline implies a lack of feedback loops.

We prefer to keep iterating quickly and keep gathering feedback. If we learn that what we’re doing is useful, we’ll keep investing until we (and the customers) are happy with it. Has the Twitter “project” finished yet?

Rather than deadlines instead think:

How much of our budget are we willing to spend on this idea?

Warning signs

Whilst a bit of pressure is good, tight deadlines are toxic. It usually results in teams rushing out poor quality systems that are difficult to maintain and because of the fixed nature of work the technical debt will remain unaddressed.

Inevitably the system needs changing at some point (by another absurd deadline, again), repeat cycle of doom forever. Engineers get further blame as things become more and more difficult as technical debt spirals out of control.

• Who is supporting the software after you release it?
• Is it really worthwhile to build if you’re not going to change it to adapting customer needs? Again, is the Twitter project finished? Is the Facebook project finished?
• Hitting deadlines is not a goal in itself. Too many companies fetishise hitting deadlines (which are often totally arbitrary ) over building good products and having healthy, meaningfully productive teams.
• If you use tight deadlines as “motivation”, you have big problems. Why aren’t people intrinsically motivated at all? Why can’t you treat your colleagues as adults and trust them? Can the management seriously not think of other ways to motivate people?

Do you have 10% time?

Ideal answer

Yes, we give space for engineers to learn because we recognise that self-improvement is vital to the success of the business.

In addition, we believe it helps with diversity. A young white male with no responsibilities can spend his free time learning the latest, greatest programming languages, but that’s not going to be true for a single mother.

Warning signs

Lack of time? Again, why are projects so poorly managed that there’s no time for the team to improve?

How do you expect the team to improve and be able to hit your aggressive deadlines if they’re always working at full capacity? You should view your development teams as important assets that you want to invest in.

Who is in charge of process? Is there a standard way across teams?

Ideal answer

The team(s) are in charge of their process. Teams are groups of different individuals working on different problems and if they have a positive, learning-led culture they will retrospect and refine the way they work.

They are trusted and incentivised to find better ways of working. Kaizen is at the heart of every team’s culture and a result of that is inevitably teams will work differently.

Some standardisation is helpful though, maybe every team is obliged to showcase their work every week for instance. However, standardisation never trumps a team’s ability to improve the way it works.

Warning signs

An answer of “Yes there is a standard process”. Teams are different and need to be empowered to improve their working practices, or they wont be able to adapt to changing circumstances.

Whilst developers being able to move between teams is nice, prioritising it over autonomy will be extremely costly. Think about what a standard process involves. There has to be some kind of governance for it. If a team needs to change the process to work more effectively, how time-consuming will that change take and how chaotic will that be for the other teams?

It’s pretty laughable how many companies will blindly follow ceremonies like retrospectives and simultaneously not allow them to act on whatever they uncover because of the process.

Quickfire questions about managers

• Do they enjoy the job? Or were they pressed into it. What do they like?
• Do they have access to training? Management isn’t an inherent skill, it is something that needs to be studied and practiced.
• How often do they have 1 to 1s, skip level meetings?
• Does your manager care about you? Have they helped move your career forward?
• Has your manager said no to you?
• Can your manager actually make decisions? Or are they just a communication funnel?
• How do you grow your reports?
• Why did you become a manager?
• When has a manager batted for you?
• Has your manager ever given you hard to hear feedback?
• Talk about a team member’s growth they are proud of
• Talk about when they got negative feedback from someone on their team, and how did they deal with it?
• What’s the biggest challenge your team faces, and what are you doing about it?

What if you answered a lot of the questions above “wrong”?

Does your organisation have the maturity and honesty to see its own short-comings? How willing is it to change? Who is sponsoring this change? Are they actually in charge, can they make decisions?

I’ve often found there are numerous people who are asking the right questions, but they’re at the wrong level at the organisation. They’re often fighting bad incentive structures. For instance, when an organisation hires and incentivises people to prioritise hitting arbitrary deadlines at the cost of everything else it’s going to be very hard to improve things.

I’ve worked in environments that have answered many of these questions poorly, but they have a good enough environment and autonomy to let us all make positive changes. So, I’m not looking for 10/10 but a willingness to improve.

Being involved with teams that have driven positive change have been the source of a lot of pride for me. The nature of our industry means all teams/orgs have to constantly adapt to deal with new circumstances. The open-minded, honest, diverse organisations are the ones that are best equipped for this reality.