We use cookies on this site to enhance your experience. Visit our Privacy Policy for more info.

Tips from the Top: How to Boost Developer Productivity

Tami Reiss | September 06, 2019| 1 min. read

Hackernoon posted a list of “Top 12 Things That Destroy Developer Productivity” - it provided food for thought for product leaders in the Insight Portfolio, so we convened Mike Doherty, Director of Product Management, WorkForce Software and Ken Surdan, CPO, Diligent for a virtual roundtable to drill down a bit further. Do these experts agree with Hackernoon’s assessment? What do they feel are the essential tools for developer productivity, and what challenges does that productivity encounter in daily business life?

Tami Reiss: The Hackernoon article listed the following items as the top 12 things most damaging to developer productivity:

  1. Interruptions & Meetings 
  2. Micro-management 
  3. Vagueness 
  4. Seagull Management 
  5. Credit Greediness 
  6. Environment (Noises), Motion, Workspace Design 
  7. Scope Creepiness 
  8. Product Definition Process 
  9. Lack of Consideration to Technical Debt
  10. Tool Multiplicity & Hardware
  11. “How” Documentation
  12. Impossibly Tight Deadlines.

Of these, which do you think are the most important? Which are the most destructive? And how can we avoid these traps?

Mike Doherty: As to which are most important? Vagueness, Scope Creepiness, Lack of Consideration for Tech Debt, and Impossibly Tight Deadlines. Clarity of vision is the most important thing, long-term - both vision for the product as a whole, and short-term goals for the current initiatives and the individual features. Providing clarity and removing ambiguity gives engineers confidence that you know what you’re talking about and why they should follow you in carrying out your request. They are interrelated. Scope creepiness and other changes to priorities also make the team lose confidence that product has a clear vision or strategy for how to serve customers.

Tech debt can get out of hand. It is essential to interact with developers every day, to understand the challenges they have. The reality of tech is that there are always some technological elements that must be done. You have to acknowledge the team’s need to repay debt. 
Your focus is always going to be on the customer, but you have to balance that with respecting your team.

Deadlines are unavoidable; as such leadership needs to adjust scope so that it’s realistic. Be collaborative. It’s up to the Product Manager to be the realist. 

Ken Surdan:  Vagueness, Micro-management and Interruptions. If you can’t define what you want to build or delineate the outcomes you’re after, they [developers] can’t be productive and effective. The most disrespectful thing to do to an engineer is give them a task that doesn’t matter. If you bring their talent and productivity to a problem with real value to the customer and the business, they will dedicate themselves and “run through walls” to get it down. I don’t want to spin my wheels. I need to trust my Agile rituals to enable the team. Interruptions and discontinuity are a result of poor scope management and definition that shows lack of discipline and poor methodology.

TR: Which of these challenges can be minimized by product managers?
MD:  All of them! Product has a very wide sphere of influence. Product has a responsibility to help with everything here, but it has to be in collaboration with our peers in Engineering. We’re all busy, but it’s important for Product to respect where ownership really lies. Product context is the “why”,and though Product may know about the “how” as well, that’s Engineering’s domain. Product should encourage engineering peers to the “how”, so that Product can spend time influencing stakeholders and owning vision and market perception, which Engineering is definitely not responsible for.
 
TR: Which of these challenges are out of product’s control?
MD:  I don’t think about what is in Product’s control or out of Product’s control. It’s all about prioritizing what is most valuable, and where my time is most valuable. If I’m worried about some of these smaller processes, is that time I could be investing in thinking about my product’s positioning in the market, which has a bigger impact on the business, and which is my main focus? If the team velocity increases, but we don’t sell products, is that success? 

TR: Are any of these pitfalls inevitable?
MD:  Only if the structure and culture allows them. Structure drives culture, and culture drives behavior. If Engineers feel invested in delivering customer value, they understand why meetings need to happen and why scope may shift. But we all have a part to play in reducing or eradicating these disturbances.

KS:  There’s no such thing as a perfect sprint, or at least it’s very rare. We need teams that are resilient to overcome these obstacles. It’s about making sure none of these challenges are happening too frequently. Great developers won’t put up with these things for too long.

TR: Hackernoon called meetings “planned interruptions.” Do you agree with that? 
MD: - You need spaces for collaboration and communication; you can’t read your way through complex businesses. You need a common “why” which doesn’t always come from Slack, Jira, etc. The team needs to be aligned to the problems that matter. I believe Standup, Planning, and Retro are all meetings which add value.

TR: What about meetings? Aren’t they a necessary evil?
KS: Regarding meetings, product must make sure to maximize the value of them , interruptions too. If I help you not go down the wrong path with scope creepiness that’s a good thing and it’s ok if a meeting or interruption was how I did that.

TR: The article focuses on destructive influences. Can you share some positive ways in which you communicate with your teams which have helped stop such destructive elements before they even start? 
MD: Here’s a positive 12 things I do as a Product Manager to help the development teams be successful:

  1. Set a clear, unambiguous vision and restate it frequently
  2. Set clear short-term goals and share explicitly what customers want to help the team make better decisions aka what we are optimizing for
  3. Align on what words like 'value' and 'quality' mean in the product context, to remove ambiguity
  4. Expose the team to the customers and end users
  5. Educate the team on the product domain to become experts
  6. Educate the team on the product’s competition e.g. when new knowledge is obtained, share it; when you've seen something good or bad show them; create a competitor wall (ideally with a nice inspirational quote around defeating the enemy)
  7. Guide the Product Owner to focus more on prioritization and ask them to let  the team own clarification of requirements as much as possible
  8. Talk about the market problems with the team to ensure that, even working in a world of fast and frequent delivery, they don't forget the bigger picture and product context
  9. Educate colleagues in  different functions on the importance of some of these principles e.g. distractions, promoting focus, context switching, WIP, etc
  10. Make decisions - they might end up wrong but I'd rather that than indecision; we move quick enough and light enough that a bad decision isn’t a big deal and can be rectified as needed
  11. Only make simple requests of the team and leave the rest up to them e.g. I frequently just ask for something like "working software at least every two weeks", as I believe this is an appropriate time frame for our teams, which helps drive good engineering practices and behaviors
  12. Find a way to allow those I work with to bring their whole selves to work - these people have been hired for a reason, let them be themselves.

KS: I like this list, Mike. I also like positioning positives.  As I learned a long time ago, hardly anyone is motivated, much less inspired, by avoiding negatives. I might add a couple to your list:

  1. Make sure that everyone knows the core "why" for the product.  What is the core reason it exists?  Why is it important?  For whom? Does everyone share the "why is this important work for our customers and ourselves?"
  2. Is there a culture of transparency where everyone, in every role on the team, has access to everything?  Not waterfall drips, full access to everyone that allows anyone to engage as an important voice.  The opposite of this is "order takers" who are unengaged and lack empowerment to be a fully informed contributor to making the product better every sprint.
  3. Make commitments together as a team.
  4. Everyone talks to customers directly.  They know who they are and engage with their issues and opportunities.  Cultivate customer empathy and you will cultivate motivation.

You’ve heard from Mike and Ken. Now what are your tips and tricks for avoiding these developer/product challenges? Share your thoughts with us on Twitter @insightpartners.