Accidentally in Code

Tag: engineering

  • Dimensions of Engineering Growth

    Dimensions of Engineering Growth

    Image by suju-foto from Pixabay

    One of my coaching clients and I developed this framework to help him think about the kind of impact he wanted to have as a Staff+ engineer, and since then I’ve taken it to other clients and direct reports in a way to think about engineering growth outside of any particular job ladder.

    The four growth dimensions are:

    • Scope
    • Complexity
    • Output
    • Agenda

    Scope

    What it means: Scope is the size of the problem or responsibility and is relatively straightforward to quantify in LOC (Lines of Code) or people involved.

    • For ICs, this often goes bug -> small feature -> large feature -> multi-feature project -> …
    • For managers it’s often TLM (Tech Lead Manager) for small team -> manage team -> manage managers -> manage managers of managers …

    Failure mode: The failure mode of growing in scope is often need to control. What is possible to control in a small team or project gets progressively harder over time. Everyone reaches some kind of limit there (admittedly some much later than others).

    Inflection point: Figure out how to get the outcomes you are responsible for with different mechanisms than that of control (documentation, setting standards, coaching and mentoring, reporting, pro-active checkins etc).

    Opportunity: As scope changes, think about how the way in which you work needs to change. Whilst we might fix a bug using a debugger, it’s much harder to develop a complex feature like that, and so that increase in scope is an opportunity to adapt and grow. This continues as you take on more responsibility; you cannot (effectively) manage managers the way you manage ICs. It’s worth noting that sometimes in our careers we might take a decrease in scope – for example when we change jobs and have to onboard through fixing jobs, or go from managing managers to managing ICs in a smaller organization. In these instances we will also have to adjust our approach to our renewed scope in order to be effective.

    Complexity

    What it means: Complexity is the difficulty of the problem, and more difficult to quantify – sometimes it takes some amount of domain knowledge to know what is challenging.

    • For ICs complexity is in the projects, the complexity of the feature, the problem space, or the code base.
    • For managers complexity is in what is being delivered and how. What is being delivered is the complexity of the product, managing a team building a CRUD app is less complex than managing a team building a more specialized/unique application with a greater variety of client side work. How it is being delivered is the way in which the tean works, for instance a team that has to manage more stakeholders (such as a platform team) may have higher complexity than a product team. 

    Failure mode: The failure mode of complexity is the continuous increase in complexity. Effective scaling (of an individual or a team) involves the transformation of complexity, where something that was complex is made simpler in such a way that it can be more sharded.

    Inflection point: Complexity is often a point where engineers around senior get stuck. Having worked with continuously increasing complexity, they either make things more complex than they need to be, or persist a high level of complexity that needs to be simplified and sharded.

    Opportunity: Take a holistic view of complexity – complexity is not just the code, but also the product and environment it exists within. Focus on outcomes to resolve and reduce complexity in such a way that it allows others to be successful.

    Output

    What it means: Getting things done, or causing things to get done.

    • For ICs this starts with an initial focus on raw individual output, and progressively shifts to enabling other people over time.
    • For managers this is the output of your team or org, over time. Over time is important, whilst you can create short term output at the expense of things (underlying work, attrition), you will typically pay for those in the form of lower output later. This means being able to balance an increasing amount of disparate work whilst maintaining a good rate of output consistently.

    Failure mode: Short term thinking. Individuals who focus on their own effectiveness at the expense of the team, managers who push short term output at the expense of longer term team functioning.

    Inflection point: Recognizing when output needs to happen through other people rather than individually. Balancing short term pressures with longer term impact.

    Opportunity: Take a broader view of output, identify where you can overall increase output outside your own individual efforts (through other people, via processes, tooling, architecture etc).

    Agenda

    What it means: The driving force of what you’re trying to get done. As you progress through an organization you will have to balance a broader agenda, ultimately driving the agenda of the entire organization, and navigating conflicts between that and the agenda of individuals or teams.

    • ICs often focus on their own work or team, but at Staff and above typically need to hold a larger agenda around an area or domain.
    • Managers need to fit the agenda of the team within the overall agenda of an organization, tying it to work that impacts the business.

    Failure mode: Taking too narrow an agenda that conflicts with bigger agendas. Such as the IC who pursues their own interest at the expense of the overall team, or a manager who is too focused on the team they manage versus taking a “first team” (peer) mindset.

    Inflection point: Moments of conflict between an individual or team agenda and an organizational agenda.

    Opportunity: Look for places where there is an opportunity to tap into a broader agenda, whether it’s focusing on the team’s needs rather than your individual needs, or the goals of an overall initiative rather than the pressures of the project.

    Making it Actionable

    When working within a job ladder framework it can be a challenge to 1) separate out evaluative feedback from developmental feedback and 2) truly focus on growth rather than trying to check a box. As such, I hope this can be a neutral tool you can use to consider how you can grow, and what kind of growth would support your actual career goals. It’s fine to enjoy scope more than complexity (and vice versa), the main thing is not to allow something to hold you back by becoming a controlling weakness.

    The first step is to identify one of these to actively work on, bring awareness to it, and execute on a plan to deliberately try to improve (whether through stretch assignments or deliberate practice).

    Good luck! Let me know how you get on.

  • Addressing Hiring Gaps Through User Research

    The hiring hot take is a regular feature of every tech conversation. Newsletters. Conferences. Blogs. Twitter. We talk about hiring a lot, because the market is competitive, and hiring well makes a big difference. Hiring effectively goes well beyond the “quality” of people you hire – it sets them up for an experience inline with their expectations, and contributes to – or is detrimental to – your company brand.

    Within that, we talk about diversity in hiring. Companies set goals, often publicly, commit to targets that are way in excess of their current demographics, without similar transparency on how they approach inclusion. Meanwhile, under-indexed people receive a volume of inbound interest, often for roles completely different to, or way less senior than the ones they have.

    Message from a recruiter I received last week. Note – my LinkedIn profile is set to Colombia – 4,500KM away from this event.

    With the volume of information out there, it’s hard to pick through what’s good and what’s not, what’s correlation and what’s cause. Much of the information is situational – what works in one context may not work in another – and conflicting.

    Meanwhile, hiring processes have an information imbalance that makes learning from them hard. You know how the people you hired performed – after a long lag time – you don’t know how the people you didn’t hire would have done. You know how some of the people who applied found you, but you don’t know anything about the people who looked at your job posting and decided “nope”, or the ones who never found you at all.

    In the product development process, we have a process for learning about the people we are trying to reach. User research. It’s something we do a lot of at Automattic, as we aim to understand the people we hope to serve with our products. It informs our roadmaps and prioritization, the way we present things, and how we talk about them.

    To that end, as we reviewed our hiring process, we realized that the demographics of people we attract to apply are not inline with the demographics of the people we hope to hire. Whilst we have implemented a strong focus on metrics, and made certain adjustments, we’ve not seen the improvements we want. If this was a product, we would go to our users and ask them – so why not do the same here?

    To that end, we are kicking off a user research project, to better understand the ways that people think about the process of finding a new job. Like all our user research, it’s compensated. Like everything we do, we share it openly – so whilst we will use the results to inform our process, we will also be sharing a public write up of the things we learned.

    For our initial research, we’re looking for women and non-binary people (trans/cis/gnc) who may experience similar gender discrimination in the workplace, who have multiple years of experience in a software development role. If you’re open to participating, please fill in some information in our pre-screening form.

     

  • Upcoming Talk on Effective Mobile Engineering Teams

    Upcoming Talk on Effective Mobile Engineering Teams

    devices

    I’m working on a talk about running effective mobile engineering teams – I’d love to know what questions you have about this, what you worry about when it comes to mobile teams in your organization, and what you’ve found most helpful to communicate about them. Comments or email or DMs on Twitter welcome!

    Title: YOLO Releases Considered Harmful – Running An Effective Mobile Engineering Team

    Organisations often worry about their mobile teams. Sometimes they are a bit separate. There’s often this inexplicable hostility to mentions of “React Native”. Why do bug fixes take so long to get to production, and what are all these certificates for, anyway?

    In this talk we’ll cover the realities of shipping compiled code, the woes of the app stores, and the infrastructure challenges we haven’t figured out yet. You’ll leave with a better understanding of the realities your mobile teams may be struggling with, and some strategies for how to help them – and your organisation – build an effective mobile team that ships regularly. And yes, you’ll finally understand the React Native argument, too.

  • All the Leaves are Brown and the Sky is Gray

    All the Leaves are Brown and the Sky is Gray

    © Copyright Peter Church and licensed for reuse under this Creative Commons Licence.
    © Copyright Peter Church and licensed for reuse under this Creative Commons Licence.

    It’s a weird thing to reflect on my career and realize that very little of the code I wrote is still in production – because very few of the things I worked on are still in production. Most of the products I have worked on have failed.

    We build with bits not bricks. Architects and civil engineers leave their legacy on the skyline. In software ours is mainly in the things we learned, and our relationships with each other. Are you better, smarter, kinder, because of the people you worked with? Can any of them say that about you? From every failed project I worked on there is someone, often more than one, but at least one, who my life has been dramatically richer for having known and worked with. Maybe that is as much as I can hope for. Maybe that is a good run.

    It’s still hard though. To look back, and see – a year of my life to that one. Dead. Six months to that one. Dead. 18 months to that ridiculous mess. Dead. Did I do anything meaningful? Was any of it worthwhile?

    By the time I left the conglomerate I was very familiar with various forms of project killing organizational dysfunction. I could predict the kind of failure, and why. I was generally powerless to do anything about it, though, and it’s pretty depressing to be the person who is predicting disaster. No one appreciates it at the time, although later people sometimes ping you to tell you, “you were right”.

    But I’ve learned something about building software well, something about mobile, something about running functional teams that execute. And most importantly – even when the product fails, it doesn’t mean that you did.

    Some failures were engineering failures, of course. The team that built a platform instead of the product we were supposed to. The team that just didn’t execute well. The team that was so busy over-engineering everything that the actual product barely moved forward (maybe because things like adding a field to a form required changing >10 files). The organization that bet that technically superiority could win over a product people were actually using – and, of course, lost.

    And there are my personal failures: prioritizing the wrong thing, trusting someone to deliver something I shouldn’t have, getting distracted from execution by politics and bullshit. Fighting for things that I was never going to win on.

    But generally engineering has been the least of it. And I think that is because the low hanging fruit is gone, and mainly we are left with minor inconveniences and behavior change. Nothing remains offline only, so we are left with things to optimize, and trying to invent new things that no one ever knew they wanted. Behavior change is hard – how many things can you think about that have been real behavior change? Pokemon go has actually got people to walk around outside, so that’s a big one. But say the – incredibly profitable – Kim Kardashian app is that really behavior change? Or just behavior facilitation. A different forum for an existing behavior of celebrity obsession.

    I think this is especially true on mobile. The most interesting things I see happening lately are in infrastructure, and on mobile we are mainly talking about new languages (Swift! Kotlin!) rather than new things we can enable for users. Last year I gave a talk about how mobile is a systems problem – as a lot of the things that make the best user experience are contextual (and contextual is 1) hard period, and 2) far too easy to be very creepy and intrusive) or moving server side to better support a multi-device world.

    This year I prepared a talk called “how to be invisible”, about how the best user experience is no user experience at all. Which comes back to this point about optimizing: when you are trying to optimize, you kind of need to disappear. There are a lot of apps trying to better facilitate minor inconveniences, and all they offer is a different, digital, kind of minor inconvenience. These applications invariably fail. I don’t believe Uber would have succeeded if they started outside of SF – because outside of SF taxis are a minor inconvenience. In SF taxis were a nightmare, so it was much easier to be a dramatic improvement. Now the experience is – mostly – better than the minor inconvenience of taxis in other cities, dramatically helped by taxis (in some cities) being one of few things that are cash-only. But I don’t think it was at first.

    There’s a rhetoric in tech that claims something grander and more dramatic. It is mostly not true. Even working at companies who genuinely have changed the world, most of the day to day work of an engineer will not come close to that kind of impact. Their careers will be littered with failed features, failed products, even as the behemoth overall moves forwards. This isn’t clear from the outside, because whilst products are launched with a fanfair, they are killed quietly. It is surprisingly easy to eliminate months, years of work.

    We build with bits, not bricks. Sometimes, often, all we leave with is what we learned, and our relationships with each other.

    Better make them good.

  • You Get What You Incentivise

    You Get What You Incentivise

    tulip stair
    Credit: Wikipedia

    It’s about 18 months since my friend Tracy wrote this post pointing out that whilst the tech industry evangelises data for decision making, there is very little available when it comes to diversity numbers. And about 12 months since we started seeing companies release their numbers. Helped along by radical shareholder action from Jesse Jackson Sr.

    This is progress, right? These things didn’t used to be discussed even internally, which is ridiculous because if you’re a woman on a team with more men named “Dave” than women, it’s the kind of thing you notice. Just because you don’t know the global, or local, percentage, doesn’t mean you don’t have a good idea of what is going on.

    These are good developments, but at this point perhaps it’s worth stepping back and considering – how far have we come, actually?

    Firstly, there is no consistent definition of what “engineering roles” means. My understanding is that it ranges from a narrow definition of ENG/UX/PM, through to a “everyone who reports into an engineering cost centre”. The numbers vary accordingly, but not everyone knows this – I’ve spoken to women who were comparing numbers at companies as part of their decision to take a job (or not) thinking that it was a different of percentages… when it was actually mostly a difference of definitions.

    Secondly, if we’re going to blame the pipeline of women and minorities with CS and related degrees, and by “we” I mean “tech companies disclaiming responsibility for the culture they have created” it makes sense to tie the numbers to roles where a CS degree might actually be a benefit.

    It’s not like there isn’t precedent for this – the ABI Top Company for Women awards use a standard definition for technical roles. Companies who have participated in this have that data. They have just chosen to release other – better looking – data instead.

    As with all processes and incentives, you get what you incentivise. What concerns me is what is what is incentivised in this scenario: padding the definition of “engineering role” to make the numbers appear better, and focus on hiring “diverse” new grads.

    What would we want to incentivise? Perhaps:

    • Hiring under-represented groups at every level.
    • Paying them equitably.
    • Building a culture where everyone is allowed to succeed:
      • Where they have equal opportunity to do equal work.
      • Where promotions aren’t delayed by gendered or racial feedback and expectations (hello, lawsuits).

    What I would love to see is firstly a standard definition of what “engineering role” means.

    The second, more revolutionary thing that I would like to see, is companies reporting not just the percentage of minority groups but the percentage of compensation going to minority groups (e.g. as determined via a standard measure, like taxation).

    This removes the incentive to pad out “engineering” with less prestigious, and less well paid roles to make the numbers look better.

    It makes hiring more senior people from under-represented groups, and paying those people equitably more important.

    And for people looking at these numbers when evaluating companies, it would be a helpful metric. For myself, I’d prefer a company with 15% women in “engineering” roles receiving 13% of “engineering” compensation than one with 18% women in “engineering” roles receiving 12% of compensation. We know there is going to be a gap – women are better represented at lower levels. But the size of, and comparison of that gap would be very telling.

    As in all things when it comes to diversity in the tech industry, we know that the data on people of color is even worse, and there is a racial pay gap as well as a gender one, generally.

    I suspect we’ll never see this data. Because yeah we saw some progress, but we saw a lot more PR.

  • Friends Don’t Let Friends… Become PMs

    Friends Don’t Let Friends… Become PMs

    Careful
    Credit: flickr / Tom T

    Recently, I heard about a school that has a mandatory “technology” class that students have to take in order to take CS classes in later years. It features: wood-working, circuit building, and Excel.

    This is horrifying. I want to go there with picket signs and stage a protest. Dress up as robots and chant things. If someone deliberately set out to design a course that would put kids off CS without them ever getting an inkling as to what CS is, they couldn’t do better than this.

    Wood work? WOOD WORK?

    And then, I’m in “training” for something (external) where old white men are telling me how to talk to high-schoolers, and describing what I do – software engineer, programmer – as “builder”. Apparently I have an “isolated” job and it’s the kind of thing that can be out-sourced… really not that high-potential a career. They seem to be saying that students should be blending a little bit of the technical with business and voila they’ll have a great career and let’s all enourage girls to do this, shall we.

    And I think, it’ll be a cold day in the hell I don’t believe in before I encourage anyone to study business period, let alone for a technology career.

    I cry a little inside because I thought I’d signed up to encourage women to go into tech, not near tech.

    Wood work starts to seem sensible by comparison.

    Thankfully after that I go back to my team of 50% woman and we keep working on creating something extraordinary. We’re trying to build something that can’t just be in the head of one person, so we have to communicate. We’re trying to build something well, so every piece of code gets looked at by 2-3 others. And later I’m stuck on something and one of them steps through it with me and I realize what I’ve done wrong and fix it. We get creative trying to do things that we haven’t done before. We have so much fun together that our visitor goes back to his office raving about how lovely we were to him and how close we are as a team.

    My isolated job, is not so isolated.

    Things I worry about with respect to girls and technology. I worry about terrible math teachers and gender-stereotyping convincing them that math is not for them, that girls aren’t good at math. Regularly I have conversations with women not in tech careers and they tell me they were good at math in school, and yet somehow didn’t consider taking it further – it just didn’t seem like an option.

    I suspect wood-working classes won’t change that.

    Then I worry about girls in university who think “I’m ok technically, but where I really differentiate myself is that I have good communication skills… I could be a great bridge between the technical and the non-technical…” who then go and become product managers. And they never find out that they were just as good as many of the guys in the class, that a technical career was an option. I know, because this happened to a friend of mine – thankfully she rethought it before she took that path and now she’s an engineer. And because it was nearly me, too.

    And so my friend and colleague complements me on my communication skills, and I quip that they would be distinctly average compared to people in any other profession, it’s just compared to engineers that they seem good.

    My point – being able to communicate doesn’t mean that a technical career isn’t a great fit, just like I don’t think there is much correlation between wood-working and software engineering skills. I’m on a mission to urge university girls – think about being an engineer before you decide being a PM is for you. It’s been four years since I finished my undergrad, and in that time I’ve come to realize – those guys who thought they were great and I figured they must be if they could be that confident? No-one is as good as those guys thought they were. Under-confident does not mean under-qualified. Really.

  • Not a Scientist, Nor an Engineer

    Mandelbrot fractal
    Credit: flickr / flickrnospam

    When I was doing my undergrad, I knew a lot of geography students. One of them told me that geographers spent a lot of time debating what geography was. I found this completely ridiculous, of course, imagining the only thing to be more pointless than studying geography was angsting about nature of geography.

    (Of course, I don’t mean to offend geographers. I’m sure there are in fact many things more pointless than geography, like… banging your head against a brick wall! Or, arguing with an idiot who will bring you down to their level and then beat you with experience. Or – philosophy! If they could only decide what geography is, I could no doubt compile a more comprehensive list.)

    There are great outreach programs at uOttawa, one for science and one for engineering. Computer Science is not covered by either of them. So I’m having my own bit of angst, what are we, and why are we rejected by both scientists and engineers? (Although, not the things we create, which they depend on heavily).

    I searched for the answer, but Google didn’t have a short answer for me (it did, however, find me a comprehensive essay). However thinking about it, I think we fall in the middle – sometimes scientists, and sometimes engineers. We can choose what we want to be, which is cool. Sometimes we’ll study, like a scientist; experiment, investigate. Sometimes we’ll build, like an engineer; design, scale.

    Perhaps one day, instead of being rejected by scientists and engineers, we’ll be claimed by both sides – celebrated for what we can do.

    Or not. Maybe we’ll just be something special, all of our own. Software Artistes, yo.