The Introvert and the Startup

feetPerhaps nowhere is the phrase “one size fits all”  more misplaced than when talking about work environments and company culture. This is particularly true if, like me, you just happen to be something of an introvert.

At startups with aggressive growth and targets to hit, we try to foster a culture in which people have the opportunity to contribute their strengths and abilities, whilst creating an environment in which they want to spend a significant amount of their time. We also want to have some fun to offset all the hard work.

The creative options and flexibility for doing this at small startups simply can’t be matched in the wider corporate world, so it is no wonder that startups tend to have some of the most enviable work environments and cultures.

But getting it right involves a complex interplay of factors when catering for a diverse workforce, and talented people bring their whole personality to work. Tweak one environmental or cultural aspect to suit certain people or to get results, and you often find you’ve ruined another aspect for someone else. Worst of all, you may even hamper their ability to contribute.

There is perhaps no group that this applies to more than introverts, as many startup environments can be somewhat charged up and geared towards the high-energy needs of extroverts.

introvert, noun /ˈɪntrəvəːt/

A person who is more energised and stimulated by spending time alone or in low-key situations, than with others, and who finds certain group interactions exhausting.

To my amusement, I find it easier to tell people that I’m gay than to admit being an introvert. The former rarely causes a ripple. But the latter is often the start of a grand inquisition: “What’s an introvert?” “Why do you say that?” “You don’t seem like one” “We don’t need introverts here” “You just need to come out of your shell and let your hair down”… All precisely the kinds of confrontation an introvert wants to avoid at any cost. It’s no wonder we usually try to fly under the radar.

It is said that people are hard-wired somewhere on the introversion / extroversion spectrum, or we learn it very early on in life and it can be incredibly hard to unlearn. This has certainly been my experience. But what we are rarely told are the upsides to being introverted, particularly in environments you might think it would be a weakness, such as at startups. Indeed, a mix of introverts and extroverts may be the ideal team configuration… but only if handled thoughtfully.

So what are some of the unexpected strengths of introverts?

  • Leading – Many famously great leaders report being introverts; Bill Gates and Abraham Lincoln among them. Perhaps introverts make good leaders because it didn’t come naturally to us, we had to learn it and tend to have a more considered leadership style that we adapt to the needs of those we are working with. We also have less of a tendency to micro manage, choosing instead to let people exercise their abilities and prove themselves to us.
  • Presenting, Explaining – Strangely, I have no difficulty standing up in front of 200 people to give a presentation or to explain a technology. But after presenting, being part of the audience as a crowd can suddenly seem daunting to me. This is perhaps the opposite of what you’d expect.
  • Listening, Insights – Introverts tend to develop good listening skills. We have a tendency to step back from crowds, or to remain at the edges. We also spend more time processing what has been said to us, less time interrupting and, because we naturally need breaks from engaging, we are more likely to spot connections and insights.

But what do introverts find harder, and what might we need adjusting in work environments and culture so we can thrive?

  • Discussion, not Confrontation – Discussions that turn into confrontations, or environments that verge on being boisterous, can be tough for introverts. We tend to retire rather than engage, feeling shut down rather than fired up. The precise opposite of how extroverts react. When discussions stick to facts, rationales and explanations rather than the raising of voices, introverts can actively and even energetically engage and, as mentioned above, may have an entirely different set of valuable insights to offer. Conversations can still be very animated and productive.
  • Space to Recharge – We tend to need time in which we are likely not to need to engage with others, so we can digest, consider and recharge. We also need the physical space to do that in. If an environment is socially charged non-stop, introverts can rapidly be worn down, drained and become detached.
    Good environments allow a mix of engagement and focus, with meetings and work spaces kept separate where possible. Some would say this limit on engagement is a downside, preferring constant communication instead, but I’d say it naturally timeboxes interaction and forces more considered work to be scheduled. No-one, not even extroverts, can stay engaged, communicative and effective the whole time. Open-plan spaces can be a drain on everyone, not just introverts.

