6 ms·

This is excellent advice but I would back up a few steps and do a few things before bringing in a freelancer team. Identify a part of this system that can work

This is excellent advice but I would back up a few steps and do a few things before bringing in a freelancer team. Identify a part of this system that can work somewhat in isolation and is non-critical if at all possible. Then document the requirements for this part thoroughly. This allows you to: - Have something smaller for your new team to cut their teeth on. - Ensure you have collected all the diffuse domain knowledge for this part in one place in the form of structured requirements. - Forces you to think in terms of what you need and what is acceptable delivery, If need be you can bring in a Senior/Staff level engineer to help you through this discovery and definition phase. In my experience the most common difference between success and failure for a project often comes down to clear requirements and expectations. Your employees are the domain experts. You need to collect that expertise and document it in a way that this team can reasonably consume. This is difficult and time consuming so start now. They will still have questions and get things wrong but this gives you a roadmap. They are going to be learning your industry while you are learning how to build software. Best of luck EDIT: formatting

danielheath 2y ago
> This is difficult and time consuming so start now. A specific difficulty you are likely to face: Your expert employees are busy doing their jobs. Writing requirements means taking attention away from that work - a difficult proposition, especially if they have managers who will ask why their KPIs are slipping.
- afpx 2y ago
  Oh - you're so right. I see this probably around 20-25% of the time. Schedules slipping because you can't get time with the main SME.
  - throwaway14356 2y ago
    would it be possible to just work on writing everything down and use all the time it takes? I imagine the complicated part would grow wordy enough to stick out like a sore thumb. Perhaps eventually have a freelancer turn it into technical documentation. The stuff we admire (if done right) but hate to do. (or in my case clueless how to) (disclaimer: I know nothing, im just reading the comments.)
    - zerkten 2y ago
      What is being expressed here is not a new problem. The challenge with solving it is that there isn't an easy set of steps that works every time. Someone's experience with the challenges of getting time with SMEs is highly dependent on the culture of the org, incentives, structure of the engagement, personality of the SME, actual workload, SMEs situation/feelings/stress, etc. You can solve or mitigate these problems, but it takes experience and expertise that most coming from more pure software development backgrounds may not have. From experience, someone coming in with some consulting experience will tackle the situation differently. Writing stuff down isn't always the best approach. Having a written record may be a good end goal. It may be better to have the small implementation soak up that experience through co-location with the experts. That way they are close by for interviews (probably too formal) but more likely sit and observe as the experts work. OP can then focus on building relationships between the experts and dev team. On this foundation you can add in more formality. As part of the relationship management, OP will have to help the experts free time by working with their management. Without details of the company, we can't give real examples, but it might include supporting their requests for contractor support or giving their leadership political help. When you can't come to some sort of co-location situation, you have seriously undermined your ability to execute the project. You will not have a true picture of the situation. Getting PMs or user experience people to engage with the experts will be lower value and require more clarifications. Developers can be low threat to the experts versus other types of people you can bring in.
- Too 2y ago
  These experts may also be hesitant to change. It could be due to many different reasons. One the personal spectrum, they can overvalue themselves or have fear of loosing their jobs. On the technical spectrum, they can be stuck in old tracks without computer knowledge and not thinking outside of the box. For example, in their eyes the objective is to move PDF file from directory A to directory B. In the ideal automated world, why is there a PDF in the first place? Basically "if you asked what they wanted they would have said faster horses...".
  - carlmr 2y ago
    For the technical side, this is a part of what a good software engineering team should be teasing out from the verbal requirements. Check if the intermediate PDF is needed, if it is, it still shouldn't be part of the automation path, but instead serialize/send the data properly and output the PDF on the side.
