Leadership
12 min read
Building an Empowered Organization
Why we are launching the Innovation Blog
Welcome to our inaugural Innovation @Artera blog post!
First things first – you will see us refer to the “iO” a lot. The iO is Artera’s version of R&D: it includes our engineering, product management, and product design teams. When we formed the iO about a year ago, we felt we needed to label the team with something more inspiring than simply “R&D.” The iO was born.
We are excited to share our innovations with you as we work towards revolutionizing the healthcare industry. We are passionate about using cutting-edge technology to create solutions that improve the patient experience in our quest to make healthcare #1 in customer service.
There aren’t many technical blogs in the health technology space. Every vertical business space has unique challenges, and healthcare + health tech are not exempt from this! We aim to use this blog to share our thoughts, ideas, and experience with health tech and the broader tech community.
So buckle your seat belts. We can’t wait to hear your thoughts, feedback, and ideas for future topics. Thanks for reading!
An empowered organization
As part of our inaugural blog, we would like to share iO’s founding principles, which have been put into action, and it all begins with an “empowered organization.”
So what is an empowered iO organization? There are many facets to an empowered organization (which we’ll get to), but the different components can all be tied back to three fundamentals:
- Solve problems vs. build features
- Focus on outcomes, not on output
- Build teams that have skills across the three main functions that matter most in R&D: Engineering, Design, and Product Management
Many of these principles are not new. They have evolved as best practices as agile product development have become more widespread. We used our experience and took ample inspiration from Marty Cagan’s books. The best of both has helped us lay the foundation to build a fantastic R&D organization.
Let’s dissect these.
#1 Why is it better to think about product development in terms of solving problems versus simply building features?
The reason for this is that if a customer tells you they want something specific, you’ll go ahead and build that without really understanding the motivation behind why the customer asked for it in the first place – and then you might miss the mark!
We’ll stick with the familiar car example. The customer says: “I need a car.” You then build the car, it takes a long time, and when you deliver it, the customer’s wish might be met, but you may not actually be solving their problem! What if when the customer said they needed a car, you responded with, “help me understand why you need a car.” The customer might respond that they need a way to get to work quickly and cheaply. Peeling the onion back, you might understand that “quickly and cheaply” means they can’t waste time looking for parking and then paying for it. With that information, the way you’re solving their problem changes drastically, and instead you might offer a skateboard or bike instead.
Being able to truly understand your customers’ pain instead of just having them tell you what to build will allow you to better meet their need. You might still build a car, but you’ll have the certainty that the car will solve their problem.
#2 What’s the difference between outcomes and output in product development?
Think of outcomes as long term business results and outputs as features shipped. You may get a lot of satisfaction from shipping lots of features. However, if those features don’t meet customers’ needs, it won’t matter how many or how fast you have shipped them. Instead, focus on what these features are doing for your customers, what value they are driving – how these outcomes are helping your customers build a solid business, which will translate into your business being solid as well. By the way, you can focus on outcomes and still have great output! But that comes as a side effect of being outcomes-driven, not the other way around.
Finally, let’s look at team makeup.
#3 An empowered team is able to understand customers’ problems and build solutions.
To do that, when you’re building software, you need to be able to rely on expertise – engineering to build, product to help translate the problem into buildable chunks, and design to consider the customer’s experience. Rarely do you see these skills available in one person – and you should not expect to! An empowered team brings complementary skill sets together to solve the puzzle. If any of these three skills or perspectives are missing, the end product will not feel finished.
Now, these fundamentals might seem simple – and they are! But putting them into practice requires rigor and intentionality.
Philosophy in action
Now let’s look at foundational pieces that enable empowered organizations. We will keep the discussion at a high level, and then we will follow up with a detailed blog on each of the areas discussed below.
The first step is to set up an organization that can embrace empowerment. There are multiple philosophies on how to form teams, and there are no wrongs or rights. Every approach has pros and cons; the tact is to be aware of the cons or risks, and proactively plan for mitigation.
Our approach has three key pieces:
- Complete teams → Teams have every skill in them to take on a feature end to end.
- Small teams → Smaller teams move faster.
- Triad model → Balanced responsibilities between product, design, and engineering.
Product (incl. design) and engineering organizations are two sides of the coin. In our experience, a schism between these two organizations creates a catastrophic result not just for the R&D organization but the company as a whole company. So it is extremely important to create a structure where both organizations operate as one.
Triads: a balanced partnership
So to offset any schisms, we implemented a triad model.
Triads are a balanced partnership between Product + Design + Engineering at all levels in R&D.
Triad comprises three (duh!) members, one each from product management, design, and engineering leadership. The triad model is implemented at each level, not just at the agile team level.
As we write this blog, the Artera iO is made up of nearly 130 members.
A few key areas are worth highlighting:
- By design, the organization is relatively flat. The empowered organization is 80% bottom-up and 20% top-down.
- The triad model exists at every level, including the executive (heads of department), who also operate in the triad model.
- Multiple agile teams are grouped under a group triad, and multiple groups consolidate under the iO triad.
- Each member of the triad reports into their org. For example, the Senior PM reports → Director of PM reports → head of PM.
- Less than 5% of iO members should be outside the triad and team structure.
- Some teams might not have user design or product manager needs (API teams, DevOps). In these cases, they will have one or two members in their triad, which is okay. We take creative freedom and still call it a triad for consistency.
It is also imperative to document the roles and responsibilities of each triad level. They have a set of shared responsibilities and operate as a unit. Then there are function-specific responsibilities that fall onto individual functions. This step is important to clarify expectations within the triad and outside (iO and the company).
Teams
As you can see from the diagram above, our ideal team consists of 9 members –
- Triad (Product Manager, Designer, and Engineering Manager)
- 5 x Engineers
- 2 x Software Engineers
- 3 x Senior(+) Software Engineers
- 1 x Automation Test Engineer
Process
We ask each team to define and document their process as part of team empowerment. The only guiding principles at the organizational level are:
- Iterative/Agile process
- 2-week iterations and the teams start their iterations in the same week
A reference process is defined for the teams that want to use it, but the process is not mandated. Teams can use scrum, scrumban, lean, or define their custom process. This whole topic will be the subject of another blog, so keep an eye out for that.
Empowering teams visa vis defined ownership or Defined team ownership (a key ingredient of empowered teams)
The last but most critical step is to divide ownership across the teams and groups. Here are a few important things we considered:
- Vertical ownership → Provide teams with end-to-end ownership of a specific product area.
- Group ownership → Logically group teams under the groups
- Reduce dependency management → Of course, some teams will depend on one another, but our goal is to see if there is a way to reduce dependencies through ownership mapping.
Once this is defined, teams align themselves with the company strategy, take on the prioritized problems to solve, and then develop their roadmap.
There are a few more pieces that make the jigsaw puzzles really fit, like discovery, planning as well as measuring success. We will dive deep into those topics in upcoming blogs. Stay tuned.
What to look forward to in our innovation @Artera blogs?
As we built the iO, we felt the need to not only create an amazing, empowered organization to build awesome products, but we also wanted to create a great culture of collaboration, passion, and thought leadership. This blog is a key ingredient and will serve as a forum for our team members to share what they are observing, learning, and doing! You’ll hear from us (Isabelle and Ashu) every so often, but you’ll regularly hear from members of the iO who have something interesting to say. When we put out our first call for topics to the iO, we got over 30+ unique submissions! We were blown away and can’t wait to get the ball rolling.
So, visit often – we’ll be posting every other week – and please share thoughts and feedback. We’d appreciate it.
Thank you for taking the time to read our inaugural blog.
The contents of this post as well as the opinions expressed herein do not contain business advice. The business information provided is for general informational and educational purposes only and is not a substitute for professional advice. Accordingly, before taking any actions based upon such information, we encourage you to consult with the appropriate professionals. THE USE OR RELIANCE OF ANY INFORMATION CONTAINED IN THIS POST IS SOLELY AT YOUR OWN RISK.
Creating a Culture of Continuous Learning and Improvement in Software Engineering
5 focus areas to build a culture where learning and improvement is prioritized.