So perhaps the strengths we’re recruiting for in fast-paced startup environments might occasionally come aligned with a personality trait we’ve usually considered to be a weakness: introversion.

Introverts comprise up to one-third of the total workforce, so getting things right for a mix of personality types could be a significant win for startups looking to build great teams and great places to work. And if startups can get this right, the wider corporate world might follow.

“Someone” Doesn’t Work Here Any More


“Someone should fix the…”

“Someone will need to…”

I hear it all the time. I even say it. There is always so much for “someone” to do.

But “someone” is a problem: A cause of forgotten issues, broken links, missing pieces, out-of-date documents, poor integrations. “Someone” clearly isn’t working.

“Someone”, when uttered, tends to mean “not me”. A way of shrugging off the item, of distancing oneself from it.

We need to ban “someone”, and instead…

Find “someone”… or a team. Or nominate one. We should make sure they will take on the issue, or put it on their list, without dumping it on them. We should check they will own it. We should look on it like a baton handover in a relay race, rather than the throwing of a grenade from a-far.

Make “someone”… if there is no-one specific. We should make a placeholder list for issues and items in the same category. We should make sure a person or team picks them up at the right time, or keep a prominent record of those lists for review. We should make sure they are easily found and not lost. This is often necessary before hiring the first person in a department, such as marketing. A placeholder list might be needed for that team, until they exist.

Become “someone”… The ultimate, is to become the “someone”, for issues we could tackle or own, or just be willing to hold until a more appropriate “someone” can be found. Sometimes this means becoming “someone” in conjunction with another person, because these are often the difficult items that require collaboration and pushing forward to completion, particularly if they fall between the remit of several teams.

In rapidly-growing startups, particularly, we all collectively need to step into the gaps between teams, the places that aren’t owned by anyone or any process yet, and fill them. There can be a lot of “someones” in startups, if we aren’t careful.

The truth is, unless we are all “someone” from time to time, then the task will default to our other favourite friend, who is always more than willing to take it: “No-one”!

Why Software Engineering Isn’t Engineering, and the Implication for Deadlines

questionmarkSoftware engineering estimates and plans often fail to live up to the reality that follows. It seems to be the only engineering discipline in which this is the rule rather than the exception.

Before you leap to the defence of software projects you’ve worked on — perhaps even your own — think about how many times those projects delivered precisely what they said they would, and in the timeframe they originally promised. If yours did, you’re probably in a happy minority, or you’ve already embraced some of the realities I’m highlighting below.

“Engineering”… Really??!

Other than for extremely formal cleanroom and safety-critical systems, the flavour of software development undertaken in most companies isn’t really an engineering discipline at all, despite our ambitions to call it that. But the real problem is that we still predominantly estimate work and plan our activities as if it was, either within the software team or in our interactions with the wider company and its goals.

We architect and break down systems into subsystems, components and tasks, then estimate the resources required for each task. At the end of it all, we are usually surprised when our estimates don’t reflect the reality of what comes next. It is clear that the wider business is often similarly surprised and, therefore, no wonder that software estimates are often viewed with skepticism and disbelief.

Roads, Bridges, Bricks & Mortar

In physical engineering (such as civil or mechanical), estimates are based upon abstractions that are known to be quite accurate and dependable; component parts integrate and combine in ways that are by now well-understood. Each level is based on a foundation that is, at the lowest levels, ultimately based on well-researched principles: physics, chemistry, metals, concrete, glass, water, soil, gravity, etc.

Even the introduction of new modern materials is relatively risk-free as they can be tested, studied and understood in isolation or smaller builds, then integrated into larger builds with fairly predictable results.

That’s not to say that physical engineering doesn’t have it’s delays, complexities and flaws… but at least there’s the possibility of attempting to plan, reason and engineer them out.

Building on a Foundation of Complexity

Teams building software seem to ascribe the same physical characteristics to it as if it were more formal engineering. Whilst it is certainly true that there may still be physical laws governing the electronics and other hardware the software ultimately runs on, most software is built at a level of abstraction several hundred layers above that, and therefore on a foundation of potential complexity we may not understand quite so well.

