Tag: management

Rules of Effective Recruiting

The proverbial needle in a haystack…

I’ve frequently been asked variations of the  question: “How does one hire the right people?”  While I by no means have a perfect record in this area, over time I’ve developed some heuristics that allow me to generally recruit good people (or at least avoid not so good people).  

Rule 1: Hire for the Future

The typical hiring process resembles detective work, with the central focus being a deep forensic dive into what a person has done in the past.  In the end, one is left with a bucketful of self-reported “facts” and a gut feeling over whether the person might be a good fit. This is a lousy way to recruit.

Why?  Simple – you’re looking in the wrong direction.  When recruiting you should be trying to uncover what the person will do for you in the future, not what they’ve done in the past.

That isn’t to say that the past has no relevance.  One should use past performance and experience as a rough indicator of potential future performance, but only if past performance can be truly known.  Most of the time you only have the candidate’s word and whatever you can read between the lines on the resume. (Ironically this plays into the hands of people who have learned to interview well but are otherwise incompetent.  Beware – there’s more of them than you might think.)

So focus on the future.  How? By asking the candidate to think and solve problems.  As information workers this is what we do every day, so you should see how they do it.  Give them case studies and assess how they approach the problem. Observe how they deal with ambiguity (another thing we deal with every day).  Get a feel for their analytical skills. See how they deal with challenges thrown at them – are they confident and collaborative or do they bristle and push back.  

Some challenges I’ve used in the past for engineering candidates include:

  • Design a [insert design challenge here – usually something like an online game or other complex scenario].  Show me on a blackboard.
  • Here’s a [ insert business problem here ].  How would you go about developing a solution?  Show me on a blackboard.
  • You’re starting a company tomorrow and you head up engineering.  How will you set up your SDLC? Show me on a blackboard.
  • The system is struggling and here are the symptoms [ insert symptoms ].  How would you go about identifying and resolving the root cause? Show me on a blackboard.
  • Here’s some data representing [ insert dataset description ].  What does the data tell you about the situation? How would you solve the problem?

One amusing anecdote – I was asked to meet with a candidate for a senior engineering role.  It was mostly a courtesy interview – the team was enamored by his magnetic personality and was ready to hire him.  My job was nominally to “sell” him on our company.  But just for good measure I wanted to get a sense for his analytical ability.  As we were meeting in a lounge without any blackboards I made up an abstract question vs. a specific engineering domain question: “How would you turn over that coffee cup sitting in front of you without touching it with any part of your body?”  I thought this was a softball question – in formulating the question I’d already come up with several ideas ranging from crazy to practical.  He just stared at me.  And stared.  And stared until it was long past the point of being uncomfortable.  Eventually he said he wasn’t prepared for that kind of question and had no answer.  We didn’t hire him.  (Note: I’m not a fan of “brain teaser” interviews so this isn’t how I normally operate, but it’s telling when someone completely freezes over a simple abstract problem.)

Rule 2: Never Settle

The most expensive thing any company can do is hire unqualified or incompatible people.  Take Germany for example – you spend 3 months recruiting, another 3 months waiting for the person to end their old contract.  Then 2-3 months before you realize they may not be a good fit. Another few months of remediation before you let them go. Then another 3 months of recruiting… Your bad hiring choice basically leaves you without a person in that role for a year or more.

Never settle.  Period. Hire only people as good or better than the average person on the broader team already.  It’s way better to have an empty seat than a seat filled (or unfilled) with a problem.

Rule 3: Recruit for Talent, Not Skills

Any smart, motivated, analytical person can learn specific tools or languages.  Not everyone who knows specific tools or languages is smart, motivated or analytical.   So weight your decision heavily towards raw talent vs specific skills when hiring for a permanent team member.  This means assessing their general problem solving ability and broad understanding of core computer science concepts.  It’s fine to also look at their specific skills, but ask yourself whether gaps in any skills really should drive a “no-go” decision.   Some of the very best engineers I’ve worked with or hired knew very little about the domain or specific programming languages at the start but ramped up quickly and became superstars as a result of their raw talent.

