Accidentally in Code

Tag: development

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.
June 6, 2022
The Rent Versus Buy of Career Growth

Credit: ejaugsburg / Pixabay

The topic that got the most attention in my previous post about being the DRI of your career is the concept of rent versus buy when it comes to managing your career.

Distinguish what your employer rents versus what they buy. I find this particularly relevant when it comes to things like “personal brand”. My employer buys my time, they rent my personal brand. To that end, I’m conscious that whilst it’s part of the value I bring, I don’t want it devalued because ultimately it’s my asset for the long term. This concept also applies to expertise. My expertise is rented, and so I maintain my understanding of what it’s worth, and what is current on the open market. If your job does not match the market in a way that will make it hard for you to find another one, I hope your employer is paying a lot of rent – because they are destroying the market value. At times that might be worthwhile, but often it is not, and people realize that too late.

Here, I’ll expand a little more on how I think about that, but I’d also love your input on how you think about it and what examples you would place in each. Leave a comment, ping me on Twitter, or drop me a note.

Rent

When you “rent” something out, you retain ownership of it – the renter just gets the use of it. As the long term owner of the asset, it’s on you to be conscious of the value, and make sure the renter is not destroying the value long term.

Expertise

Expertise is a key example here. Your expertise is yours. It’s what will help you get your next job, negotiate your salary (oh hai “market value”). Because “professional development” is a core retention strategy in tech, too many people are complacent and outsource this responsibility to their current employer, instead of being strategic in how they consider their own development. This is why there’s discussion about “staying current ” as a developer. We used to hear the phrase “there are a lot of unemployed COBOL programmers”, and now it’s more like, there are a few COBOL programmers, they make a lot of money, largely from banks or the government.

This piece is often where the side project dialog goes off the rails. Should you need to do side projects to get a job? Are open source contributions a requirement? I am a hell no on both these points. However, being strategic about where you invest resources (time and money), and/or developing a habit of deliberate practice can help you develop your expertise and command a higher rent on the market. The extent of that investment is up to you.

I think developers, if they are lucky, can largely get away without thinking too critically about this, because professional development is a core retention strategy of most “good” tech companies. But at smaller companies, levels above senior developer, or in management, training is often limited and deficient, and if the individual doesn’t take control over their own growth they will hit a ceiling.

As a hiring manager, the biggest mistake that I see people making in this realm is the resume that shows “X years of experience” (where X>=6) but when you dig in you see the same 1-2 years of experience again and again. These people top out, stop getting recruiter pings and they don’t know why – but it’s because they didn’t consider how to grow their expertise as they switched (or didn’t switch) jobs.

Brand

There used to be a lot of discussion about “personal branding” and frankly it was nauseating. But, as an individual we all have a “brand” or a “profile”. At a minimum, it’s what’s on your resume, and how you build the narrative of your career. Some companies or roles are detrimental to that. If you work at a company that is materially contributing to (and profiting from) the collapse of society, that may reflect on you.

A common mistake I see is where people have a job title or custom role that does not match the market. Companies sometimes try to pay their “rent” in inflated job titles – I’m extremely skeptical about the value these have on the open market. For a good recruiter or hiring manager, a “VP” or a “Director” job title without an expected scope of responsibility opens more questions than it answers. It’s worth mapping your responsibilities to the expectations of the market periodically, and checking that you’re still generally employable – hybrid roles where people do A and B are particularly susceptible for not meeting the criteria of either A or B externally. An “and role” can be a plus when you do one thing particularly well but have additional skills – for example an engineering manager who does some product work, or a designer who also does some CSS. “And roles” where people do two+ jobs, poorly, do not set people up for success in their broader career.

But for those of us who have a bigger profile, some recognition in the community, the concept of brand goes beyond the resume. In a leadership role or DevRel, but to some extent elsewhere, your profile and ability to attract talent is part of your value to a company. It’s important to remember that you retain ownership of your profile, and that it’s for the long term. You don’t want to be seen as a shill for a company that later turns out to be problematic.

