organisational issues

Don’t Try to Innovate on Your Entire Business Model in The Existing Organisation

June 7, 2020 by Greger Wedel

Much is written about how to innovate in tech. Still, it boils down to the simple ability of individuals to focus on and prioritise the right things on a day to day basis, and that other people in other functions prioritise not only the same right things but also at the SAME TIME! This is where most organisations fail.

In Are You Lost in All the Priorities, I wrote about a methodology (slicing, pacing, and themed releases) to execute quickly on a set of super-high priorities across the organisation. I focused on how a young and immature organisation does not have prioritisation and execution processes in place to execute many large priorities in parallel. This is typical for startups as they are growing. However, the reverse question is this: Given the organisation’s current processes and people, what type of priorities can the organisation successfully execute on without getting hindered by the processes they have set up? This question is relevant for both young and mature (and large) organisations.

A company is typically set up around a defined customer group with a corresponding go-to-market strategy, channels, partners, sales (and marketing) and with employees who fit with this strategy. The product management and engineering organisation builds products that fit this market, these end-users, and this go-to-market. The company’s business model (how money is made) is accompanied with an operating model (how the company is set up to create value), and both people and processes are established around this. For startups and scaleups, both the business model and/or the operating model(and maybe also the market) are still being discovered, and the product strategy is still being formed. For a mature organisation, these things have been settled, and people take a set of truths for granted: “this is how we do things.”

For a young company, this is what creates the ability to scale up, but it is also exactly what prevents the organisation from doing new things. This is especially painful in a scaleup organisation as structures and “how we do things” are starting to get shaped and accepted, but the organisation is still not mature enough to have established ways of doing new things.

There is a value chain that goes from each individual developer and UI designer and all the way through the organisation and out to the partners and the customers. For example, there is consistency in what product marketing is messaging and what is added as features to the product. The organisation “knows” the criteria and how to evaluate priorities. This is what immature organisations don’t have, and in mature organisations, this is what makes it hard to go outside the established boundaries and bring to market a product to a new customer group, through a new channel, or using a new and disruptive technology:

You need to change the known “truths” across all functions in your organisation and in a coordinated way.

Any innovation or product development effort that is outside the known will require discovery and trial and error. If you try to do this in your existing organisational structures, the known “truths” will create resistance. Trying to both discover what is the right thing to do and implement that across all the various groups in your organisation at the same time will feel similar to trying to push a long piece of string across the table. You need to go back and forth and push a little bit on each spot over and over again, and it takes forever.

When a company grows and prepares for scale, people and groups will specialise and bring with them a piece of the “truth” about what the company does and how things should get done. This has been settled in larger organisations, while scaleups bring in new people and the “truths” are not yet agreed upon. Everything that fits with existing “truths” will be easy to execute on. Everything that is outside gives you that feeling of pushing a piece of string.

This is why I argue for doing a “slice” across the organisation when you need to substantially change or adapt your business model and/or operating model. You want to empower a small group of people to make quick decisions in a coordinated way across all the relevant functions in your organisation. You want all of them to have the same set of priorities at the same time and in the same order. This is NOT each function agreeing to a set of priorities and executing on those integrated with all the other activities. This is a tight-knit group of people who are tied into their functional areas, but who have joint objectives and deliverables as a cross-functional team. This slicing can be done in many different ways. The approach described in Are You Lost In All The High Priorities is just one.

You want to make sure that the learnings can be brought back to the main organisation, and this is one of the key reasons why many organisations resist organising a slice! The argument goes that this change is so key to the organisation that it needs to be done through existing roles, functions, and teams. This idea is a fallacy! Even when the desired end state is known, organisational change takes time and is risky. Not knowing where you are going and bringing the entire organisation with you is doomed to take too long time and have a too high risk.

Yes, there are organisations that have successfully implemented highly flexible and agile organisations that are capable of rapidly reacting to changes conditions and requirements. If your organisation is like that, congratulations! You have the capability of light-weight exploration of new opportunities built into the organisational culture and processes. The “slicing” will happen integrated in what you do.