Of course, if you need a specific skill now – knowledge of a particular software package, for example – then by all means make that required.  In that case, though, you should consider bringing on a contractor or freelancer until you have the right permanent team member ready to take on the role.

Rule 4: Key Indicators

Not all factors should be considered equal when evaluating a candidate.  Being human, we overweight “personality,” “self-confidence” and other soft attributes.  These may be important but often weak indicators of future performance and team fit. You need to be intentional about down-weighting those factors and staying focussed on the critically important attributes.  These include:

  • Accountability.  People who lack accountability and ownership will fail.  My experience is that low ownership correlates almost 100% with a bad outcome.  Avoid these people like the plague. How do you gauge accountability? Ask questions about projects or other initiatives that didn’t go so well and see if they take some of the responsibility.  Ask what they’d do in the future to get a different outcome and listen for whether they share responsibility for the improvements. Role play with a difficult challenge that has plenty of excuses and see if they take the excuse.  Be creative. 
  • Problem solving.  Creative analytical abilities are the foundation of any problem solver, and problem solving is what we do.  To do this you just need to observe them solving problems. Put them on a blackboard and give them open-ended questions.   
  • Integrity.  If you can’t trust them 100% then you definitely don’t want them on the team.  This is tough since only truly incompetent people will obviously lie to you, but you can ask questions about their resume and drill down a bit in areas where you have expertise to see if they represent themselves accurately.  You can ask questions multiple times with subtle variations to see if the answer changes. You can always verify references or facts listed in the resume. 
  • “Fire in the Belly”.  You want people who will show up on day 1 and apply themselves 100%.  This is sometimes tough to discover in interviews so is often something you have to assess early in the on boarding.
  • Respect/Arrogance.  Will they treat their teammates with respect or will they lord their excellence over everyone?  You don’t want them on your team if the latter. No one likes working with assholes. Most likely they’ll defer to you, the hiring manager, but watch how they interact with the receptionist when they arrive, waitstaff when you take them to lunch, or anyone else not involved in the process.  You can also get a glimpse of this if you challenge them hard during an analytical exercise and see how they respond under pressure. 

These five (and I’m sure there are more) are strong “fail” signals.  If the person is lacking any of these attributes it’s highly likely they’ll fail as a colleague.  

The inverse, however, is not necessarily true.   Someone who possesses these attributes may not be a great team member, but at least they have a good head start.  So use these as a filter gate.

Rule 5: Group Think

So, who decides if a candidate is right for the team?  One common approach is to have a hiring manager make the call.  It’s simple. It empowers the hiring manager. But in the end it’s a bad idea.

Why?  For several reasons, but I’ll focus on two.  First, we all suffer from biases. We tend to overweight certain attributes (e.g. those most like us) and we each have our pet peeves.  We also see what we see in the frame of our past experience. All of this together means we’re susceptible to making the hiring decision on the wrong factors.

Second, the reality is that we’re hiring for the company as much as we’re hiring for a specific team.  Engineers move teams all the time, whether for their own career growth or because the mission changes. You need people who are not only a good fit for their team but for the organization as a whole.

You can solve both problems by not going it alone.  Get several people involved including people from outside the team.  Group interviews are fine to save time, but make sure each interviewer has specific things they’re looking for.  At the end of the interview cycle take a confidence vote – I’d argue that you want unanimous agreement on a 4 or better out of 5 else you should probably pass on the candidate.  

Accelerated Velocity: Clarifying Processes and Key Roles

Note: this article is part 7 of a series called Accelerated Velocity.  This part can be read stand-alone, but I recommend that you read the earlier parts so as to have the overall context.

In a previous article I argued that great people are needed in order to get great results. To be clear, this theorem is asymmetric: great people don’t guarantee great results. Far from it – the history of sports, business and military is littered with the carcasses of “dream teams” that miserably underperformed.

