I’ve seen nearly every flavour of dysfunction after 20 years of working with software teams. Some are mildly dysfunctional. Others are spectacular disasters.
Suppose you wanted to create a miserable software development team. Here’s exactly what to do.
Consider this a checklist of anti-patterns. If your team exhibits more than 20 of these, you’re in trouble. More than 50? Start looking for a new job.
- No roadmap
- Write nothing down
- Feature delivery only
- Change your direction daily
- Unstructured brainstorm meetings
- No clear notes or follow up actions
- Constant interruptions
- Hire before you need
- Shitty interview questions
- Hiring someone’s mate or family member
- Hire folks with incompatible personalities
- “I’m here until I get my bonus”
- Change leadership every few months
- Make the team’s motto “customer obsession”
- Assume customers understand the real problem
- Assume customers know the best solution
- Collaboration is like walking through a minefield
- Thinking and planning considered BDUF
- No formal designs
- Discussing ideas considered a waste of time
- Create tickets for everything
- High prioritise everything
- Completely ignore the backlog
- Key details in multiple different private chats
- Write novels worth of documentation
- Write totally inaccurate stuff down
- Stakeholders can pester developers
- Clients can contact the developers directly
- Micromanagement
- Someone with an MBA
- Add a HR person
- No psychological safety
- Narcissistic individuals
- Ego-driven developers
- Sales-driven and unrealistic milestones
- Create a reporting hierarchy
- Manage by emails and CC everyone
- Completely remove all autonomy
- A project manager for each developer
- Two business analysts for each project manager
- Agile (not going to elaborate further)
- Ask for accurate estimates
- Then squeeze the estimates
- Story pointing
- Agile coaches who think agile is scrum
- Praise whoever aligns with leader
- Back stabbing are rewarded
- Churn and no stable relationships
- Functional silos
- Individuals own parts of the system
- Overlapping responsibilities
- Repeated scrapping and starting again
- Pair programming over Zoom
- Create interfaces for every little thing
- Prohibit strongly-typed languages
- Encourage technical debt
- Refactoring is punishable
- Hard-code as much as possible
- All code is saved in txt files
- No version control
- No coding standards
- No code reviews
- Too busy to test
- Coding from a dark basement
- No automation of any kind
- Deploy code directly from DEV to PROD
- Deployments are not automated
- Midnight deployments on a weekend
- Patch directly in production
- Change requests via CAB
- Quarterly on-call rotations
- Tools that prevent engineers doing the job
- Use hallucination prone AI tools
- Free coffee and out of order signs on the bathroom
- Product owners who know nothing about products
- Mistakes carry individual responsibility
- Never provide positive feedback
- Weekly all hands on Wednesday
- Publicly criticise team members at daily standups
- Business outcomes decided by tech
- Rank contributors by PR stats
- Focus on velocity
- Insufficient parking
- Mandated timesheets
- Timesheet system is a severe pain to use
- Needless return-to-office mandate
- Encouraging sales to sell vaporware
- Open plan office next door to sales
- No headphones allowed
- Employees must clock in and out when leaving their desk
- Install cameras to monitor staff
- Shit keyboard, mouse and monitor
- Local machine is a dumb terminal
- Development IDE is Vim
- Force them to use Windows (if they’re Linux)
- Force them to use Linux (if they’re Windows)
- Don’t pay or give time off for training
- Jira tickets with generic titles like “sprint 2 feature 1”
- Javascript (just joking, a bit)
- Team building is a strip club until 3am
- Ask them to make the logo bigger 😂
Recognise your workplace?
The opposite of each item on this list is how you create a high-performing, happy team. Clear roadmaps. Psychological safety. Autonomy. Good tooling. Respect for people’s time and expertise. And, underpinning much of it, the discipline to write clearer requirements so the team isn’t building blind.
If you’re facing several of these issues and lack the authority to change them, think carefully! The question isn’t “How do I fix this?” It’s “Should I leave?”
Some workplaces are too dysfunctional to save. Knowing when to walk away is a valuable skill.