Ask HN: How do I help an underperforming team get on track
I&#x27;m experiencing a similar sort of situation, developers are in this case all savvy and the code quality is technically good.
I judge our issues stem from uncertainty in three elements:
- we&#x27;re a new team and our functional experience is very different
- we lack some knowledge that is pretty core to the intended application design (the ecosystem is huge and discovery is a slow process)
- we don&#x27;t have an actually project manager and the actual PO is almost completely hands off (scope is a blur)<p>I think identifying and acknowledging unknowns and uncertainties are a good start, and as it happens, it&#x27;s nothing unheard of.
Teams can take time gaining efficiency. 
Agility is introspection, so retros at each level (personal, team, project, and team or project context ~ doesn&#x27;t necessarily mean specific meetings, but it does mean being critical of all of that each time ~ possibly just keep an ongoing checklist). 
That&#x27;s the linchpin.<p>Communication is likely where you&#x27;ll ultimately get the biggest win (knowledge transfer means level up in all sorts of dimensions)
Communication is also where you potentially stand to lose most longterm...
It&#x27;s an long ongoing process that is pan-project.<p>Uninterrupted flow is key to good code production. Working on communication can bring synergy within the team, each just know when&#x27;s a good time or not a good time. Practiced com channels are also generally less disruptive.<p>Efficient communications are: on point (concise, on topic, structured ~ PRs, docs, slacklike code blocks, tight dailies, (and tight deadlines :-P) are all good training grounds. Note that those skills apply as well to a anyone facing a task needing a break down.)<p>Tests: In my experience, bad tests&#x2F;testing is most caused by not enough time to write good tests. Getting better at that might be a case of devoting a sprint priority on the test process, frameworks, ease of use, and task definition. Everyone should be comfortable writing tests.
Having an already started codebase actually helps because you&#x27;ll more easily  uncover patterns that you may have missed in the stress of running late.<p>Most aspects of a project are tied to the delivery itself.
Hazy goals and a hazy roadmap to delivery (the deep level roadmap, tech bit by tech bit) are very disruptive to focus.
Thankfully as you avance in the fog you will acquire visibility. 
Some will gain visibility faster than others (like the PM and any dev tied to the app plumbing), but on a technical standpoint you need a team that is confident in the roadmap; not in a sense of time but in the sense of all the necessary steps that need to be taken in other to achieve your goals. Confidence in someone with that confidence can also be enough.
With that confidence, each step of the way can be a lot more focused. Developers don&#x27;t need to constantly be looking at the distance and looming deadlines, but can instead focus on the present problem, knowing (or working on accepting), that it&#x27;s a necessary step, and that they&#x27;re will simply be another after that. Better focus.
The mindset is simple: oh my goal is that, and I need to take those smaller steps to reach it, well let&#x27;s dive in.<p>A simple metaphor would be the climbing of a nice big mountain. There&#x27;s a point at which the effort is such that it&#x27;s easier to just stare at one&#x27;s feet, and just take a step at a time (ah and there&#x27;s less tripping over roots). 
As you go up, you gain strength and stability, and you can start keeping your eyes ahead more. Remember to look at the view: wow what a beautiful sight this and that is! Look at how high we are, look at that beautifully challenging clifface we&#x27;re going to be tackling :p 
It&#x27;s the journey right?<p>As a developer (I&#x27;m all over the place :p) we have to be able to focus enough, but there is a lot of shakeout that needs doing while we gain visibility and efficiency. 
At first, the confidence may need to come from the outside (from you): trust in the team&#x27;s individual qualities, trust in the introspective process.
As time goes, the confidence comes from the increased visibility, achievements, the increasing smoothness of communications, the increasing trust, awareness and confidence and respect of each developer for they own selves and they&#x27;re teammates strengths and weaknesses (always more areas of improvement :))<p>You&#x27;ll note that I haven&#x27;t really worried about any actual deadlines. Here&#x27;s the thing: If your team is actively working on improving itself, you should have confidence that they are working at best capacity at any point in time. If the deadline is too short, what are you going to do? Make them magically better? No. You can only realign goals, load, priorities, timelines, resources and have confidence in the fact that they are getting better. Give them the time they need and be the driver for improvement.<p>Rituals and all are pretty good, but do allow flexibility and allow everyone to be critical of them. Standards can be a good skeleton, but the principle is that you need to contributorily fit things to your needs.
Meetings should be adding clarity, but they do take some focus away as well if they are too many.<p>Work on teambuilding as well. There&#x27;s lots of ways to do it. Sharing a screen a and keyboard once in a while is a great way to get to know how other developers think, though it doesn&#x27;t work for everyone eh?<p>Ok I&#x27;m done.
Ways to go but our team is improving greatly btw, that is so satisfying in and of itself.