No, there are several factors that need to be in place for teams to excel. The ability to take independent action, discussed in the previous article, is one of those factors. I’ll discuss others over the next few articles, starting here with clarity around processes and roles.

Even the best people have trouble reaching full potential if they don’t know what’s expected of them. True, some people are capable of jumping in and defining their own roles, but this is rare. Most will become increasingly frustrated, not knowing on any given day what’s expected of them and what they need to do to succeed.

People in teams also need to understand the conventions for how best to work with others. How they plan, collaborate, communicate status, and manage issues all play a part in defining how effective the team is. Too much, too little, or too wrong, and a high potential team will find itself hobbled.

The same applies to teams and teams-of-teams. Teams need clarity about their role within the larger organization. They also need common processes to facilitate working together in pursuit of common goals.

Popular software development methodologies provide the foundation for role and process clarity, with the “agile” family of methodologies being the de-facto norm. These frameworks typically come with default role definitions (e.g. scrum master, product owner) as well as best practices around processes and communications. When applied correctly they can be powerful force multipliers for teams, but adopting agile is not a trivial exercise.  In addition, these frameworks only cover a portion of the clarity that’s needed.

Bonial’s Evolution

Bonial in 2014 was maturing as an agile development shop, but there were gaps in role definitions, team processes, and inter-team collaboration that suppressed the team’s potential. Fortunately Bonial has always had an abundance of kaizen – restlessness and a desire to always improve – so people were hungry to change. No-one was particularly happy with the status quo and there was a high willingness to invest in making things better.

We rolled up our sleeves and got started…

We attacked this challenge along multiple vectors. First, we needed a process methodology that would not only guide teams but also provide tools for inter-team coordination and portfolio management. The product and engineering leadership teams chose the Scaled Agile Framework (SAFe) as as over-arching team, program and portfolio management methodology. It was not the perfect framework for Bonial but it was good enough to start with and addressed many of the most pressing challenges.

Second, we spent time more clearly defining the various agile roles and moving responsibilities to the right people. We started with the very basics as broken down in the following table:

Area of ResponsibilityRole Name (Stream / Team)Notes
What?Product Manager, Product Owner Ensures the the team is “Doing the right things”
Who and When?Engineering Manager, Team Lead Ensures that the team is healthy and “Doing things right” while minimizing time to market
How?Architect, Lead Developer Ensures that the team has architectural context and runway and is managing tech debt  

We created general role definitions for each position, purposely leaving space and flexibility for the people and teams to adapt as appropriate.  (I know many agile purists will feel their blood pressure going up after reading the table above, but I’m not a purist and this simplicity was effective in getting things started.) 

A quick side note here. One of the unintended consequences of any role definition is that they tend to create boxes around people. They become contracts where responsibilities not explicitly included are forbidden and the listed responsibilities become precious territory to guard and protect. I hate this, so I emphasized strongly that (a) role definitions are guidelines, not hard rules, and (b) the responsibility for mission success lies with the entire team, so it’s ok to be flexible so long as everything gets done.

Third, we augmented the team. We hired an experienced SAFe practitioner to lead our core value streams, organize and conduct training at all levels, and consult on best practices from team level scrum to enterprise level portfolio management. This was crucial; the classroom is a great place to get started, but it’s the day-to-day practice and reinforcement that makes you a pro.

Finally, we placed a lot of emphasis on retrospectives and flexibility. We learned and continually improved. We tried things, keeping those that succeeded and dropping those that failed. Over time, we evolved a methodology and framework that fit our size, culture and mission, eventually driving the massive increases in velocity and productivity that we see today.

Team Leads

There was one more big role definition gap that was causing a lot of confusion and that we needed to close: who takes care of the teams? While agile methodologies do a good job of defining the roles needed to get agile projects done, they don’t define roles needed to grow and run a healthy organization. For example, scrum has little to say regarding who hires, nurtures, mentors, and otherwise manages teams. Those functions are critical and need a clear home.