Even where component parts of our system are well-understood (operating systems, languages, libraries), they can interact with one another, and with the foundations they in turn depend upon, in ways that components rarely would in a physical build.

Add to this the fact that most of our abstractions are about systems the precise likes of which we may have never personally built before, and it becomes clear that we are, at best, working with assumptions.

It seems we often mistake our ability to envisage a final system for the reality of the way that system will actually need to function, and the work involved in building it.

Complexity Appears Late

Problems and complexity appear notoriously late in software projects. Attempts to get an early understanding — such as proofs of concept, or use of spikes in the Agile world — can help, but they often don’t uncover the reality of the actual system we’re building… just one similar to (and therefore potentially totally unlike) it.

The result is that reality rarely adheres to our estimates and plans.

So What?

It is probably high time that we admitted most software engineering isn’t actually engineering, in the strictest sense of the term. The implication is that our estimates and plans — and our ability to hit deadlines — shouldn’t be relied upon in the same way. Embracing this truth, company-wide, might help us.

Secondly, I’d say that Agile, yet again, has something to contribute: We already know that it helps to nail requirements by working in an iterative and evolutionary manner alongside a customer, but it also assists in handling complexity and planning, by removing strict estimates and by working iteratively.

Most Agile “stories” are planned in points, t-shirt sizes, and other schemes, in an attempt to get away from time-based estimates and instead plan based on the perceived complexity and past ability of the team to deliver similar stories. Agile’s iterative approach means we can adjust course as complexity and other problems appear, just as we adjust course by regularly showing early versions of a system to a customer.

One implication of accepting this is that software projects will be notoriously hard to plan against calendar deadlines. This means the wider company will need to work with software teams in a way that depends less upon deadlines, estimates and plans. Many organisations embrace Agile in their software teams, but not in the wider company. This creates the untenable combination of Agile software work practices, but rigid / calendar deadlines and deliveries to the wider business… and the largely unacknowledged fact that these two worlds seldom align.

Maybe it’s time we embraced the reality of this less-than-formal “engineering” activity of ours, owned up similarly to the reality of our less-than-dependable “estimates”, and relied more on ways to work with these truths, such as Agile? This may finally mean embracing Agile in a truly company-wide manner, rather than just within software teams.

Hitting Software Deadlines: Essentials Only… then Upgrade

From “Deadline” can seem like a dirty word, in the software world. But without them, our work wouldn’t see the light of day, get an audience or have an impact. So despite their perceived unpleasantness, I’m all for them.

We tend to plan work towards a deadline in ways that ignore two inherent truths about software development, and therefore often miss them:

  • Complexity appears late: Despite our best efforts to surface it during planning and design activities. This is the reason plans go awry at the eleventh hour and deadlines that seemed achievable are inexplicably missed;
  • Completeness is hard to nail: Specifically, deadline-completeness. This means only the things that are strictly necessary for a viable release, launch or demo at the deadline. This is likely smaller than the list you feel you want to include, but adds crucial items that are usually not visible to a client, such as productionising, releasing, legal formalities, etc. Many of these are usually slotted in just-in-time before a deadline, or missed. Denial of the need to nail completeness, or discovery of further complexity here, can undermine a deadline.