For most organisations though, even tech organisations, you need on an ad-hoc basis create the slices through the organisation that you need to explore new opportunities . Over time, doing “slicing” should become an integrated organisational capability, but you don’t start there.

Are You Lost In All The High Priorities?

April 4, 2020 by Greger Wedel

As software product organisations grow, they can become the victims of their own sales success. Many high-priority customers and features put pressure on the engineering organisation to deliver, but even when using all the traditional ways to prioritise and optimise execution, you feel progress is slow and the overall “delightfulness” of your product is not what it should be.

The root cause is simple: as you grow in people and priorities, you have lost that focus you had naturally when the company was a small startup, but the commonly understood criteria for prioritisation and the execution capabilities of a more mature product organisation are not yet firmly established. The solution though, is not simple: on the top level, you know what the key priorities are, but then as you break down and distribute responsibilities, each part of the company seems to have a reasonable amount of work, and your organisation MUST now be big enough to execute on multiple things in parallel.

The Challenges

There are typically two key challenges in this situation. The first is that although the ownership of each priority is distributed, the delivery of the priority involves many parts of the organisation. This cross-team alignment typically involves the same people in each team and as they have been assigned different priorities, they will order their tasks differently. Still, everybody will try to satisfy other peoples’ needs, thus they will start up many tasks in parallel, and all priorities will slow down due to switching costs and that time is distributed across many tasks.

While the first can be seen in large, mature organisations as well, the second challenge is typically a startup/scale-up challenge: mature organisations have normally figured out their criteria for prioritising features and backlogs, how to groom the backlog efficiently, how to align dependencies across teams, basically, how to get things done through distributed mechanisms that don’t need escalations to management. In a less mature organisation, all these things are still being shaped. So, the organisation is typically less capable of executing many things in parallel.

You need to do something to ensure that the organisation increases total capacity through establishing the mechanisms that will work for you, your culture, your people, and your products. One approach that I have used successfully in both large and small organisation is what I call slicing, pacing, and themed releases. This is not a steady-state recommended scheme, but rather a mechanism to fast-track super-high priority product deliverables that are critical to your company. It can be used for a strategy pivot, building a new and different product type in a mature organisation, or to fast-track product-market fit in that critical phase where you know the high level, but need a fine-tuned product that really solves customer problems.

Slicing

The principle is pretty basic, but hard to execute on: define a very clear, very concrete priority that slices through all parts of your organisation; include at least one representative from sales, finance, sales engineering, support, UX/CX, product management, as well as from each of the engineering teams you need deliverables from. A related strategy is known as the “startup-in-a-startup” approach. However, if you isolate this new team as an internal startup, you get innovation, but you get no organisational learning in the wider organisation. This is where the first “slicing” happens: you create a slice through your organisation with hyper-focus on solving one and only one problem at the time, but you keep everybody in their respective organisations and with the mandate to shape the priorities of their home teams.

Make the on-boarding journey from signing-up to paying for our service into an interactive and delightful experience that drives conversion from today’s 1% to 5%.
Example of a charter for a slice

You should establish a “situation room” for the team, physically or virtually through a tool like Miro. This is where you have a visual representation of the concrete end-to-end problem to solve and where the team is responsible for continuously updating with plans and results as they go. It can be useful to have a concrete and representative customer used as a benchmark. The slice participants will each be responsible for working with their home teams to come up with ideas and solutions, and to bring back to the situation room the actual work done and show how it solves the defined end-to-end problem.

