I am expanding my team of Senior Engineers across Canada, is it true that I can claim up to 50% in salary compensation per employee? And if so how?

A great team looks like this - 2 full stack engineers. They can manage servers, security, build features and code front end JS/interactions. - 1 visual designer focused on product, information architecture, UX and flows. - 1 front end developer who can take designs and built out killer interactions and can wireup any back end code to the UI The CEO can manage product + customer development and everyone on the team does support. That's 5 people and can accomplish a lot!

I am assuming your question is more pertaining to empowering and motivating (rather than hiring). I can outline some of the practices I have seen really result in high motivation and sense of ownership among engineering teams: * Empathize - Your engineering team will work well and be more motivated if they see you as one of them rather than a person who doesn't understand their function. Show your geeky side to them, and show that you understand their thought process and drivers. * Pick their brain on big and small decisions (roadmap, usability, whatever it is) - Product teams value being heard. The more you position yourself as someone who is WANTS to listen, is keen to have their inputs, you will be surprised at how involved they can get, and also how you can actually tap into a lot of smart ideas/thoughts from them that you can develop on. * Take care to explain - show how you arrive at decisions. Share your research, competitive analysis, and even your thought process on arriving at a feature set or list of things for a release. Its stuff you would have worked on anyway - so no harm sharing with more eyes! * Share customer feedback - nothing motivates your engineers than a positive interaction with a customer. Get them to see customer feedback. Have them sit in and observe some of the usability studies. (B2B - have them see you do some demos or do a successful sales pitch) * Send out interesting articles, insights, business and tech articles with your comments/highlights to them on a regular basis (maybe twice a week?) - maybe even some analysis you did on competition or customer feedback * Engineers like working with people they feel are competent and complement the work they are doing to build a great product. So make sure they see how everyone else around them is also doing a good job and adding value and contributing to the success of the product. * Be transparent about the product/business - Make them feel they are responsible and involved in the business, not just technology. I've seen engineering teams happy about their annual goals having components relating to making revenues, keeping customers happy, or reducing costs. If they are enthused about the business as a whole, they will be more motivated with their engineering efforts * Have a mix of little experiments, R&D, attending to engineering debt, in addition to bug fixes and new features that each engineer gets to spend some time on (based on their interest) * Finally get to know each of your engineers personally, and be aware of what their priorities are. Each of us has different motivations in life, so there is no silver bullet to motivate people. When they know you care for them, they are more motivated :).

This is a typical problem with any start-up, i.e. intention to trade everything for equity. I am assuming that you're trying to trade equity for cash. In that case I would suggest you to look out for individuals with diversified skills and competencies. The reason being, less the number of individuals less the amount of equity that would be required to trade. Second option could be to look out for agencies to whom you could outsource the business process. I am not at all ashamed to mention that my own company is one such agency. However, my only piece of advice to to try and add some retainership component to your model, apart from equity, as in a long term it's easier for people to lose motivation in absence of any capital gains. The reason being, people don't understand the value of equity in startup. Rather, the time it could take for that equity to turn into something big; it may not happen as well. That's why they say there's nothing called free lunch. In my more than a decade experience working with entrepreneurs and helping them bootstrap, I have learnt that the market out there is crowded with individuals with a lust to join startup as a equity holder. In a short term, they may speak all those rosy language that may sound like coming directly from the Horse's mouth. But, in a long term you realize not everything is hunky-dory. As far as finding a co-founder or a CTO or any other executive team member is concerned, ensure that you put down the roles and responsibilities attached with each title. Apart from above, ensure that you communicate your expectation lucidly and understand the values everyone is required to bring on the table. Usual people who could be a good fit for you, apart from any agency, are people who aren't big on title. Is there anything specific you're looking at? Please feel free to revert with more clarity to receive clarity. I am just a call away. All the best!!