- BurningFrog 2y ago
  Maybe a nit pick, but I would not accept the expert employees writing requirement documents that are "thrown over the wall" to the dev team. You need personal access to talk to the experts anytime some question comes up. This means 1-2 experts work part time as PMs more or less, which will impact their regular work. Costly, but I don't trust any other way.
  - zerkten 2y ago
    I think there are variations of this. Yes, your experts need to give an amount of time to the effort. Making them a PM, in any sense of the word, is a step beyond contributing their expertise and can be avoided. What you need is someone with significant dev experience, but enough outside exposure to step into the PM role. Ideally, it'd be someone with interest in user experience research, or a personality that connect outside of a dev team. They should be able to perform this role in a mechanical fashion to avoid a dedicated PM. Doing this will be effective enough until things are at the point where a dedicated PM can be justified. If there is a struggle with the user experience aspects and getting knowledge out of the experts, you can get expertise from an agency on a short-term basis. Adding a pure PM is going to significantly slow you down unless are one of the rare switchers who flip between dev, PM, and dev manager roles. People don't know what to make of these people, but they exist, especially in the freelance contract world. People will only full-time experience tend to look down on them because they can't understand it.
osigurdson 2y ago
>> project often comes down to clear requirements and expectations Here you are just copying an existing system. Reverse engineering requirements from domain experts unnecessarily turns this into a green field project.
throwaway201606 2y ago
Want to second the two parent comments to this. Small freelance / contract team of very very senior very experienced people. 3 to 4 max. I was fortunate in that I, for the first part of my career, joined teams that were structured like this. Some additional thoughts: - keep things small at the start - task your team with at least two goals for the first 90 to 180 days i ) to define a small but critical piece of work (actually designing and coding something related to what you need to do). Cannot be part of your core platform but will need to eventually be in the platform. Picking the right piece of work here is critical. ii ) to define a design, roadmap and project plan for completing everything you want done with cost, staffing, tech and effort estimates Then use the 90 to 120 days and the two tasks above to evaluate: i) if the folks and team you have put together works: a) as a team and b) with your existing business ( can they do the work, can they work effectively with the rest of your business, is the design the come up with solid and does it give you confidence that they can tackle the real core work you need done) ii) if you can get a sense of what it will cost (what did the 90 day project cost and was it delivered on time and budget per the team's estimate ) iii) if the team can put together a road map with support of the business for the broader objective in parallel to executing the piece of work chosen iv ) if the solution if palatable from a cost perspective ( money, people, tech, disruption ) v) if the staffing model , architecture and integration proposed for the project by your new team could work (get feedback from the rest of the business about what is proposed by your new team ) vi) if your business can work with this new tech team ( feedback from your existing staff about the folks doing the work and their product for the small piece of work they tackled ) - It is really critical that they be 'senior' people - 'senior' here meaning they have done and seen a lot. The title will not tell you if they are. You have to actually look at what they have done. Look for senior free-lancers with a variety of (longish 4 to 5 years) experience using a variety of technologies (C / Java / PL-SQL / Perl / Rust / C++ whatever etc etc - but boring old tech is better, you will eliminate another variable from your project complexity ) in variety of industries / verticals ( 3 to 5 industries. This is a signal of effectiveness at learning new things and delivering effectively in new fields with new people in new environments. - it is critical that your freelancers not just be developers: they have to be "business-goal oriented". Consider asking for references who are not developers and consider filtering your freelancer hires through their networks in LinkedIn - do they have a good mix of senior and non-senior people in their network who are NOT developers? That is a good indicator they worked effectively enough with other non-software parts of the business that the people on that side of the fence (marketing, ops, finance etc etc ) are comfortable being associated with them. Pick the areas that matter to you. - Consider filtering for delivered results when you talk to candidates and in resumes: look for achievements / projects / work delivered rather than work done as this 'could' be a signal that the person is focused on actually 'owning' projects (not work ) and closing out on projects / goals (could also be a signal that the person did not not consider put delivered work in their resume so there is that - so, if you don't see it, just ask something like "what projects have you owned start to finish and how did you architect, design and execute on them" and interpret the response ). - Key skills to look for in free lancers: - systems integration (making systems 'talk' to each other - you will have to make your existing system talk to your new system + you will eventually have to get your data off wherever it is now to your new environment and you will have to make the new system work with all the other tech systems you have now) - system architecture: designing software solutions - database architecture & design - project & program management - lean six sigma / green belt ( means they have may have worked with ops people to optimize operations ) All the difficult stuff is going to happen in the background (batch processing, integration etc etc) so don't bother with front end development skills at the start - that is actually relatively easy to hire for. You will definitely find folks who have the right profile who will work with you - the key is decent (not crazy) pay, benefits and elements of stability attached (contracted duration with pay guarantees for performance, performance bonuses if possible etc etc). - Plan on developing a bench from the freelancers so hire some mid-level junior folks to work alongside them for when the freelancers inevitably move on. You will have to hire from outside (try and get mid-level people in the industry, not senior folks, so that it is clear that your senior freelancers are the leaders / owners of work ) but try really hard to source at least a few of these folks from existing staff if possible ( people in other job functions - and are good at those jobs - who are programming inclined ) as they are a good source of how things work to integrate into the team or as new hires. They do not have to be as as senior but they have to be able to keep up. These people start as grunts for your freelancers and learn the system as it is built - they are your future tech staffing. - Plan ahead for what WILL go wrong. I strongly strongly strongly recommend reading two books - The Phoenix Project - https://www.amazon.ca/dp/0988262592 - The Unicorn Project - https://www.amazon.ca/dp/1942788762 They deals with how executives and staff tackled a situation very similar to what you are dealing with and explains how to tackle some of the key structural problems you WILL run into. It is also a great resource for understanding how to run a project like this and understand how things could go right and more important, how things can go wrong and what to do WHEN they do go wrong (because they WILL ). The books will give you a very strong set of foundational thoughts about how to think about running this project if you decide to commit to doing it.
phkahler 2y ago
>> Identify a part of this system that can work somewhat in isolation and is non-critical if at all possible. I'm probably thinking about this at a different level, but when I start something new I like to find the core pieces and the most difficult pieces and see if I can tackle those first. Everything else builds on top of that. I'm assuming you mean to start at a higher level piece that will need to use all of the lower level pieces. That's good too because it may help identify what those difficult core pieces even are that I'd like to go after first.
- alemanek 2y ago
  It’s a new team. This non-critical part is your shakeout cruise before heading off into the open ocean. You can identify how well you hired as well as how well you prepared for these contractors to begin work. Make appropriate calibrations or worst case scrap it and let the whole team go. If they produce some big mess you will find out much quicker than if you set them loose on the big project. Small deliverables which incrementally get larger is how you roll on a new team. It allows you to get fast feedback and make small calibrations as you go. Hopefully avoiding the “fire them all” failed project scenario

