Accidentally in Code

Tag: success

  • How Should We Define Success?

    This is part 5 of a series of blog posts based on a talk I prepared called Successfully Derailed Product. It’s about the ways in which we define and talk about “success” influence what – and how – we build. See part 1, part 2, part 3, part 4.

    What we’ve covered up to now is how the ways in which we define success don’t work, or break down when they come into contact with other people and their definitions of success. It’s okay to be despondent at this point – me too.

    One thing we haven’t talked much about until this point is company success. If we want to stay employed, we hope the company we work for will be successful. When a company does one thing, in a very focused way, company is like a superset of team. We can go through the same exercise.

    As companies get bigger, and do more things, the company becomes the context. The processes become more relevant to individuals and small teams than the mission.

    (which is why you need to be very careful what they are)

    “My first denied promotion taught me the wrong lesson. I thought I could keep doing the same work but package it to look good for the promotion committee. I should have done the opposite: figure out what the promotion committee wants, and do that work exclusively.

    I adopted a new strategy. Before starting any task, I asked myself whether it would help my case for promotion. If the answer was no, I didn’t do it.

    My quality bar for code dropped from, “Will we be able to maintain this for the next 5 years?” to, “Can this last until I’m promoted?” I didn’t file or fix any bugs unless they risked my project’s launch. I wriggled out of all responsibilities for maintenance work. I stopped volunteering for campus recruiting events. I went from conducting one or two interviews per week to zero.”

    ~Michael Lynch, Why I Quit Google to Work for Myself

    I’m sympathetic to this guy’s conclusions – the post is a story of how someone wanted to be a diligent engineer and a good teammate, but the promotion system, and their personal desire for promotion (and recognition!) meant what they personally felt incentivized to do made them a bad teammate. You don’t want to work with that person, and you don’t want to be that person. But this is what the system told them “success” looked like.

    Running engineering teams like this definitely impacts product – which impacts users too. For internal users whose service becomes unreliable or unmaintained once someone gets promoted (or because it won’t help someone get promoted), or external users who live with things that aren’t great, because improving or fixing them is not promotion worthy – so no-one wants to do it.

    The end of this story, by the way, is that he figured out how to play the system, got great review scores… but his teams kept getting re-organized which made promotion impossible – and that wasn’t a gameable system. So he quit.

    One of the reason why I was looking to see how many articles mentioned users in my research around teams is that studies show that people are more motivated when they see how their work impacts real people. Fundraisers for scholarship donations were more motivated when they had contact with scholarship recipients. Lifeguards were more vigilant after reading studies about people whose lives had been saved by lifeguards. When cooks see who will be eating their food, they feel more motivated and work harder.

    Are we doing that in development teams? Well if we are, we don’t seem to be talking about it that much. I ask everyone I interview if they have any experience with user testing, and the overwhelming majority say no. But – those who have that experience talk about how impactful it has been on them.

    So this is really not about how teams should define success – but about how we can align team success with user success. This changes our definition of what success is, and it’s also good for motivation.

    But – we have to be careful that we actually do understand what users consider to be success. I used to work on a carpooling app, and we talked about how people wanted a way to organize their car pools and exchange money more easily. But I used to read every support ticket, and the what I ended up suspecting was that really what people wanted to do was track their carpooling in order to qualify for company eco incentives. Which… sounds a lot less like a viable business model. So you know… I don’t work there anymore, and neither does anyone else.

    One thing we do on my current team, is a quarterly “empathy challenge” where we attempt to connect more to how people use the WordPress apps – there are options, like joining a call with a new customer, or running a user test, or blogging ourselves from a mobile device. We collect case studies of people who are regular users of the apps and ask them about their website, what are they trying to do with it, how do they use the app. Everyone on the team starts with three weeks in support and spends a week each year doing support – and it’s important to listen to user pain and frustration. But we’re trying to balance that by also listening to people who are happy. It’s important that we understand what’s broken, but it’s also important we understand how we’re helping people reach their goals. It’s also much more uplifting. And it reminds us that whatever we ship is measured not in lines of code, or how technically interesting or challenging it was… but how useful real people find it.

    Because despite what the aliens may have concluded – we don’t run teams to run teams. We run teams to do something.

    Keeping this mindset also changes the way that we talk about our work and focuses on impact rather than the details of what. It doesn’t necessarily change what we do – but it does communicate the why more effectively. And it does make the “finish” line clearer – because that’s around the impact – something that we can share as a “this is a new thing for you”. If we don’t feel proud of talking about what we’re doing in that way, then maybe it’s not yet finished, or maybe it’s not worth doing at all.

    As a result, we rebranded “Networking refactor” to Full Jetpack Support,  “New Editor” -was rebranded to talk about accessibility and performance, and being a building block for Gutenberg. We rebanded “Async” to be about not waiting for media to upload when you’re ready to publish. Finally we rebranded “Bug fixes and improvements” to #NoMoreBrokenWindows – making it a point about how we wanted to improve the polish and overall experience.

    These things can seem silly, or manipulative, like they don’t result in more being done as a team, but regardless of what is objectively true – and how would we measure it anyway – tying our success to user success gave us a sense of meaning, which I think translated to momentum and focus. Our support people tell us they spend less time helping people with basic things that shouldn’t confuse them, and out app store ratings have crept upwards.

    Now we’ve aligned the team with our users, what about individuals?

    Maybe now you’ve gathered, I’m not really big on “should”, so this is really: how can you create success for people in a way that aligns with your team? Because even though individual success is personal, people respond to the expectations – and incentives – we create for them and those can work against what’s best for the team and the product if we’re not careful.

    What’s next? How we can create alignment.

     

  • How Do Users Define Success?

    This is part 4 of a series of blog posts based on a talk I prepared called Successfully Derailed Product. It’s about the ways in which we define and talk about “success” influence what – and how – we build. See part 1, part 2, part 3.

    Let’s take another step back and talk about how users define success.

    Because really – we’re building software to do something, right? For actual humans to use. So why wouldn’t we talk about them when we talk about success.

    Working on WordPress.com, we talk about this a lot. It turns out people mostly don’t want to “make a website” or “choose a theme”, they might talk about wanting to “make my site look the way I want it”. But really, they want to be found by potential clients, sell things or just take payments, share their ideas and perspectives – in the hope of reaching a community or potential clients. They love their stats, because it’s a metric that shows them how they’re doing on their goals. There’s a framework for thinking about this called “jobs to be done”, which is essentially the idea that people “hire” software to do “a job”. So when they talk about the software they want, they’re talking about what they think will do the job. But we’ll design better experiences if we focus on what job they want the software to do.

    A fascinating article from basecamp about people requesting a calendar view was one of the two user focused articles I found in my research on teams.

    So if we think about the job to be done for an On demand app, they might be around:

    • Convenient way to get what (or where to) I need.
    • Faster than alternatives.
    • Cheaper or comparable.
    • More choice.

    But on demand apps are two sided market places, so what kind of things might the providers of on demand services be thinking about?

    • Be discovered by new people.
    • Make more money.
    • Flexibility about when to work.

    And then you can think about things like surge pricing as balancing that tradeoff – more money, for less flexibility for the driver. More expensive, but more convenient for the rider.

    If we thought about Social networking, there are some well documented adverse effects – like depression and low self esteem. But what might be the job to be done?

    • Connecting with friends, or new people.
    • Building an online presence (in pursuit of some goal). Although someone told me the other day his kid wanted to be “a youtube star” so…. I guess that’s a job now.
    • Finding relevant, real time, information.

    But! Social networks are also a two sided market place, and the other side is the advertiser. So what are they trying to achieve?

    • Selling their product, which they quantify by return on ad spend. So per dollar spent advertising in some place, what amount of sales are generated.

    One thing that starts to be clearer here is how products can align their success with the user’s idea of success. So if someone can achieve the goals of their website – if they can connect with people, or sell their product or generate leads for their business, it’s doing it’s “job” and they will be happy to keep paying for it. What’s good for the user is good for the business.

    You can see that with an on demand app too, if it’s a better experience for the customer, and allows the service provider to make more money, it’s a win for the platform because more business flows through it. Let’s just leave out bending employment law and potential monopolies for now.

    With things like social networking though, it’s much harder to align the interests of both sides of the marketplace. I did not join Instagram thinking I wanted to be sold random shit, I joined to for the constant stream of raccoon pictures. And yet Instagram shows me as many advertisements for random shit I don’t want  – and yet so compellingly I often wonder for a minute if I do – as adorable raccoons.

    average_minutes_per_day.png

    There was a study recently from a company called Moment (an app to encourage you to use your phone less, oh the irony), that showed the apps we like most are the ones we spend the least time using.

    Capture d’écran 2018-03-23 à 11.01.57.png

    What’s also noticeable to me is how many of the apps that make people happy are ones where they are more clearly serving some kind of purpose, rather than things used to pass time. Those tend to make us unhappy.

    There was a period where we talked a lot about “delighting” users, and this by and large seemed to be a conversation about aesthetics and animations. But what I take from this is the value of thinking about how we serve users. What do we make possible for them? What do we make easier? Because if we’re not building what I would term “digital crack” user success is product success, and product success is team success.

    What’s next? How might we define success.

  • How Do Teams Define Success?

    How Do Teams Define Success?

    This is part 3 of a series of blog posts based on a talk I prepared called Successfully Derailed Product. It’s about the ways in which we define and talk about “success” influence what – and how – we build. See part 1, part 2.

    Taking a step back from individual success, I wanted to understand was an industry we talk about building teams. What is the team working towards? What motivates them? What bonds them? What makes them proud?

    I turned to a resource called Software Leads Weekly. It’s a newsletter that was one of the first things I was pointed towards when I became a manager, and it’s read by around ~18K people a week. I figured it would be a reasonable example of how we talk about technical leadership. I went through every issue this year, 13 issues with 130 articles and categorized every article in a spreadsheet. Blog posts made a bit over 50%, and tweets a bit under 40% (I shouldn’t tell my boss this, he’s pretty into blogging), with the rest a mix of media articles, video etc.

    To try and quantify the bias here, whilst I was at it checked the gender breakdown of things included. 15.4% of included articles where by women. Now, gender is not binary, and not the only measure of diversity. BUT – it’s easiest to quantify, and necessary but not sufficient. I.e. if something is genuinely diverse, it will have good representation of women. If something is representative of women, it can still be poor at representing other axes of diversity like race or ability. Now for those of you who think 15% is OK, because it’s about tech, note that not all the articles are from tech, and so there’s plenty of possibility to do better than the poor standards of this industry. But that is not taken.

    I read a good amount about management, and running teams, and sometimes I wonder if an alien was studying this, like the way the alien in Hitchhiker’s Guide called himself Ford (because he thought cars ruled the earth), what would they think development teams do?

    So finally, I have my answer. And it’s pretty much: they might reasonably think we run teams to run teams, as some kind of cultural ritual.

    The most popular categories are team operations – which was a broad category included things like process, job roles etc, and individual effectiveness which was narrower – personal productivity strategies – time management, decision making, etc. Less than 30% of articles had the word “user” or “customer” in them, but only 2 could really be defined as being about users and what the software we build is for.

    I rounded out this biased research with some more biased research on Twitter.

    I got some interesting responses. But I’d also love to know what you think. (Leave your answer in the comments or tweet at me).

    Note – much less popular, and far fewer responses. I wonder why that is? Do people have less clarity there? Are they less willing to share it?

    Capture d’écran 2018-04-03 à 11.49.35.png

    There are two themes worth highlighting here. One is clarity, the other is psychological safety. Clarity around what the team is doing, and needs to do. Psychological safety is about the team feeling good about getting there together.

    Capture d’écran 2018-04-03 à 11.49.41.png

    I like the idea that “a successful team cares”. One thing I would highlight here is how quickly “what does a successful team look like” becomes “things managers should and should not do”.

    Like… optimizing for playing video games. I have some feelings about this…

    Capture d’écran 2018-03-23 à 10.27.37.png

    I’m not sure what to take from this research. It’s hard to see the relationship between what individuals are seeking out and what teams are. At best, we’re talking about teams as an environment for individual work, rather than the way in which we work together on something bigger.

    Maybe that we’re more comfortable talking about video games and individual effectiveness than the bigger differentials of effective teams? Are these the things that we just don’t want to talk about in public? I run a slack for engineering managers and the topic discussed there are very different.

    I wonder if part of this is the challenge of generalising when teams are made different not just by the people in them, but in the circumstances they operate in, and the harder things get the more personal things become. When we distill to a blogpost, by necessity we leave much of the complexity out of it. So it’s a lot safer to write about how to bring in Kanban, than is it to talk about how to manage up. It’s much easier to talk about how to hire than how to fire – and hopefully we do more of the former, anyway. It’s more enticing to talk about the CI stack than the slow grind and many failures towards achieving product market fit.

    But ultimately I think any experienced manager will tell you the harder topics make the biggest difference to the a team that executes on meaningful work, than a disconnected non-team that does not execute at all.

    What’s next? How users think about success.

  • How do Developers Define Success?

    How do Developers Define Success?

    This is part 2 of a series of blog posts based on a talk I prepared called Successfully Derailed Product. It’s about the ways in which we define and talk about “success” influence what – and how – we build. See part 1.

     With the caveat that how we define success comes from various places, and any collective definition is most likely nonsense. I set off to understand the ways in which developers, and particularly individual contributors think about success.

    I started with the Stack Overflow survey. Caveat: I hate it and I think it’s riddled with bias. For example, women make up ~fifty percent of the population, around ~twenty percent of technical roles… and 7.2% of the respondents to this survey.

    So let’s start by looking at how developers feel about jobs and careers. Developers tend to be pretty satisfied with their career, a bit more so than their current job.

    This slideshow requires JavaScript.

    When looking for their next job, the top priorities are professional development, compensation, office environment and technologies.

    Capture d’écran 2018-03-23 à 09.14.15

    The most valued parts of compensation are vacation time, remote options, health benefits and expected work hours.

    Capture d’écran 2018-03-23 à 09.15.18

    Most developers check in code multiple times a day. And the more often they check in, the happier they tend to be.

    This slideshow requires JavaScript.

    Success metrics developers would choose are: customer satisfaction, time and budget, peers rating and product performance. It’s interesting that manager ratings and self ratings are considered about as useful. Not a ringing endorsement for managers there.

    Capture d’écran 2018-03-23 à 09.20.01

    So to rounding out the quantitative data riddled with bias, I got some biased qualitative data in the form of posting a question on twitter.

    I got some interesting responses. But I’d also love to know what you think. (Leave your answer in the comments or tweet at me).

    Many of the themes from the Stack Overflow survey showed up here – shipping code, learning and developing, autonomy.

    Capture d’écran 2018-04-01 à 16.40.39

    There was also a theme of recognition – including financial. Which makes sense, because as as society money is the usual mechanism by which we communicate value.

    Capture d’écran 2018-04-01 à 16.40.42

    People also talked about the way the sense of accomplishment changes (or has to change) as your job evolves and you take on more responsibility.

    Capture d’écran 2018-04-01 à 16.40.48

    Another theme, though, was the theme of impact. People using what was built, benefitting others in some way.

    Capture d’écran 2018-04-01 à 16.40.44

    The graphs show trends, but people’s personal definitions show that success is personal. We see the baggage people bring with them from previous (external) definitions, the way that definition changes over time, or that what we believe is important conflicts with what makes us happier in the moment.

    It was noticeable to me that women who responded seemed much more likely to talk about the supporting others in some way – whether their teammates, or people using what they worked on. There are a number of different observations we could make here – one is that the patriarchy trains women to consider others in a way that is not as true for men. But also it hints at what might be different about those survey results if they were more representative of the demographics of the industry – and what could be different if the industry were more reflective of society as a whole.

    What’s next? A look at the way we talk about team success.

  • Whose Expectations are Those, Anyway?

    Whose Expectations are Those, Anyway?

    This is part 1 of a series of blog posts based on a talk I prepared called Successfully Derailed Product. It’s about the ways in which we define and talk about “success” influence what – and how – we build.

     

    raccoon
    Credit: ToRange

    There used to be a joke at a company I worked for that went “how many test frameworks do we have” and the answer was “how many SET5s do we have?” It was “funny” because an SET was a software engineer in test, and to get promoted to Level 5 they would have… written a test framework.

    How often have you have seen those kind of things? Where the things that get incentivised for individual success turn out to be a joke at scale? Because clearly when it comes to testing frameworks, more is not better. It’s pretty orthogonal to the goals of testing – which are generally around continually shipping with confidence.

    This isn’t to say that promotion processes are inherently bad, or that individuals shouldn’t desire and work towards professional advancement. Just that the processes and goals that we define profoundly affect our organisations, the environment it creates for people who work there, and the things we are able to ship as a result. Your processes define your culture, and your organisational dysfunctions show up in what you ship and when you ship it.

    This isn’t to say that goals are bad. Goals are good… it’s well documented that we make more progress when we know what we’re aiming for. But if we set the wrong goals, or we set goals that aren’t compatible, then what? And when we agree on the goals we should be setting… are they supported or sabotaged by our processes?

    Let’s talk about what “success” even is. Take a moment, and think about some goal in your life. What is it? (Leave it in the comments or tweet at me).

    Do you have something in mind? Now I want you to think about where it came from.

    Hard part over: how do you measure it and how do you report on it?

    Example 1: I have a goal of increasing the monthly actives in the app. My boss gave it to me. I measure progress on it using analytics and report on it every two weeks.

    Example 2: I have a goal of clarifying the “vision” for my team. I got this from my team in various ways – surveys / direct feedback about this being something people want. I measure it quantifiably using surveys, and less quantifiably from the kind of questions that get asked in our monthly townhalls or in the regular skip 1:1s I have with everyone on the team. I report on it quarterly – in that we have a document outlining the longer term plan for the team, and this is how often it gets updated.

    There’s a framework by Gretchen Rubin on how people respond to expectations, called the Four Tendencies. She describes it in Better than Before (Amazon) and goes into more depth in The Four Tendencies (Amazon). Essentially, there are four ways in which people respond to expectations.

    Obligers respond to expectations from other people. They struggle meeting their own expectations.

    Upholders respond to all expectations – including those they define themselves.

    Questioners question all expectations, and respond only to expectations they think make sense.

    Rebels resist all expectations.

    https://twitter.com/alexisylchan/status/975048974032814086
    Obliger Goals, 2018

    So how does this relate to goals? Well obligers probably got their goals from other people, upholders might be making great progress on things they don’t actually want, questioners are trying to ignore things they can’t make sense of, and rebels are opting out of the very thought.

    Meanwhile, obligers often feel unappreciated because they’re so busy putting other people ahead of themselves they can’t get their own stuff done. Upholders don’t understand why people don’t just do what they are asked or say they will do without complaining or asking so many questions. Questioners are annoyed by all the arbitrary things that other people want (and also, ironically, by being questioned) and rebels just want to be free to do whatever they feel like and resent all the interference.

    All these things are playing out around us. But a lot of the time we don’t have a way to articulate it so we don’t talk about it.

    Currently, I manage five managers, and we started talking about it towards the end of last year, in part because reading the book I realised that I was not great at managing obligers. I’m a questioner, and I was completely mystified by the behaviour of taking on arbitrary things and then resenting them. So you know, an obliger gets overwhelmed, and my response is along the lines of “why are you doing that anyway”, which, you know, they don’t find helpful… and then they feel resentful and I feel confused. It’s great working with obligers because they are so nice and helpful. But because of that it’s very easy for people to inadvertently create expectations and take advantage of them. Meanwhile upholders can lack empathy for people who aren’t as effective. This gave us a shared language to talk about how we are creating and responding to expectations with each other.

    On a more organisational or social level, there’s an idea called Campbell’s law.

    “The more any quantitative social indicator is used for social decision-making, the more subject it will be to corruption pressures and the more apt it will be to distort and corrupt the social processes it is intended to monitor.”

    ~Campbell’s Law

    Bit abstract, right? A good example of teaching to test. Standardized testing can work for measuring attainment, but once students are taught to pass the test, both the teaching and the test lose value.

    You can think about this in terms of promotion processes. You define a system which makes sense, but then people work to the system, and both the work and the system become less useful.

    Another place you can see this is the tension around shipping culture and something that might be called a “quality culture”. When you define a process to incentivise shipping, shipping becomes the goal and what is actually shipped tends to become secondary – and not very good. Then in a “quality culture” the quality is the most important thing, and so nothing gets shipped at all…

    …But if it does ship, it will be perfect.

    animal-black-and-white-fence-160709
    Credit: Pixabay

    (As an aside, this is why I like to talk about shipping as a habit rather than as the goal itself. I think this is something where release cycles help, because it can force shipping on a cadence rather than shipping specific things).

    One way to phrase Campbell’s law is that we work on the definition of the thing. And the result is that definition is probably nonsense.

    I find all this pretty fascinating, but what does it all mean? How do these things connect? Well when we define systems, we create incentives – or expectations. Individuals take these expectations and it influences their goals (even if they’re rebels – just in the opposite way).

    Essentially – defining systems is fraught with risk of derailment, because teams are not made up of rational actors, but rather: people.

    What’s next? A look at the way individuals define success.

  • NSConf: Halle Winkler – Duck Taping the Gates of Chaos Shut

    NSConf: Halle Winkler – Duck Taping the Gates of Chaos Shut

    My Notes from Halle‘s amazing talk at NSConf.

    success failure
    Credit: Pixabay / geralt

    Terror – have people who have had great app indies for 5-10 years – real experts. This has been working 3.5 years. Been an interesting and challenging 3.5 years.

    Started because was “meh” at apps. 3 paid apps. Got positive feedback, but couldn’t crack the marketing code. Decided to pause, reconsider, decide what the next thing should be.

    This isn’t really a failure talk. Failure tolerant industry. Used to be the case that one big failure could take you out. Now maybe we’ve gone too far the other way – glamourising and valorising failure.

    Suspicious about how much data you get from failure. Can fail on the app store but not know why.

    Focusing on failure may lead us to mis-categorised success as failure. Leading us to abandon a strategy that is working, but slowly.

    E.g. hit 75% of target – do you have a failed product? Did you estimate the wrong timeframe? Do you have a resource allocation problem?

    If looking for a failure in that scenario, you’ll find it. But maybe it’s an undersized success.

    When you stop, and reconsider, how do you proceed.

    With intention, that is how you carry on.

    “What do I want to do?” – one of the scariest first world questions. When we answer it, we might actually be able to do that thing.

    Let’s not make it too complicated.

    We want to make something useful. We can make something entertaining. Entertaining is a use.

    Wanted to build on something that was already demonstrably working.

    Had released a library – making offline voice recognition look good. Wanted to make offline speech recognition look good. Improve UX by stealth.

    How to make it into a business?

    Unusual as a sector – most businesses aren’t a single isolated thing. They usually have some diversity and consonance.

    In a lot of businesses, diversity, protects you from a shock. Consonance – multiple products build interest in each other.

    How to do that with OpenEars?

    Wanted it to be free. Didn’t want to do the selling support business model – selling support creates perverse incentive not to make it as simple as possible. But believe it should be as simple as possible.

    If something is a core value for you, the best place to put it is in your business model.

    In a lot of places where there is one app, there is a quiet second business. Often a media channel. A fantastic blog, or a fantastic podcast. Has a halo effect, your audience is with you in social media. When you talk about your app, that gets amplified by your audience. Don’t do this cynically, but if you’re interested, good way.

    Now have 5 plugins, 6 integrated products. One developer.

    Little Things

    Meet the Neighbours – step from the agile manifesto. When you start a new software project, look at who is nearest and reach out to them. Decide what relationship you want to have with them, and create that. Asked “how can I be of use to them” – this is the question.

    Software projects that work, last for years. So decide at the beginning what kind of relationships you have and make that happen.

    Having a role model is good. Having an idiot role model is better. Had another software vendor, her vendor, was so angry with them all the time. Doing everything wrong. Wanted to rant about twitter every day. Realised, their product structure is a bit like Politepix. “They could be a lot like my company in 2 years!” Became fascinated, why do they make such terrible decisions, what was going on. Read all of their apology blog posts – it was like a visit from bad decisions future.

    You can learn from mistakes. There are enough mistakes to go around, you don’t have to make them all yourself.

    Learn doubly-entry book-keeping. Fired accountant, didn’t understand what he had done. Had to learn it. Like getting an introduction to the history of capitalism from first principles. Will let you do great projections for your business, if you understand it. Once you learn which side of the ledger capital is on when you hear about a terrible startup raising a series A, you will have the appropriate response, which is sympathy.

    Big Things

    Industriousness

    Small business can take up all your time. Have to focus on improving your product. Use programmer laziness. Automate everything you can.

    Don’t repeat yourself

    • Automated documentation pushing this in all formats. Most important, documentation is really pretty.
    • Code snippets. If you don’t give them snippets, they will go to stack over flow and get a snippet. Then you will have to support it. Created a customisable tutorial tool.
    • Forums – main problem was pointing people to the right answer when not finding it themselves. Wrote a tool, dealt with 90%. Macros for other 5%.

    The third time you do a production task, and it’s not improving your app, automate.

    Support became a much less big job, but 1 in 3 shot it would be a horror scenario. Started to dread looking at questions. Wrote a sentiment analysis tool that helps. If sentence particularly negative. If sentence is particularly subjective. What the worse sentence you wrote is. And makes suggestions, “maybe go take a walk before you answer this.”

    Tool is “Me on my best day giving advice to me on my worst day” which helps respond to people when they are really stressing you out.

    Anything you are doing that requires manual intervention, you can probably automate that.

    Automated automated testing. Wrote a fuzzer, called HWHorrorShow. Randomised cross-thread stress-test.

    You can automate all kinds of things that you wouldn’t necessarily think you could.

    Agreeableness

    Learn to say no. Bootstrapping through contracting is great, but you have to stop when you stop.

    If you run a product company and it works, you’re probably really good at executing. You don’t know if they are going to be.

    No to free updates.

    No talking about future plans. When someone asks you, they are asking you because they are making a plan. You only have control of the plans you make at the beginning, things change.

    No spending all of your money on the products of famous luxury brand, Apple. Cost control is a real thing. Isn’t discussed that much. Standard business model high growth low revenue, not sure about the end game. Small, sustainable indie – want to be profitable in 12 months.

    No to being a fan of Apple. You can like, respect, but you should be clear – if you want to be a fan, be a fan of your peers. They are doing amazing things, it’s going to mean a lot more for them.

    No features for individual people.

    No to the avoidant decision process. Because you’re afraid of people’s negativity.

    The Philosophy of Death

    Anxiety is normal. Confusion about your sphere of control. You control your planning, part of your execution, the way that you respond, basically nothing else. If you react to these worries, everytime something awesome happens, there’s something that can bring you down.

    A business entities life is not a human life. When fearing business will tank, you will look at doing things that you would not normally.

    Looked to ancient greek philosophy to deal with anxiety. Not big fans of positive thinking. Visualise that every morning, and then put it away and then you’re done.

    The Doldrums

    Not becoming such a dull person that new ideas can’t find your address.

    Small business problems can be addictive. You can fill 100% of your time with that. But your creativity is your most important tool and characteristic.

    Cultivating your spark is a really big part of your job – like taking care of your health and psychological well being to the best of your ability.

    Berlin is full of hidden courtyards. Become obsessed with getting into all of them in neighbourhood.

    Find the source of the delight that leads to making delightful products. Don’t think you find that behind a screen.

    Don’t eat the seed corn – your creative capacity is what got you into this, it’s the only thing that can move you forward.

    Closing Thoughts

    Irony in making something very self-sufficient, makes less need for collaboration. And that is a huge loss.

  • Stories We Don’t Tell

    Stories We Don’t Tell

    © Copyright Richard Croft and licensed for reuse under this Creative Commons Licence.
    © Copyright Richard Croft and licensed for reuse under this Creative Commons Licence.

    Over the past year, I feel like I’ve been working through the stages of grief about being a women in tech, and I’ve not been blogging because I couldn’t find the words to share the story I wanted to tell. I’ve denied the extent of the problem. I’ve got angry. I’ve bargained. I’ve cried, and made my exit plan. And finally, I’ve come to some degree of acceptance.

    I’ve said, “there are worse places to be a woman than in tech, like a coalmine”. I’ve wondered, what the tax is – a 6 day week rather than a 5 day week? 50% extra than the dude next to you? And finally I’m at the point where I say, “well, it’s better than being an accountant”.

    This isn’t a good thing. We need to have hope that it will get better to continue, and I don’t always think it will. Yeah, there are wins, and every nerdy boy we educate is a huge achievement, but there are new ones at such a rate, with their entitlement, and their straight white male privilege, and it seems like a drop in the ocean; it just won’t stem the tide.

    It is hard to be on the internet and think that things are getting better, when it seems like every week I read another horrifying story. Because, I know, these are not aberrations – it’s only the horrifying stories that are posted, by people who no longer fear the ramifications. I couldn’t write about GHC last year, because the main thing I walked away with was this knowledge, that we all have these stories, these tales of horrifying misogyny and unfairness, along with a thousand tiny cuts.

    I have my story, but whilst my friends know, I don’t know that I’ll ever be able to write about it here, because I still fear the ramifications of sharing it. It’s a tale about how I was incredibly stupid, and did not realize what was going on until it was way out of my control, and the willingness of people to ignore the evidence, because they don’t want to believe that is the kind of world they live in.

    Someone does/says something horrible, but with such confidence that whilst something rings false, it almost seems normal. And good, well intentioned people who would never do such things themselves, don’t realize how not normal that is.

    I understand not wanting to believe that. I wish I still did. That – denial – is what got me into that situation. It was happening to me, and I didn’t realize how far it was from normal. And a long time later, I look at it, and marvel at how I could be so incredibly naive and optimistic about people’s intentions.

    There are the thousand tiny cuts. The little comments, the gendered feedback, surprise that you’re an engineer rather than a PM or UX. The feeling of being other. Being the only woman in the room.

    But what I realized, is that I wasn’t alone in having my big story, that I couldn’t share. Nor was I alone in having gone to someone nice, and well intentioned, and have them not want to believe this is the world we live in, have them dismiss it, tell me it wasn’t worse because I am a woman, that it is just how it is. And I was not alone in not knowing what to do after that.

    But this is the world we live in. And so, when I meet that rare women who tells me she doesn’t have a story, I think, it’s coming for you. Or wonder if it happened, but she didn’t notice at the time and eventually, she will.

    It’s hard to believe this, and stand up in front of girls and tell them – be an engineer. I finally did that again for the first time in 2012 a few months ago, with one of my favorite people in Sydney. We did a double act, and it felt like cheating, because he is the kind of nerdy boy, who is so kind, and special and supportive of everyone (but especially women) that if they were all like him, I’d still feel other, but it would be OK.

    And then I did a panel at a retreat we hosted. I was so nervous, and I asked myself, “how do I tell them it’s OK?” – but they were university students, and so some of them already had their story, and they know, so I admitted that things happen, but told them “We have each other”.

    My friend laughed when I told her I was giving up online dating because “I spend all day surrounded by dudes, the last thing I want to do in the evening is meet more dudes”. It’s true, some days I worry my life doesn’t pass the Bechdel test. But I’m also surrounded by amazing women.

    We give – to each other, and those behind us. But we also take, from those around us and ahead of us. I don’t think there is any other way to survive.

    I’ve organized things, helped build communities, I’ve mentored, I’ve encouraged, I’ve stood up in front of groups of people so they know there is such a thing as a female engineer. I’ve taken calls from friends in tears, advocated for and tried to protect other women. Told the truth. I’ve held myself to such high standards, researched extensively before ever asking a question on a mailing list because you suck at math / girls suck at math.

    New to a city, I’ve been grateful to find those communities ready made. I have mentors, people who encouraged me, who believed me, and in me, I’ve called friends in tears, been advocated for, and been protected. And every year at GHC, I watch these amazing women stand up on stage, and I know, that OK, there may be a tax on being a woman in this industry, but we can work harder, smarter, and better, and we can find the extra that we need to be successful.

    I have my story I can’t share. It’s likely you do too. We can tell them in person, if we need to, because they are so depressingly similar and we know. And on bad days, when we want to run away, we can remind ourselves, that we have each other. Which doesn’t always sound like much, but it’s actually pretty incredible.

  • Blood, Bones and Butter

    Blood, Bones and Butter

    blood, bones and butter
    Blood, Bones and Butter

    I read about Blood, Bones and Butter by Gabrielle Hamilton (Amazon) on the Eloquent Woman blog, which discussed a section of the book in which the author writes about a panel she was on, and things she wanted to say, but didn’t. It was a panel about female chefs. Initially she has an attitude of “why are we still talking about this?” but it turns into frustration with the other panelists, as they come out with trite things and she wants to say, but doesn’t, that it is hard to do the second shift, to constantly second guess yourself, make tradeoffs between your work and your family.

    I was fascinated, drawing parallels between that and women in tech, and trying to find some broader variety in my reading matter. So I bought it.

    That is my favorite chapter in the book, but the book as a whole I also really enjoyed and it gave context for it. This woman has had a fascinating and extremely eventful life. So many stories. They can seem a little disjointed, and the ending a little abrupt, but it’s an autobiography not a novel, so I forgive it.

    I think, ultimately, the thing that gripped me most is that this woman is fantastically successful, and it’s clear – and she writes about this – that she never had a plan. She never set out to be a chef. She went off to grad school thinking about becoming a writer. And here she is, apparently both. There are so many people who are all about the plan, say they always knew. It’s refreshing to see this other, honest, perspective, of not knowing what the hell you’re doing but working incredibly hard and figuring it out as you go along.

  • Reminding Myself As To Why We Continue, Despite Everything

    Reminding Myself As To Why We Continue, Despite Everything

    If you can turn yourself into smoke whenever you want, why do you bother walking?
    Credit: flickr / Jackman Chiu

    It’s been a mixed week. Some successes – Awesome Foundation! Girl Geek Dinner! Getting my visa sorted! And then a number of things that made me wonder why I was bothering. Mostly stupid things, and you could say that I shouldn’t worry about them – but that is easy to say, and hard to do.

    Telling a friend about one of them, she gets it, telling me I shouldn’t be bothered by it but understanding that I am, likening it to the first negative comment she received on her blog (which, of course, she still remembers). And I think about how insane it is that I can’t remember the first positive comment from a stranger on my blog, but I can remember chunks of the nasty ones. How I’d forgotten I was on the radio until the recording came on my iPod and creeped me out (“who’s that talking? Oh wait, it’s me?”) but I definitely haven’t forgotten the couple of mixed press articles about things I’ve done, or the article where they misspelt my name.

    In interpersonal relationships, a ratio of five positive to one negative interactions is needed, from Wikipedia:

    After studying married couples for many years, psychologist John Gottman has proposed the theory of the “magic ratio” for successful marriages. The theory says that for a marriage to be successful, couples must average a ratio of five positive interactions to one negative interaction. As the ratio moves to 1:1, divorce becomes more likely. Interpersonal interactions associated with negative relationships include criticism, contempt, defensiveness, and stonewalling.

    When doing things, I don’t know what the ratio is, but I do know that it’s very easy to dismiss the nice comments as people “just being nice” and take the nasty ones to heart. By nasty I don’t mean constructive criticism – the kind people who say, “have you thought about X” and then offer you something – time, a contact, a piece of information – that will help you do that. I mean, just straight up, “you suck” with no acknowledgement of the time, effort, and energy you put into doing whatever it was sucked. It’s stupid to get worked up about, I know. If they have nothing nice to say, they were likely not your target audience.

    Personally, I do things for two reasons. Either I find them interesting, or I think they should be done. “Have people tell me how awesome I am” is not on that list, and please, should it ever be that way, shoot me. So – why does “Having people tell me how much I suck” make the list of reasons not to? It shouldn’t. I know, objectively, that the more successful you are and the more you do the more people will try and belittle what you do, and at times somehow manage simultaniously to try to take the credit for it. I know that. And yet, each time it happens (as it did twice this week) I’m hit, afresh, with feelings of guilt, inadequacy, and frustration. And, too often, I wonder if they have a point.

    Deep breaths. Focus on the reasons why. When I dislike someone’s means, remind myself that the ends – and their intentions – are good. And, as a reminder that set-backs are not necessarily the end, this week a battle that I had been fighting for several months, was won. I hadn’t thought it would be, and I’d had to go and focus on other things. But then, someone else didn’t give up, and the result is that we all win. And the following day, something happened to remind me why I thought that battle was important in the first place.

    But, again, all of this – easy to say, hard to do. So tell me, how do you avoid taking things you shouldn’t to heart?