I do consulting1 on software architecture, network protocol development,python software infrastructure, streamlined cloud deployment, and open sourcestrategy, among other nerdy things. I enjoy solving challenging, complextechnical problems or contributing to the open source commons. On the bestjobs, I get to do both.
Today I would like to share with you a secret of the software technologyconsulting trade.
I should note that this secret is not specific to me. I have several colleagueswho have also done software consulting and have reflected versions of thisexperience back to me.2
We’ll get to the secret itself in a moment, but first, some background.
Companies do not go looking for consulting when things are going great. Thisis particularly true when looking for high-level consulting on things likesystem architecture or strategy. Almost by definition, there’s a problem thatI have been brought in to solve. Ideally, that problem is a technicalchallenge.
In the software industry, your team probably already has some softwareprofessionals with a variety of technical skills, and thus they know what to dowith technical challenges. Which means that, as often as not, the problem isto do with people rather than technology, even it appears otherwise.
When you hire a staff-level professional like myself to address your softwareteam’s general problems, that consultant will need to gather some information.If I am that consultant and I start to suspect that the purported technologyproblem that you’ve got is in fact a people problem, here is what I am going todo.
I am going to go get a pen and a pad of paper, then schedule a 90-minutemeeting with the most senior IC3 engineer that you have on your team. I willbring that pen and paper to the meeting. I will then ask one question:
I will then write down their response in as much detail as I can manage. If Ihave begun to suspect that this meeting is necessary, 90 minutes is typicallynot enough time, and I will struggle to keep up. Even so, I will usuallymanage to capture the highlights.
One week later, I will schedule a meeting with executive leadership, and duringthat meeting, I will read back a very lightly edited4 version of thetranscript of the previous meeting. This is then routinely praised as a keenstrategic insight.
I should pause here to explicitly note that — obviously, I hope — this is notan oblique reference to any current or even recent client; if I’d had thismeeting recently it would be pretty awkward to answer that “so, I read yourblog…” email.5 But talking about clients in this way, no matter howobfuscated and vague the description, is always a bit professionally risky. Sowhy risk it?
The thing is, I’m not a people manager. While I can do this kind of work,and I do not begrudge doing it if it is the thing that needs doing, I find itstressful and unfulfilling. I am a technology guy, not a people person. Thisis generally true of people who elect to go into technology consulting; we knowwhere the management track is, and we didn’t pick it.
If you are going to hire me for my highly specialized technical expertise, Iwant you to get the maximum value out of it. I know my value; my rates are notlow, and I do not want clients to come away with the sense that I only had acouple of “obvious” meetings.
So the intended audience for this piece is potential clients, leaders of teams(or organizations, or companies) who have a general technology problem and arewondering if they need a consultant with my skill-set to help them fix it.Before you decide that your issue is the need to implement a complexdistributed system consensus algorithm, check if that is really what’s atissue. Talk to your ICs, and — taking care to make sure they understand thatyou want honest feedback and that they are safe to offer it — ask them whatproblems your organization has.
During this meeting it is important to only listen. Especially if you’re ata small company and you are regularly involved in the day-to-day operations,you might feel immediately defensive. Sit with that feeling, and process itlater. Don’t unload your emotional state on an employee you have powerover.6
“Only listening” doesn’t exclusively mean “don’t push back”. You alsoshouldn’t be committing to fixing anything. While the information you aregathering in these meetings is extremely valuable, and you should probably acton more of it than you will initially want to, your ICs won’t have the fullpicture. They really may not understand why certain priorities are set the waythey are. You’ll need to take that as feedback for improving internal commsrather than “fixing” the perceived problem, and you certainly don’t want tomake empty promises.
If you have these conversations directly, you can get something from it that noconsultant can offer you: credibility. If you can actively listen, theconversation alone can improve morale. People like having their concernsheard. If, better still, you manage to make meaningful changes to addressthe concerns you’ve heard about, you can inspire true respect.
As a consultant, I’m going to be seen as some random guy wasting their timewith a meeting. Even if you make the changes I recommend, it won’t resonatethe same way as someone remembering that they personally told you what waswrong, and you took it seriously and fixed it.
Once you know what the problems are with your organization, and you’ve gotsolid technical understanding that you really do need that event-drivendistributed systems consensus algorithm implemented using Twisted, I’mabsolutely your guy. Feel free to get in touch.
Today I would like to share with you a secret of the software technologyconsulting trade.
I should note that this secret is not specific to me. I have several colleagueswho have also done software consulting and have reflected versions of thisexperience back to me.2
We’ll get to the secret itself in a moment, but first, some background.
Companies do not go looking for consulting when things are going great. Thisis particularly true when looking for high-level consulting on things likesystem architecture or strategy. Almost by definition, there’s a problem thatI have been brought in to solve. Ideally, that problem is a technicalchallenge.
In the software industry, your team probably already has some softwareprofessionals with a variety of technical skills, and thus they know what to dowith technical challenges. Which means that, as often as not, the problem isto do with people rather than technology, even it appears otherwise.
When you hire a staff-level professional like myself to address your softwareteam’s general problems, that consultant will need to gather some information.If I am that consultant and I start to suspect that the purported technologyproblem that you’ve got is in fact a people problem, here is what I am going todo.
I am going to go get a pen and a pad of paper, then schedule a 90-minutemeeting with the most senior IC3 engineer that you have on your team. I willbring that pen and paper to the meeting. I will then ask one question:
I will then write down their response in as much detail as I can manage. If Ihave begun to suspect that this meeting is necessary, 90 minutes is typicallynot enough time, and I will struggle to keep up. Even so, I will usuallymanage to capture the highlights.
One week later, I will schedule a meeting with executive leadership, and duringthat meeting, I will read back a very lightly edited4 version of thetranscript of the previous meeting. This is then routinely praised as a keenstrategic insight.
I should pause here to explicitly note that — obviously, I hope — this is notan oblique reference to any current or even recent client; if I’d had thismeeting recently it would be pretty awkward to answer that “so, I read yourblog…” email.5 But talking about clients in this way, no matter howobfuscated and vague the description, is always a bit professionally risky. Sowhy risk it?
The thing is, I’m not a people manager. While I can do this kind of work,and I do not begrudge doing it if it is the thing that needs doing, I find itstressful and unfulfilling. I am a technology guy, not a people person. Thisis generally true of people who elect to go into technology consulting; we knowwhere the management track is, and we didn’t pick it.
If you are going to hire me for my highly specialized technical expertise, Iwant you to get the maximum value out of it. I know my value; my rates are notlow, and I do not want clients to come away with the sense that I only had acouple of “obvious” meetings.
So the intended audience for this piece is potential clients, leaders of teams(or organizations, or companies) who have a general technology problem and arewondering if they need a consultant with my skill-set to help them fix it.Before you decide that your issue is the need to implement a complexdistributed system consensus algorithm, check if that is really what’s atissue. Talk to your ICs, and — taking care to make sure they understand thatyou want honest feedback and that they are safe to offer it — ask them whatproblems your organization has.
During this meeting it is important to only listen. Especially if you’re ata small company and you are regularly involved in the day-to-day operations,you might feel immediately defensive. Sit with that feeling, and process itlater. Don’t unload your emotional state on an employee you have powerover.6
“Only listening” doesn’t exclusively mean “don’t push back”. You alsoshouldn’t be committing to fixing anything. While the information you aregathering in these meetings is extremely valuable, and you should probably acton more of it than you will initially want to, your ICs won’t have the fullpicture. They really may not understand why certain priorities are set the waythey are. You’ll need to take that as feedback for improving internal commsrather than “fixing” the perceived problem, and you certainly don’t want tomake empty promises.
If you have these conversations directly, you can get something from it that noconsultant can offer you: credibility. If you can actively listen, theconversation alone can improve morale. People like having their concernsheard. If, better still, you manage to make meaningful changes to addressthe concerns you’ve heard about, you can inspire true respect.
As a consultant, I’m going to be seen as some random guy wasting their timewith a meeting. Even if you make the changes I recommend, it won’t resonatethe same way as someone remembering that they personally told you what waswrong, and you took it seriously and fixed it.
Once you know what the problems are with your organization, and you’ve gotsolid technical understanding that you really do need that event-drivendistributed systems consensus algorithm implemented using Twisted, I’mabsolutely your guy. Feel free to get in touch.
![[DK]](/data/avatars/s/57/57999.jpg?1720990206){kind=avatar}
