3 ms·

Good questions. > Do you have clear milestones and performance metrics? Milestones yes, performance metrics not so much. Main reason here is that we serve dif

• gregjor 4y ago
  I have freelanced for about 15 years. I normally have multiple customers and projects simultaneously. I rarely manage other programmers so I’m only responsible for my own productivity. My customers know I have other jobs, they have to trust me that I don’t disclose their secrets or work for a competitor. It’s never presented a problem. With my customers I am continuously negotiating goals, milestones, expectations, costs, and risks. I want my customers to understand what they are paying for and what I am committing to. As much as possible I try to charge for deliverables rather than for my time, but sometimes customers prefer to pay by the hour, or on a retainer. However we work that out I try to always make sure my customer and I are clear about what they expect from me and how much time that will take and what it will cost. That comes down to communication, and generally we iterate on their goals. Measuring productivity is a hard problem, and even harder for creative people who may have large variations in their own productivity over time, and aren’t directly comparable to other individuals. I would start with setting clear goals and measurable deliverables and then getting the employee to commit to those. That means breaking the work down into measurable pieces, which will happen one way or another, so it’s probably best to do that work up front so no one gets surprised. Communication is something you can set clear expectations about. For example I commit to my customers that I will answer routine emails the same day, and urgent emails or phone calls immediately. I ask my customers to respect my time and if everything turns into an emergency with them we’ll have to talk about that. You should have some idea of what fair pay or market rate looks like for the people you employ. Personally I don’t believe it’s fair to pay people less because of where they live — everyone should get paid according to the value they add, whether they live in London or Bangalore. If you don’t pay people enough they will take on other jobs, or look for a job elsewhere. I would not sign a contract that obliged me to inform my employer or a customer about other work. Sometimes issues of competition and intellectual property come into play. If someone is inclined to act unethically or break the law a contract clause isn’t likely to stop them. If you ask employees to agree to inform you of outside work, what do you agree to in return? Do you inform your employees about all of your customers? How much the company gets paid by customers? Whether the founders have other business commitments? Bottom line is you pay people for their work, period. You can’t expect loyalty or openness or trust, especially if it’s one-way in the company’s favor. People are loyal to employers who treat them well. They trust employers who trust them and treat them with respect. How open someone is with their employer is really up to them — they don’t owe that to their job.
  • NaTopp 4y ago
    > I want my customers to understand what they are paying for and what I am committing to That's what I'd like to see from everyone (generally spoken). Anyhow, thanks for your thoughts and sharing your experiences! There is a lot of value in it. I guess communication is - as usual - a huge factor in all of this (from each party). ---- > For example I commit to my customers that I will answer routine emails the same day, and urgent emails or phone calls immediately. That's very valuable and honest from you. But it's you who is doing that. Not everyone acts like that (from my experience). So how would one be able to create a proper adherence for such a commitment (that was agreed on while signing the contract)?
    • gregjor 4y ago
      I don’t know how your company works, so I’ll make general comments. People who manage, including those who manage programmers, too often don’t actually do the work of managing. A big part of managing a team or project is making sure everyone knows what they are expected to do, how long that will take, how much it will cost, what risks it involves. It also means discussing alternatives and fallbacks. At all times the manager should know what people are working on, when to expect delivery, and know how to detect schedule/cost slips early on. The programmer(s) should know exactly what they are supposed to be doing, and what “done” looks like — what their deliverable is. What I actually see most of the time is vague requirements like “make an e-commerce site in six months” from management (or in my case, customers), and the programmers left on their own to figure that out. Then the team spends five months arguing about programming languages and tools and the “best” approach to edge cases while nothing gets delivered, and their manager is not paying attention. If the manager set the deliverables the team could work to deliver in a clear way. “Site structure with navigation but no content or functionality in two weeks,” for example. Give the team a few days to decide on language and tools and so on then move forward. With short iterations it should be obvious fairly early if the tasks are too vague, or the estimates are way off, or if the team is not working on the agreed-to goals. When those problems become apparent the manager (or customer) and the programming team identify the cause and adjust so the next iteration (call it a sprint if you want, same thing) goes better. The team should be delivering all the time — manager should not allow 80% of the schedule to go by without seeing continuous progress. In my case I’m putting something in front of my customers every few days, and my deliverables are easy-to-measure things like (for example) import these CSV files into a Postgres cloud instance, or verify that the addresses users enter have valid ZIP codes. With a more experienced and “gelled” team you can make the deliverables a little broader. I’m describing Agile development, but not the rituals and nonsense that have made the term almost meaningless. Iterative development with clear tasks and deliverables, and a feedback loop with the customer, right from the beginning. As for communication, you can set those expectations and if the programmer is not talking to the team, or the manager, or customer, within the time limits you both agreed to, you have a performance issue to deal with. Poor communication sinks projects more often than not understanding binary trees. From my own customers the number one thing I hear is “The last developers stopped answering my emails and phone calls.” I make a point to always answer and keep my customers informed, which puts me in the top tier of freelancers even if I’m not the most technically awesome programmer.