In Bonial engineering, we put these responsibilities on the “team lead” role. This role remains one of the most challenging, important and rewarding roles in Bonial’s engineering organization and includes the following responsibilities:

  • People
    • Recruiting
    • Personal development
    • Compensation administration
    • Morale and welfare
    • General management (e.g. vacation approvals)
    • Mentoring, counseling and, if needed, firing
  • Process
    • Effective lean practices
    • Efficient horizontal and vertical communications
    • Close collaboration with product owner (PO)
  • Technology
    • Architectural fitness (with support from the architecture team)
    • Operational SLAs and support (e.g. “On call”)
    • “Leading by example” – rolling up sleeves and helping out when appropriate
  • Delivery
    • Accountable for meeting OKRs
    • Responsible for efficient spend and cost tracking

That’s an imposing list of responsibilities, especially for a first-time manager. We’d be fools to thrust someone into this role with no support, so we start with an apprenticeship program – where possible, first time leads shadow a more experienced lead for several months, only taking on individual responsibilities when they’re ready. We also train new leads in the fundamentals of leadership, management and agile, and each lead has active and engaged support from their manager and HR. Finally, we give them room to both succeed, fail and learn.

So far this model has worked well. People tend to be nervous when first stepping into the role, but over time become more comfortable and thrive in their new responsibilities. The teams also appreciate this model. In fact, one of the downsides has been that it’s difficult to recruit into this role since it contains elements of traditional scrum master, team manager and engineering expert – a combination that is rare in the market. As such, we almost always promote into the role.

Closing Thoughts

In the end we know that no one methodology (or even a mashup of methodologies) will satisfy every contingency. To that end there are two important principles underpinning how we operate: flexibility and ownership. If something needs to be done, do it. Its great if the person who is assigned a given role does a full and perfect job, but in the end success is everyone’s responsibility, so it’s not an excuse if they can’t or won’t do it.

Some closing thoughts:
• People need to understand their roles and the expectations put on them to be most effective.
• Teams need to have a unifying process to facilitate collaboration and avoid chaos and waste.
• The overarching goal is team success; all members of the team should have that as their core role description.
• Flexibility is key. Methodologies are a means to an end, not the ends themselves.

Accelerated Velocity: Building Leaders

Note: this article is part 2 of a series called Accelerated Velocity.  This part can be read stand-alone, but I recommend that you read the earlier parts so as to have the overall context.

Positive changes require a guiding hand.  Sometimes this arises organically from a group of like-minded people, but far more often there’s a motivated individual driving the change.  In short – a leader.

Here’s the rub: the tech industry is notoriously deficient in developing leaders. Too often the first step in a leader’s journey starts when their manager leaves and they’re blessed with a dubious promotion… “Congratulations, you’rein charge now.  Good luck.”  If they’re fortunate their new boss is an experienced leader and has time to mentor them.  In a larger organization they may have access to some bland corporate training on how to host a meeting or write a project plan.  But the vast majority of people thrust into leadership and management roles in tech are largely left to their own devices to succeed.

Let me pause for a moment and highlight a subtle but important point: leadership and management are different skills.  Leadership is creating a vision and inspiring a group of people to go after the vision; management is organizing, equipping, and caring for people as well as taking care of the myriad details needed for the group to be successful.  There’s some overlap, and an effective leader or manager has competence in both areas, but they require different tools and a different mindset. This article is focussed on the leadership component.

So what does it take to develop competent and confident leaders?  When I look at some of the best-in-class “leadership-centric organizations” – militaries and large consulting companies for example – I see the following common elements:

  1. Heavy up-front investment in training
  2. High expectations of the leaders
  3. An reasonably structured environment in which to learn and grow
  4. A continuous cycle in which role models will coach and mentor the next generation

How did this look at Bonial?

Upon arriving I inherited a 40-ish strong engineering organization broken up into five teams, each headed by a “team lead.” The problem was that these team leads had no clear mandate or role, little or no leadership and management training, and essentially no power to carry out a mandate even if they’d had one.