The end-to-end problem to solve should be finite, concrete, and need refining and iteration. The first task of the team should be to attack the assigned problem area and start breaking it down, and find out how they will attack the problem. Here, you will go different directions depending on how many engineering teams you need to rely on. If you are able to gather a group of full-time developers to work on the problem and you don’t have other dependencies, you can do agile sprints with at least bi-weekly demos to stakeholders (customer(s)!). If you have a more complex setup with multiple teams involved, you will need to introduce the second type of slicing and do pacing. This second type of slicing is done when you use the end-to-end problem and the situation room to agree to a set of common things to tackle across all the teams for the upcoming sprint. This way you make sure that the switching costs are low and that people work on the same things in the same order. If you have a back-end API team, this team should e.g. do a quick mock API to realise the proposed UX/UI, and then iterate together with the front-end team as they learn more about how to solve the problem.

Themed Release

If the problem you are solving is isolated from the rest of the products in your organisation, or it’s your entire product, you can quickly release functionality the way you are used to (and through devops and CI/CD for Software-as-a-Service products). However, if your slice is a part of a bigger product or platform where also other functionality will be released in parallel, you may be able to better scale the impact in your organisation and customer base through doing a themed release. Your slice is then equal to the release theme (to frame for other stakeholders what all this new functionality is solving), and you should release at regular intervals, not too often (as nobody will really pay attention), and not too far apart (to get the feeling of accomplishment and push towards a milestone in the team). 4-6 weeks can be a good choice as you can have 1-2 stakeholder demos and iterations to deliver something that has clear customer value.

Pacing

Finally to pacing: the more teams involved, and the more people involved, the more you will get drift in the project. Product engineers have a tendency to want to solve problems generically, so that it can be used by all customers. This is a good thing, but it introduces the risk that one team can spend a whole week on delivering something another team needs, when they could have done something simpler on Monday, unblock the other team, and then continue on making the feature more robust and generic the rest of the week. These opportunities for increased overall velocity can only be discovered across the teams. One way of doing pacing is to have pacing meetings that have a similar format to standups, but where the sole focus is to identify drift and focus on quick tasks that can unblock other teams.

If you haven’t done slicing, pacing, and themed releases before, you should probably start with only one. You will have most of your engineering resources already allocated to other priorities, so the “allocatable time” of your teams is probably far less than you want to think. Once the organisation understands how to execute on slicing and a themed release, you can evaluate running 2-3 such themed releases in parallel. Typically, over time the themed releases should be less and less an extraordinary effort, and more an approach to aligning product management, priorities, and engineering execution.

The Three Deadly Sins of Scale-Ups

February 22, 2020 by Greger Wedel

So, you managed to pull it through. You found your product-market fit (or at least partially), got customers to pay, and secured your funding to expand. Your tight-knit team where everybody knows what everybody is doing will now double and triple in size as you add more people to the team to support your growth. Congratulations! Make sure you take time to celebrate because you are about to embark on a new and equally challenging journey!

The people you hired for the first phase were most likely generalists who thrive when things are unclear and problems just need to be solved without any process or long decision processes. You now need to decide who to hire for the next phase. Do you hire more generalists? Smart people who are individualists who will figure it out or do you hire people from larger organisations who can help you put things into process and scale up? Chances are that you are already establishing an HR organisation, and you are about to distribute the control of who you hire to those you have just recently hired. Most likely, the new HR organisation will put together an interview process, hiring criteria, and individual managers will start making hiring decisions. You are supposed to hire quickly, and priority number one is to hire the best people, but not necessarily the ones you need. This is deadly sin number one: not having explicit and detailed criteria as well as hands-on control over who you hire in this phase. The people who you hire now will define your company in years to come.

Many years ago, during the dot-com boom, I worked in Silicon Valley and got exposed to the cynical view that:

“A-people hire A-people, and B-people hire C-people.”

Through the best of intentions, you are now hiring (hopefully) smart people who can help you reach the goals of scaling up your company. If not, you will get a lot of people who are good, but not star performers, and then they will hire people who are not that good. Be careful, who do you need and what do you want for your organisation? Smart or best are not good hiring criteria, what will they prioritise and how will they shape your organisation?