I saw a tweet lately that made me think about this; the company thought they were buying this person’s profile. But she was clear it wasn’t even available for rent.

This point on brand doesn’t apply to everyone, but where it does it’s worth considering carefully. My main point here is: boundaries. Think about how you want to use your profile, what options you want to be available to you, what boundaries you want to set around it. Make sure that you’re balancing between the rent and ongoing market value.

Attention / Context

Attention is also rented. What do I mean by that? Often you work in a particular domain, and you pick up things about it. Maybe you work in fintech and you acquire a bunch of knowledge about financial regulation. Maybe you work on web standards, and acquire a bunch of knowledge about governance. Maybe you work in Open Source and acquire a bunch of knowledge about licenses. Your attention is directed by your domain.

When you leave, you take with you that context and what you learned, and that can help you elsewhere. Personally, I’ve been working in Open Source and building remote teams for a long time – those things have had my attention, now I know a bunch of stuff about them, and that is one less thing anyone has to explain to me when I switch jobs. In another part of my life, I did a bunch of work on presentation software and picked up various things about file formats and rendering. At times, I use these bits of information. It’s like a shorthand; I can more quickly evaluate a resume, or the likely complexity of a project, because I have that domain knowledge.

The win of attention is a little additional curiosity can result in disproportionate amounts of learning given current context. Later, you have these bits of useful information that you can use to accelerate things. Being conscious of how you allocate that can make a difference and make more opportunities available – whether you go deep, or pick up complementary / adjacent contexts. The mistake of attention is when people think they know a domain, but really they know a company. I remember the interview where someone told me they were a “$domain guy” when their understanding seemed very limited to questionable business practices of one particular company which… okay yes, did have a product in that domain.

Buy

If some things are rented, what is bought?

Time

Time is the obvious one, typically part of the working agreement, officially around 40 hours per week. Some jobs are more than that for whatever reason, and should pay more as a result.

The time aspect is interesting, because research shows that in senior roles, they are more likely to be held by men, whose wives are less likely to work. Women in these roles have fewer children, and are more likely to be single (source: HBR, see also: “7 in 10 men who have enough income to put their households in the top 1% of earners have stay-at-home spouses” Qz, “Why promoted women are more likely to divorce” BBC).

What I take from this, is that the time commitment of certain roles is such that it’s extremely challenging for someone to have such a role and be a parent. Those roles are compensated highly because it’s essentially compensating for the time of two people, where one is the “worker” and the other is the person who makes that level of work possible. The US presidency is perhaps the biggest such example, and one of the interesting things about Dr Jill Biden continuing to work at her usual job as a Professor, is that the position of “FLOTUS” (the unpaid second position that comes with POTUS) has to be filled at least somewhat by people who are actually paid… themselves… to do the work.

Working in a distributed context for years, the biggest mistake people make with time is that they don’t manage it well. Some people cannot cope with the flexibility, they fail to give themselves the structure they need to be effective. The other failure mode is the opposite – people struggle to disconnect from work, overwork, and burn out (for more on this topic, see: Figuring out Remote Work is Figuring out Work).

Energy

I include energy as distinct from time, as I think it’s what explains the continual gap between the hours that people work, and the hours that people think they work (much more). My theory is that when people think about how much they work, they count the energy that they spent. When they track the time, it’s more concrete. So a long dinner with friends is definitely not counted as “work time”, but if you’ve had a shitty week and spend half of it emoting… it counts energetically.

Dysfunctional environments are an energy drain way beyond the time commitment, and typically way beyond what you are actually compensated for. Thinking about it this way is an encouragement to set boundaries, or – if they aren’t respected – draw lines (like turning the phone off, or ultimately look for another job).

Adherence