I feel your pain — I've been there several times in a couple of my companies. Each situation ended up being unique, and had to be handled differently. I think there are a few things to consider before you make your decision: -- 1. What is in your cofounder's way? Is you cofounder being held up by a lack of clarity? Lack of motivation? Lack of autonomy? One of my past cofounders was very good at getting the job done, but didn't naturally have the skill to lay out tasks in a manageable way. To get around this, I worked with the whole team (4 people) to write up process documentation that removed the need to "figure out what to do next" that was tripping up this cofounder. -- 2. What job was your cofounder brought on to complete? And is it being completed? One of my companies brought on a cofounder simply to give us a marketing platform — he had a huge online audience — but he did nothing else. At first, this caused tension; once we had specifically laid out who was on the team and for what purpose, it was easier to identify where responsibilities lay. -- 3. Is your cofounder capable of doing the job? One of the more painful ordeals I've gone through in business is bringing on a good friend, then realizing that — despite his talent and intelligence — he just wasn't able to perform the job I'd hired him for. His skills were better suited for a different job: he needs hands-on management; he works better with repetitive tasks that don't require big-picture thinking; he lacks assertiveness and confidence, which were critical for the management-level role he'd been hired to do. After I tried to clear everything in his way, it became clear the company couldn't survive if he remained on the team. I had to lay him off. -- 4. Do you just simply not like the way this cofounder works? In one of my startups, there was a cofounder who I didn't know all that well, but he had amazing industry contacts and domain knowledge. However, once we started working together it became clear that we had VERY different working styles. He drove me completely nuts with (what seemed to me to be) a very ADHD-style of planning, with projects starting and being dropped and then coming out of nowhere with a call at 21:00 to discuss something critical that would be forgotten tomorrow. I'm sure I drove him nuts, too. So eventually we ended up selling that company — it was that or shutter it — because we knew there wasn't a chance we'd be successful if we continued as we were. -- Working with other people is tricky in general. Our instinct is to assume that we're the best workers on the planet and everyone else is incompetent, an idiot, a slacker, or all of the above. Usually it's a combination of an organizational-level lack of clarity, poor communication, no processes, and (sometimes) plain ol' we-don't-see-eye-to-eye-on-things-ness. Hopefully that helps. Feel free to get in touch if you'd like to hear specifics on my situations, or if you'd like any help devising a strategy for resolving your cofounder trouble. Good luck!

I've been involved in several projects that hinged upon this question (generally start-ups or web+mobile apps), and it's not a clean or easy answer unfortunately! Plus every developer you talk to is going to try to sell you their services, but what you need is simply the truth! I'd suggest that you consider shifting your focus away from finding a best language. That sort of premise can eliminate options that are actually quite valid solutions. Keep in mind that any mobile app will require multiple languages working in harmony - all while used in a commercially consistent and standards-based manner. That's the part that determines your technical scalability! Almost every programming language can achieve this functionality with an experienced developer on your team. The best advice I can give you, is to consult with at least two people on this, and three if your app is os-specific. The most important insight will come from a "full stack" developer. One who's got a variety of enterprise experience, and can code at all levels of the stack. This person needs to have experience in leading a team of other developers, which forces the strategy of which technologies to use and why onto their plates daily. Secondly, you'll want to consult with a "front end" developer, who can tell you what's possible using advanced OOP JavaScript techniques (like Google's angular.js), because in an absurdly fast change over the past 3 years, much of the formerly back-end work has made it's way to the front-end, and is driven by JavaScript, predominantly JSON data, and awesome API's. The game has changed and the front-enders are the poor souls dealing with this rapid shift daily. To do this, they're also fantastic JavaScript programmers, which is a language that runs on all mobile devices and all browsers, too. Love it or hate it JavaScript is the most commonly used language in the world. Finally, if your app is OS-specific, you'll want to consult with a developer who works predominantly with the OS your app is built for. This person lets you know what's possible from the device POV, should know what stacks and JavaScript approaches can and can't be done on that OS, and how to leverage the resources of the device for your app as well as extend it's functionality. BONUS - loop back to the full stack developer to double-check the claims of the front-ender and the mobile developers. Always double check with your most senior programmer ;) All of these consults together in addition to your own research and due diligence will get you comfortable and allow you to navigate on this rather daunting but deeply important journey. There aren't any turn-key options. Instead it's a series of inter-connected modules driven by different languages, and all working in tandem. Every solution will have bugs, and no one group of technologies can do everything without proper developers. If you'd like to go further down the rabbit hole, then we should definitely set-up some time to speak. Otherwise, I wish you great luck in research and encourage you to learn as much as you can! :) It's going to seem hard, and might give you a headache here or there, but learn everything you can about how different technologies "talk" to each other, and then you will be able to build a map for keeping your app and business scalable regardless of the changing tides of technology!