Maybe we could try something along the following lines, to hit deadlines more often:

  • Find the Essentials for Deadline-Completeness: Begin by ruthlessly separating the work that must be completed for the deadline, but perhaps in a heavily-downgraded form.
    This might mean something releasable to a production environment (in a walled-off manner, minus a final trivial “reveal” on the deadline date), something that discharges legalities, and something that exercises the agreed use cases in a minimal but viable manner.
    Encourage people to write separate stories for bare bones deadline completeness, and then the rest.
    Also write meta stories for items required for completeness that would otherwise be forgotten due to not being visible to a client, such as deployments and productionising;
  • Hit deadline-completeness early: Complete the bare bones deadline-sensitive work as early as possible, and nothing else. In an Agile approach, this should be at least a sprint or two before the deadline itself. You will end up with a very minimal but released (though perhaps walled-off) system that would hit your deadline, but would perhaps disappoint you in a number of ways. Learn to accept this, because you won’t be revealing this version of your work and something much more crucial just happened that is worth celebrating: You already hit the deadline. You are already capable of delivering. So now, you can…
  • Upgrade, iteratively: Add in the work to upgrade that initial complete solution in tight iterations. Each of these should result in a system that is “better” in some way but still deadline-complete; remains releasable, still discharges legal obligations, still exercises the same use cases and perhaps some new and less crucial ones.
    Iterate on these upgrades, in a order of decreasing priority, until the deadline.

When the deadline comes, as it inevitably will, you are guaranteed to hit it in some viable and complete manner. There will always be upgrades you wish you could have included but they will be the least important ones and, much more crucially, you aren’t left with an incomplete solution that can’t released, demonstrated or used.

Approaching deadlines in this way means that complexity can be handled as it arises, without derailing the deadline. Hitting deadline-completeness in a minimal way, then upgrading, allows complexity to push out less-crucial upgrades if necessary. Yes, you don’t want it to… but the reality is it might need to. Post-completeness, there is room for the battle between complexity and upgrades to take place, however that plays out and without risking the deadline.

How do you persuade people to adopt this approach? By showing them that everything is still planned to be included, but that deadline completeness is prized first. Assure them that other upgrades, in decreasing priority order, will only be omitted if unforeseen complexities or problems arise. The maximum value possible is still going to be delivered. Nothing has changed but the approach to delivery and risk.

Isn’t this just Agile? If your approach to Agile (and there are many) includes a notion of deadline completeness, perhaps. But who really does Agile that way? After hitting the deadline early, the iterations are Agile-like. But this approach forces early inclusion of aspects that might be unseen to a customer in an Agile world — hence no stories — but which are crucial for the deadline, such as productionising.

Find the essentials and complete them early, then upgrade. By planning in a way that handles complexity like this, maybe we can let it do its worst — as it inevitably will — and still deliver to a deadline?

Software Teams: One Vital Missing Question?

questionmarkBuilding software as a team may appear to be mainly about writing and releasing code. But it is underpinned by something much more fundamental: An ability to define and share information and complexity within the team.

It’s about making sure the ways in which we each model that complexity in our head match those of other team members. Unfortunately this doesn’t just happen magically, despite our best hopes and intentions.

If we aren’t all in possession of the relevant information and a similar view of the complexity we’re faced with, we’re forever building products that no-one wants (disconnected requirements and use cases), wasting time repeating development effort (wrong design / architecture / decisions), or building things that just don’t work (badly integrated, installed or deployed).

I’ve found that encouraging everyone to ask themselves one deceptively simple question, regularly and about almost everything they do, may provide the missing perspective that’s vital in keeping everyone on the same page: “Who else might need to know this?”  Yes, rather simplistic and, of-course, you have to act on the answer, but I think just remembering to ask that question about everything is the key change required.

What kinds of complexity and information are we needing to share as a team? For even the simplest of software projects:

  • Domain knowledge – Every business / sector has its own concepts. People arrive in the team with different backgrounds and therefore with a different need to familiarise with that domain knowledge. Without this, a fair portion of the thousands of little domain decisions an engineer needs to make each day will be inappropriate or wrong;
  • Terminology – For the domain and product, we’d better all be using the same words, right?! I’ve seen projects, where key terminology wasn’t nailed down early, go horribly wrong;
  • Research & Decisions – What we looked into (tech, architecture, anything), the decisions we made based upon our findings and the things we’ve learned. Recording these prevents us from revisiting prior decisions or mistakes unnecessarily, but also allows us to choose to revisit them, pick them apart and change our minds;
  • Architecture & Design – What we think we’re building, and how we’re breaking that down into components, infrastructure, etc;
  • Plans & Tasks – How we’ll build it, the individual chunks of work, sprint-by-sprint planning, agile boards… plus bugs as they arise;
  • Milestones – Points by which we’ll measure our progress. These should be in terms of usable chunks of the deliverable product itself, not just “sprint 1”, “sprint 2”;
  • Progress – Where we actually are versus the plan, and what else has happened on the way (because the plan always changes);
  • Product specifics – Usage, configuration, installation, etc. These arise throughout the project, and need capturing somewhere so the product is installable, releasable, usable, etc;
  • Product – The actual deliverable; probably many different versions of it and details of what went into each of them.

