ryansloan
Joined 17 years ago
Joined 17 years ago
It's interesting to me that this article focuses on how they might be using data to understand who can be persuaded. I recently read a book by Eitan Hersh called Hacking the Electorate about how campaigns use data to perceive voters (and how they primarily focus on public data). Hersh suggests that persuadability isn't a focus of campaign initiatives because it's too hard to do in a way that is cost-effective. He suggests this is the main reason campaigns focus on mobilizing people who are likely to vote for their candidate. It will be interesting to see if campaigns are able to build better models for persuasion this year.
A->B->C->A
D->E->F->D
Unfortunately real-life intervened and we didn't have time to decide if this was an NP complete problem or not...
When I was a student, I had some great teachers who were tenured and some great teachers who were non-tenured. However, nearly all my awful teachers did have tenure. A lot of the people I know were in a similar situation. Some were good teachers who got complacent and lazy, and some seemed to have slipped through the cracks from the beginning. Small N, but I can see how tenure definitely creates some messed up incentives.
That said, I think there are two sides to this issue. Making it easier to get rid of bad teachers is a start, but it's also important that there's a good, transparent way of evaluating whether a teacher is good or bad. I know a lot of teachers, and they all feel as if the way their performance is measured is pretty broken. They're measured based on performance on standardized tests that don't test the right things, etc. I think if you want to attract and retain good teachers, you have to establish better metrics, too. With the wrong metrics, what you end up with is a big pool of teachers who are successful at checking off the right boxes.
(I realize this performance measurement thing is a hard problem in just about every industry!)
1) You can scope your team's features and commitments more effectively if you have some understanding of the technical complexity of each ask.
2) Understanding the technology (and the skills of your people) means you have better intuition about the right people to bring into the room when a problem arises
3) It's easier to be empathetic with your team when you have engineering experience, because you know that many times the spec is just the tip of the iceberg.
4) Credibility. A group of devs will have a lot more respect for you from the start if they know you're not just a bureaucrat and you can code (even if it's not as well as they can)
I don't know enough about your niche to say anything definitive (and I'm not really an expert, anyway) but I was working on selecting a research and export control system and there was a ton of regulatory policy we had to learn/consider. I'd say you should start by talking with faculty members who are directly involved with the process to see what you're getting into.
The one question that was pretty constant across the departments I worked with was "How long will this company be around, and what is our support commitment?" Universities usually avoid spending money on IT if they can, so they want a product that is going to be well-supported. Switching solutions is costly, so that makes them fairly risk-averse as well.
In addition, the procurement processes are usually bureaucratic nightmares, but that's the same with large companies :)
* Formerly: Product at Textio, Product Manager at Code.org, Program Director at Coding with Kids, Program Manager at Microsoft
* Georgia Tech Computer Science Grad
http://ryanjsloan.com
http://twitter.com/ryansloan