danielheath 2y ago

> This is difficult and time consuming so start now. A specific difficulty you are likely to face: Your expert employees are busy doing their jobs. Writing requirements means taking attention away from that work - a difficult proposition, especially if they have managers who will ask why their KPIs are slipping.

afpx 2y ago
Oh - you're so right. I see this probably around 20-25% of the time. Schedules slipping because you can't get time with the main SME.
- throwaway14356 2y ago
  would it be possible to just work on writing everything down and use all the time it takes? I imagine the complicated part would grow wordy enough to stick out like a sore thumb. Perhaps eventually have a freelancer turn it into technical documentation. The stuff we admire (if done right) but hate to do. (or in my case clueless how to) (disclaimer: I know nothing, im just reading the comments.)
  - zerkten 2y ago
    What is being expressed here is not a new problem. The challenge with solving it is that there isn't an easy set of steps that works every time. Someone's experience with the challenges of getting time with SMEs is highly dependent on the culture of the org, incentives, structure of the engagement, personality of the SME, actual workload, SMEs situation/feelings/stress, etc. You can solve or mitigate these problems, but it takes experience and expertise that most coming from more pure software development backgrounds may not have. From experience, someone coming in with some consulting experience will tackle the situation differently. Writing stuff down isn't always the best approach. Having a written record may be a good end goal. It may be better to have the small implementation soak up that experience through co-location with the experts. That way they are close by for interviews (probably too formal) but more likely sit and observe as the experts work. OP can then focus on building relationships between the experts and dev team. On this foundation you can add in more formality. As part of the relationship management, OP will have to help the experts free time by working with their management. Without details of the company, we can't give real examples, but it might include supporting their requests for contractor support or giving their leadership political help. When you can't come to some sort of co-location situation, you have seriously undermined your ability to execute the project. You will not have a true picture of the situation. Getting PMs or user experience people to engage with the experts will be lower value and require more clarifications. Developers can be low threat to the experts versus other types of people you can bring in.