This setup was intended to keep the organization flat and centralize the administrative burden of managing people so as to allow the team leads to focus on delivery. Unfortunately this put the leads in a largely figurehead role – they represented their teams and were somehow responsible for performance but had few tools to employ and little experience with which to effectively deploy them. They didn’t hire their people, administer compensation or manage any budgets. In fact, they couldn’t even approve vacations.  To this day it’s not clear to me, or them, what authority or responsibility they had.

This arrangement also created a massive chokepoint at the center of the organization – no major decisions were made without approval from “above”. The results were demoralized leads and frustrated teams.

Changing this dynamic was my first priority.  To scale our organization we’d need to operate as a federation of semi-autonomous teams, not as a traditional hierarchical organization.  For this we needed leads who could drive the changes we’d make over the coming years, but this would require a major shift in mindset.  After all, if I couldn’t trust them to approve vacations, why should I trust them with driving ROI from the millions of euros we’d be investing in their teams?  Engineers have the potential to produce incredibly valuable solutions; ensuring they have solid leadership is the first and most important responsibility of senior management.

We started with establishing a clear scope of responsibility and building our toolbox of skills.  I asked the leads if they were willing to “own” the team results and, though a little nervous, most were willing.  This meant they would now make the calls as to who was on the team and how those people were managed. They took over recruiting and compensation administration. They played a much stronger role in ensuring the teams had clarity on their mission and how the teams executed the mission. They received budgets for training, team events and discretionary purchases. And, yes, they even took responsibility for approving vacations.

