Pawel Brodzinski on Leadership in Technology

Whatever it takes to lead a team, build a product, and run a business

Tag: AI

  • The Renaissance of Full-Stack Developers

    The Renaissance of Full-Stack Developers

    I’m old enough to remember the times when we didn’t use a label for full-stack developers because, well, all developers were full-stack.

    In the 1990s, we still saw examples of products developed single-handedly (both in professional domains and entertainment), and some major successes required as little as an equivalent of a single Scrum team.

    What followed was that software engineering had to be quite a holistic discipline. You wanted to store the data? Learning databases had to be your thing. You wanted to exploit the advantages of the internet boom? Web servers, hosting, and deployment were on your to-do list.

    It was an essentially “whatever it takes” attitude. Whatever bit of technology a product needed to run, developers were picking it up.

    Specialization in Software Engineering

    The next few decades were all about increasing specialization. The increasingly dominant position of web applications fueled the rise of javascript, which, in turn, created front-end as a separate role.

    Suddenly, we had front-end and back-end developers. And, of course, full-stack developers as a reference point to differentiate from. The latter has quickly become a topic of memes.

    Full Stack Horse

    Oh, and mobile developers. Them too, of course.

    The user-facing part has undergone further specialization. We carved more and more stuff for design and UX roles.

    Back-end? It was no different. Databases have become a separate thing. Then, with big data, we’ve got all the data science. The infrastructural part has evolved into devops.

    And then it went further. A front-end developer turned into a javascript developer, and that one into a React developer.

    The winning game in the job market was to become deeply specialized in something relatively narrow, then pass a ridiculous set of technical tests and land an extravagantly paid position at a big tech.

    The transition wouldn’t have happened without two critical factors.

    Growth of Product Teams

    First, the software projects grew in size. So did the product teams. As a result, there was more space for specialized (sometimes highly specialized) roles in just about any software development team.

    Sure, there have always been highly specialized roles—engineers pushing an envelope in all sorts of domains. But the overwhelming majority of software engineering is not rocket science. It’s Just Another Web App™.

    However, because Just Another Web App™ became increasingly larger, it was easier to specialize. And so we did.

    Technology Evolution

    The second factor that played a major role was the technology.

    Back in the 90s, when you picked up C as a programming language, you had to understand how to manage memory. You literally allocated blocks of RAM. In the code. Like an animal. And then, with the next generation of technology, you didn’t need to.

    The same thing happened with the databases. The first time I heard an aspiring developer claim that they neither needed nor wanted to learn anything about SQL because “RoR takes care of that for me,” I was taken aback.

    But it made sense. The developer started their journey late enough, so they could have chosen a technology that hid the database layer from them entirely (and, unless supervised, made an absolute disaster out of the data structures, but that’s another discussion entirely).

    And don’t even get me started about front-end developers whose knowledge of back-end architecture ends at knowing how to call an API endpoint. Or back-end developers who proudly resolve CSS as Can’t Stand Styling.

    Ignore my grandpa’s complaints, though. The dynamic was there, and it only reinforced the trend for specialization.

    The Bootcamp Kids

    As if that all weren’t enough, the IT industry, still hungry for more specialists, turned into a mass-producing machine of wannabe developers.

    With such a narrow specialization, we figured it might be enough to get someone through several weeks of a coding bootcamp, and voila! We got ourselves a new developer, high five, everyone!

    Yes, a developer who can do rather generic tasks in only one technology, which covers just a small bit of the whole product stack, but a developer nonetheless.

    The narrow got even narrower, even if the depth didn’t get deeper at all.

    AI Disruption

    Enter AI, and we are told we don’t need all these inexperienced developers anymore because, well, AI will do all that work, what don’t you understand?

    Seemingly, we can vibe code a product, which is a lie, but one that AI vendors will perpetuate because it’s convenient for them.

    The fact is that these narrow & shallow jobs are gone. The AI models generate boilerplate code just fine, thank you very much. Sure, the higher the complexity, the worse the output. But that’s not where those shallow skill sets are of any use.

    Arguably, depth doesn’t help as much either.

    We need breadth.

    Since an AI model can generate a working app, it necessarily touches all its layers, from infrastructure, through data, back-end, front-end, to UX, design, and what have you.

    Breadth over Depth

    The big challenge, though, is that AI can hallucinate all sorts of “fun” stuff. If our goal is to ensure it does not, well, we need to understand a bit of everything. Enough of everything to be able to point (prompt) the AI model in the right directions.

    A highly specialized knowledge can help to make sure we’re good with one part of a product. However, if it comes in the package of complete ignorance in other areas, it’s a recipe for disaster.

    The new tooling calls for a good old “anything it takes” approach.

    If that weren’t enough, the capability to generate code, especially when we talk about large amounts of rather basic code, potentially enables a return to smaller teams.

    The jury is still out. On the one hand, Dario Amodeis of this world would be quick to announce that we’ll soon see billion-dollar companies run by solopreneurs. On the other hand, the recent METR study suggested that experienced developers using AI tools were, in fact, slower. And that despite their perception of being faster.

    In the new reality, a developer becomes more of a navigator than a coder, and this role calls for a broader skill set.

    Filling the Gaps

    Increased technical flexibility is both a new requirement and an opportunity. At Lunar Logic, we work extensively with early-stage founders. That type of endeavor sways toward experimentation and, on many accounts, forgives more than working on established, scaled products.

    On the other hand, the cost-effectiveness is crucial. The pre-pre-seed startups aren’t known to be drowning in money.

    Examining how our work evolves thanks to AI tooling, I see similar patterns. For some products, the role of design and (arguably) UX is significantly lesser than for others. Consider a back-office tool designed to support an internal team in managing a complex information flow, as a good example.

    A now viable option is to generate the whole UI with a tool such as v0, focusing on usability, which is but one aspect of design/UX, and we’re good.

    Is the UI as good as designed by an experienced designer? Hell, no! Is it good enough within the context, though? You betcha! The best part? A developer could have done that. Given they know a thing or two about usability, that is. That knowledge? That’s breadth again.

    I could go with similar examples in other areas, like getting CSS that’s surprisingly decent (and way better than something done by a Can’t Stand Styling developer), or a database schema that’s a leapfrog ahead of what some programming languages would generate for you out of the box (I’m looking at you, Ruby on Rails).

    The thing is, every developer can now easily be more independent.

    Full-Stack Strikes Back

    The tides have turned. We have reversed the flow in both product team dynamics and technical skills required to be effective. That, however, comes at a cost of a new demand. We need more flexibility.

    It’s not without a reason why experienced developers are still in high demand. They have been around the block. They can utilize the new AI tooling as an intellectual exoskeleton to address their shortcomings (precisely because they understand their own shortcomings). Thanks to extensive experience, such developers can guide AI models to do the heavy lifting (and fix stuff when AI breaks things in the process).

    That’s the archetype of a software engineer that we need for the future. Understandably, many developers are caught off guard as they were investing in a completely different path, sometimes for all the wrong reasons (like, it’s a meh job, but at least it pays great).

    These days, if you don’t have a passion to learn to be a full-stack developer, it will be harder and harder to keep up.

    A disclaimer: there have always been and will always be edge-case jobs that require high specialization and deep knowledge. Nothing changes on this account. It’s just that the mainstream (and thus, a bulk of “typical” jobs) is going to change.

    Reinventing the Learning Curve

    That, of course, creates a whole new challenge. How do we sustain the talent pool in the long run? After all, we keep hearing that “we don’t need inexperienced developers anymore.” And the argument above might be read as support for such a notion.

    It’s not my intention to paint such a picture.

    I’ve always been a fan of hiring interns and helping them grow, and it hasn’t changed.

    hiring junior developers

    You can bet that many companies will not view it in this way.

    best time to plant a tree

    Decades back, we were capable of learning the ropes when we needed to allocate a block of memory manually each time we wanted to use it. I don’t see a reason why shouldn’t we learn good engineering now, with all the modern tools.

    Sure, the way we teach software development needs to change. I don’t expect it to dumb down. It will smart up.

    Then, we’ll see a renaissance of full-stack developers.

  • Pivotal Role of Distributed Autonomy

    Pivotal Role of Distributed Autonomy

    I’m a massive fan of distributed autonomy. I believe that, in principle, giving people more autonomy at work is the largest organizational challenge the modern workplace faces.

    Yes, the news of the day is either remote/hybrid work or the impact of AI on everyday jobs. Reinventing the organizational structures of a 21st-century corporation doesn’t belong to a broad discourse.

    From both perspectives, however, distributed autonomy plays a pivotal role.

    Autonomy in Remote Work

    With remote work, the dependency is straightforward. Much of the work has moved from the office—where it could be physically supervised by a manager—to homes, where supervision is significantly limited.

    The manager’s control is limited to the outcomes but not the actions that lead to them. For example, I can observe whether my engineers deliver features or add code to the codebase, but I don’t see when, how, and how much time they spend on activities that lead to “new features.”

    Sure, some organizations would turn to digital tools to control employees’ activities. Guess what. It doesn’t work. Well, it does, but not the way they intend. Here’s what this kind of monitoring does to people:

    • It reduces job satisfaction.
    • It increases stress.
    • It reduces productivity.
    • It increases counterproductive work behaviors.

    One hell of a slam dunk, really.

    It’s not only the lack of control, though. It’s also the availability of help. For the vast majority of organizations, remote work creates additional communication barriers.

    My leader no longer sits at the next desk. I can’t see whether it’s a good moment to interrupt them. Sure, I can drop them a DM on Slack, but they may not answer instantly. So, whenever I face one of those micro-decisions that I might have naturally delegated to my leader in the past, I may call a shot myself. It feels more convenient.

    What has just happened here was me grabbing a little bit more authority. I might have had it all the time, but I didn’t use it because it was easier to ask the leader. Now, the path of least resistance is making decisions myself.

    Multiply that by everyone in an organization, and suddenly, we have more distributed autonomy.

    The choice is between embracing and strengthening the change or resisting it. In the latter case, well, we tax ourselves on every single front, from productivity to employees’ mental health. Not really a choice, is it?

    Autonomy and AI

    The emergence of AI creates another shift in the nature of work. We get a relatively powerful co-pilot that can help us with many tasks that would be difficult or arduous in the past.

    Back then, we might have turned to the experts for help. Or drop the task altogether if it was non-essential.

    The experts would give us a suggestion, and we’d accept it as the decision. If we abandoned the task, there would be no decision to make whatsoever.

    But now, with our AI co-pilot, we have new capabilities at our fingertips. Yet it wouldn’t make any decision for us. Again, the path of least resistance is to grab some of that power, make a call, and move on.

    As an example, it’s often a challenge to dig up a relevant source to link in my writing. I often remember a research paper or article covering a useful reference. But its topic or author’s name? Beats me.

    Googling it was always a struggle, so I either turned to a human expert friend or gave up.

    But now? LLMs are pretty decent in digging up relevant options. Still, the work of reviewing suggested sources and choosing a valuable one is on me. I now face a decision that I earlier deferred to an expert or dodged entirely.

    More autonomy again.

    Adhocracy

    The changes coming from different directions align with a broader evolution of the nature of work. Julian Birkinshaw, in his book Fast/Forward, provides a neat big picture.

    Over the past century or so, the world has evolved from the industrial, through the information, to the post-information era. Each step changes the rules of the game.

    A hundred years ago, scaling was the biggest challenge, and the effective use of resources was advantageous. Thus, bureaucracy was a winning strategy.

    In the second half of the 20th century, we saw the increasing value of information, and its accessibility and effective use gave us an edge. Thus, meritocracy was gaining ground.

    Now, information is ubiquitous. In fact, with the help of LLMs, we can easily generate as much of it as we want. The world becomes less about who knows what. It’s about who can act upon (incomplete) data in a fast and effective manner. Thus, ad-hoc action gives an advantage.

    Coexistence of bureaucracy, meritocracy, and adhocracy over time.

    Birkinshaw coins the term adhocracy to describe this new mode of operation.

    A side note: one important part of the model is that all three modes of operation coexist. However, an organization will defer to the default mode whenever it faces uncertainty. We can’t expect a bureaucratic, hierarchical behemoth to act in an adhocratic way routinely.

    The coexistence of all modes will naturally create tension. The decision can’t be made at the same time made by:

    • a manager with the most positional power
    • an expert with the best data and most expertise
    • a line professional involved in the task hands-on

    If we want to embrace adhocracy, which Birkinshaw argues is a prerequisite for organizational survival, we necessarily must move authority down the hierarchy.

    We need to distribute more autonomy. Again.

    Common Part

    It’s not a surprise. When you go through the stories of companies successfully embracing non-orthodox management models, autonomy would be one shared part of all.

    Be it a turnaround story in David Marquet’s, unsurprisingly titled, Turn the Ship Around, or Michael Abrashoff’s It’s Your Ship, pushing autonomy down the hierarchy was crucial.

    And the fact that the military context would pop up so frequently in this discussion shouldn’t be a surprise. Decentralizing control was a pivotal part of the revolution of the 19th-century Prussian army. Its victory streak forced other armies to follow suit.

    Yes, the corporate world, despite all its inspirations from the military lingo, takes its sweet time to adopt the truly important inventions. And yes, our views of the military tend to be rooted more in Hollywood movies than in the actual realities of these gargantuan organizations.

    I often mention that we’d see more distributed autonomy in late 19th-century armies of the West than in many 21st-century corporations.

    We’ll arrive at the same conclusion if we stick to management theory. Take Holacracy, Sociocracy, Teal, or whatever generates the most buzz these days. The cornerstone of each of those will be autonomy. It may go into how we design roles (Holacracy), get to the principle list (self-government in Teal), or define the decision-making process (consent in Sociocracy). But it’s always there.

    When you think of it, it’s only natural. For hundreds of thousands of years, homo sapiens lived in small tribes of hunter-gatherers that were egalitarian and had very little to no hierarchy.

    Even when our species started evolving into bigger societies, adopting a strong hierarchy wasn’t given and was only one of the possible ways of coordination.

    I’d speculate that we are genetically predisposed to autonomy.

    Reinventing Autonomy

    Wherever we look, we seem to be reinventing the role of distributed autonomy. It’s critical to succeed on a battlefield. Staying relevant in business increasingly requires its presence. It sneaks along with the changes in the nature of work. We know it’s a prerequisite for engagement and motivation.

    Nothing should be easier than embracing the change and giving people more power.

    Sadly, it’s not the case. Power is a privilege. And as with every privilege, those in power will not give up easily. The good old bureaucracy will fight back.

    More importantly still, even if we have the means to overcome the resistance, the challenge is not as easy as “Let’s just give people more autonomy.”

    We need to take care of other things before we embark on this journey. But that’s the topic for another post.

    This is the first part of a short series of essays on autonomy and alignment. The following part(s) will be published on the blog and linked here during the next weeks.