31–40 of 79 posts
As an experienced manager, I shudder at the thought of pulling this off. But... and want to push myself to a first experience software lead. Am I to take this to mean this is your first experience leading a team? If that is the case, you are being set up for failure so that the CEO doesn't have to take the heat. "I brought in a high-dollar contractor, she was supposed to be good, but I guess not." If what you describ…
If there are tickets, read and understand all the tickets, organize them in a way you can manage day-to-day.
If you're working off some other spec, start breaking it up into individual tasks that can be managed on a spreadsheet or in a ticketing system.
If you're working off general guidelines without documentation (and you can't run!), start by writing out all the tasks that need to be accomplished to finish the project. Even if they are brief.
Now take the list of tasks and organize them into 2 "types"
Stories: Tasks that deliver value to the end user
Tasks: Tasks that are required or nice to have to enable 1 (Tasks or Chores)
Now prioritize those into different buckets
1. MVP: if we don't ship this, the project will fail
2. Nice to Have: Someone _really_ wants this but it's not MVP
3. Phase 2
The more scope you can put into bucket 3 the more likely you'll be able to deliver _a_ working, functional project on time. You will get more credit for delivering something _good_ than failing to deliver the perfect project.
Your team will also thank you for taking significant stress off their plate and for making them a success.
I'd go about it like so. 1. Start on a high note, take the team out to lunch / dinner and start to get to know them. 2. Don't force any changes, they will likely resist and you'll lose any budding support. Forcing a code review workflow is likely to demoralize them, and will be perceived to be slowing down dev that's already behind. 3. Work longer hours than anyone. You need to earn their respect, being seen to work…
This is an outstanding list and should be required learning on every software manager's todo. I can't tell you how important 3. is.
I think you are setting yourself up for failure: > Depending on how the CEO will introduce me to the team I'd resolve that NOW, before you fly out. If the culture is hierarchical, and you are supposed to be the "lead", but you aren't introduced as such, you are dead in the water IMO. > They are struggling with a project and the deadline is close...I need to sell good practices to the team so it becomes the natural ne…
This. Unless there's a competant project manager already in place and they are asking for a good technical lead to be put in place, it's highly likely a last ditch attempt to pull something magical off. If there's no PM then that's what the company needs, not a technical lead. As others have said, the teams under stress and the delivery date is coming up, so the only thing to really change is the scope and project tr…
As an experienced manager, I shudder at the thought of pulling this off. But... and want to push myself to a first experience software lead. Am I to take this to mean this is your first experience leading a team? If that is the case, you are being set up for failure so that the CEO doesn't have to take the heat. "I brought in a high-dollar contractor, she was supposed to be good, but I guess not." If what you describ…
Firstly this is not about the team. It's never about the team. Even if these guys are incompetent and flailing, a competent upper management would have seen it and dealt with it ages ago - long before this hail mary pass you are being handed.
So that means upper management are not up to the job. They could not spot a three-ring disaster, so they won't spot brilliant effort from you.
Now if you are not looking at the team but at the project management the questions become very different - forget code reviews, start asking
- what is the business value for the project - who pays for the project, who gets the benefits of the project, - and what are the utter core deliverables that will get them that value
If you don't know this you should not get on the plane
Next, those people identified above (presumably the CEO and his stakeholders) have three options - chnage the team, chnage the scope, increase the timelines
if you fly out to become the team, you will get changed when you cannot deliver
So pick your battle very carefully and be very sure the CEO or other stakeholder is fully onboard with cutting scope and extending time to get it over the line.
"Responsibility without authority is like being up a creek without a paddle."
If you are expected to make improvements, you must be granted to power to make changes. Otherwise neither your needs nor the company's will be met.
The current situation is apparently not working, and simply throwing bodies at the problem is likely to make it worse. Insist on a level of control minimally equal to the things you must deliver.
I would start with the infrastructure stuff like you said, a staging server and CI. If every dev has been relying on local builds, this will probably find a bunch of issues right off the bat.
After a stable build environment is established, I would go over the bottlenecks they currently face and work on freeing those up so they can work more efficiently. Since you're so late to the game, you should focus on enabling them to work faster to hit the deadline. All the other methodology and code quality stuff you mentioned can come after that.
It also sounds like there's a huge political element here too, so of course be aware of that. Definitely don't try to rock the boat too much at first until you understand specifics of what is wrong. Overprescribing can be demoralizing, and if the project still goes south then you're the one to be blamed, since it was your idea to "change things". Not to say you should do nothing, its a delicate balance, and one I would certainly struggle with myself. Best of luck.
Learn about their positive and negative experiences before changing anything. People are rarely as dumb as you think and often have to follow the instructions of their former dumb managers. Don't be another assumptive manager. Anonymous feedback forms during meetings are great for questions.
Position yourself as not their boss but being there to serve their needs, find how to support them and ultimately have the project succeed. Many employees are used to being mistreated overseas, some may not be able to handle this as they don't get moving until yelled at, others will cry out of happiness of dignity and respect. Strong emotional breakthrus are needed for turning around a project and for trust to form.
Make change plans together so the change is managed and there is an ownership in continuous improvement.
Create a culture of learning together and providing lots of mentoring and training that they didn't get in the past.
Reduce the culture of fearing mistakes and introduce one of learning. Lunch and learns are helpful to say this week I messed X up and learned Y from it. Do it yourself too.
Get lots of resources to help them learn in their own time. Lynda.com,etc. Make it clear your are here to help their personal and professional development first because that will get everyone positive results on the project.
Set the bar for work ethic. Nothing will move unless you do. You will find people who align with your message, or those who don't, and it may be required to replace some folks.
Rather than get into painting the sky magical colors, if your remaining project scope is known, implement a ticketing system like Jira with a basic workflow to teach the team how to record and build the defects. That will likely get more done to start a change that you can layer agile, etc with in the future.
The first thing I would do is check your own personal network to see if you know anyone that grew up in the culture of whatever country this dev team is in. In my experience, as far as culture, you really don't know what you don't know. So it could be very helpful to get a brain dump of advice. Even if they the person that advises you is not technical they could likely offer a lot.
"find a friend to be your senses" is my wording of it (from long ago).. And do this in all possible aspects (of culture or else) - common-people, company/companies, devs, management.. and once and again.
Technical stuff might be in dire state but is usualy fixable... unless people/culture simply prevents it. So beware.. esp. of things you are not told, like why these devs, why this project, why finish it, why now, .. why you?
Fish starts smelling from the head first.
and... Westerners might not be too welcome everywhere. Watch and Listen.. before doing anything. YMMV