I thought that was a good article, but it dances around the core of the issue by not declaring what motivation is and how managers should think about it at the start.
Intrinsic motivation is a function of autonomy, mastery, and purpose. A managers purpose is to promote intrinsic motivation.
When you identify a weak performer without understanding which pillar of motivation is weak, it generally results in a direct and total assault on intrinsic motivation.
Interventional supervision is decreased autonomy.
Interventional supervision is a powerful indirect invalidation of mastery. Being overruled is a powerful invalidation of mastery. Being told what to do or how to do something rather than being told a goal to achieve is an invalidation of mastery. Being ignored when you bring up an issue or not having your issue be treated with seriousness is incredibly invalidating. Being told, directly or indirectly, that you are wrong without having it explained to you is a complete invalidation of mastery.
Lastly, assigning lower risk work, work that doesn't matter as much, is a direct assault on purpose.
When intrinsic motivation is assaulted, it is no surprise that the employee becomes less motivated, and therefore less capable, independent, and thoughtful, and therefore a much less appealing person to give work that matters creating a viscous cycle of being managed out at the cost of everyone's mental health.
So a managers purpose is to promote intrinsic motivation, but the standard actions taken are a direct assault on it. The manager adopts an "organization vs employee" approach rather than an "us vs the problem" approach and the consequences are always exactly as you would expect.
The proposed solution in this article (practice active listening, which means listen with the expectation of and desire to change your mind), is a core weakness I've seen from managers promoted from engineering, and especially managers from more hierarchical cultures.
I agree with the final assessment of the article. A mastery problem cannot be solved by a manager, so if the employee is truly not technically capable, they need to be let go. The entire purpose of a technical interview is to ensure there is a bar that is cleared for mastery. Autonomy and purpose problems are generally a problem with a manager failing to manage upwards, set expectations, or a managers inappropriate application of dominance (often manifested by a lack of active listening), rather than a failure to "manage" an employee.
This is quite applicable to many situations I‘ve witnessed. I‘ve also witnessed the exact opposite. I.e. managers blame themselves to avoid making hard decisions with employees. It would be great to have this article and another article which addresses „hard decisions“ in order to help managers navigate ambiguous situations.
I second this article, having applied the ideas (and shared the article) with people I've worked with in the past. The ideas are still relevant today, despite the original publication in 1998.
--
The comic partway through the article gives a good overview, and the following are a few highlights:
"Before the set-up-to-fail syndrome begins, the boss and the subordinate are typically engaged in a positive, or at least neutral, relationship. The triggering event in the set-up-to-fail syndrome is often minor or surreptitious. The subordinate may miss a deadline, lose a client, or submit a subpar report. [...]
"Reacting to the triggering event, the boss increases his supervision of the subordinate, gives more specific instructions, and wrangles longer over courses of action.
The subordinate responds by beginning to suspect a lack of confidence and senses he's not part of the boss's in-group anymore. He starts to withdraw emotionally from the boss and from work. He may also fight to change the boss's image of him, reaching too high or running too fast to be effective.
"The boss interprets this problem-hoarding, overreaching, or tentativeness as signs that the subordinate has poor judgment and weak capabilities. If the subordinate does perform well, the boss does not acknowledge it or considers it a lucky "one off." [...] The subordinate feels boxed in and underappreciated. He increasingly withdraws from his boss and from work. He may even resort to ignoring instructions, openly disputing the boss, and occasionally lashing out because of feelings of rejection.
"In general, he performs his job mechanically and devotes more energy to self-protection. [...] The boss feels increasingly frustrated and is now convinced that the subordinate cannot perform without intense oversight. He makes this known by his words and deeds, further undermining the subordinate's confidence and prompting inaction."
---
My own summary follows. The idea is that a good relationship between a manager and a junior can unnecessarily fall off the rails, beginning with the manager perceiving that the junior has made a small or moderate mistake.
Instead of letting it go, the manager begins a corrective action with more micro-management (such as requests for more check-ins or progress reports). This can result in the junior becoming disengaged with the work, or alternatively trying to take on too many responsibilities to regain the manager's trust. In any case, the manager tries to correct this by increasing micro-management (which is the opposite of what the junior wants), which worsens the relationship.
To solve this, the article recommends an open discussion between the manager and junior, with specific, concrete goals for restoring trust in the relationship (as well as attempting to prevent this in the first place). The article also notes that an attempted solution entirely on the junior's side—where the junior over-achieves for a while to attempt to rebuild trust—is often ineffective, as a manager may not even notice these efforts due to a bias to already label the person as unreliable.
The article omits SB 50 [1], the effort by Scott Wiener (state senator from SF) to increase housing density and remove regulatory hurdles for housing development near transit.
From what I’ve seen it’s the most promising method to increase housing supply CA-wide given that many municipalities resist development.
I'm the lead frontend developer at Ayasdi, and I figure I should take this opportunity to let the HN community know that we're actively hiring in engineering :)
If you're a frontend engineer with an interest in machine learning and data visualization, Ayasdi is a great place to build those skills. We use Backbone and D3 as our core stack on the client side, and we're pushing at the edge of what's possible when building rich data analysis applications for the web. (Incidentally, we're talking about our approach at the next Bay Area D3 User Group meeting http://www.meetup.com/Bay-Area-d3-User-Group/events/19268574...)
Feel free to contact me directly (contact info in profile) if you're interested in learning more about Ayasdi!
I'm a PhD student in pure mathematics (studying theoretical computer science), and I have a list of industry companies I might want to work at in the event I don't get a satisfactory post-doc.
To what extent do the folks at Ayasdi engage in the research side of the picture? Would you be interested in hiring someone with both strong programming skills and mathematical knowhow to work on both the research and development sides?
Definitely — our R&D team works on developing new mathematical approaches (for example, how to best leverage TDA for classification problems) and also applying existing approaches to new problem domains. The team also does plenty of prototyping (coding) and then works with engineering to move new algorithms to production. Drop me a line and I can put you in touch with someone who can talk in depth about what we're up to on the research side.
I'm in the research group at Ayasdi and can say that we actively do research in both TDA and Machine Learning and have developed unpublished but cutting edge fusion between the two fields - using TDA to enhance traditional machine learning models (not yet released in public).
I regularly attend academic conferences, give university colloquia and also talk at industry events (eg. In the last month I gave two workshop sessions at ICML in Beijing, gave a lecture at a drug design conference in NJ and presented at a Big Data conference in NYC).
We do basic research but as a small company (and small group) we have to keep our eyes on the commercial application and financial implications of our work. For myself I've found this environment stimulating and if anything has helped my research productivity.
It's worth pointing out that Gunnar Carlsson - who is mentioned in the article - is both one of the inventors of TDA and someone who participates in the daily development of the company and product. We have an open seating plan and he currently sits diagonally to my desk and next to one of our most junior employees (not in the research group). In that sense, there's opportunity for people to step up as they desire with access to people who aren't just leaders in TDA, but who invented it.
As a company we consider someone like yourself in a variety of roles - Data Science, Research or Engineering. In all of those groups people develop novel techniques that could be qualified as "research" and all groups contain people with PhD's in technical fields - some coming straight out of grad schools, some after postdocs and some after holding faculty positions. We are broadminded regarding academic backgrounds and there are people with undergraduate degrees making novel contributions as well. One of our presales engineers (who has a PhD) just had a paper published in Nature - which I mention to show how we have research capabilities spread very broadly through the organization.
If you want to talk more feel free to reach out to me.
From the article I'm having a hard time figuring out if this new technique is a clustering algorithm, a feature reduction algorithm or dimensionality reduction algorithm
It makes a lot of sense to reduce the number of Ss for the sake of gameplay, and it seems like Butts redistributed those extra tiles amongst the vowels.
Yes, my distaste for C is probably because I'm not a good enough player, haha. I received an email mentioning the CLARINETS heuristic for choosing tiles to leave in one's rack, and in that context the drop in C's value makes sense, as you say.
I was thinking that you could sum up the transition probabilities from the actual transitions available on the board as the main measure. Then you could use frequency by length to weight legal Boggle plays (3/4 letters and up, so 2-letter words wouldn't even count).
You're right that with a Boggle board you could just count up the available Boggle points by finding all the possible words, but that might miss some aspects of how hard the words are for a human to find.
If you had enough real games data you could see how often a word is found when present and use that is a weighing factor. Although the arrangement if a word might also impact the likelihood to be found.
Changing the values of tiles will change the game, so you'll have a new mismatch. I think that a simpler fix would be to ban plays of fewer than three or four tiles are placed (I'd say four since three is still too easy). You can still score off the stupid two letter gotchas, but you have to place a three or four letter word down to score anything.
The game would end when all players had two few tiles to play.
Yeah, we'll do what we can to comply. If you're signed up and have your Twitter account connected you do get the reply/retweet functionality on hover. We like the calm of having no avatars, but we could add them (and see if we get busted if we let users toggle them).
The part that is tough for us is third party actions. It's specifically those actions we're excited to enable. So while we don't anticipate having to totally remove Twitter data, we do expect it to become less useful and integrated.
It's unclear how draconian Twitter wants to be. We'll do our best to work with them while refining and adding other services as a hedge against getting cut out.
