- The Art of Leadership by Michael Lopp (aka Rands of Rands in Repose fame)
Which tackles situations he encountered (and are all too familiar) while managing in various roles at Apple, Netscape and Slack.
- The Engineering Leader by Cate Hudson
What I think is absolutely great about this book is that it isn't just about how to deal with the people you are responsible for but also how to deal with _yourself_
- The Engineering Executive's Primer By Will Larson
This one is meant more for "Head of Engineering" types, but still contains tons of handy information to turn yourself into a effective leader.
And last but not least:
- Become an Effective Software Engineering Manager by James Stanier
Subtitle of this book says it all. Highly recommended!
For people management, The Manager's Path by Camille Fournier is fantastic. That said, managing an offshore team (that also sounds junior) is going to create many headaches in addition to those you'll normally face as a first-time manager. Good luck!
Do you have to hire new devs for this? Sounds generic enough you can farm it out to any Shopify or WordPress/Woocommerce agency and probably get better results.
Ecommerce has a lot of intricacies, from the checkout flow to cross-site inventory management to CRM to product returns to transactional emails to order management to security and payments and PCI compliance, etc. It's a well established pattern that there are readymade providers and best practices for, but if you have no experience as a web dev and are working with a bunch of juniors who also have no experience... you might create a lot of footguns along the way.
They already have a WordPress/Woocommerce solution that is slow and very inflexible for what they need. Shopify would be a good option, but they also take a hefty percent of every sale, not any better than 3rd party. Good thing is I will not be hiring any developers, the plan is to hire a development firm that will build out the website.
Thanks for the info on the intricacies, do you have any resources that can help me out with those?
What is making hte WordPress/Woocommerce solution slow/ what additional flexibility would be required. It sounds like it might a better use of money to optimize the Woocommerce site than to reinvent the wheel and have a whole custom ecomm app to have to maintain.
> They already have a WordPress/Woocommerce solution that is slow and very inflexible for what they need.
I concur with the other poster that it's probably easier/safer to fix and/or extend the Woocommerce with additional functionality than to try to reinvent the wheel from scratch. Wordpress/PHP is pretty extensible and can be made performant with good caching.
Probably moving it to a better Wordpress host like Pantheon or WPEngine would speed it up with minimal effort (but possibly high hosting costs, which are usually still cheaper than dev time).
Depending on what additional flexibility you need, you might be able to write plugins to add just that functionality while keeping the basic ecommerce stuff in the core?
> Good thing is I will not be hiring any developers, the plan is to hire a development firm that will build out the website.
It would probably help if the agency has prior ecommerce experience with a popular stack. It doesn't have to be Woocommerce or Shopify specifically, but I'd stay away from something totally custom unless you absolutely have to. A commodity stack is a lot easier to maintain over time and to find people to work on later if they need to add additional features. Even something no-code/low-code like Wix/SquareSpace/Square these days has ecommerce built-in, and that's a heck lot less work than building a web app from scratch with no experience. At the very least, you should outsource payment processing at least, like to Stripe or others, instead of processing your own credit card payments using custom software (PCI compliance is hard and it's easy to accidentally create vulnerabilities)... you should never know your customers' credit card numbers if you can help it.
If I were doing this, I'd really look at the business (profit margins, how they handle orders and shipping and refunds and all that), who's on the dev team both now and for the foreseeable future, etc.
It basically comes down to how much staff the business wants to keep over time to maintain this thing in-house, vs outsourcing as much of possible to a specialized vendor that they can just have a contractual relationship with.
From one techie to another, this is the sort of thing any of us can build with some time and research, but that's the sort of project that can too easily backfire and end up creating a lot of tech debt for your client (your friend) if nobody else can easily maintain it later.
If your client uses a run of the mill Woocommerce setup, after you leave they can easily hire any ol' Wordpress dev for a few days to fix whatever comes up. That might cost a few hundred dollars.
But if you make something completely custom for them using a nonstandard stack, suddenly it's a multi-month affair for a much more experienced (and expensive) dev to come in and reverse engineer your whole stack and learn to extend it, only to extend it with their own nonstandard way. Suddenly this simple ecommerce site is now a full-blown web app requiring a whole team of specialists to maintain. Now it's several tens of thousands of dollars. It's not good for most small businesses to have to deal with something like that.
IMHO a commodity online shop shouldn't be a fancy vanity project; it should be simple and reliable and predictable and require the least amount of ongoing maintenance possible.
> Thanks for the info on the intricacies, do you have any resources that can help me out with those?
Sorry, I'm not the best person to ask that of :( I've mostly just learned through accumulated experience working on ecommerce and other sites.
I bet these days there are good online tutorials or YouTube videos to get you started, but an ecommerce shop is such a broad (if relatively shallow) app that it's hard to get it all right. It really depends on the level of functionality, security, etc. that you need, and at what budget, with what staff/expertise availabile.
At the simplest level, if you can outsource all actual order management and fulfillment to a third party (like Amazon or Shopify or whatever), you basically end up just creating a bunch of mostly static product pages that pulls pricing and order data from an API. That's not so bad since all the critical stuff is handled elsewhere.
But the moment you need to start maintaining your own databases for all that stuff, it can get a lot more complicated really quickly.
There are also partially-vendored solutions like CommerceLayer or Commerce.js that do some of the heavy lifting for you to add a simple frontend on top of, or old-school PHP monoliths like Magento (now owned by Adobe, apparently).
I don't know if you can afford this, but it might help to look at some high-level (abstract) ecommerce UX, like from the UX group NN: https://www.nngroup.com/reports/ecommerce-user-experience/ This discusses many of the user-facing concerns that you can think about whether you need to build. If you don't want to buy the report, you can also browse through their free articles and videos: https://www.nngroup.com/topic/e-commerce/. That just discusses the UX though and not so much the "how to build it" part.
If you've never done web dev before, some random keywords you can look into for an idea of what you might have to deal with are: payment gateways/hosted checkouts, iframes, CORS, TLS/HTTPS, PCI, AJAX, ACID, accessibility, internationalization, CDNs, responsiveness, dev/staging envs (or CI/CD for something more enterprise-y), network stuff (DNS, hosting, caching, load balancers if you get a lot of traffic), SEO, forms & validations & sanitization, roles & permissions & session management, LEMP vs Jamstack, CRM, transactional emails, SPF/DKIM/DMARC (email deliverability)... that's probably a good start? None of those topics are individually very difficult, it's just that there's so many of them to juggle together to make a basic, functional ecommerce solution :(
Your point about the technical debt is fully appreciated!
I am definitely aware of the challenges that maintaining full website like this can be, and totally not thinking about reinventing CC processing! With my initial research, an AWS based approach is what I had in mind, with most of the heavy lifting by AWS and Stripe for payments. I still don't know how I can stitch up everything with AWS, but thankfully I've found the developer docs to be fairly intuitive so far.
If you're not going to do be doing the hiring... mate, I don't think you're in a spot to manage them.
Best thing you can do to help is set good requirements. Be clear up front. Have designs ready. Know how you want integrations to work. For off-shore teams especially, you need to have workflows, annotated wires, a style guide, and some sort of clickable prototypes to get the most out of the team.
You do all this mostly so you know where you need to provide copy, and so you know you're picking and choosing how all the integrations work.
As others have pointed out, there are nuances to eCommerce that can be tricky.
Some basics... (for pretty much any project these days)
1 - Make sure all code goes into a repository you control. Make sure there are no passwords in the code, and that you know how deployments work, and can build one (ideally on your local) if needed.
3 - Have them use Wave. If they can build a site without accessibility issues, odds are they know HTML / CSS fairly well. Aim for No Errors or Contrast Errors or a it's a fail. https://wave.webaim.org/
4 - Have them use HTTP Observatory from the start (just keeps everyone mindful about integrations and 3rd Party tools... updates to the Content Security Policy is another great way for you to make sure your architecture diagrams are in good shape. Aim for a B+ or it's a fail. https://developer.mozilla.org/en-US/observatory
5 - Make sure everything they use is open-source and permissively licensed, or you're comfortable paying for the license. A lot of times people will use some sort of proprietary accelerator, and the only real way to maintain a site built on those is to keep paying the people who wrote the tools... shady. Just be mindful for stuff like this -- the best way, I've found, is to make sure you are watching what all is used and how it's all licensed.
6 - Make sure you document things well, and assume devs will cycle off and on the project. Off-shore teams typically cycle through devs quickly, so you'll need a way to on-board new devs to the project quickly. Keep your architecture diagrams, and onboarding doc, coding standards updated. Make sure you have everyone's contact info; don't put up with anyone using a generic account, or handing an account off to someone else... best way to prevent being scammed with a bait and switch. "Oh here's the dev you'll be working with..." and then they switch him for someone less talented or who doesn't communicate after the first session... no thank you. Ha. 2FA on everything helps a bit. I always insist on doing a video calls with the devs when hiring 3rd Party devs... I hate doing it, but it just sort of keeps everyone honest.
The Managers Path is mentioned earlier.
Can also recommend:
- The Art of Leadership by Michael Lopp (aka Rands of Rands in Repose fame)
Which tackles situations he encountered (and are all too familiar) while managing in various roles at Apple, Netscape and Slack.
- The Engineering Leader by Cate Hudson
What I think is absolutely great about this book is that it isn't just about how to deal with the people you are responsible for but also how to deal with _yourself_
- The Engineering Executive's Primer By Will Larson
This one is meant more for "Head of Engineering" types, but still contains tons of handy information to turn yourself into a effective leader.
And last but not least:
- Become an Effective Software Engineering Manager by James Stanier
Subtitle of this book says it all. Highly recommended!
For people management, The Manager's Path by Camille Fournier is fantastic. That said, managing an offshore team (that also sounds junior) is going to create many headaches in addition to those you'll normally face as a first-time manager. Good luck!
Thanks for the book recommendation, will check it out!
Do you have to hire new devs for this? Sounds generic enough you can farm it out to any Shopify or WordPress/Woocommerce agency and probably get better results.
Ecommerce has a lot of intricacies, from the checkout flow to cross-site inventory management to CRM to product returns to transactional emails to order management to security and payments and PCI compliance, etc. It's a well established pattern that there are readymade providers and best practices for, but if you have no experience as a web dev and are working with a bunch of juniors who also have no experience... you might create a lot of footguns along the way.
They already have a WordPress/Woocommerce solution that is slow and very inflexible for what they need. Shopify would be a good option, but they also take a hefty percent of every sale, not any better than 3rd party. Good thing is I will not be hiring any developers, the plan is to hire a development firm that will build out the website.
Thanks for the info on the intricacies, do you have any resources that can help me out with those?
What is making hte WordPress/Woocommerce solution slow/ what additional flexibility would be required. It sounds like it might a better use of money to optimize the Woocommerce site than to reinvent the wheel and have a whole custom ecomm app to have to maintain.
I haven't looked into what's making the current solution slow/bad. I agree, better to start with this before I try to build and maintain custom site
Hi if u want to hire ,I run a dev agency in Pakistan
> They already have a WordPress/Woocommerce solution that is slow and very inflexible for what they need.
I concur with the other poster that it's probably easier/safer to fix and/or extend the Woocommerce with additional functionality than to try to reinvent the wheel from scratch. Wordpress/PHP is pretty extensible and can be made performant with good caching.
Probably moving it to a better Wordpress host like Pantheon or WPEngine would speed it up with minimal effort (but possibly high hosting costs, which are usually still cheaper than dev time).
Depending on what additional flexibility you need, you might be able to write plugins to add just that functionality while keeping the basic ecommerce stuff in the core?
> Good thing is I will not be hiring any developers, the plan is to hire a development firm that will build out the website.
It would probably help if the agency has prior ecommerce experience with a popular stack. It doesn't have to be Woocommerce or Shopify specifically, but I'd stay away from something totally custom unless you absolutely have to. A commodity stack is a lot easier to maintain over time and to find people to work on later if they need to add additional features. Even something no-code/low-code like Wix/SquareSpace/Square these days has ecommerce built-in, and that's a heck lot less work than building a web app from scratch with no experience. At the very least, you should outsource payment processing at least, like to Stripe or others, instead of processing your own credit card payments using custom software (PCI compliance is hard and it's easy to accidentally create vulnerabilities)... you should never know your customers' credit card numbers if you can help it.
If I were doing this, I'd really look at the business (profit margins, how they handle orders and shipping and refunds and all that), who's on the dev team both now and for the foreseeable future, etc.
It basically comes down to how much staff the business wants to keep over time to maintain this thing in-house, vs outsourcing as much of possible to a specialized vendor that they can just have a contractual relationship with.
From one techie to another, this is the sort of thing any of us can build with some time and research, but that's the sort of project that can too easily backfire and end up creating a lot of tech debt for your client (your friend) if nobody else can easily maintain it later.
If your client uses a run of the mill Woocommerce setup, after you leave they can easily hire any ol' Wordpress dev for a few days to fix whatever comes up. That might cost a few hundred dollars.
But if you make something completely custom for them using a nonstandard stack, suddenly it's a multi-month affair for a much more experienced (and expensive) dev to come in and reverse engineer your whole stack and learn to extend it, only to extend it with their own nonstandard way. Suddenly this simple ecommerce site is now a full-blown web app requiring a whole team of specialists to maintain. Now it's several tens of thousands of dollars. It's not good for most small businesses to have to deal with something like that.
IMHO a commodity online shop shouldn't be a fancy vanity project; it should be simple and reliable and predictable and require the least amount of ongoing maintenance possible.
> Thanks for the info on the intricacies, do you have any resources that can help me out with those?
Sorry, I'm not the best person to ask that of :( I've mostly just learned through accumulated experience working on ecommerce and other sites.
I bet these days there are good online tutorials or YouTube videos to get you started, but an ecommerce shop is such a broad (if relatively shallow) app that it's hard to get it all right. It really depends on the level of functionality, security, etc. that you need, and at what budget, with what staff/expertise availabile.
At the simplest level, if you can outsource all actual order management and fulfillment to a third party (like Amazon or Shopify or whatever), you basically end up just creating a bunch of mostly static product pages that pulls pricing and order data from an API. That's not so bad since all the critical stuff is handled elsewhere.
But the moment you need to start maintaining your own databases for all that stuff, it can get a lot more complicated really quickly.
There are also partially-vendored solutions like CommerceLayer or Commerce.js that do some of the heavy lifting for you to add a simple frontend on top of, or old-school PHP monoliths like Magento (now owned by Adobe, apparently).
I don't know if you can afford this, but it might help to look at some high-level (abstract) ecommerce UX, like from the UX group NN: https://www.nngroup.com/reports/ecommerce-user-experience/ This discusses many of the user-facing concerns that you can think about whether you need to build. If you don't want to buy the report, you can also browse through their free articles and videos: https://www.nngroup.com/topic/e-commerce/. That just discusses the UX though and not so much the "how to build it" part.
If you've never done web dev before, some random keywords you can look into for an idea of what you might have to deal with are: payment gateways/hosted checkouts, iframes, CORS, TLS/HTTPS, PCI, AJAX, ACID, accessibility, internationalization, CDNs, responsiveness, dev/staging envs (or CI/CD for something more enterprise-y), network stuff (DNS, hosting, caching, load balancers if you get a lot of traffic), SEO, forms & validations & sanitization, roles & permissions & session management, LEMP vs Jamstack, CRM, transactional emails, SPF/DKIM/DMARC (email deliverability)... that's probably a good start? None of those topics are individually very difficult, it's just that there's so many of them to juggle together to make a basic, functional ecommerce solution :(
Your point about the technical debt is fully appreciated!
I am definitely aware of the challenges that maintaining full website like this can be, and totally not thinking about reinventing CC processing! With my initial research, an AWS based approach is what I had in mind, with most of the heavy lifting by AWS and Stripe for payments. I still don't know how I can stitch up everything with AWS, but thankfully I've found the developer docs to be fairly intuitive so far.
Appreciate all the additional info too, cheers!
If you're not going to do be doing the hiring... mate, I don't think you're in a spot to manage them.
Best thing you can do to help is set good requirements. Be clear up front. Have designs ready. Know how you want integrations to work. For off-shore teams especially, you need to have workflows, annotated wires, a style guide, and some sort of clickable prototypes to get the most out of the team.
You do all this mostly so you know where you need to provide copy, and so you know you're picking and choosing how all the integrations work.
As others have pointed out, there are nuances to eCommerce that can be tricky.
Some basics... (for pretty much any project these days)
1 - Make sure all code goes into a repository you control. Make sure there are no passwords in the code, and that you know how deployments work, and can build one (ideally on your local) if needed.
2 - Have them use Lighthouse. Aim for 90s in all categories or it's a fail. https://developer.chrome.com/docs/lighthouse/overview/
3 - Have them use Wave. If they can build a site without accessibility issues, odds are they know HTML / CSS fairly well. Aim for No Errors or Contrast Errors or a it's a fail. https://wave.webaim.org/
4 - Have them use HTTP Observatory from the start (just keeps everyone mindful about integrations and 3rd Party tools... updates to the Content Security Policy is another great way for you to make sure your architecture diagrams are in good shape. Aim for a B+ or it's a fail. https://developer.mozilla.org/en-US/observatory
5 - Make sure everything they use is open-source and permissively licensed, or you're comfortable paying for the license. A lot of times people will use some sort of proprietary accelerator, and the only real way to maintain a site built on those is to keep paying the people who wrote the tools... shady. Just be mindful for stuff like this -- the best way, I've found, is to make sure you are watching what all is used and how it's all licensed.
6 - Make sure you document things well, and assume devs will cycle off and on the project. Off-shore teams typically cycle through devs quickly, so you'll need a way to on-board new devs to the project quickly. Keep your architecture diagrams, and onboarding doc, coding standards updated. Make sure you have everyone's contact info; don't put up with anyone using a generic account, or handing an account off to someone else... best way to prevent being scammed with a bait and switch. "Oh here's the dev you'll be working with..." and then they switch him for someone less talented or who doesn't communicate after the first session... no thank you. Ha. 2FA on everything helps a bit. I always insist on doing a video calls with the devs when hiring 3rd Party devs... I hate doing it, but it just sort of keeps everyone honest.
[dead]