How to manage your software development team

Getting the most value out of your development project requires everything to run like a well-oiled machine. This probably means you need to skill yourself up and adopt the correct mindset. By understanding what the major roles are in the project (including what role you have to play), and how the processes work – will go a long way towards giving you predictable outcomes. 

User Experience

It’s possible that you will engage with user experience designer – especially building consumer-facing applications. Good user experience is a key part of acquisition and retention and driving your overall goals.

What do UX people do?

A user experience designer focuses on your goals, what you want your users to achieve. They look at the application from the perspective of the end-user. Therefore they spend a lot of time understanding exactly who these users are, what their motivations are, and what you want them to do.

How to deal with UX people

  • Give them context: UX people will greatly benefit by understanding the bigger picture of your project – what are your business goals, future vision, feature roadmap, your business goals etc.
  • Develop personas – find a simple persona template, and spend a bit of time thinking about who your ideal users are. Think about (and document) outliers within your persona group, and the “middle of the road” users – to give them a perspective on the range of users.
  • Define your high-level user flows – UX people think in terms of “flows” in your application as a user will experience them. Think about your main application flows, and document it – in bullets or a process diagram (or both if possible)
  • Identify key screens: Using your key flows, think about important screens in the flow, list them out, and do some rough sketches if possible.
  • Allow space for creativity – UX people are by nature creative – by giving them the above, you will provide enough structure for them to work very efficiently on your project, however, allow them some space to optimise your user flows, propose changes to functionality and designs. This is the sweet-spot of the value that they bring to the project.

Designers

What do designers do?

Although Design and UX are often done by the same individual, or a small team working very closely together, they are completely different disciplines and are dealt with separately and in different ways. Designers:

  • Sets design guidelines and standards for the product
  • Turn UX flows and wireframes into screen designs
  • Creates “assets” (graphics, images etc.) for front-end developers to build the user interface

How to deal with Designers

The most important thing to understand about designers is that context-switching is very “expensive”. You need to change mental gears to change from one project to another, you need to set up a different set of design tools and frameworks, refresh your mind about the project and the way you’ve built it. 

A good designer will take a couple of hours to get into a groove, and then build momentum. They typically achieve peak performance after about 2-4 hours of focus. Some tips for getting the most out of your designer(s):

  • Be responsive: The best thing you can do is to be responsive. The ideal scenario is that you’re both online at exactly the same time, and as the designer is popping designs off to you, you’re giving them immediate feedback. This way you keep the designer “in the zone” and can massively improve the efficiency of this stage of the project.
  • Be decisive: Make a decision once, and don’t change your mind.
  • Be critical: Look for every little flaw in the designs and point them out. Your ability to spot the smallest of flaws will demonstrate your attention to detail, and build both respect and rapport with the designers – which is how you exert influence in the project.
  • Compliment good work: The Designer-persona is usually very self-critical and insecure about the work they put out – just like artists or actors. Take the opportunity to compliment excellent work. You will see the quality and pace of the work increase even further.

Business Analysts

What do BA’s do?

Business analysts are responsible for translating business requirements into a language that everyone can understand, and build consensus. They are the “translators” – they speak both “development” and “business” dialects. The good ones are experts at drawing information out of you (requirements “elicitation”) and capturing it in concise, accurate, and easy-to-consume information packages understandable to business and technical people.

How to work with a BA

  • Create context: A good business analyst wants to see the big picture. They will get confused and frustrated by only seeing slithers of the business or a process. Here’s how to create context:
    • Identify your major business functions – think about them as “process groups”
    • Do a deeper dive into the business area where you want to do your development – document your higher-level business processes
  • Set your objectives: a business analyst needs to understand the “why” and “what”, not the “how”. Be clear about why you want to do something, and what you want to do.
  • Be patient: It will take some time for the Analyst to get onboarded, you may need to repeat yourself a few times. It’s super critical that there’s absolutely no misunderstanding between team members. Every hour you invest here will drastically reduce your risk going forward.
  • Be responsive: As with designers, ensure a quick turnaround on your feedback. Be clear.
  • Focus on Acceptance criteria: Firstly, if your BA doesn’t build Acceptance criteria into their user stories or specs, fire them immediately, no questions asked.
  • Get a good BA: Good BA’s are qualified, certified and have a track record of successful projects. An unqualified, inexperienced BA will cost you a lot of money, time and sleepless nights. 

Other things that BA’s can bring to a project

Business Analysts have some additional value to add to your project if you know what to ask for. Here is a couple:

  • Sizing, estimating development work: Why is this important? “Shit happens” development projects, and with Agile (you’re using Agile, right?). Sizing your development into sensible pieces will give you a lot of flexibility, you can switch pieces of work out into your work batches (e.g. sprints). This means you can maintain development “velocity” even as you experience “blockers”. Basically it’s a risk mitigation strategy, which saves you time (due to flexibility), and thus money.
  • Technical design: A good BA will negotiate technology design with developers while they’re eliciting requirements with business – this means your technical design is “baked in” during the analysis phase – and written into your requirements. There is already a consensus between business and development – not only about what must be done but also how it will be done. This reduces stress on the requirements process  – and “business” (that would probably be you).
  • Quality Assurance: Good BA’s can also test if you want them to – as they understand the requirements. Compare the cost of onboarding a tester and their rate, vs the rate of the BA – there could be a business case to use the BA. 

Developers

What do developers do?

The most important thing to know about developers is that they work on a very low level of detail – the UX person looks at the world through binoculars, the developer looks at the world through a microscope.

How to deal with developers

  • Perfect clarity: By the time a developer starts working on something, there should be absolutely no misunderstanding of what needs to be done. You really don’t want your developer “to be creative” or “to figure it out”. You may as well set a pile of money on fire. Remember they are zoomed in at 10,000x magnification – you don’t want them to be looking for the spot where they need to point their microscope.
  • A developer will follow requirements to the letter: Even if you take a step back once a feature has been built –  and you say “this doesn’t make sense” – that’s none of the developer’s business. It’s up to you, the UX person, Designer and Business Analyst to give the developer(s) instructions that makes sense – it’s up to the developer to figure out how to make it happen.
  • Consistency: Context-switching is even more “expensive” for a developer than for a designer. Context switching your developers is the most wasteful activity (other than changing requirements) you can engage in. Every time you ask a developer to switch gears, you’re probably burning about 5 full days of development time. That’s lost productivity, lost velocity, and frustration for the developer which creates a further negative feedback loop
  • Acceptance criteria: The developer will (or should) focus very carefully on the “acceptance criteria” – this is their primary focus
  • Don’t tell them how to do their jobs: Don’t try and dictate the technical details of how your product is going to be built, what technology to use etc.

Understanding all the roles, personalities, how to deal with the individuals, how to manage them and what to expect would contribute to a constructive, productive working environment, and support a high rate of work.