Too 2y ago
These experts may also be hesitant to change. It could be due to many different reasons. One the personal spectrum, they can overvalue themselves or have fear of loosing their jobs. On the technical spectrum, they can be stuck in old tracks without computer knowledge and not thinking outside of the box. For example, in their eyes the objective is to move PDF file from directory A to directory B. In the ideal automated world, why is there a PDF in the first place? Basically "if you asked what they wanted they would have said faster horses...".
- carlmr 2y ago
  For the technical side, this is a part of what a good software engineering team should be teasing out from the verbal requirements. Check if the intermediate PDF is needed, if it is, it still shouldn't be part of the automation path, but instead serialize/send the data properly and output the PDF on the side.
BurningFrog 2y ago
Maybe a nit pick, but I would not accept the expert employees writing requirement documents that are "thrown over the wall" to the dev team. You need personal access to talk to the experts anytime some question comes up. This means 1-2 experts work part time as PMs more or less, which will impact their regular work. Costly, but I don't trust any other way.
- zerkten 2y ago
  I think there are variations of this. Yes, your experts need to give an amount of time to the effort. Making them a PM, in any sense of the word, is a step beyond contributing their expertise and can be avoided. What you need is someone with significant dev experience, but enough outside exposure to step into the PM role. Ideally, it'd be someone with interest in user experience research, or a personality that connect outside of a dev team. They should be able to perform this role in a mechanical fashion to avoid a dedicated PM. Doing this will be effective enough until things are at the point where a dedicated PM can be justified. If there is a struggle with the user experience aspects and getting knowledge out of the experts, you can get expertise from an agency on a short-term basis. Adding a pure PM is going to significantly slow you down unless are one of the rare switchers who flip between dev, PM, and dev manager roles. People don't know what to make of these people, but they exist, especially in the freelance contract world. People will only full-time experience tend to look down on them because they can't understand it.

osigurdson 2y ago

>> project often comes down to clear requirements and expectations Here you are just copying an existing system. Reverse engineering requirements from domain experts unnecessarily turns this into a green field project.

throwaway201606 2y ago