Anyway, some of these new hires will come from larger organisations (you need that). However, this is where you risk doing deadly sin #2. As you grow, people will loose touch with management decisions, who is doing what, how to get things done, and as growth is typically chaotic, you will get dependencies across different parts of the organisation that will slow things down or even prevent people from even attempting to do the right thing. The response is always the same (and especially from people who come from larger organisations): We need more knowledge sharing through presentations, newsletters, demos, documentation, presentations, wiki pages, you name it. AND, we need processes that can help us get things done: A program management meeting, let’s hire project managers, we need more coordination meetings, who can make sure we sync up across teams, how do we make decisions, who can describe how we are supposed to do X?

You were used to having an organisation where everybody just made it happen, now, you have people who see it as theie job not to make it happen, but to coordinate, call meetings, write summaries and project plans, and structure your Jira projects. And who do they engage? Exactly the people who used to spend all their time making it happen, so now they have to spend time in meetings, report on progress, and update tickets. And they don’t think things are going in the right direction…

It is all done with the best of intentions and there IS a need to coordinate more, document things, and create some processes. And after all, this is what worked for organisation X (replace X with your favourite large tech company). The two main problems are that:

this is often overwhelming to people, and you risk them disengaging from many of the things that are not directly related to them and
you are introducing bureaucracy (i.e. a predictable process), but is it at the right place (helping you scale) or do you create barriers for getting the right things done? Also, your early generalists are bickering, this is not what they like. Where they earlier just fixed the problem, they now have to follow a process and they feel they waste their time. You risk loosing some of the star performers that enabled you to do the right things early on

So, deadly sin #2, overwhelm everybody with knowledge sharing that they don’t really know if they need and not controlling strictly where you introduce the right process, so in sum you frustrate people and slow down execution.

This is where you are about to enter the ranks of established companies, and your employees will be able to complain about how much red tape and meetings you have, and how difficult it is to just do the right thing because there are so many people who need to have an opinion. Now we are getting to the worst of the deadly sins, #3: introducing top-down processes of program management, managers, decision processes, gating criteria, and other mechanisms that are meant to get overview and control. It is in the nature of people to seek control, of course the organisation needs to be in control. The move towards the top-down control is reinforced by the people you hired. People who are very comfortable with establishing processes and deliverables to get in control.

But what is really the alternative?! Not putting in place ways to get decisions done, coordinate with others, and share knowledge will also slow down your organisation. We hear about empowerment of employees and establishing independent teams that can make decisions without consulting everybody else. But is that desirable? Can you avoid top-down control and still move forward as one company? So, should you avoid it? You want the ability to deliver on your corporate goals, you want to be able to estimate delivery dates, and you want to report on the progress, right?

De-coupling of dependencies between teams and individuals is the only scalable alternative to top-down control. It requires careful design of organisation, responsibility, and accountability.

This is really, really hard, but it is the only way you can get employee empowerment and the engineering and product velocity you want. If that is what you prioritise. The top-down control and planning may be something you prioritise, and you are willing to sacrifice velocity to get it. However, if speed is what you need, you need to organise small teams that are not dependent on top-down planning processes, where dependencies on other teams can be loosely coupled, and where the teams and the individuals are comfortable with making decisions and deliver on what they believe is the right things to deliver.

Teams will in reality never be independent, there will always be some other teams that will be impacted by decisions or that rely on what is delivered by others. Also, you want people to run in the same direction. This means that you need two things to get a de-coupled organisation:

a strong sense of strategy and purpose down to team level that guides decisions and
technical and organisational mechanisms that make it simple to understand how to interact with other teams (i.e. loosely coupled).

Designing a loosely coupled organisation is not trivial, especially when the urge to get that overview, that top-dow control, is so strong. However, if somebody pushes a change to a repository, the right documentation is updated, and the right people are notified, and they know how to change and update their own code, then you are onto something!

