Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

To become a software consultant, avoid letting clients pay you for code (2017)

daedtech.com

Post reply on HN
Print view View original

81–90 of 135 posts

Re: To become a software consultant, avoid letting clients pay you for code (2017)

#81

Post by rorykoehler »

nkohari wrote: post #7
geekuillaume wrote: post #3

Earlier quoted context omitted.

I'm working on a new consultant biz, oriented toward "freelance CTO" for early-stage startups. It's general purpose but provide a non-technical client a better view of the technical aspects of their product. I'm convinced it has a lot of value for this kind of clients.

I tried this a bit myself. You are right that you can provide tremendous value, but early-stage startups either don't have, or aren't willing to spend, the money that you deserve for the value you'd provide. Maybe there's a niche you can target that I was unaware of. Hopefully you have more success!

This is why I decided to offer the same fractional CTO service but to focus on small cap listed companies.

Re: To become a software consultant, avoid letting clients pay you for code (2017)

#82

Post by 01100011 »

tptacek wrote: post #75

This notion of the distinction between contractors and consultants as a career status strikes me as similar to the distinction we make between developer and manager. And then, this is useful advice if what you want to do is manage, and code less. I've been consulting professionally since 2005, and I think I've gotten pretty good at it? And my take on this is, graduating from "IC" to "manager" in the eyes of your clie…

I think the biggest failures at the software consulting houses I've worked at have come from not building adequate tooling and not establishing a framework for knowledge/skills transfer. A close runner up would be failures related to trying to build actual products. The problem with consulting though is scalability. You can make a product and recoup your NRE with the first x units, and then most of what you sell beyond that is pure profit which can roll in while you sleep. Scaling a consulting business is tough. You just have to increase billable hours and that is a lot tougher than it sounds(especially in the current market).