When it comes to sharing this complexity and information, most teams work on the basis that people will always ask what they need to know, at the time they discover the need. This is on-demand sharing. In an increasingly agile world, perhaps it feels like the right approach.

I’d assert that anyone missing a piece of information will often (though not always) ask what they know they need to know, but that may be incomplete. Even if they do in-fact ask, it will probably be for a very restricted fragment of information they know they are missing. What they will be without is context, background, and the top-down structure that would make the fragments more easily digestible by them. Context would also allow them to retain the information and to see the links — the bigger picture — rather than building their own mental picture iteratively from scratch, bottom-up, and perhaps by trial and error.

I’d say we should sharing all of this information much more keenly, and certainly before we think someone else may need it.

But isn’t keen sharing wasteful? Certainly not as wasteful as all those missed connections, delayed understanding, repeated work and the constant need to chase clarity. I’m not advocating writing lengthy documents, just capturing information, making it discoverable and keeping it up-to-date. Once captured, it can always be further structured at a later date.

For some of the information we need to share, there are already great tools out there, particularly task management and agile planning. But what are the best ways to share other information and complexity, and what are the pitfalls?

  • Online docs / wiki (lowest impact, longest-term retention, most transferable) – This is by far the best way to share to allow people to seek out information long-term and efficiently, but it comes with a health warning and an obligation: Wiki contents should be regularly reorganised for easiest navigation and digestion. They should also be updated, or marked as obsolete or, better still, archived when no-longer relevant. If a new hire needs the wiki explaining to them, it isn’t a wiki, it’s a dumping ground! The general rule is to encourage people to leave the wiki in a better state than when they found it. Besides the code base itself, the wiki represents shared team knowledge in its most accessible form;
  • Email – Whenever you email something, the need for which may go beyond a few days or a week, ask yourself the question “How will someone who isn’t on the receiving end of that email get the info?”. To retain the email benefit of highlighting the info to people right now, you may wish to email a link to a Wiki page instead, and this avoids the next new hire being unable to find it. Never email anything that doesn’t need drawing to the team’s attention now. If it simply needs to be available somewhere (a logical “somewhere”, preferably), put it on the wiki. Email inboxes are not a good repository for information;
  • Verbally / Whiteboard (highest impact, shortest-term retention, not transferable) – For the highest impact, nothing beats verbal communication; a stand-up, huddle round someone’s desk or a whiteboard, a meeting or presentation. Much of what was said may be lost beyond the occasion itself though, and it certainly isn’t available to anyone who wasn’t in the room (unless you recorded and uploaded it). Anything shared verbally or on a whiteboard should also be available on the wiki, either as a presentation / image, or by being absorbed into existing content after the meeting. Even just chronologically capturing whiteboard contents can help, and the structure can be rearranged later. Ask yourself if you’ve had to explain the same concept more than a few times. If so, it probably deserves to be documented somewhere.

Building software is about managing and sharing complexity. It may sound rather remedial, but encouraging people to regularly ask themselves “Who else might need to know this?” can affect a powerful change in the way a team works together and shares information. The answer usually prompts keen sharing and, if we also encourage the most appropriate methods and levels of sharing, it means that others will have access to the information when they need it, more often than not. Far from being cumbersome or time-consuming, keen sharing greases the wheels that lead to good teamwork… and perhaps even to better software.