Adherence is the agreements we make as part of any employment contract. Some jobs don’t allow people to do any programming/writing/speaking externally, and this can be a lot to give up. Maybe you have to live in a certain place, work out of an office, etc. In distributed contexts, travel used to be one aspect of adherence. When hiring at my last job, we would be super clear: 49 weeks of the year, you are wherever you like. 3 weeks of the year, you need to make travel work. It wasn’t for everyone, but I think that is normal and expected; not everything is for everyone.

If your employer is buying adherence, then it needs to be reasonable. Perhaps no amount of money would make you go back to an office – totally get it, but if your employer thinks they have paid for that, you are going to have to figure a way out of that disagreement that may well involve finding a new place to work. Personally, I can’t imagine selling my ability to write and code for fun ever again, but earlier in my career I made that trade-off for a while, and paid for it later.

Trade offs

Thinking about career decisions this way, you can consider different tradeoffs and options that work best for you at any given time. As an employee, it’s typical to allocate more time, more energy, and in return typically receive higher levels of investment in expertise – this helps people grow more, and ultimately earn more over time. The benefit of different working relationships, like contracting, is often to set stricter boundaries around time and energy, which can free people up for other things (or just maximize short term income). I can’t emphasize enough that all choices are valid and that people operate from wildly different constraints, many of which perpetuate systematic inequity. My question is: are you making those choices mindfully? And do they work for the life and career you want?

October 12, 2021
Estimations and Orders of Magnitude

Call me a cynic, but I don’t expect software estimations to be accurate. Because software is built by humans – and they take sick days, and vacations, time to help their colleagues (hopefully), have off days as well as good ones.

But I still think estimations are worth doing. Firstly, because if we don’t have some reasonable concept of how long something will take, how do we compare the effort and impact of A vs B and make any kind of rational decision?

Mainly, though, because the order of magnitude by which we are off says something about the project. We should be off by an order of magnitude smaller than the one we estimated in. I.e. when we estimate in months, we should be off by weeks. When we estimate in weeks, days.

Being off by an order of magnitude smaller allows for humanness and human error.

Being off by the same order of magnitude we estimated in suggests the project wasn’t thought through enough at the outset. It makes a case for spikes, and discussions, and architectural reviews.

Being off by an order of magnitude larger than we estimated in suggests something went truly wrong. These are the projects that drag on and on with no end in sight, and sunk costs too deep to rationally contemplate. They sap the morale of the team and destroy your reputation – internally if not externally. They are usually a sign that some bigger change is required.

July 17, 2018
On Boiling Frogs and Drowning Rats

Credit: Flickr / Mad Visions

Today's management lesson: "You have to boil people like frogs, not drown them like rats" — @catehstn

— Beau (@beaulebens) June 25, 2018

Beau recently tweeted an observation I made to him, which people reacted to… Something to do with “plague animals” all “ending up dead”. And well… maybe it isn’t my best management metaphor.

It’s a metaphor for how we expand people’s comfort zones – the way we want to give people more responsibility gradually, as it feels possible.

I suspect most high achievers have a point where we go from energised to so overwhelmed by everything we grind to a halt. Keeping people (especially new managers) in the space where they are energised, and catching as they head towards overwhelm is part of the job. It’s great if people will realise it themselves and surface it, but if we haven’t built a relationship such that they feel they can bring it to us… what are they going to do?

This is the failure mode – people drown in the sea of things they have to do, with nowhere to turn.

Some people like to be thrown in the deep end to figure it out, but thinking about this metaphor I realise that people who thrive when thrown in like rats are people who have built up their own resiliency and support. They’re not really being thrown in, because they have a parachute to deploy and a support team on standby, ready to help.

Which also clarifies that part of the frog boiling is to help people develop resilience – and a support network. I tell everyone around me that when their job gets harder, they should make a friend. Coaching is also amazing for helping develop resilience (and self awareness) and I encourage everyone to take advantage of it (if they can). But as a manager, how you react to the inevitable failures of people on your team – do you react with kindness, understanding, and coaching?

