This is part 2 of a 3-part series on key questions to ask before taking on a development assignment as a consultant.

In Part 1, we explored how to evaluate the technical foundation of a potential assignment. But even the best codebase can become a nightmare with poor practices and dysfunctional teams.

In this second part, we'll focus on how work gets done and who you'll be working with – the practices and people that will shape your consulting experience.

5. What does your release process look like – manual, automated, CI/CD?

The release process reveals a lot about an organization's maturity and stress levels. Smooth deployments enable innovation; painful ones create fear and stagnation.

Follow-up questions:

• How often are releases made (daily, weekly, less often)?

  • Frequent releases indicate confidence and good practices
  • Monthly or quarterly releases often hide accumulated risk

• What CI/CD tools are used (GitHub Actions, GitLab CI, Jenkins, etc.)?

  • The specific tool matters less than how it's configured
  • Look for comprehensive pipelines, not just basic builds

• Are releases stress-free or a sacred ritual?

  • Release day shouldn't require all-hands-on-deck
  • Stress indicates missing automation or poor testing

• Do you have rollback strategies in place?

  • Quick rollbacks are essential for experimentation
  • Complex rollback processes discourage innovation

• Is each release tested in a staging or QA environment first?

  • Production-like environments catch issues early
  • "Works on my machine" shouldn't be the final test

• Can developers deploy code themselves?

  • Self-service deployments accelerate delivery
  • Gatekeepers create bottlenecks and reduce ownership

6. How do you approach testing and test coverage?

Testing practices directly impact your daily workflow. Good testing enables confident changes; poor testing means living in fear of breaking things.

Follow-up questions:

• What levels of testing are in place (unit, integration, end-to-end)?

  • A healthy test pyramid prevents both bugs and flakiness
  • Over-reliance on any single level creates blind spots

• Which tools do you use – Cypress, JUnit, Playwright, etc.?

  • Modern tools can make testing enjoyable
  • Outdated or clunky tools discourage test writing

• Is writing tests a requirement before merging or releasing?

  • Test-first cultures produce better code
  • Optional testing usually means no testing

• Who owns testing – developers, QA, or both?

  • Developers should own their tests
  • Separate QA can add value but shouldn't be a crutch

• How much manual testing is required for each release?

  • Extensive manual testing indicates automation gaps
  • Some manual exploration is healthy, but not as a gate

• What happens if a test fails in the pipeline?

  • Failed tests should block deployment
  • If tests are regularly ignored, they're worthless

7. What's the composition of the team I'll be working with?

You'll spend more time with your team than with the code. Team composition and dynamics often determine job satisfaction more than technical challenges.

Follow-up questions:

• How many developers are there, and what's the seniority mix?

  • Balanced teams provide learning and mentoring opportunities
  • All-junior or all-senior teams each have their challenges

• Are roles like PO, Scrum Master, QA, and UX represented?

  • Cross-functional teams deliver better results
  • Missing roles often mean developers fill the gaps

• Is the team cross-functional or focused on a specific layer (frontend/backend)?

  • Full-stack teams have more autonomy
  • Layer-specific teams risk becoming silos

• What's the communication style – standups, Slack, face-to-face?

  • Communication should match the team's needs
  • Too many or too few meetings both harm productivity

• Are there peers to bounce ideas off of?

  • Isolation kills creativity and growth
  • Look for collaborative problem-solving culture

• Is the team stable or high in turnover?

  • High turnover signals deeper problems
  • Stable teams build better products and relationships

8. How's the collaboration between development and the business side?

The relationship between developers and business stakeholders often determines project success. Good collaboration creates great products; poor collaboration creates frustration.

Follow-up questions:

• Do you have direct contact with product owners or users?

  • Direct contact improves understanding and motivation
  • Telephone games through intermediaries lose context

• Can developers take part in needs analysis, or just receive specs?

  • Early involvement prevents building the wrong thing
  • Pure spec implementation wastes developer insights

• How well does the business side understand tech constraints and possibilities?

  • Mutual understanding enables better decisions
  • Ignorance on either side creates unrealistic expectations

• Are developers allowed to push back on or question requirements?

  • Healthy debate improves outcomes
  • "Just do what you're told" cultures waste expertise

• How are priorities decided – data-driven, gut feeling, or politics?

  • Data-driven decisions are ideal but rare
  • Political priorities often lead to abandoned features

• Any recent wins from joint initiatives between tech and business?

  • Success stories indicate healthy collaboration
  • Lack of examples might signal siloed thinking

Key Insights

When evaluating development practices and team dynamics, look for:

1. Release processes that enable rather than constrain
2. Testing practices that provide confidence, not theater
3. Teams that are balanced, stable, and collaborative
4. Business relationships built on mutual respect and understanding

The best technical practices mean nothing without people who can execute them effectively. Similarly, great teams struggle without proper processes and tools.

Red Flags to Watch For

• "Hero culture" where releases depend on specific individuals
• Testing as an afterthought rather than integral practice
• Siloed teams with minimal cross-functional collaboration
• Adversarial relationships between development and business
• High turnover masked as "bringing in fresh perspectives"

Green Flags to Seek

• Boring deployments that happen without drama
• Developers writing tests as naturally as writing code
• Cross-functional teams that own their features end-to-end
• Product and engineering planning together, not in sequence
• Team stability with healthy knowledge sharing

In the next post, we'll explore growth opportunities, working environment, and setting clear expectations – ensuring the assignment aligns with your professional goals.