It is not ego tripping. They probably loathe you because you turn the power structures even more in capital's favour by undercutting or overriding them.
I’m smiling a bit reading this thread because I went essentially the opposite way: started contracting in 2010 when my grad school stipend ran out, in Feb 2020 (kind of lucky timing…) one of my clients convinced me to come on as FTE #2 at their startup (I’d done a 6-month prototyping gig for them in 2019 that was responsible for them unlocking their first tranche of funding). Have stuck around since then because the work is compelling and to some degree I’ve shaped the engineering org into what I want it to be, even though we’ve hired people above me (it’s kind of neat and weird hiring your own manager so that you no longer report direct to the CEO)
Anyway, as far as I can tell, the engineering teams that I was paid to help, I believe, generally loved me. The work I’d do generally fell into one of three buckets:
- early-stage prototyping work, where there was no engineering team yet and I was laying the foundation for v1 of a product
- modernization work, where a company has a product line that’s sitting generating revenue but there’s no engineering capacity to actually make v2. This was often more on the embedded side but occasionally stuff like pre-ARC Objective C -> Swift. Everyone’s too busy working on some other thing and the good-but-crusty product is starting to die due to lack of attention
- rescue work, where the engineering organization (management + ICs) have gotten themselves into a situation they’ve realized they can’t get themselves out of on their own. Often performance, scaling, or velocity-related, almost always with an element of pathological engineering culture.
The first two cases aren’t as relevant, but the third type was always a hearts & minds campaign. The outcome was two-fold: fix the software, fix the team.
First step: take the team out for lunch without their manager. To the loathing comment above, not everyone would take me up on the offer, but I could usually get enough of a critical mass together. Two objectives: convince them that I do not, under any circumstances, want to work with them long-term; convince them that I was on their side. Get them talking about what’s wrong, ostensibly about the product, but this would frequently pivot to the structural organizational problems that led to the product being how it was.
From there, put together two plans. Plan 1 was for how to tackle the software problem. Plan 2 was how to fix the engineering org. Typical situation was they had some ideas on the first part and LOTS to say about the second part. The connection between the two was they often had a good high-level idea about how to fix the software but didn’t have the specific skill to do the fix and didn’t have time to learn.
Then I’d start working both problems in parallel: knock out a quick win on the software side, do a lunch & learn with the team and their manager to explain what I’ve done, what tools I used if I used anything exotic, discuss next steps, and discuss whether someone else on the team wants to work together on the next thing. Meanwhile, I’m watching the team (incl. management) and the complaints that I got from them over lunch and while working with them. Looking to see which of those complaints I can see in the day-to-day work environment and who to… blame isn’t the right word, but figuring out who I need to nudge in which direction to make the problems that led to my involvement go away.
This usually went through a few iteration loops but I was always clear to everyone involved that my goal was for the team to not need me anymore. That was the outcome: problem solved, team can solve the same kinds of problems on their own without me. I’m available if you ever need to hire me again, I’m here if you get stuck on something tactical and can help out for a few days here and there.
If my goal was to get fired, how do I know that I did good? Direct feedback from ICs was one way. I smoked a fair bit back then and the number of times I had people come up to me outside during a coffee/smoke break and just say “hey man, I really appreciate what you’re doing here, I’ve learned a lot about ____”. The other one: referrals. Maybe 20% of the work was inbound LinkedIn cold calls, while the other 80% was referrals from existing clients (or callbacks) with about a 50-50 mix of that being management or IC referrals. Work with a team for 3 months, a couple months later get an email “hey so I was out for beer with XXX and I think you might be able to help me…”
Comments
It is not ego tripping. They probably loathe you because you turn the power structures even more in capital's favour by undercutting or overriding them.
Or leaving shitty code for others to fix later, like a lot of contractors do.
I’m smiling a bit reading this thread because I went essentially the opposite way: started contracting in 2010 when my grad school stipend ran out, in Feb 2020 (kind of lucky timing…) one of my clients convinced me to come on as FTE #2 at their startup (I’d done a 6-month prototyping gig for them in 2019 that was responsible for them unlocking their first tranche of funding). Have stuck around since then because the work is compelling and to some degree I’ve shaped the engineering org into what I want it to be, even though we’ve hired people above me (it’s kind of neat and weird hiring your own manager so that you no longer report direct to the CEO)
Anyway, as far as I can tell, the engineering teams that I was paid to help, I believe, generally loved me. The work I’d do generally fell into one of three buckets:
- early-stage prototyping work, where there was no engineering team yet and I was laying the foundation for v1 of a product
- modernization work, where a company has a product line that’s sitting generating revenue but there’s no engineering capacity to actually make v2. This was often more on the embedded side but occasionally stuff like pre-ARC Objective C -> Swift. Everyone’s too busy working on some other thing and the good-but-crusty product is starting to die due to lack of attention
- rescue work, where the engineering organization (management + ICs) have gotten themselves into a situation they’ve realized they can’t get themselves out of on their own. Often performance, scaling, or velocity-related, almost always with an element of pathological engineering culture.
The first two cases aren’t as relevant, but the third type was always a hearts & minds campaign. The outcome was two-fold: fix the software, fix the team.
First step: take the team out for lunch without their manager. To the loathing comment above, not everyone would take me up on the offer, but I could usually get enough of a critical mass together. Two objectives: convince them that I do not, under any circumstances, want to work with them long-term; convince them that I was on their side. Get them talking about what’s wrong, ostensibly about the product, but this would frequently pivot to the structural organizational problems that led to the product being how it was.
From there, put together two plans. Plan 1 was for how to tackle the software problem. Plan 2 was how to fix the engineering org. Typical situation was they had some ideas on the first part and LOTS to say about the second part. The connection between the two was they often had a good high-level idea about how to fix the software but didn’t have the specific skill to do the fix and didn’t have time to learn.
Then I’d start working both problems in parallel: knock out a quick win on the software side, do a lunch & learn with the team and their manager to explain what I’ve done, what tools I used if I used anything exotic, discuss next steps, and discuss whether someone else on the team wants to work together on the next thing. Meanwhile, I’m watching the team (incl. management) and the complaints that I got from them over lunch and while working with them. Looking to see which of those complaints I can see in the day-to-day work environment and who to… blame isn’t the right word, but figuring out who I need to nudge in which direction to make the problems that led to my involvement go away.
This usually went through a few iteration loops but I was always clear to everyone involved that my goal was for the team to not need me anymore. That was the outcome: problem solved, team can solve the same kinds of problems on their own without me. I’m available if you ever need to hire me again, I’m here if you get stuck on something tactical and can help out for a few days here and there.
If my goal was to get fired, how do I know that I did good? Direct feedback from ICs was one way. I smoked a fair bit back then and the number of times I had people come up to me outside during a coffee/smoke break and just say “hey man, I really appreciate what you’re doing here, I’ve learned a lot about ____”. The other one: referrals. Maybe 20% of the work was inbound LinkedIn cold calls, while the other 80% was referrals from existing clients (or callbacks) with about a 50-50 mix of that being management or IC referrals. Work with a team for 3 months, a couple months later get an email “hey so I was out for beer with XXX and I think you might be able to help me…”