The key challenge is that the urge and the ways to implement top-down control are generic and well-known, while the path to de-coupled organisations is always specific to the organisation and requires careful and step-wise implementations that are tested and continuously improved. This is why the three deadly sins are so connected: the people you hire will determine whether you are able to scale through de-coupling or top-down mechanisms.

The Perfect Engineering Manager

October 2, 2019 by Greger Wedel

In my last post I introduced a practical approach to engineering leadership and the skills required in any engineering organisation.

The post must have struck a nerve as it got a lot of reads, especially on Medium in The Startup magazine where I cross-post some of my blog posts.

However, I’m sure people have many new questions on the practical side of how this works in practice. The key insight I tried to convey was that all engineering organisations are built around four distinctly different skill sets and that you need engineers who jointly cover all the skills, no matter how you distribute the responsibilities: code development skills (the developer), task priority and tradeoff handling (the backlog owner), technical architect skills managing long-term vs short-term (the architect), as well as people and team skills to keep people happy, make them work on the right things, and make sure things get delivered (the manager).

The larger the organisation, the more roles tend to be specialised. As a result, the coordination cost goes up. You typically then get elaborate frameworks and formal development processes to ensure coordination. This is a drain on time and motivation for most software engineers. On the other hand, in successful and small startups, you typically see very flat organisations where everybody seems to do everything. How then can you successfully scale an engineering organisation and keep the energy and productivity? Amazon’s 2-pizza teams is a famous approach, but reality is that it all starts with the people you recruit, so you need to start early. If you hire a project or program manager who has been managing projects and processes, but without delivering own content into these projects, you will get more projects that are managed by process, not by purpose.

And “purpose” is a keyword. You want people who are driven by purpose, not process. And here we get to the Perfect Engineering Manager. If you have one Perfect Engineering Manager on each team, focus will be on purpose and you can reduce coordination to a minimum. So, who is this Perfect Engineering Manager? In fact, he or she probably does not exist, or there are very few of them out there. Luckily, the skills can be trained. Not surprisingly given the lead-in to this post, the Perfect Engineering Manager is a person who is a brilliant coder, loves enabling and helping out others to make them successful, takes natural responsibility for delivering high-quality code into production, knows the code base inside-out and will re-factor quickly while adding new abstractions and code that will help others deliver in the future. Mentoring more junior developers comes as a given, and the natural authority of the Perfect Engineering Manager makes it a breeze to drive prioritisation, sprint planning, daily stand-ups, or any other chosen development approach. Of course, the social skill set of the Perfect Engineering Manager means that other developers love working for her or him and necessary interactions with other teams are always pleasant and smooth!

The Perfect Engineering Manager is an ideal and getting closer should be an aspiration for well-rounded, senior engineers. Not in the sense that everybody should strive to become Perfect Engineering Managers, but that one or more skills can be chosen and improved as part of developing as an engineer and a human being.

Without at least one such person, or a team of people who together cover the Perfect Engineering Manager skills, you will not have a 2-pizza team, you will have a small group of developers that rely on others to get things done. Developing great software and great products is not rocket science, but it requires systematic and careful grooming, development, and attention. In too many organisations, software engineers are left on their own without much help or guidance on how to grow their career, job satisfaction, contributions, and as human beings. The Perfect Engineering Manager is of course instrumental in facilitating and making the right decisions to make sure that the engineers on his or her team are not in that unhappy group.

A Practical Approach to Engineering Leadership

August 17, 2019 by Greger Wedel

In my previous post on the new engineering leadership skills needed in a devops world, I called for a more systematic approach to developing leadership capabilities in engineering. But I gave no answers. In this post, I’ll share my practical approach to developing leadership capabilities in an engineering organisation.

When developing great software, there are some fundamental questions all engineers have:

What can I decide?
Who can make decisions on things I cannot decide?
Who do I need to talk to or involve when resolving an issue?
Who determines the targets for what we make, how we make it, and how we go about doing it?
What is expected of me and what kind of rewards do I get when I meet expectations?

