Yes. I'm in diapers in terms of experience compared to you, but I tweeted about this as a reply to people who want to get into consulting/freelancing. A few things that came to my mind at that time from exclusively dealing with large organizations for mid six figure contracts that one or two motivated people could pull off[0][1].
Are you doing this as an individual or through a company? In any case, why one and not the other?
- [0]: https://twitter.com/jugurthahadjar/status/131066829330549965...
- [1]: https://twitter.com/jugurthahadjar/status/131971626283503206...
I don’t have much formality or process. I ask potential clients to make a list of their priorities, pains, problems and then attach a value to those. I build long-term relationships by communicating and delivering what I promise, and taking an interest in the client’s business.
When I ask clients what went wrong with their last developer it’s usually poor communication or not understanding the business priorities, or both. It’s never “They didn’t know how to balance a binary tree with Rust.”
This is the secret of being "good" at consulting.
If I am a business, and I have a problem, and I bring in a consultant to solve that problem, and I have to assign one of my people to handhold the consultant through solving the problem, then I've now (1) paid for a consultant & (2) lost substantial amounts of one of my peoples time.
So I had 1 actual problem, and now I probably have 2.5 problems: paying a consultant, less productivity out of one of my people, and a half-working solution to the original problem.
As a good consultant, your job is to change that equation. Have a light footprint on other people's time & communicate clearly and concisely. Make sure you understand the actual problem, and weigh in if you're being asked to build a solution that doesn't solve it well (there may also be good reasons you aren't informed of about why it's built that way).
It's not hard. But it is specific. And trainable in yourself!
Most companies are variations on the same theme. And their dysfunctions are variations on the same problems.
"Building the solution" is table stakes. The real skillset for consulting is shadow-technical-PMing.
Remember: by definition, you're parachuting into a company that wasn't able to efficiently and effectively solve this problem themselves. So is it reasonable to expect them to tell you how to solve it? ;)
As a consultant, don't be an administrative burden for the client, be someone that gives them a feeling they can really stop worrying about their problem or task, because a real pro now has it in hand and it will magically get solved, and they will get the correct reports so that everyone is happy etc.
Ideally you let them imagine you are much, much better than anyone they've ever worked with, by rolling with that idea and not doing anything to detract from it. It's what they want to believe from the start, so you actually have some advantage from that. E.g. you can communicate when other people would avoid doing so, which often helps a business problem anyway, and you are likely to be presumed quite authoritative, even if you're secretly reading up on the material as fast as you can between meetings.
And be straight with the client if at all possible about issues, including whether you're being asked to do the right tasks, and manage yourself as if you had a great manager and PM so they don't have to. If necessary, help with gaps in managing other people too, but gently, by making sure people know bits of information that help, and taking small initiatives as long as they help. Overall be like you are wise, insightful, helpful, and understand engineering and businesses better than anyone they could hire normally, even if it's not really true.
I have just been a problem to two of my current clients, because of a timing conflict (and being messed around in a serious way by another company). That anguishes me and I'm now in repair mode. ethbr0's advice is exactly what I will be trying to get back to, and in the spirit of "be straight with the client" I will literally tell them that I understand why they hire a consultant, that I failed and have cost them (because I really have), and what I'm doing to rectify the problem. It's likely to work out fine, because once they (all the relevant people) feel that I really understand what they need, they're likely to stop worrying and be glad that someone else is making the problem magically disappear again. It will take about 1 meeting per person and some good deliverables, and a week or so for the network of managers talking to managers to calm down, until they feel that way, but me showing understanding and an aura of "humility, integrity and leadership" usually means they go back to all the other busy things occupying their time, confident I'm "on it" again.
After a while, I arrived at the conclusion that it wasn't. I could try to get enough business domain knowledge to put up an act like I was a mediocre junior trader or banker, or I could better spend that time to improve myself learning tech (and studying for interviews for that matter).
Plus if I were to leave the finance industry (which I'm desperately trying to do), none of that business domain knowledge would be portable, whereas most of my technical knowledge would be.
Just my two cents, but then again, I'm not looking at freelancing.
The point I meant to make is about understanding and taking an interest in business priorities. When you work for a bank or any company that isn't in the software business it's important to understand that their priorities have little or nothing to do with programming languages or technical debt or the many other things programmers obsess over. It's not that those things aren't important to programmers, but they aren't usually business priorities.
My customers rarely care what language or tools I use. Technical debt is not a big concern to them because they have short-term goals, they know the business landscape will change, and they've amortized the cost of software development and maintenance (or at least think they have). The key insight for me was understanding that "reduce shipping costs" as a business priority may have a technical side, but problems like that are rarely 100% software or technical problems, so it's important to see the entire problem and have the language to talk to people who aren't programmers to get to a solution.
I have observed my own customers sitting through presentations from developers or people selling software products and noticed, more often than not, an intense focus on technical details, but little or no interest in business priorities. Choice of programming language might be important, but it's not a business priority most of the time. Rewriting a legacy application in Rust might make sense in terms of programming and future maintenance, but may not make any sense in terms of addressing business needs. To freelance/consult successfully outside of the small niche of pure software companies you have to try to understand the actual problems and requirements, and resist the tendency programmers have to immediately reduce the problem to code.
I'm not sure I'm expressing this very well. Here on HN I see programmers posting that they just want to code in their favorite language and skip meetings and be left alone by managers and users. I see people complaining about the "stack" they have to use and writing about quitting so they can work with shinier newer things. While I like that mode too, it's not an attitude that will lead to successful freelancing/consulting, because it's too disconnected from business requirements.
Another way to look at it: software development projects generally fail or rack up big budget/schedule overruns because of misunderstanding of requirements, and miscommunication within the team and especially between the team and the business stakeholders. An example from my own experience: a brick & mortar company paid for a new e-commerce site. A week before go-live was scheduled the owner (not a technical person by any stretch) discovered that the new site did not have any provision for shipping charges or state sales taxes. She assumed the developers would know that, because any company shipping physical products has shipping costs and has to collect sales taxes. The developers blamed the customer for not spelling those requirements out. Late project, each side blaming the other, bad feelings, a potential long-term relationship spoiled. At one point in my early career I would have blamed incomplete requirements. Today I would take the customer's side -- developers selling themselves as e-commerce experts should have asked about shipping and taxes, even though those are business domain questions. My solution was to help the customer move to a SAAS e-commerce solution, which meant changing some minor parts of her business process, but kept her away from owning custom software that almost no one would want to touch in six months. I didn't get as much money from that customer as the original developers, but I'm still on speaking/consulting terms five years later whereas the original developers got sued for breach of contract.
If you are a UI designer, a little bit of knowledge about web developer can help you make UI choices which work for both the customer and for the developer.
If you as a developer know a bit about Ops, you can tweak your website design to hopefully make OPS better. Or atleast start broaching the question with your Ops girl
It happens anythime there is collaboration: knowing a little about the capabilities and constraints of the people upstream and downstream of you (suppliers and customers (perhaps internal)) helps you make better decisions or at least have better conversations etc.
This is a precious comment and i totally agree with you the things you mentioned. Understanding the business problem is more important compared to what stack or programming language to choose.
It doesn’t matter if you choose python,golang or java as long as it solves the business requirements that’s all what matters and programming languages are tools but its good to choose the right tools for the job
You get it. Sometimes the problems are cool - like some of the financial recon projects I worked on required neat algorithms (not complex or exotic ones, but "fun" ones) to solve something in Python in 1 minute that a R programmer's (they weren't great) script took 10 hours to solve - but most projects are boring implementation wise.
Actually, most of my really, really good and valuable work doesn't amount to any more than comparing Excel files, and giving you a report on that data. Tons of companies need that.
It's a commonplace observation that data has more value than code to companies. Lots of their data is in spreadsheets and databases (relational or otherwise). I've seen medium-sized companies running their operations in Filemaker, Access, and of course Excel. In big companies you'll find departments using the same tools. Critical to the business, not technically interesting or challenging. Plenty of work/money in that. Same for WordPress sites -- lots of them, most of them need work, not sexy or particularly challenging but you can get top dollar doing that.
I much prefer to take the data into a language -- like Python -- and do analysis on it. Sometimes (actually, 1/10 times in my experience) this is not actually possible, so SQL is a great skill to have.
I know of three fortune 100 companies that run 100+ person departments entirely from Excel. Massive Excel files.
..or something like that..
How do you find financial clients how are looking for automating repetitive tasks