We agreed to align around the leader-leader model espoused by David Marquet (https://www.davidmarquet.com/) in his book “Turn the Ship Around!”  We read the book together and discussed the principles and how to apply them in daily practice.  The phrase “I intend to…” was baked into our vocabulary and mentality.  We eliminated top-down systems and learned to specify goals, not methods.  We focussed on achieving excellence, not just avoiding errors.  The list goes on.

I also started a “leadership roundtable” – 30 minutes each week where we’d meet in a small group and discuss experiences and best practices around core leadership and management topics: motivating people and teams, being effective, basic psychology, communicating, coaching and mentoring, discipline, recruiting, personal organizational skills, etc.  Over time, dozens of people – ranging from prospective team leads to product managers to people simply interested in leadership and management – participated in the roundtables, giving us a common foundation from which to work.

As I’ll share in a future article, we also created a career growth model that fully supported a management track as well as a technical track and, most importantly, the possibility to move back and forth freely between the two.  We encouraged people to give management a try and offered mentoring and support plus the risk-free option of being able to switch back to their former role if they preferred.  In the early days this was a tough sell – “team lead” had the reputation of being mostly pain with little upside.  Never-the-less a few brave souls gave it a shot and, to their surprise, found it rewarding (and have since grown into fantastic leads).

It wasn’t easy – we had a fair share of mistakes, failures and redos – but the positive effects were felt almost immediately. Over time this first generation of leads grew their teams and created cultures of continuous improvement. As the teams grew, the original leads mentored new leaders to take over the new teams and the cycle continued. As it stands today we have a dozen or so teams/squads led by capable leaders that started as software engineers, quality assurance pros, system engineers, etc. 

For what it’s worth, I believe the number one factor driving Bonial’s accelerated velocity was growth in leadership maturity. If you’re looking to engineer positive change, start here.

Some closing thoughts:

  • Positive change requires strong leadership.
  • A single leader can start the change process, but large-scale and enduring change requires distributed leadership (e.g. ”leader-leader”).
  • Formal training can be a great source of leadership and management tools, but mastering those tools requires time, a safe and constructive environment and active coaching and mentoring.
  • Growing a leadership team is not a linear or a smooth process.  The person driving and guiding the development must commit to the long game and must be willing to accept accountability for inconsistent results from first generation leads as they learn their trade.

Read part 3: Building Great Teams

How we Plan at Bonial (part 2: control)

blue angels - extreme control
Blue Angels – extreme control

As you read in the previous post, we shed some light on what we were (and weren’t) doing with some simple Clarity mechanisms with regards to planning our software development.  Now we needed to make sure everyone knew who should be doing what – a.k.a. Control. 

We started with a new roadmap governance process.  We knew that if we wanted to scale the organization we had to fundamentally rationalize the “roadmap committee”.  To that end we developed the following decision flow chart:

Bonial’s first update to roadmap governance

Though it appears complex, it’s built around a single principle: push as many decisions to the teams as possible.  The “roadmap committee” would be responsible for major strategy and funding decisions and for monitoring progress; the teams would execute under the broad guidance from the committee.  

This shift to distributed control was fundamental to our later growth and success but the truth is that it took the better part of a year until we “got it right-ish”.  It was an iterative process of building trust on all sides – management had to trust the teams to make good decisions, the teams had to trust management to provide clear guidance and hold to it, and the stakeholders had to trust both.  But it was worth it.  

Most importantly, the teams began to “own” their mission which changed everything. 

The Roadmap Committee has long since been replaced with other more focussed and lighter-weight mechanisms, but the principles still hold true – executive management sets the goals, allocates resources and provides experience and mentoring; the teams decide how to achieve the goals and execute.  We continue to explore different organizations and alignments to optimize our software development and delivery and we assume we’ll continue to experiment as we grow and our missions changes.

Another major step we took that impacted both control and clarity was to align our teams into Value Streams.  In our effort to improve how we applied Lean and Agile principles at the team and group levels, we decided to adopt best principles from the Scaled Agile Framework (SAFe) for software development at the enterprise level.  SAFe teams are built around “Programs” or “Value Streams” that allowed teams to focus on a specific portion of the mission and operate as independently as possible.  We deviated quite a bit from pure SAFe and formed three streams around our user facing efforts, our business systems and our operations initiatives.  Never-the-less the benefits were immediate as we reduced “prioritization hell” which is what I call the often fruitless act of trying to compare a revenue generating topic with, for example, a cost savings or security topic. 

Key takeaway: it’s impossible to both scale and maintain central control.  Effective scaling requires creating semi-autonomous, fully-capable teams organized to be relatively independent and provided with the clarity needed to tackle their mission.  This can be a tough step, especially in organizations with a long history of central control, but it’s a step that must be taken.  (FWIW I’ve seen the opposite and it’s not pretty.)

So now we knew what we were doing and who should be doing what.  We were getting a lot closer, but we had one more big step…

How we Plan at Bonial (part 2: clarity)

Clarity

How do you go about fixing something that requires you to change almost everything you do?  As described in part 1, this was the situation we faced at Bonial in late 2014 when it came to the governance and execution of our product development roadmap.  

Rather than re-inventing the wheel, we took advantage of proven play books – one for organization change and one for enterprise agile.  On the organizational side, we knew that the “top down, centralized control” model was already strained and would not scale.  So we leveraged elements from the (fantastic) book “Turn this Ship Around!” by Capt. David Marquett, which describes one organization’s journey from a top-down leadership structure to a “leader-leader” structure with distributed ownership and control.  Bonial would have to undergo a similar transformation – we needed everyone to be engaged and feeling ownership if we were to realize rapid transformation and scale. 

In the book, the author presents a couple dozen excellent leadership mechanisms and groups them under three high-level categories – Clarity, Control, and Competence.  In the interest of brevity, I’ll describe just a few of the things we did to improve in these categories.  (I’ll also break them up over several posts.)

Starting with clarity, we began with the simplest exercise possible: we documented all of the work-in-progress on one list.  Absurdly basic yet profound.  We created the first draft by literally going from team to team and asking them what projects were in progress and putting them in a Google Sheet.  (Why this format?  Because normalizing and adapting the existing tracking tools (Jira, Trello) would have taken far too long and wasted the team’s time and energy.  Also, Google Sheets allow for simultaneous editing which is critical for collaboration.)  To make this relevant for business stakeholders, we then dropped the small “story” and “task” level items and broke down the “saga” level items so that the resulting list was at a meaningful “epic” or “project” level.

Here’s a snap of an archived copy of the first version:

Screenshot of first Bonial Roadmap on Google Sheets

This exercise had several immediate impacts.  First, it showed our stakeholders that the engineering team was actually working on a quite a few projects and began to restore some confidence in the product development function.  Second, it shed light on all the projects and prompted a number of valid and constructive questions as to priorities and business justifications for the projects.  This in turn led directly to our decision to do more formal and intentional planning: we wanted to ensure that our engineering resources were “doing the right things,” not just “doing things right.”

Over time this simple Google Sheet has grown to be the primary tool for viewing and communicating the current quarter’s roadmap development.  We populate the sheet with the output of each quarter’s planning exercise (more on that to follow).  Twice a week we review the status of all items (red, yellow, green) and discuss as a team what we can do to adjust if needed.  The same spreadsheet is publicly available to all stakeholders for full transparency.  We’ve considered several times moving to more sophisticated (and expensive) tools but each time we decided that the Google Sheets does everything we need.

Key takeaway: it’s hard to plan if you don’t know what you’re already doing.  Take the time to get clarity on what’s happening, tune it to the right granularity, and ensure there’s full transparency.

In the next post I’ll talk about how we approach mechanisms for control. 

How We Plan at Bonial (Part 1: the early days)

Today is the first day of our quarterly planning ritual here at Bonial.  As I write this the teams are huddled away passionately discussing, digesting, challenging, and estimating their candidate work items.  We have over a hundred people from 25 different countries and multiple offices working through dozens of epics.  By tomorrow we’ll have a solid plan agreed upon by the engineers, designers, testers, data scientists, operations specialists and product managers as well as their stakeholders.  

It wasn’t always like this.

When I arrived at Bonial a couple of years ago, there was no documented roadmap or cohesive prioritization process.  The planning horizon ranged from intra-day for emergencies to a couple of weeks for most other items.  No-one had a clear understanding of what we were working on and why.  The stakeholders didn’t trust engineering and everyone was unhappy.

Getting from there to here hasn’t been easy.  Over the next few posts I’ll walk you through how we got to where we are today.  

But to understand the journey we have to start at the beginning-ish…

In 2014, Bonial was a mature startup with seven or eight years under its belt.  We had a very successful mobile and web app being used in a dozen or so countries.  The product development crew was organized into four scrum teams, an ops team and a design team and was responsible for developing all of the user facing systems as well as the critical business systems.  All-in-all, there were 40-50 people working together in product development.

Unfortunately the team was less effective than it could and should have been, in large part due to lack of clarity and governance.  For starters, not only was there a lack of a coherent roadmap, there wasn’t even any clear record of what work was currently being executed.  We had tickets in Jira scattered across a dozen or more “projects,” Trello boards, stickies on blackboards, and whole lot of ideas in people’s heads, but there was no one place a stakeholder could go and get a simple answer to the question: “what is the status of my project?”

What roadmap planning was done happened in a bi-weekly session called the “roadmap committee.”  This was a group of senior managers from the extended product development organization and stakeholders who reviewed development progress and made decisions on new initiatives.  I’m being nice when I say that it wasn’t much fun.  The selection of initiatives being governed was somewhat arbitrary and the value provided by the committee was questionable.  We often hashed over the same questions over and over again.  Unfortunately it was the only vehicle in place to provide some level of two-way communications regarding roadmap and status.

The end result was that no-one was happy.  The stakeholders and customers felt like their needs were ignored and that, when their projects were accepted, delivery was too slow.  The engineers felt like they were in a blender of arbitrary and incoherent requirements over which they felt no sense of ownership.  And the product management team was stuck in the middle, working to adjust to the latest change and managing both unhappy stakeholders and engineers both.  The end result was perceived and real low performance and sense that we were set up to fail.

So we decided to change this; the solution would require a great deal of work in many areas across the people/process/technology spectrums.  It all came together, though, in planning.  Stay tuned for part 2.