In a small startup team, you don’t really need a lot of these things explicit. The goals, actions, and rewards are mostly shared across the team, and everybody contributes where they see a need. The entire team has the same priorities, the tradeoffs are decided upon continuously, and changing course is done quickly.

However, you cannot grow much as an organisation without introducing slightly different priorities in different teams or roles. You are starting to introduce the cost of coordination. For a while, you can align everybody around the same priorities through some kind of coordination process or meeting that gives you the “top 5 things to work on this week”. But to allow rapid growth you need to at some point allow different people or teams to focus on different priorities. I have seen numerous approaches to solving the resulting coordination problem, and most either introduce too much process or too little.

There is no single answer that works for everybody in every situation. However, if we go to the fundamentals of how to build great software, there are four different areas that always have to be covered in some way:

Build high quality code, designs, and other tangible stuff
Knowing what to make to solve the customer’s problem
Knowing how to technically solve the problems and deliver something that will work over time
Knowing how to go about making the tangible stuff like code and actually delivered what’s agreed upon

The skills that go into each of these four areas are very different. And the more people involved, the more coordination and collaboration is needed to make sure everybody is pulling in the same direction. Ideally, you want everybody to be 100% productive, but that is not possible as long as there is some kind of dependency between what people are supposed to do. How do you get the productivity percentage as high as possible?

Typically, each of these responsibilities translates into one of four roles (not individuals):

Developers build stuff
Backlog owners manage the priorities and the definitions of what is to be made
Technical architects determine how to technically solve problems
Engineering managers lead people, the process of development, assign the right person to the right task, and ensure velocity

These are roles, not individuals, so many engineers will wear multiple hats. Also, there is one missing part here: the service or product. Each organisation has to break down its services and products (and thus code bases) and group them in a sensible way. Once that is done, it should be possible to identify the developers, backlog owner, the manager, and the architect for each. An engineer can be a developer on one code base/service, an architect on another, as well as manage a deliverable.

This break down into modules and components is absolutely critical to the productivity of your engineering organisation and subject to Conway’s law.

Unless you match the identified ownerships and roles with your modules and components and get that right relative to your organisational structure, you are introducing inefficiencies in your software architecture and how people communicate. This is a continuous process and needs to be adapted to the changing needs with respect to both features and the underlying system architecture.

Going back to the questions at the top of this post (that most people have in a software development organisation), it should now be possible to answer the questions. You don’t have to go through a central manager or (..!) a committee or a process, you can reach out directly to the person in charge who can make a decision. E.g. if you are a backlog owner and you need more engineers to work on your backlog, you can talk to a manager. If you need an evaluation for how to implement a certain functionality, you talk to the architect. If several components need to communicate through an API, you know exactly whom to invite to discuss this.

You thus get an organisation that can resolve most day to day matters without central coordination.

Typically, you will have triplets of lead people for each of your main components: a manager, an architect, and a backlog owner. The development team can thus be productive by getting help from each of these three. Ideally, all three roles/people are co-located physically for highest productivity since high velocity requires quick and frequent touch points.

There are two other roles missing in this picture: if the team is a product team, you need a product manager role (who could also be the backlog owner, dependent on skill set). If your component or product has a UI, you should also have a UX lead who can work with the backlog owner and product manager to get clarity on the deliverables. See also an earlier post on the backlog and the product owner role.

This model is also good for training and career development. There are four areas where skills can be built dependent on individual interest. As engineers grow from juniors to become more senior, they will take on more roles and expand what they take ownership of. Some may want to take on manager roles and lead teams. Some may want to deep dive in a very narrow technical area and become lead architect.

Remember that any changes in an organisation will take time. You need to repeatedly clarify the expectations, the opportunities, show that real authority to make decisions come with these roles, and systematically encourage people to take ownership. And if people are uncertain, you need to exemplify what concrete tasks and actions are necessary and expected.

The reward is an empowered engineering organisation that can deliver great software with high velocity!