Or do you do you take your broken trust out on the person, destroying the relationship between you in the process?

How do you react to your own failures? Do you display the same accountability and commitment to learn that you ask of them? Or do you embrace a double standard?

As I think more about this metaphor, I see that the art of change management is the art of frog boiling. As much as we might be tempted to throw grenades in there “for speed”, consistent temperature and stirring will yield the highest number of live, temperature resilient frogs.

July 10, 2018
Empathy and Mobile Development

Credit: Pixabay / techlec / 140 images

One of the (many?) things my team may be tired of hearing from me is “empathy is part of our job”.

What do I mean by that? Well as mobile developers, we are the closest to the humans that use our product. We need to have empathy for our users – what do they need? What’s their experience?

For me empathy starts with a foundation of self-awareness and self-care. It’s a lot easier to consider other people’s needs when my own are being met.

Then, we can build on that with empathy for each other. If you can’t find it in you to connect on a human level with the teammate you work with every day, how do you find it in you to connect with the abstract idea of a human using your product?

What does this mean? Because honestly this phrase even for me invokes some nightmare scenarios of codependent emoting. But what I mean is the practise of seeing someone else’s perspective. Listening to each other. Valuing each other’s strengths, and not judging each other for our quirks.

We could start with a culture where we don’t blame, where instead we look at our processes and consider how they have contributed to the situation. Then, we improve our processes. Our “culture” is defined by our processes, afterall.

It’s a pyramid, and at the top is empathy for the user. We have to care about them. What they are trying to do, and in what situation, and on what device, they are trying to do it.

For me, the practise of empathy is mainly taking a moment to see the other side. But how do you do that for an abstract person? One example is that when I’m frustrated by fragmentation on Android, I remind myself that fragmentation is mainly a problem on lower-end devices, and as a result lower-income users. And then I feel a lot better about spending time on it. When I’m trying to prioritise anything to do with personal information I think about how upset I was when GMail changed my name and I couldn’t change it back and that reminds me how that would be even more upsetting for some other people.

Basically when I look at some large piece of engineering work and ask how important it is, I ask, who is it important to?

Thinking about this left me with one question – can you have empathy for the user if you don’t have empathy for your team-mates? Or, can you build a functional product without a functional team?

The conclusion I came to was that I think it’s possible, but I have never seen it. I think the answer as to why is that emotional energy is exhaustible, and if you spend it fighting for or defending yourself, there’s less of it when you need it to fight for, or defend, an abstract person you’ve never met.

April 14, 2016
Over-Engineering Culture, Hacking, and Complexity
Credit: Flickr / Glory Cycles

I was talking to a fellow escapee of The Conglomerate and we were talking about over-engineering culture. In the sense of “lol things built because it was time for someone to get promoted” and in the sense of complexity.

The thing about layers and layers of (debatably necessary) abstractions is that they make things that should be simple, complex. Which makes people feel stupid. The last change I committed there I was adding one field… and I had to change > 15 files. The biggest problem I had? Was thinking I must be doing something wrong because it couldn’t possibly be this hard to add one field, right?

I think of hacking as fixing one corner case only to make two more for later. So, reflecting on this, this is also true of a culture where things are hacked together. Because when hacks build on each other again and again, the result is that simple things become harder (and slower) than they should be. It makes people feel stupid.

We often talk about these two cultures like they are completely separate but this is not true. They feed on each other.
- Hacking can be a result of over-engineering culture, because things that can’t be done “correctly” may as well not be done properly at all.
- Hacking can be a reaction to an over-engineering culture, because people tired of things being so hard want to move fast and break things.
- Over-engineering can be a reaction to hacking because someone bitten by too many corner cases decided that it would be better if everything were a perfect circle.
- Over-engineering can be a reaction to hacking because perfectionism can be a reaction to things constantly breaking.
Personally, I like to think about the medium term. Essentially this means: don’t hack things because hacks are short-term. But just because there might be a reason why something won’t expand to fulfil some other purpose doesn’t mean that it should be generalised (yet). If that scenario is uncertain, and not in the current timeframe, document and move on.