I made a lot of money in consulting over the years, but at the middle of my career I find myself looking for a product company to call home. Consulting can be great... or it can be terrible. My friend is now charging $165/hr for his solo corp... but sometimes the invoices never get paid and you have to swallow a loss(I'm owed over $14k currently and will probably never see it).

Re: To become a software consultant, avoid letting clients pay you for code (2017)

#83

Post by beatgammit »

mlthoughts2018 wrote: post #28
rumok wrote: post #23

Earlier quoted context omitted.

I'm genuinely curious, why do you believe scrum to be "stupid and horrible"?

Many years of experience with it across orgs of various sizes and ages. One-size-fits-all software management and metrics about planning and velocity are things that exist to give middle management surface area to tell whatever political blame/credit stories they want, and have not got shit to do with productivity, adjusting to change, or delivering anything. And don’t even get me started on why Agile is emphatically…

No single methodology is right for everyone, but lean principles tend to be a better fit for most. And that's really what Agile and Scrum are.

The most important thing for teams is to establish a rapid feedback loop, and make sure someone is tasked with handling that data. Once you know your customers' needs, you can act to resolve them. If you're using a waterfall approach, you can miss the window, which delays your ability to get changes in front of customers, which delays feedback and increases the chance that you're wasting time.

Before we adopted an Agile-inspired process, we had several projects get scrapped after weeks or months of work because we misunderstood the customer's problem. When we adopted a new process, we built smaller MVPs (took days instead of weeks) and got customer feedback that indicated we needed to make a shift. Many of our features got smaller because we didn't get time to over-engineer them.

The major flaw, IMO, is technical debt. Our product is released on a schedule, but we get feedback from users with alpha products, so we have time to clean up the implementation once we get hands-on feedback from customers.

If we adopted Agile 100%, we likely would rack up more technical debt, and I've actually seen this happen in that same company as management made changes (I became trainer and technical lead instead of project manager).

If you drink too much of the kool aid, you'll get a stomach ache.

Re: To become a software consultant, avoid letting clients pay you for code (2017)

#85

Post by beatgammit »

gk1 wrote: post #36
PeterStuer wrote: post #20

Having seen all type of consultants over the year: - The strategic consultant you describe manages to have a higher tariff, but the sales cycle is long and the downtime between gigs significant - the 'software consultant' has an on average lower tariff (depending on the specialization), but little downtime and faster sales. Pick your poison and do what you feel most comfortable with.

I disagree. I fit into the “strategic consultant” category and my sales cycle from referral to signing is a few weeks, with zero downtime because I work on several projects at once. The great thing about being independent is you can design your engagements however you want. Not happy with amount of downtime? Find a way to do two (or more) projects at once. Not happy with sales cycle length? Simplify your offerings. A…

What does this mean exactly? Do you essentially build the specs and someone else does the work? Or do you see the project to completion (you design and implement the product)?

I'm really confused because I really didn't see anything meaty in the article other than "talk about problems, not implementation". I thought the article was going to be about "licensing" vs "copyright transfer", but instead got a lecture about something far more nuanced.

Is the difference just terminology and how you present yourself? If so, what terminology to people look for, and how does a project work from start to finish for you?

Re: To become a software consultant, avoid letting clients pay you for code (2017)

#86

Post by beatgammit »

I'm confused. The title made the think the article would be about licensing is IP transfer on project completion, but I got a lecture on what I consider to be a nuanced lecture about marketing.

Because of this and the reactions here, I'm sure I'm missing something and I think others may as well.

Is the author essentially saying "outsource the development?

As a consultant, I'm expecting to sit with the client, figure out their problem, and provide a solution. I charge based on the project and provide a breakdown of how much they'll pay for each deliverable and when it'll be available. The customer doesn't have to care who does the work (it'll probably be me), provided the deadlines are met, and at anytime the client can stop (they'll pay for any in-progress work).

Is that what the author is saying? Or are they saying to avoid taking any responsibility over the development process? Subcontracting is always an option, so if there's too much work, outsourcing is an option. I just don't feel comfortable just delivering a design, but I can if that's objectively better.

Re: To become a software consultant, avoid letting clients pay you for code (2017)

#87

Post by chrisbennet »

acconrad wrote: post #39
chrisbennet wrote: post #16

One way to get clients to respect your input is to charge a lot.

Easier said than done. They may respect you but they'll also likely not hire you. They have to respect you AND know you. It's hard to justify paying someone a lot if they are an unknown quantity. I checked out your HN profile: do you think you can hire more because you specialize in Computer Vision/Graphics? I'd also imagine your clientele is highly-targeted as well?

"I checked out your HN profile: do you think you can hire more because you specialize in Computer Vision/Graphics? I'd also imagine your clientele is highly-targeted as well?"

Sorry, I didn't answer your question. Yes, to some extent, they just can't find someone else to do their project. I've got a kind of bizarre mix of skills I guess.

I'm not sure what you mean exactly by "highly-targeted". I don't look for clients, they just fall in my lap. They probably fall in my lap because I have those skills (and some others). The typical job goes something like this: someone I've worked with before asks me if I'm available and if I could do something like X. I tell them, "Why yes, I'm an expert in X, as far as you know." (Just kidding.)

Re: To become a software consultant, avoid letting clients pay you for code (2017)

#88

Post by PeterStuer »

warent wrote: post #33
PeterStuer wrote: post #20

Having seen all type of consultants over the year: - The strategic consultant you describe manages to have a higher tariff, but the sales cycle is long and the downtime between gigs significant - the 'software consultant' has an on average lower tariff (depending on the specialization), but little downtime and faster sales. Pick your poison and do what you feel most comfortable with.

When you say tariff do you mean price?

Sorry for the confusion, I think the correct term is 'hourly rate', what you charge as a consultant for your time.

Re: To become a software consultant, avoid letting clients pay you for code (2017)

#89

Post by AgalmicVentures »

rpeden wrote: post #53
acconrad wrote: post #40

Earlier quoted context omitted.

When I got into consulting I read that MacKenzie article and answered an ecstatic "Yes" to all three and yet people see my resume and previous work and just immediately slot me into the "code monkey" territory. I am able to negotiate a great rate, so I've done very well, but I believe I could do better if I was able to get the higher value projects, but no one has yet to perceive me this way.

Is it possibly because you've positioned yourself in a such a way that you attract customers who will only ever see you as a coder for hire? I love the look of your consulting website, but "We create beautiful, engaging applications" isn't a very strong positioning statement. Most generalist software shops have something similar on their site. And if you position yourself that way, whether online or in person, I thin…

Thank you so much for writing this. I've struggled with positioning for a long time, and although I have a niche, it was a challenge to communicate the value I offer in a succinct way. This nails it:

> You don't just deliver code. You deliver complete end-to-end solutions that don't require the customer to specify everything in excruciating detail. Instead, you're like an amazing machine to which customers only have to insert high-level business requirements.

Reading over the website, The Positioning Manual seems to have more actionable information than the sum of all other source I've found, so thank you for that too.

Re: To become a software consultant, avoid letting clients pay you for code (2017)

#90

Post by vram22 »

tptacek wrote: post #75

This notion of the distinction between contractors and consultants as a career status strikes me as similar to the distinction we make between developer and manager. And then, this is useful advice if what you want to do is manage, and code less. I've been consulting professionally since 2005, and I think I've gotten pretty good at it? And my take on this is, graduating from "IC" to "manager" in the eyes of your clie…

>2. Specialize. Start looking for commonalities between the projects that you do. Build tooling for them. Maybe publish some open source stuff. Build a specialty practice around that. You can do this repeatedly, for different areas; eventually, you'll do it for business verticals.

A former manager of mine, who had some consulting background, once told me that the big management consulting firms like McKinsey do something like this. They compile tons of detailed case studies from former engagements (that's what consulting gigs are called in that field) and then reuse the hell out of them for new gigs, thereby saving a lot of their staff's working time on those. Also probably surprise the clients (who may not know about this practice) by being able to come up with results sooner due to this.

Post reply on HN