Want to second the two parent comments to this. Small freelance / contract team of very very senior very experienced people. 3 to 4 max. I was fortunate in that I, for the first part of my career, joined teams that were structured like this. Some additional thoughts: - keep things small at the start - task your team with at least two goals for the first 90 to 180 days i ) to define a small but critical piece of work (actually designing and coding something related to what you need to do). Cannot be part of your core platform but will need to eventually be in the platform. Picking the right piece of work here is critical. ii ) to define a design, roadmap and project plan for completing everything you want done with cost, staffing, tech and effort estimates Then use the 90 to 120 days and the two tasks above to evaluate: i) if the folks and team you have put together works: a) as a team and b) with your existing business ( can they do the work, can they work effectively with the rest of your business, is the design the come up with solid and does it give you confidence that they can tackle the real core work you need done) ii) if you can get a sense of what it will cost (what did the 90 day project cost and was it delivered on time and budget per the team's estimate ) iii) if the team can put together a road map with support of the business for the broader objective in parallel to executing the piece of work chosen iv ) if the solution if palatable from a cost perspective ( money, people, tech, disruption ) v) if the staffing model , architecture and integration proposed for the project by your new team could work (get feedback from the rest of the business about what is proposed by your new team ) vi) if your business can work with this new tech team ( feedback from your existing staff about the folks doing the work and their product for the small piece of work they tackled ) - It is really critical that they be 'senior' people - 'senior' here meaning they have done and seen a lot. The title will not tell you if they are. You have to actually look at what they have done. Look for senior free-lancers with a variety of (longish 4 to 5 years) experience using a variety of technologies (C / Java / PL-SQL / Perl / Rust / C++ whatever etc etc - but boring old tech is better, you will eliminate another variable from your project complexity ) in variety of industries / verticals ( 3 to 5 industries. This is a signal of effectiveness at learning new things and delivering effectively in new fields with new people in new environments. - it is critical that your freelancers not just be developers: they have to be "business-goal oriented". Consider asking for references who are not developers and consider filtering your freelancer hires through their networks in LinkedIn - do they have a good mix of senior and non-senior people in their network who are NOT developers? That is a good indicator they worked effectively enough with other non-software parts of the business that the people on that side of the fence (marketing, ops, finance etc etc ) are comfortable being associated with them. Pick the areas that matter to you. - Consider filtering for delivered results when you talk to candidates and in resumes: look for achievements / projects / work delivered rather than work done as this 'could' be a signal that the person is focused on actually 'owning' projects (not work ) and closing out on projects / goals (could also be a signal that the person did not not consider put delivered work in their resume so there is that - so, if you don't see it, just ask something like "what projects have you owned start to finish and how did you architect, design and execute on them" and interpret the response ). - Key skills to look for in free lancers: - systems integration (making systems 'talk' to each other - you will have to make your existing system talk to your new system + you will eventually have to get your data off wherever it is now to your new environment and you will have to make the new system work with all the other tech systems you have now) - system architecture: designing software solutions - database architecture & design - project & program management - lean six sigma / green belt ( means they have may have worked with ops people to optimize operations ) All the difficult stuff is going to happen in the background (batch processing, integration etc etc) so don't bother with front end development skills at the start - that is actually relatively easy to hire for. You will definitely find folks who have the right profile who will work with you - the key is decent (not crazy) pay, benefits and elements of stability attached (contracted duration with pay guarantees for performance, performance bonuses if possible etc etc). - Plan on developing a bench from the freelancers so hire some mid-level junior folks to work alongside them for when the freelancers inevitably move on. You will have to hire from outside (try and get mid-level people in the industry, not senior folks, so that it is clear that your senior freelancers are the leaders / owners of work ) but try really hard to source at least a few of these folks from existing staff if possible ( people in other job functions - and are good at those jobs - who are programming inclined ) as they are a good source of how things work to integrate into the team or as new hires. They do not have to be as as senior but they have to be able to keep up. These people start as grunts for your freelancers and learn the system as it is built - they are your future tech staffing. - Plan ahead for what WILL go wrong. I strongly strongly strongly recommend reading two books - The Phoenix Project - https://www.amazon.ca/dp/0988262592 - The Unicorn Project - https://www.amazon.ca/dp/1942788762 They deals with how executives and staff tackled a situation very similar to what you are dealing with and explains how to tackle some of the key structural problems you WILL run into. It is also a great resource for understanding how to run a project like this and understand how things could go right and more important, how things can go wrong and what to do WHEN they do go wrong (because they WILL ). The books will give you a very strong set of foundational thoughts about how to think about running this project if you decide to commit to doing it.

phkahler 2y ago

>> Identify a part of this system that can work somewhat in isolation and is non-critical if at all possible. I'm probably thinking about this at a different level, but when I start something new I like to find the core pieces and the most difficult pieces and see if I can tackle those first. Everything else builds on top of that. I'm assuming you mean to start at a higher level piece that will need to use all of the lower level pieces. That's good too because it may help identify what those difficult core pieces even are that I'd like to go after first.

alemanek 2y ago
It’s a new team. This non-critical part is your shakeout cruise before heading off into the open ocean. You can identify how well you hired as well as how well you prepared for these contractors to begin work. Make appropriate calibrations or worst case scrap it and let the whole team go. If they produce some big mess you will find out much quicker than if you set them loose on the big project. Small deliverables which incrementally get larger is how you roll on a new team. It allows you to get fast feedback and make small calibrations as you go. Hopefully avoiding the “fire them all” failed project scenario