Hacking to over-engineering isn’t a scale, it’s a circle. At the darkest part where they meet, simple things are hard, and engineers trying to get to grips with it feel stupid. Thinking about it, I’m not sure whether that codebase that required fifteen files to be changed to add one field was over-engineered or made of hacks, but does it matter? The effects were the same. Move slowly, with things that barely work.
August 26, 2015
Multiple Cellphones: How I Balance my Usage Across Both
Credit: Wikipedia

I have carried multiple cellphones for about 2 years now. I think as a mobile developer, it’s important to be familiar with both the major platforms (iPhone and Android) and I find the context helpful regardless of which platform I am working on.

Currently, I carry an iPhone 5 and a Nexus 5. My Nexus 5 is my “primary” phone – it has my UK sim card in it, and as such is the one that I use when I am not on a wifi connection (not that often, since there is wifi at home, at work, and in the gym). My iPhone has a US sim card in it, as it is now my designated travel phone. I use this to listen to music, and (almost) all the pictures I take, I take on my iPhone.

A couple of things:
- The apps I use most (chat, Twitter, 4Square, Feedly) are on both.
- Email and calendars are synced on both – not that I use email on my phone much. Now that I’ve eliminated most junk mail I get notifications for personal email on one phone, only.
- Necessary apps that aren’t instant are only on my secondary phone – this includes banking apps and personal activity tracking apps. This forces me to switch over periodically.
- Also, music and pictures.
- I make an effort to switch to my secondary phone when I get home and ignore my primary. Same in the gym, where there is free wifi – I leave my primary phone in my locker, and take my secondary with me to the x-trainer (with my iPad – I now tweet and watch TV whilst I get my cardio).
- In fact basically anywhere with wifi, I use my secondary phone.
My usage is the best it has ever been, a big factor in which is that I actually love my Nexus 5 enough to want to use it (a level of affection I never managed for my old Galaxy Nexus – I think this is mostly the beautiful screen), but after the first thrill of getting it, and a brief period of neglect for the iPhone I’ve found a balance.

I think, on the whole I slightly prefer my iPhone – the great camera, and all my music being on iTunes is great – I can play music on my Apple TV, and then when I head out the door I plug in my headphones and it continues right where it left off. Also, some apps are better on the iPhone, Twitter being a big one – the Android app is much more likely to lose my place in the stream, which annoys me, and the clicking out to launch chrome rather than the embedded web view is slower. Also on Android, you don’t see the page snippet in the expanded tweet view (sometimes enough that I don’t need to click out). Although I use Buffer on both, and it’s so much easier on Android, because of the share intent. In fact sometimes my workflow is that I go through my favourites (which I use as a mechanism for things to read later) using both devices (web page loading being the bottleneck) but do all my sharing from the Android.
March 14, 2014
Mini-Generation Gaps

Credit: Wikimedia

When I gave the Holiday Science lecture, one of the things that I touched on briefly was how my childhood was unrecognizable compared to the childhood of children 10 years my junior.

This article – The Children of Cyberspace – from the New York Times elaborates on that further. From the article:

“Researchers are exploring this notion too. They theorize that the ever-accelerating pace of technological change may be minting a series of mini-generation gaps, with each group of children uniquely influenced by the tech tools available in their formative stages of development.”

Lately, I’ve been thinking more about this and how technology education needs to prepare people for the future – both in terms of how we encourage children to take an interest in informatics (Computer Science) and what they’re taught when they get here. I’m starting to work out the details for a presentation, which I’m thinking about calling “Preparing for a Revolution”.

What do you think? Any suggestions?

January 12, 2010