I dont think this article stresses one point enough.
You only get to be "new" once, You only get to have a fresh perspective once. There is a reason that you're a bad judge of the "usablity" of your product. You already know how to use it. your numb to it's mistakes and flaws. New team members dont suffer from this!
The bigger lesson here is for the team, and its sadly between the lines! You can get a lot of insight based on what new people ask about, where they stumble and what they need real help with.
Always a good idea to keep a work journal, but there's something on the tone of this article that bothers me. I would like working with someone that is not a borg and is not following a script that seems taken from How to win friends and influence people. In general I will mistrust anyone that tries to manipulate me, that is, if I catch them doing it.
That intentional attitude around how the author wants to be perceived is definitely going to sound offputting to mamy people.
Just wanted to comment to say: don't get carried away by that knee-jerk reaction. Sit with it for a while.
Personally, I also have a goal for how I want my stakeholders to feel. And it'd been a useful rule of thumb in how to behave. I've also run into provlems with my technical work whenever I ignored the human dimension (like what kind of gossip is going around, how I'm perceived by others and how others are casting my work). "Just do a good job" doesn't get rid of the fact that there is a "feelings dimension" to your work - and that it matters how you & your work make others feel.
What about the tone bothers you? I've never read How to win friends and influence people. I thought the article is pretty well-written
I will quote specifically some examples of what jumps out to me as manipulative behavior:
> I'll ask why things on the list are that way, and how they got to be that way. I'm trying to establish credibility as someone who's genuinely curious and empathetic, who's patient, and who respects the expertise of my coworkers. That's the reputation that's going to let me make changes later.
I would not try to establish credibility, but earn it. I will not try to be genuinely curious or empathetic. I either am, or am not.
> At this point I'm looking for one or two problems that have been bugging one of my new teammates for a while, and that have relatively simple solutions. I'm looking for something I can put on the retro board and know I won't be the only person who's bothered by that problem.
This screams to me as playing the work game. If someone can spend time looking for problems over their coworker shoulders or "something to put on the retro board" it just means they are out of meaningful tasks to do.
> Then, during the team conversation about the problem, I'll identify something that teammate suggests as an action item that we could try immediately. That way the team starts to see me as someone who helps them solve their problems.
Change the context and this sounds like a pickup artist explaining dating tricks, or a con man telling you how to infiltrate or someone on the secret service trying to enter a gang.
> The feeling that I want to create, the association I want people to have with me, is, "Oh, Nat joine [...]
Feelings are not something one goes around creating unless they are actively manipulating people around.
> There's a very specific reputation I want to have on a team: "Nat helps me solve my problems. Nat get things I care about done." That's the reputation that's going to get me the results I want in next year's performance review.
I could keep going on, but I think these are enough examples
I think your reaction is common, your mindset is one that I recognize in myself and causes me many insecurities in relationships both personal and professional.
However, it's worth saying that: Being intentional about relationships is not manipulation.
If I decide "I want to be a better husband" and then spend time noticing and writing down a list of things that my wife says bother her or would make her happy or she thinks would be romantic, and then I go through and choose some of them and set myself reminders in my calendar to do them... Am I "manipulating" my wife into "thinking" I'm a better husband? Or am I just plain being a better husband?
Would it be worse if I got the idea from a book titled Would it be better if, instead of being so intentional, I just let my passions and romance sweep me into doing romantic things without any conscious thought? Why?
To make my point clear: Being very intentional about relationships (how others perceive and feel about you — and what actions you take to make them feel and perceive you that way) is not manipulation. If I act in a way that makes my coworkers think that I'm a good coworker, then I AM a good coworker! The fact that it was on purpose and not accidental is...?
Manipulation happens when you develop your "be-a-good-coworker" skills (which is good) and then use those skills in a way that intentionally hurts your coworkers or makes them act against their interests (which is bad).
I see evidence in the article of the first but not the second.
The Turing test for husbands: determine if your husband is actually a good person or if he is acting like a good person so that you will love and appreciate him.
You say the genuine motivation would be: "I acknowledge my flaws and I'm willing to put in the effort to change myself for the benefit of my wife"
But... How do I know which actions will "benefit" my wife? I argue that one of the best ways to know is to ask myself: "Will this action make her feel positively about me?". That way, I'm not going to do things that are important to me but not her, or that I think she SHOULD appreciate but she doesn't actually care about, or whatever.
Of course, to answer that question accurately requires plenty of listening, understanding and empathy.
In the past, I thought more like you. But I think it harmed me. Ultimately I came to the conclusion that intentionally doing things so that other people like to be around you isn't "disingenuous", it's a wonderful thing to work towards!
For some this might have a bit of sociopathic creepiness to it which even seems more apparent in that marriage context than it does in the original article of an "deeply" structured coder.
Of course control might be a valid goal, and controlling your need to control might be a good meta step, too, in a professional environment. The issue of the line between caring and controlling just seems not been discussed enough. And not seeing and mentioning that obvious emotional aspect might already make it look a bit weird.
I don't agree. You should only do things that benefit the team if they are done out of a true sense of cameraderie, and pure desire to empathize and solve problems? Not everyone has natural empathy, and people who don't have it learning how to do it in a way that benefits them and the people around them is positive.
Re:'It sounds like a con artist', the techniques for getting people to trust and like you are often the same whether your intent is good or bad. I don't think these techniques should be reserved for people who have an innate wellspring of curiosity and cooperation.
This person is trying to earn credibility, and is specifically focused on the 'new' phase of being on a team, when you do not have a big pile of meaningful tasks yet and your primary goal is getting the lay of the land and establishing good relationships with your teammates.
Finally,
> Feelings are not something one goes around creating unless they are actively manipulating people around.
I don't really understand what this means. I create feelings all the time, intentionally and unintentionally. I often do things where the primary purpose is to make somebody feel good, usually things like 'make some effort to solve a problem that I don't think matters' or 'let somebody explain something to me that I already know about'. It's not about gaining power and status, it's about greasing social wheels and making friendly cooperation easier.
Am I 'manipulating' people? Well, I am often trying to influence them so that they act in a way that I believe will benefit both of us. I do want to rise in my career, but I want to do it by making positive impacts and relationships, not by stepping on others. I don't think that's a bad thing.
Without imputing any actual intention to the author, I agree with your points on tone. It feels focused on optics, not outcomes.
It's one thing to say that you want to get things done. It's another to say you want to be _seen_ as someone who gets things done.
Again, I don't intend to mind read here, and I think the author actually has some really good data gathering ideas. But the language definitely smacks of political motivation, which some folks (myself included) find off-putting.
I get where you're coming from, but in a somewhat large or large organisation the organisation has a life of its own and it couldn't care less whether you're authentically you or not. If there is something to gain from throwing you out it will, regardless of how you feel about it.
Hedging against that with conscious social strategies can be a reasonable thing to do, at least if you are in or are likely to end up in such a large organisation.
I've made the choice to be in a small organisation, in part because my contributions don't need packaging and announcements to become known to those with more power in it than I have. If I were to change my mind and join a large organisation I wouldn't think twice about entertaining a 'game', balancing the degree to which I exploit other people and organisational weaknesses to gain money and stability for myself against a semblance of professional and personal ethics.
He thinks about those types of things and are acting on it (which is the key point in my opinion) because he is someone who thinks about those types of things.
I think thats a very good attitude.
Not the parent, but what bothers me is how the author tries to spin the idea of taking notes when you're new as something profound. He even gives it a catchy name "WTF Notebook". And the connection between creating a reputation of a fixer at the company, and taking notes with a WTF journal, is weak. I usually don't like to hate on articles like this and instead ignore them, but since you asked, it mostly sounds like bullshit to me.
Writing things down and thinking them over before acting on them, isn't bullshit. There's other decent advice in the article. I think your review of the article is overly negative.
Perhaps these techniques come naturally to some people, and others need to learn it by instruction? I'm in the latter camp. I often need to think about how I sound and make sure I don't come across as too negative.
I think there's a strong connection between identifying and fixing problems, and between fixing problems and getting a reputation as a fixer.
You hit on the most interesting aspect from this. I will explain what I noticed and I’m interested in how this viewpoint lands.
First, the author is doing 101 new leadership stuff. I’ve done it, I’ve seen it done, there’s a science to it. I can distill the whole blog post into when taking over leading something (as an experienced IC, as a new manager, as an army officer, it’s all the same), take the first 30-90 days to not change anything, and just seek to understand how and more relevantly why things work. There are a mess of organization benefits to this, it would take more than a comment to explain why. But in short, ya this is how it’s done.
Second, engs have worked for awful managers, can’t often understand or exactly place why but they know their manager sucks. I can argue capably in thread about how often this difficult to explain “sh*ty manager” sense boils down to the manager not doing like tactically good leadership. In the same way as engineering is a taught skill, so is leading teams. Issue is only a few places teach it intentionally. Top of mind for me is the military, and senior exec training. There’s an actual science to it, full stop. You either get taught it by orgs that treat it this way, or you pick it up from a mentor who learned it somehow. Note - the author learned it this second way. This is really common.
Third, to work for good managers, you actually want to work for good leaders. Leadership is a tactical skill, the same way efficient lines of C++ are. Leadership tactical means tactically shaping and steering people to achieve a goal greater than the sum of the team’s individual parts. This full stop requires what in a certain light is what you point out - it’s a bit manipulative feeling. It’s using leadership methods to make people work together in a way that is effective. A lot of this is good EQ and stuff like the author maps out.
So, who do engs like working for? Often it’s working for technically inclined good people who go to bat for their team with external parties, shield their team from stupid stuff, resource the team to complete its goals, praise in public criticize in private, give good but not overly micromanaging guidance on where to steer things, recognizes and rewards performance, holds unperforners to a standard, and so on and so on?
Some examples of who knows how to do this but for the wrong reasons are people engs don’t like working for - to stereotype: charismatic jocks out of MBA programs who can know nothing about tech but know corp politics and deploy this stuff tactically.
Who do engs hate working for often - technical hires promoted into management and they hate/are bad at their jobs bc management != tech chops, as my above covered.
So, what that leaves is a scenario where teams are led by the occasional person that inherently knows good leadership chops, or more often it’s pissed off engineers who hate working for someone manipulative or incompetent.
To raise the collective industry odds that tech teams work for skilled and competent leaders, that leaves as the solution spelling out tactical leadership - how to do it, what it looks like, how people fit into it, like this blog does.
Pick your poison - more of the same, or good people who just need clear guidance learning from resources like this on how to run teams people want to work on? HN certainly complains to no end about the dynamic caused by not approaching leadership as a skill vs some nebulous thing people somehow know how to do.
I think you nailed it here. It's important to internalize that being a good employee (and/or leader) is not a virtue, it is a skill. You can be a good person and a bad employee/teammate/leader. A bad employee in the sense that you're letting other people down, and/or a bad employee in the sense that you're not getting paid appropriately or getting denied opportunities.
Your job is a really important part of your life - and you will also affect a lot of other people. It's important to be a bit strategic. Otherwise, even if you have wonderful intentions, there's a great chance you'll work on things that don't matter and that leadership knows nothing about, until your career quietly fizzles out.
Yeah, my first thought was "how often does this guy change jobs?"
>There's a very specific reputation I want to have on a team: "Nat helps me solve my problems. Nat get things I care about done."
Managed that...would not recommend. When you're in a large organization and word spreads that you're the guy that can sort out issues...that goes viral and not in a good way.
Recently had a guy reach out to me from Serbia for a solution. I didn't even know we had a fuckin office in Serbia let alone some guy there wanting a slice of my time.
I was that guy at my previous job, and had a much better experience.
For starters, at that company, I always fortunate to have a manager that had my back when it came to deflecting requests that didn't come from him or her. If a random person reached out to me with a request to do some non-trivial work that I either didn't have the bandwidth or interest to do, all I had to say was, "Sorry but I don't have the time to look into this right now. If you need this prioritized, please run it by my manager." 99 times of 100, my manager never heard from them.
The biggest upside to being the go-to guy for people across the department/company is that you get to collect acquaintances and contacts. It's a fun little micro-superpower. Extremely valuable when you need some bit of info from someone outside your team, or need someone to cut through some red tape to get something important done. It means I also have a modest network of people to hit up when I go looking for new opportunities. (This is how I have landed 100% of the jobs in my decade and a half of civilian employment.)
Interesting take. Let's just say, one of these approaches sails through the promotion process, and one does not.
>promotion process
That's the thing. You don't get credit for those death by a thousand cuts queries that come with a universal X is the person with the answers rep.
None of my superior knew we had an office in Serbia either...let alone crediting me with "yes havoc is totally flooded but he helped serbia guy anyway".
Note that I'm talking general corporate here. Things may be different in a pure SWE eng context. My observation is strictly corporate life...may or may not extrapolate to SWE context.
Sounds to me like you've turned yourself into a Staff Engineer, and should ask for that next review cycle. What I'm hearing is that you're influencing the whole organization by enabling many people to get more stuff done, beyond what you could be doing as an individual contributor. That's a very, very good thing.
You can only write so much code per day. If you can help 100 people be 10% more productive, you're leveraging your knowledge to help the whole company do 10x more than you could personally do. Congratulations!
Peer feedback!
"Without Havoc, project FooBar could not have happened"
"raised organizational awareness about offshore projects"
I work in a big software company with 100k and i get asked about stuff from people.
But i'm seen as knowledgeable and my manager basically lets me completly alone doing my thing and gives me all benefits regarding salary he can to keep me.
Only if you’re not pigeonholed.
That promotion is going to need a backfill and the organization may decide that it’s best to keep you in your place. Though it could lead to being able to negotiate a raise earlier than normal.
This idea, I think, is a huge hole that most organizations have. Which is that salary is too tied to hierarchical structure. If you have someone that is amazing at doing something valuable, they should be able to keep getting raises without necessarily getting promoted out of the role. We have this in some measure with jobs that are easily commission-able, but it's not common for tech roles or HR or whatever.
It's the law of people being "promoted to incompetence" - the Peter Principle.
The middle ground is learning how to be the helpful guy but also being able to say no when you don't have time. Not easy, but enforcing boundaries is an important skill.
You have to couple this with the strong ability to say no
Not sure why this is bad?
Usually you are not employed to help out everyone, everywhere in a team. Maybe such a position should exist in any large company, but, yeah, I don't think it does...
Charge more.
> Before I started keeping this kind of list, I brought up problem I saw immediately, as soon as I noticed it. The reputation I got was, "Nat's always complaining about things. Nat thinks we're never doing things right." People stopped listening to me. I was personally frustrated, and professionally ineffective.
This should be near the top of the article, not buried at the bottom. This level of self awareness is a real skill that is worth mastering.
The ex astronaut Chris Hadfield talks about a similar approach he used when joining new missions and teams in his book. Basically being in observation mode first to learn if these WTF moments are valid, and not annoying new team members. Its worth a read.
> The ex astronaut Chris Hadfield talks about a similar approach ... Its worth a read.
Interesting, is it in a book authored by Chris Hadfield, could you point which one?
It's one he wrote, titled "An astronaut's guide to life on Earth"
He's also written a children's book, which is great.
That is roughly how I've approached things whenever I'm walking into a pre-existing situation. I spend the first week just reviewing everything and writing down questions/observations, etc. Not only the "WTF" moments, though. I also take note of things that I think work really well or were really great ideas.
Then there's some time to review/prioritize/etc before any sort of discussions.
"There's a very specific reputation I want to have on a team: "Nat helps me solve my problems. Nat get things I care about done." That's the reputation that's going to get me the results I want in next year's performance review. That's the reputation that's going to get me a referral a few years from now."
This works for a referral, but it is a career killer. I did this for 20 years in different departments. Every time they wanted to keep me there to solve their problems, but this never puts you on the promotion list. I had a colleague that retired after 40 years, he was the go-to person for any problem, but he was never promoted, he was way more competent than any of his managers and their peers. He was the ace in everyone's sleeve, rarely recognized (it was considered to be "normal" that he solves any problem) and never rewarded; his performance was considered an expectation, while the rest of the people at the same level had a much lower bar. In the last performance review, his manager said that his performance is compared with his goals and targets, not with peers. I was told the same by a different manager, so it is not an accident.
>>I'll ask why things on the list are that way, and how they got to be that way. I'm trying to establish credibility as someone who's genuinely curious and empathetic, who's patient, and who respects the expertise of my coworkers. That's the reputation that's going to let me make changes later.
Seems like an excellent corollary to Chesterton's Fence, about someone who comes upon a fence they want to remove:
"If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it"
Or, more explicitly: "Although this looks out of place, we do best to assume that those who came before us were intelligent, and there is a reason for it. That reason may be obsolete, but it must be accounted for or we'll simply repeat a mistake."
It’s a good idea because not only do you keep a list of things you want to fix, but letting things hang out in there sometimes gives you time to understand why something is the way it is.
There will be plenty of times where things were rushed or mistakes were made, but sometimes it really is the case that you just can’t wrap your head around some piece of complexity right away just by looking at a line of code.
With enough experience one usually can start to differentiate the actual hoo-why-oh-why WTFs from the oh-there's-subtle-complexity-here WTFs. The first are straight up failures, the second usually resolve themselves after steeping oneself in the environment. Still handy to note them down, regardless.
Wow. I was just telling 2 co-workers this week that I keep a "How the F" file on my machine. It is not exactly what the author describes, but it's very similar and includes all the "how th f do i do this thing again?" every time I run into a problem when I'm new to a team.
I don't bring it to management's attention like the author suggests, but it gives me a perspective on what sticking points the team and company have that I need to work through over time.
I live by just writing down every idea I have in a list. No particular order, I just append them on a piece of paper or a text file.
Ideas rarely appear when you need them, but come throughout the day as you do other things, and at least in my case, I can never remember if I don't jot them down.
Then when it's time to get something done, I just cross things off one by one. Never have to wonder what to do next, never run out of ideas, which allows some pretty spectacular bursts of productivity.
I'm struggling to see how this relates to TFA. It sounds like you're talking about organizing your personal TODOs, whereas the article is about how to acclimate and communicate within a team.
This is essentially my note-taking strategy with Apple Notes and Notally (on Android). Life's too short to organize notes. I'd rather just jot down everything and rely on the reverse-chron and search to find stuff later.
The irony is that, while I know I have a treasure trove of amazing ideas, at my age I don't think I care enough to execute them like I would have in my 20s. Oh well!
> I don't think I care enough to execute them
You can own this, its totally reasonable to have a good idea and say "meh".
> at my age
This is a cop out. It's weak at best and you contributing to your own discrimination at worst.
You might not like that but I'm not just talking, I'll bring the receipts;
https://medium.com/illumination/late-success-is-possible-8ba...
I highly recommend you look at the 77th infantry division in WWII: https://www.youtube.com/watch?v=0Su5-_KuDf8 Is an entertaining summary.
> This is a cop out.
I see what you are saying, though I find it a bit unfair. I don't think age has to stop anyone, and I was more so using it as a proxy for being a different person with new priorities. In my years approaching 40, I can't say I care at all about sitting in front of a screen for hours on end making some doo-dad when I could be forming relationships that I missed out on earlier in life.
I will definiteky check our your video, though.
>> I see what you are saying, though I find it a bit unfair.
It totally was, and on purpose!!!
>> In my years approaching 40,
At 48 I can tell you that slowing down is NOT what you want to do, speed up!
>> I can't say I care at all about sitting in front of a screen for hours on end making some doo-dad when I could be forming relationships that I missed out on earlier in life.
One does not preclude the other. Hell everything is better with friends! The thing about old people is we dont want doo dads we want to get shit done. You can build all the things you want as beer money projects with the friends you make and if one of them hits, well... Im sure you know better what to do with money now then in your 20's.
"Beware of an old man in a profession where men die young"
The biggest reason i've seen is because management hasn't prioritized it. It takes a few scars before understanding the importance of these tasks, pushing for them prematurely can be really risky. Letting stuff fail might be a better path for consensus.
Yes, the people who set the priorities have to feel the pain in some way. If you as an employee want your boss to do something, you have to communicate it in a way that makes clear how the problem will affect what the boss cares about, not what you care about. Usually that means translating it into dollars or one of the boss's KPIs, like deployment frequency or support ticket volume.
Sometimes management doesn't prioritize problems because they're short-sighted or overwhelmed. But sometimes it's because they just don't understand how big a problem it really is, and the team fails to communicate it to them effectively.
For example, I've heard devs complain about how "the tests take too long." On one team I was on, a couple junior devs were complaining about this, but it turned out that "too long" meant five minutes. Could they be more efficient? Maybe, but getting that down to one minute would take a lot of work with no impact on our ability to develop and deploy multiple times per day. Once I showed them how to run their tests locally on just the files that changed, the problem was solved. But before that, they thought the problem was "technical debt," when really it was just a training issue. (Or, you know, a lack-of-ability-to-Google issue, but I'm trying to be generous.)
On another team, when I heard this complaint, the team explained that the full test suite took almost an hour, and flaky tests meant that they often had to rerun the tests or merge with failing tests. Needless to say, this had a clear impact on our ability to deliver rapidly with high quality, so this was something I prioritized.
Managers don't do the same work as you, so they don't feel the pain firsthand. And they're often not incentivized to care about the same things as you, at least on the same scale. As an IC, you tend to be focused on the next task at hand. The manager is thinking about their quarterly OKRs or whether the team is on track to meet their sprint commitment. If you want something to change, you have to connect the problems you have on the micro scale to the problems the manager cares about on the macro scale.
And if you can't do that, or your manager won't listen, then yeah: let the problems bubble up until the manager feels the pain, as long as it won't come back to bite you.
When I work with new hires, or I'm working in an area a teammate is unfamiliar with, I will often have them sit with me to watch and ask questions of me. I always encourage them to bring in a notebook and take notes for anything that they might have difficulty remembering, or may need more clarification on at a future time. So far, I've found that every new hire or teammate that decides not to bring a notebook and write anything down, never lasts for long. I'm happy to answer questions and help when I'm able to, but when I start getting the same questions we've already covered multiple times, and I've already told them to write it down and they don't, my confidence in their skills starts to dwindle.
In contrast, the ones that use the time wisely, and take notes end up getting fast tracked to architecting systems on their own (with my oversight and code reviews). Those are the teammates that I love to work with, the ones hungry for knowledge and aren't afraid to make mistakes (assuming they aren't hiding them). I'd say I get almost as much knowledge out of mentoring as the new new hires do from learning new techniques and technology. It can be extremely rewarding.
I've learned to do this as well, and as a consultant it's become part of my job, so I've picked up a couple of extra tricks.
One kind of WTF that isn't usually obvious from looking is when doing what looks like a simple thing takes excessive time and effort. Sometimes, after a couple of weeks, you can see something that has been in progress but not completed for no clear reason. Oftentimes these extra effort things don't show up because the team avoids doing them unless absolutely necessary. It's worth asking a team member for a tour around something you know from past experience in similar situations should be easy and quick. A big tell is when the response to your request for a demonstration or explanation involves a need for someone to block out extra time or involve a specific individual who knows it best.
I've never been on a team where we've needed a new IC to come in and assess our inefficiencies, question priorities, and lengthen meetings with debates we've already had. There are plenty of management consultants available for that. What we wanted was for an IC to come in and help us meet our goals by churning out more code. There's lots of talk about reputation but no mention of value.
The existing team tends to be blind to stupid things they're doing. There's a period of time where the new guy sees things and thinks "wtf are you doing that for". Shout him down and you solve the annoyance problem and add him to the list of people who no longer notice the stupid things, or at least no longer try to fix the stupid things.
Maybe your team is only doing sensible things and all is perfect. Maybe you're blind to things that could be better. Heuristically, if you're writing software, it's not likely to be the first case.
My professional project moved to GitHub recently. It is terrible. The pull request / review system is borderline unusable. But already I can feel myself adopting clumsy workarounds and losing sight of how much better it should be.
I've seen plenty of teams who didn't think they needed someone to evaluate what they're doing and just thought they needed someone churning out code.
If they'd had someone do the former, most of the time they'd not have needed the latter quite so much.
What's more likely: a team of equally experienced engineers is waiting on a new hire to identify and fix significant blind spots or a team just needs more bandwidth to get things done?
in my experience, while teams are rarely “waiting around” for a new hire, it’s the outside perspective that makes the most significant improvements to process, tooling, and impact, and teams that resist the notion of blind spots that suffer from them the most.
but maybe that’s just me.
Removing technical debt and improving tooling is often a good way to add value. Sharpening your tools makes you work faster.
These things can add value, but no one needs a new hire to point that fact out. I'm also skeptical that a freshly hired IC's values will align with business values, even though the latter is what shapes the tech debt and tooling you're referring to.
The point being is that new hires will bring fresh eyes to an organization, whereas the team in place might be numb to some of the issues.
You don't need a new hire to fix those problems, but it certainly helps shed new light on some problems. Especially if you are hired as a senior dev or a team lead, you will be expected to fix some of those things.
I wish I had read this a year ago. I kept a mental note of pain points in the workflow, played it cool for four months, researched solutions to the problems, then when I got a shot as a task lead on a fresh project, I jettisoned the rituals and was way ahead of schedule while nobody was looking. Two months later the neurotic hall monitors found out. Oh no, sir. You don't just thumb your nose at practices that were pioneered in the 1990s just because they quintuple the cost of work. You will be made to do it our way to atone for your arrogance. You will use my ancient excel spreadsheet and tell me how much you like it.
Now the project is financially a total shit show, I'm besieged by dweebs, and I've been quietly looking for a new job for 6 months. Apparently, this was an avoidable situation.
Before you solve a problem, you always have to watch out if the person/team who created the problem are still around.
If they are, then you need to apply special tact to the way you solve it.
Interesting. Why do they want you to do it the old way? Or could you explain more? I've never worked somewhere like this, so curious as to why this would happen?
Im not saying I don’t believe you, but I’ve never been anywhere that wasn’t at least a little like this. There’s always some power tripping person using “the way we do things” as a club against the newthought people
The short answer is pride and inertia.
The immediate cause is lower management can't be assed to learn anything, and nobody makes them. This is in part because at big firms after 5-10 years you can politic or job-hop into management and be an email engineer who does little outside of scheduling meetings and marking up PDFs. Young engineer training is usually informal and in master-apprentice fashion. Your mentor will show you how he or she learned it 10 years ago, which is how his or her mentor learned it 10 years before that.
There is little technological progress in civil engineering design that is not externally imposed, and the last big step forward was Excel and replacing hand drawings with CAD in the 90s. Digital delivery will be the next leap, but it's going to take lobbying, fanatical champions, and pure luck that Autodesk and Bentley don't use their billions to suppress it.
Procurement laws, client ignorance, and network effects shield engineering consultants from the discipline of the market. Wasteful practice is not punished. That and licensing regulations have created a sort of guild socialism that has allowed backwardness to survive.
I do something similar, except at one shop where the WTFs outnumbered everything sane by a wide margin.
I love the concept, I had started some time ago something like this but more about things that I wanted fixed/investigated which were creating issues for someone/anyone in the team, so whenever I have some spare moment I can investigate that further.
Now I have a fun name for it :D
Totally agreed. I've always liked this concept, and TIL there's a good name!
Also, now I know there's a link! Sometimes you have a new hire or team member who's a little too eager to criticize and fix everything they see, and you need to sit them down and explain this strategy. Now thanks to Bennett, you can back it up with a link.
I'd caveat that while a "two week" waiting period might work well for Bennett as a senior engineer moving between similar-enough teams, a brand new hire or a junior dev might do better with a longer delay.
The article is good, but as an aside, wow thank you for the introduction to "the bullet journal". Seems like an awesome time management tool.
I've kept a series of notebooks for my career starting prior to dot com 1.0.
Looking back, over all that time, all of my notebooks tend towards WTF.
Or you could just go to the Daily WTF: https://thedailywtf.com
Don't say you, say we.
I like this article because it’s surprisingly humble. The author has learned from previous mistakes and now has a solid process that prevents him trying to fix everything unnecessarily while annoying people as he does so.
The writer gives a very honest-sounding description of their strategizing, and the rationale for that. And there's also some good advice about being judicious about what issues you raise.
At the same time, this sounds very political, and not traceable to goals of the business:
> There's a very specific reputation I want to have on a team: "Nat helps me solve my problems. Nat get things I care about done." That's the reputation that's going to get me the results I want in next year's performance review. That's the reputation that's going to get me a referral a few years from now.
I like to be on teams for which, if new to the team, mostly you notice things being done sensibly (in context), and the 3 things you see that you don't understand, you can just ask about them, because everyone on the team just wants to work well together to achieve the genuine goals.
Not to have to bank observations as an asset, to be introduced diplomatically and strategically, according to a script, to maximize performance reviews and peer approval ratings.
> I like to be on teams for which, if new to the team, mostly you notice things being done sensibly (in context), and the 3 things you see that you don't understand, you can just ask about them, because everyone on the team just wants to work well together to achieve the genuine goals.
I've observed this kind of culture mostly at startups. Once places start to make a lot of money -- things become political.
So if you want to work at the highest paying jobs, you'll have to deal with politics. Because once they make enough money to afford you, the company also makes enough for savvy gatekeepers to entrench themselves in a core system and carve off a piece of that revenue for themselves.
> I make a note every time I run into something that makes me go "wtf,"
I need that type of note in my life
I call mine a ticketing system. ;)
Also, when you hear real WTFs, try to keep a straight face.
I think the concept of a 'WTF notebook' is great, and I think writing down one's thoughts in general is a good idea. I also think that it helps formulate thoughts and communicate them in a more thoughtful not-in-the-heat-of-the-moment way.
However,
> For two weeks, that's all I do. I just write it down. I don't tell the team everything that I think they're doing wrong. I don't show up at retro with all the stuff I think they need to change. I just watch, and listen, and I write down everything that seems deeply weird.
> [...]
> Before I started keeping this kind of list, I brought up problem I saw immediately, as soon as I noticed it. The reputation I got was, "Nat's always complaining about things. Nat thinks we're never doing things right." People stopped listening to me. I was personally frustrated, and professionally ineffective.
Not bringing up things that you think could be improved in a retro.. that's pretty silly. If you are getting a reputation of 'always complaining', and coming across as 'telling people they are doing things wrong', etc. then you are just bad/unprofessional at communication.
Communicate things as 'I was thinking maybe we could do <X> better if <Y>, what do you think?' and make it a genuine discussion with people, rather than 'WTF <x>?' - especially when it is someone else's work and you want to remain on good terms with them.
You don't have to wait 2 weeks, compile a secret list and then bring it to your manager - though. You can communicate things that you think can be improved in a polite/respectful manner as they occur. Being on a team is about working together. If you cannot safely do that when communicating effectively, then you are with a terrible team/company.
If the author is anything like me, I get it.
I have 20 years of software engineering and infosec experience can fill a few hours talking about all the crazy risks I find in a day of looking around most any company I interact with.
The status quo for security in our industry is abysmally bad. Not washing hands while working in a hospital WTF bad, everywhere.
Bringing it all up as I go can burn everyone out on interacting with me or trusting me at all if I am not careful, because survivors bias is a hell of a drug.
Two weeks to collect information and context is about right. I just usually do it as a contract security auditor now and provide a detailed report at the end.
I think you missed the point. This is about someone entering into a new team. Walking into a team day 1, knowing nothing, and telling everyone they’re doing it wrong, is a horrible way to start things off.
By watching and waiting a bit, it gives time to learn why the stupid things are stupid, what is actually being worked on, etc. This helps build trust in the team, because it shows the new person respects the team enough to take some time to learn how things are before trying to change it. I don’t trust anyone in a leadership role that starts changing things before taking the time to learn how and why things are currently done the way they are.
A guy on my team now takes your approach. He derails every meeting with the way things “should” be, and he is just saying what everyone already knows, he just lacks the understanding on why the problem is more difficult to fix than he realizes. If he would talk less and listen more, he might understand those things better and stop wasting everyone’s time.
Yes, I think I have been "that guy" when I walk into a situation I have been hired to fix, I want to get started right away.
If I see a common problem, I want to fix it immediately and say something like "I see big batch sizes all the time and they have a simple, counter intuitive fix. In fact, of you had read more than 30 minutes, you would see it addressed."
Waiting a couple weeks makes sure you have enough context to usefully contribute with less stepping on toes.
I also always think this way. I Summarize it as be a doer not a complainer
Well...I have found that we should be careful, when considering "solutions."
Here's my take on it: https://littlegreenviper.com/miscellany/problems-and-solutio...
Sounds good. I decided to create two WTF notebooks, one for the team and one for myself. I, for one, am definitely not one without errors -- plenties of them, actually.
My first note would be:
- WTF! I ate five Lindt chocolates (they tasted so good) during a intermittent fasting session. I should burn in hell.
I sort of did this with the management at a large company I used to work for. Whenever they'd do something that I thought was incompetent and/or sociopathic, I'd just write a bullet point in a file called `bullshit.md`. The file got to about three hundred bullets.
I eventually stopped this because it kind of made me feel like a sociopath and/or narcissist myself. I don't really think it's healthy to keep tabs on everything that pisses you off, like some kind of scoring system. It's not like me writing this stuff down helped anything, and it just felt like I was trying to keep score so that if I get in trouble I have a retort. I think it's actually good to occasionally forget stuff and let it slide, because there will always be bullshit management policies at pretty much any company with more than like four people, and writing this stuff down just makes it easier to let stuff continuously bother me.
ETA:
To be clear, it wasn't my idea to write it down, I was getting in trouble for complaining too much at this job, and my direct manager suggested I write things down. I think he thought it was a way to cool off, even though I don't think that was the effect.
Don't call it 'bullshit.md', call it 'challenges and opportunities.md', s/fuck|shit|cunt// inside and organize a series of coaching sessions about how you fixed one of these and how can they help themselves fix these.
or, channel your inner complainer into your promo-seeking behaviors.
I don't doubt that that would have been the most profitable solution to this for me, but that's really not my personality.
This is not a joke or sarcasm: I genuinely think I might be slightly on the spectrum, because I have a lot of trouble with corporate dishonesty, and there are plenty of times that I will say things that are apparently controversial and I don't realize it.
For example, at that job, during a discussion about them getting rid of a benefit that they used to pay for, I made the mistake of once saying to higher-management that "we all do this job for the money", and I got a bunch of indignant responses about how they believe in the cause and all that shit [1]. I was really confused, because I didn't even realize that that was up for debate; I'm quite confident that if this company stopped signing their paychecks, they'd stop showing up for the job and I really didn't (and still don't) think that there's anything particularly wrong with that. I'm selling my time and expertise, Tombert is a for-profit enterprise.
When I tried explaining this to them, I get a private meeting with one of my million managers above me that I have a "bad attitude" and that I'm trying to "stir the pot", and I genuinely wasn't trying to, I was just trying to make a point cutting through some of bullshit flavortext to get to the point that getting rid of a benefit that we liked does affect us because I was under the impression we worked for money, not for fun.
I have a million stories like this, and it's why I suspect that I will not be able to grow my career much more than I have right now.
[1] To be clear, this wasn't some non-profit, this was a very very large for-profit company that you've definitely heard of that my lawyer/mom has advised me not to directly name.
it isn't a question of personality, it's a question of 1) what should be done 2) who should do it 3) is it actually worth doing, not necessarily in that order.
I am partial to your self-diagnosis - everything is always up for debate no matter how true or false it is and if you must be reminded of it, you just might be on the spectrum.
(by the way, HR is not your friend - it's corporate police with a PR department. yes, they're in it for the money, too, and yes, they won't dare to admit it in public. never challenge people in public, they will do the rational thing and try to save face. this is also why corporate successes are widely celebrated and failed projects are swept under the rug.)
It’s not that I need to be reminded of it exactly, so much as I am extremely impatient with it. Still, I think it might be worth me getting tested.
I am very aware that HR is not my friend. I have posted about this here before, but there was a time that I asked an HR person to keep a conversation between us in regards to some medical history, they agreed, and the next day my immediate manager is asking me about it, despite the fact that I never told him about this. Treat HR like a police interrogation and keep your answers as utilitarian as possible.
[dead]
[dead]
There is a reason that you're a bad judge of the "usablity" of your product. You already know how to use it. your numb to it's mistakes and flaws. New team members dont suffer from this!
One of the best things my company does is allow me to sit down on a chair next to the people who use my products as they use them.
I just sit there with a notebook and write things down, and talk to the users as they're using the product.
Once you start doing that, you understand that it doesn't matter how many terabytes of "telemetry" you gather, you will never understand how people use your product as well as actually speaking to them.
The tech industry really needs to get over its fear of other human beings.
Early in my work life I had a job on the UI side of things.
Watching people use your app behind a 2 way mirror was probably the most illuminating thing ever. Users from outside the tech bubble have a very different take from most of the HN set. It influences how the look at, use and think about applications.
You can watch 7 people DO the right thing and then tell you, out loud, that it sucks for the same reason. Every app is filled with problems like this. If you aren't testing with "inexperienced" end users you are likely missing a LOT!!
If you aren't testing with "inexperienced" end users you are likely missing a LOT
Conversely, if you're only testing with "inexperienced" end users, your app will never become the professional's choice: there's just too many guardrails needed for inexperienced users that get in the way of an expert's workflow.
This was even covered in our school. Test your program on your classmates, and then the rest of the school. This was way before smartphones though, it had to be in the computer rooms.
If you're yelling that they're using it wrong, you're doing something wrong.
Yes, this, exactly.
Swizec recently wrote about "desire paths": https://swizec.com/blog/architecture-is-like-a-path-in-the-w...
Fully agree.
Early in my career, I ran these sessions.
I wish all companies did this. Even better, record the experience.
It’s astounding how many UI developers never watch a real customer using their product. All UI is compromise, but you see a very different set of possible compromises when you watch someone (particularly a new user) use the product.
My favorite is the whole “let it be a user setting” compromise. If you don’t get the “correct” default, then a non-obvious user setting does nothing. And if you do get the default right, then you probably don’t need the setting.
Sometimes it's a "McNamara fallacy", where there's just too much emphasis/bias towards quantitative data.
It ia true that everybody can fall into that trap. Becoming blind to weird quirks of your own product is the equivalent of a senior professor becoming blind to the fact that the stuff they need to explain is hard to fresh students.
The thing is, that not all people suck equally bad at this. A big part of it is to actually care and be empathic enough to put yourself into the shoes of the un-initiated. Two people who both have used the Bash shell a million times might have a completely different understanding of what makes it weird and unintuitive to someone starting out, even if both had trouble when they themselves did.
Looking at things with a fresh mind is a skill one can get better at, just like you can learn how to look at actual light and objects to draw what you see instead of drawing what your brain tells you you see. It is a hard thing to learn and it is something that can fail you even once you became somewhat decent at it, but every good educator needs that skill.
I think TFA is more stressing that this only "new" once perspective can lead you to exclaiming WTF a lot to all your new colleagues - thus giving the impression of being a loud complaining nuisance.
Instead, by writing it down and NOT expressing it just yet, you give yourself time to learn the lie of the land and why things are the way they are; to orient yourself in the workplace. And when you are comfortable, settled with accounts/permissions/authorisations, you have a nice list to move on.
The team is then more likely to think you are being helpful rather than a popup muppet exclaiming "WTF is that!" all the time.
I worked at a tiny self-funded startup once where we required new hires to update the documentation and processes to fix the problems they encountered during onboarding. That worked great with 12-15 people; not sure how it scales.
I worked at a MegaCorp, and we required all new hires to (1) teach the next hire our architecture, core user journeys, etc and (2) the new hire had to present their learnings to the team, standing with their (quiet) teacher.
Both of these steps were crucial. The presentation serves a ton of purposes, it ensures both the student and the teacher learn the material enough to present with a whiteboard, and the team can catch any mistakes or misunderstandings at a time when they'd have the most sympathy towards ignorance. It also is a good low-stakes way to force someone to present and get used to the team and talk to everyone in a formal setting. We also always ordered pizza + beer after too make it a "fun" (or at least casual) environment that wasn't too serious.
I do this as a freelancer who onboards with new teams pretty regularly. I've only had positive feedback from sending PRs that fix or improve the documentation on my first days with a project.
I tried to do this when I joined a new company. Problem was there were four other guys on the team, all of whom thought the correct process was different, not just from what was documented, but from each other's, and would go back and re-"correct" things after me.
I spent the whole 3.5 weeks I worked there starting fights and noped right back out.
We have done that at a few orgs that have scaled up to hundreds of engineers
You are only new once.
But I expect starting a journal like this, waiting for a list to grow, is also a great path to resensitizing oneself to all the potentially useful problems to solve.
Writing down something and then waiting is such an immediate, low effort/immediate reward (my list got longer!), but long-term high-payoff act, I think it can be easily relearned with a systematic practice like this.
I like the continuous separation of recognition and recording, from the downstream progression: Create a map (see), take time to study it (learn), form a party of the co-concerned (lead), before running off into the forrest.
I recently interviewed with a mega-big bank for a role that I 'got it'/I have the 20y of experience on the thing. I've talked to 4 people. I usually ask "what are the 3 things that you want to see me do/not do in the first 6 months" (among other questions. Person #3 said "don't ask to change things, observe for the first 12 months, and on the 13nth month raise your hand and speak up, not before".
I have been journaling like for (8 years). Both notebooks and Scrivener. I like Nat's journaling method. This way he avoids looking like a fool/jumping the gun, and he gives the time for things to unfold (or not).
> You are only new once.
Really comforting
This is exactly why i as a manger want to assign bigger projects on new hires. They have fresh eyes, and are not used to things we do just because we have always done them in a special way. It's interesting to see how they solve tasks, before they get used to the status quo.
I feel the same way. It's interesting how someone new to something tackle issues compared to yourself that has been doing things a certain way for so long. I've definitely picked up new skills just by watching less experienced developers use their own way to handle issues, and I make sure to let them know when they've inspired or led to my own gain in knowledge. I think it's a positive feedback loop that strengthens a team.
And then grab some people off the street to test your product. Let them play with your app. Treat them to lunch, interview them while eating :-)
A year ago, I got hired at this place that is, shall we say, less than stellar at teaching their new hires about their custom, specialized code framework.
Of course only new hires notice. Maybe only new hires who have been enough places to realize that it doesn't have to be this hard...
Ease of onboarding and usability for new team members was very important during ZIRP when headcounts were exploding and people were changing jobs for 40% raises all the time. I'm not sure it's going to be such a useful optimization target going forward.
https://en.wikipedia.org/wiki/Shoshin
I believe in the First 100 days phenomenon but I vigorously ignore any bullshit about fixing major tickets within n days of starting at a company. First of all many places I’ve worked were deluding themselves about the feasibility of doing this. Their onboarding process inhibited any such wishes when I started there.
I’ve been doing user studies on developers for more than a dozen years. It got a lot easier once screen sharing was more common. But letting new hires or devs with brand new machines twist a little when going through the setup docs and taking notes. Or doing similar when I’ve made a major change or introduced a new API to see what fresh eyes see that I did not (or in some cases, that which was true but no longer is).
If at all possible I task them with fixing the docs. First, as you say, they don’t have the Curse of Knowledge, so how they word it will reach down the ladder behind them. Second, if what they say is completely wrong, then I can correct the miscommunication easier when they’ve used their own words to repeat back what we discussed.
Making edits to the wiki is usually the first contribution I want to see from a new hire. Even if it’s just untangling a run on sentence.
You can get part way there with a sabbatical.
I recently took a 2 month break from work, and coming back I had plenty of these moments too.
Things that previously I thought were smooth weren't. Processes that I thought worked fine seemed to crumble. The overall application speed felt like treacle where previously I thought it was fine.
Sometimes a fresher perspective on the state of things is important, although unlike a new team member it's not doing me many favours pointing some of this stuff out.
Being a new team member is also an amazing opportunity for being able to speak freely about problems and point out that the emperor is nude.
It's not always the staleness of perspective that is the problem. Often it is your personal opinion (the perspective itself) that is both right and wrong.
I think the greatest mistake in software design is the pattern of structuring UI/UX around assumptions. Every assumption made in software design is a demand for the context that that software will be used. The reality is that context will always be fluid, and that it will often contradict itself. Free software can be liberated from its assumptions, but it requires redundant work for every unique contextualization.
But it's not us we just keep being let down by these new hires. I don't get it, how are they all stupid or lazy?
- Many a myopic org